Java垃圾回收小結

垃圾回收是Java最大的特點之一,由于垃圾回收是java虛擬機自動進行,在代碼開發(fā)中不用去管理垃圾什么時候回收。而且現(xiàn)在集群部署及機器物理內(nèi)存可擴增,內(nèi)存問題在很多開發(fā)場景都被忽略,都是讓Java虛擬機自己管理。

怎么確定一個對象可以被回收

最主要的兩個垃圾回收算法就是引用計數(shù)跟蹤搜索算法,引用計數(shù)算法就是給對象添加一個計數(shù)器,當被引用時就加1,引用失效時就減1,在任何情況下都為0時,該對象就可以被回收;但這種算法難以解決對象環(huán)狀循環(huán)引用的問題。

跟蹤搜索算法在《深入理解Java虛擬機》書中定義為:通過一系列命名為“GC Root”的節(jié)點向下搜索,當一個對象到“GC Root”節(jié)點沒有任何引用,即到“GC Root”節(jié)點不可達,則該對象就可以被回收。

"GC Root”節(jié)點定義
  1. 虛擬機棧(棧幀中的本地變量表)中的引用的對象。
  2. 方法區(qū)中的類靜態(tài)屬性引用的對象。
  3. 方法區(qū)中的常量引用的對象。
  4. 本地方法棧中JNI(即一般說的Native方法)的引用的對象。

垃圾回收方式

標記清除算法(Mark-Sweep)

顧名思義,先將需要回收的對象進行一一標記,完成之后進行統(tǒng)一的回收。這是最基本垃圾回收算法,但是在最初標記的時候以及清除垃圾的時候效率都不高,并且在清除后以前被占用的內(nèi)存就變成了不連續(xù)的內(nèi)存碎片,在存放大對象時很可以為因為連續(xù)的內(nèi)存不夠而引發(fā)Full GC。

復制算法

復制算法為了解決效率,將內(nèi)存劃分為相同的兩快,每次存放時只存放一邊,內(nèi)存滿了之后就將存貨的復制到另一邊,然后對剩下的進行垃圾清理,每次回收時只用移動對象內(nèi)存指針,按照順序分配,且不用考慮內(nèi)存碎片的問題,簡單高效?,F(xiàn)在的分代收集算法中新生代基本就是按照這種算法實現(xiàn)。但對存放時間長的對象,每次就要進行多次復制,而且還需要額外的空間擔保,所以并不適用于老年代。

標記整理算法

與標記清楚算法前部分一樣,在清理對象時,將存活的對象移動并按順序排列,完成后將存貨對象界限意外的刪除,這種多用于老年代收集。

分代收集算法

將內(nèi)存根據(jù)對象不同的生命周期劃分為幾塊,一般分為新生代、老年代、持久區(qū)等,然后每個分區(qū)選擇當前最合適的垃圾回收算法。

垃圾回收測試

在單元測試的run configuration 中添加:

 -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+PrintGCTimeStamps 

意思是運行的初始和最大內(nèi)存為jvm20m,新生代使用10m。-XX:SurvivorRatio=8 表示新生代中eden和survivor的比例,由于survivor是同時存在2個,所以為8:1:1,-XX:+PrintGCDetails打印GC日志, -XX:+PrintGCTimeStamps 打印時間

測試代碼

public class JavaOOMError {  
  
    private static  byte[] bts = null;  
  
  
    public static void init(){  
        bts = new byte[3 * 1024 * 1024];  
    }  
  
    public static void main(String[] args) {  
      
        init();  
      
        byte[] bts1 = new byte[1 * 1024 * 1024];  
        System.out.println("-----" + 1);  
        byte[] bts2 = new byte[2 * 1024 * 1024];  
        System.out.println("-----" + 2);  
        byte[] bts3 = new byte[3 * 1024 * 1024];  
        System.out.println("-----" + 3);  
        byte[] bts4 = new byte[4 * 1024 * 1024];  
        System.out.println("-----" + 4);  
        byte[] bts5 = new byte[5 * 1024 * 1024];  
        System.out.println("-----" + 5);  
    }  
}  

運行結果

