（轉）調用System.gc沒有立即執行的解決方法

 

調用System.gc沒有立即執行的解決方法

查看源碼

當我們調用System.gc()的時候，其實並不會馬上進行垃圾回收，甚至不一定會執行垃圾回收，查看系統源碼可以看到

    /**
     * Indicates to the VM that it would be a good time to run the
     * garbage collector. Note that this is a hint only. There is no guarantee
     * that the garbage collector will actually be run.
     */
    public static void gc() {
        boolean shouldRunGC;
        synchronized(lock) {
            shouldRunGC = justRanFinalization;
            if (shouldRunGC) {
                justRanFinalization = false;
            } else {
                runGC = true;
            }
        }
        if (shouldRunGC) {
            Runtime.getRuntime().gc();
        }
    }

ps：注釋

也就是justRanFinalization=true的時候才會執行 

查找發現當調用runFinalization()的時候justRanFinalization變為true 
下面是runFinalization()的源碼

/**
* Provides a hint to the VM that it would be useful to attempt
* to perform any outstanding object finalization.
*/
public static void runFinalization() {
        boolean shouldRunGC;
        synchronized(lock) {
            shouldRunGC = runGC;
            runGC = false;
        }
        if (shouldRunGC) {
            Runtime.getRuntime().gc();
        }
        Runtime.getRuntime().runFinalization();
        synchronized(lock) {
            justRanFinalization = true;
        }
}

其實當我們直接調用System.gc()只會把這次gc請求記錄下來，等到runFinalization=true的時候才會先去執行GC，runFinalization=true之后會在允許一次system.gc()。之后在call System.gc()還會重復上面的行為。
所以System.gc()要跟System.runFinalization()一起搭配使用才好。
查看ZygoteInit.java 里面 gc()和runFinalizationSync()是配合使用的，這樣才有效果

static void gcAndFinalize() {
    final VMRuntime runtime = VMRuntime.getRuntime();

    /* runFinalizationSync() lets finalizers be called in Zygote,
    * which doesn't have a HeapWorker thread.
    */
    System.gc();
    runtime.runFinalizationSync();
    System.gc();
}

解決方案

由此可見，當我們需要調用的System.gc()的時候 要這樣才會執行

System.gc();
runtime.runFinalizationSync();
System.gc();

不過個人建議不到萬不得已不要調用,因為jvm有自己的gc策略，根本不需要我們來手動

System.gc()與Runtime.gc()的區別

(1) GC是垃圾收集的意思（Gabage Collection）,內存處理是編程人員容易出現問題的地方，忘記或者錯誤的內存回收會導致程序或系統的不穩定甚至崩潰，Java提供的GC功能可以自動監測對象是否超過作用域從而達到自動回收內存的目的，Java語言沒有提供釋放已分配內存的顯示操作方法。

(2) 對於GC來說，當程序員創建對象時，GC就開始監控這個對象的地址、大小以及使用情況。通常，GC采用有向圖的方式記錄和管理堆(heap)中的所有對象。通過這種方式確定哪些對象是”可達的”，哪些對象是”不可達的”。當GC確定一些對象為”不可達”時，GC就有責任回收這些內存空間。可以。程序員可以手動執行System.gc()，通知GC運行，但是Java語言規范並不保證GC一定會執行。

(3) 垃圾回收是一種動態存儲管理技術，它自動地釋放不再被程序引用的對象，當一個對象不再被引用的時候,按照特定的垃圾收集算法來實現資源自動回收的功能。

(4) System.gc();就是呼叫java虛擬機的垃圾回收器運行回收內存的垃圾。

(5) 當不存在對一個對象的引用時，我們就假定不再需要那個對象，那個對象所占有的存儲單元可以被收回，可通過System.gc()方法回收，但一般要把不再引用的對象標志為null為佳。

(6) 每個 Java 應用程序都有一個 Runtime 類實例，使應用程序能夠與其運行的環境相連接。可以通過 getRuntime 方法獲取當前運行時。 Runtime.getRuntime().gc();

(7) java.lang.System.gc()只是java.lang.Runtime.getRuntime().gc()的簡寫，兩者的行為沒有任何不同。

(8) 唯一的區別就是System.gc()寫起來比Runtime.getRuntime().gc()簡單點. 其實基本沒什么機會用得到這個命令, 因為這個命令只是建議JVM安排GC運行, 還有可能完全被拒絕。 GC本身是會周期性的自動運行的,由JVM決定運行的時機,而且現在的版本有多種更智能的模式可以選擇,還會根據運行的機器自動去做選擇,就算真的有性能上的需求,也應該去對GC的運行機制進行微調,而不是通過使用這個命令來實現性能的優化