java - 垃圾回收

Question

爲什麼方法調用System.gc()不能保證垃圾回收算法會在那一刻運行？爲什麼它無法回收所有未使用的對象的內存，只要它被調用？

Answer 1

1. 強制對象銷燬是錯誤編碼的標誌，因此Java可能希望避免開發人員沉迷於其中。
2. 如果Java允許您自由強制破壞對象，則不當使用它可能會對應用程序性能產生不利影響。
3. 這個限制允許你（強迫你）把更多的精力到業務邏輯比內存managemnt
4. JVM是當需要的內存管理，以及如何做決定的最佳人選。
5. 您可以（應該）信任JVM，讓它以比我們更好的方式處理事情。
6. 你還真的想強迫物體破壞嗎？如果是，爲什麼？

Answer 2

爲了確保方案在JVM中運行平穩，JVM本身管理垃圾收集。 垃圾收集已變得相當複雜。當您詢問系統進行GC運行時，您期望使用哪種算法？一個「完整的GC」？還有很多堆，哪一個是你關心的垃圾？你不知道，這種方法不表示。

假設調用System.gc()總是觸發完整的GC。一個錯誤的程序可能會輕易將JVM性能癱瘓。在防禦方面，JVM希望限制它響應這種調用的頻率。

如果您正在非嵌入式系統（例如服務器或臺式計算機）上的JVM中運行，除了監視它和代碼之外，沒有理由關心內存管理的任何方面有效率的。

Answer 3

不能肯定回收所有未使用對象的內存時，它被調用

你的這種假設是錯誤的。在大多數情況下，垃圾收集器可能會在任何時間點收回所有未使用的對象。但是，如果標準Java庫提供了一種保證的方法，那麼它將給GC子系統帶來完全不合理的負擔，以提供大部分時間無用甚至可能造成破壞的服務。

Answer 4

但是也有一些用來評估垃圾收集器性能的幾個指標，其中一些是：

• 吞吐量的垃圾收集沒有花總時間的百分比-The，認爲在很長一段時間。
• 垃圾收集開銷 - 吞吐量的倒數，即在垃圾回收中花費的總時間的百分比。
• 暫停時間 - 發生垃圾回收時應用程序執行停止的時間長度。
• 收集頻率 - 相對於應用程序執行而言，經常發生收集。
• 佔地面積 -a尺寸的度量，例如堆大小。
• 提示 - 當一個對象變成垃圾和當內存變爲 可用時之間的時間。

現在如果JVM聽System.gc()想好寵物，並保證在每個System.gc()調用執行動作，想象一下會是應用程序的性能，如果它被稱爲程序中的許多倍。!! ??

1. 吞吐量將減少
2. 垃圾收集開銷將增加。
3. 由於應用程序忙於重新收集內存，所以會暫停多次。
4. 如果佔用空間很大，垃圾收集器將不得不掃描所有內存區域以恢復內存，而不管是否存在符合垃圾收集條件的對象。

因此，通過這些點看後，我猜它提供了足夠的理由JVM上的應用程序選擇System.gc不響應，但對自己的算法。 Garbage Collection肯定會回收所有未使用的對象的內存，但其調用完全依賴於JVM自己的算法，而不是用戶的選擇。

來源：內存管理在Java的HotSpot™虛擬機 - Sun Microsystems公司