-----1  
-----2  
0.644: [GC (Allocation Failure) 0.645: [DefNew: 6807K->482K(9216K), 0.0102920 secs] 6807K->6626K(19456K), 0.0109738 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]   
-----3  
-----4  
0.658: [GC (Allocation Failure) 0.658: [DefNew: 7812K->7812K(9216K), 0.0000349 secs]0.658: [Tenured: 6144K->9216K(10240K), 0.0090041 secs] 13956K->13793K(19456K), [Metaspace: 1636K->1636K(4480K)], 0.0095951 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]   
0.667: [Full GC (Allocation Failure) 0.667: [Tenured: 9216K->9216K(10240K), 0.0030476 secs] 13793K->13782K(19456K), [Metaspace: 1636K->1636K(4480K)], 0.0031219 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]   
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space  
at com.test.gc.JavaOOMError.main(JavaOOMError.java:51)  
Heap  
def new generation   total 9216K, used 4893K [0x03e00000, 0x04800000, 0x04800000)  
eden space 8192K,  59% used [0x03e00000, 0x042c7458, 0x04600000)  
from space 1024K,   0% used [0x04700000, 0x04700000, 0x04800000)  
to   space 1024K,   0% used [0x04600000, 0x04600000, 0x04700000)  
tenured generation   total 10240K, used 9216K [0x04800000, 0x05200000, 0x05200000)  
the space 10240K,  90% used [0x04800000, 0x05100090, 0x05100200, 0x05200000)  
Metaspace       used 1654K, capacity 2242K, committed 2368K, reserved 4480K  
  1. 在打印3前新生代執(zhí)行一次Minor GC,由于初始化的靜態(tài)變量占了3M,后面用new 了1和2 共3M對象,所以第三次執(zhí)行新生代剩余的不足2M,后面的在new一個3M大對象無法存放時,就會執(zhí)行一次垃圾會后,回收后新生代空間 6807K->482K(9216K),之前的6m就被放到老年代(之所以不能被清除,是因為所有的對象根據(jù)跟蹤搜索算法還存在);

  2. 在3和4被執(zhí)行后,執(zhí)行5時,由于此時5的需要的空間為5M,新生代已被占用7M,空間不足,會執(zhí)行垃圾回收,執(zhí)行minor GC后,將3放到老年代中 Tenured: 6144K->9216K(10240K) ,但是新生代發(fā)現(xiàn)內(nèi)存還是不夠,執(zhí)行Full GC,最后還是沒有可連續(xù)的5M內(nèi)存空間,就只能報OutOfMemoryError: Java heap space異常。

  3. 從上面可以看出,java垃圾回收的一個具體信息,在上面代碼中,如果添加bts4 = null;再次執(zhí)行

添加位置如下

    System.out.println("-----" + 4);  
    bts4 = null;  
    byte[] bts5 = new byte[5 * 1024 * 1024]; 

運行結果:

    -----1  
    -----2  
    0.757: [GC (Allocation Failure) 0.758: [DefNew: 6807K->482K(9216K), 0.0059942 secs] 6807K->6626K(19456K), 0.0066999 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]   
    -----3  
    -----4  
    0.765: [GC (Allocation Failure) 0.765: [DefNew: 7812K->7812K(9216K), 0.0000312 secs]0.765: [Tenured: 6144K->9697K(10240K), 0.0050508 secs] 13956K->9697K(19456K), [Metaspace: 1636K->1636K(4480K)], 0.0051905 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]   
    -----5  
    Heap  
    def new generation   total 9216K, used 5446K [0x03e00000, 0x04800000, 0x04800000)  
    eden space 8192K,  66% used [0x03e00000, 0x04351af0, 0x04600000)  
    from space 1024K,   0% used [0x04700000, 0x04700000, 0x04800000)  
    to   space 1024K,   0% used [0x04600000, 0x04600000, 0x04700000)  
    tenured generation   total 10240K, used 9697K [0x04800000, 0x05200000, 0x05200000)  
    the space 10240K,  94% used [0x04800000, 0x05178440, 0x05178600, 0x05200000)  
    Metaspace       used 1640K, capacity 2242K, committed 2368K, reserved 4480K 

此次執(zhí)行并沒有報出異常,主要在放入4后,執(zhí)行5時,內(nèi)存不夠執(zhí)行垃圾回收,由于此時4已經(jīng)屬于不存活對象,被回收掉,3轉(zhuǎn)到了老年代;此時新生代的空間足夠放入5,所以并不會執(zhí)行Full GC。

最后編輯于
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容