Java虚拟机学习之垃圾回收
程序员文章站
2022-07-15 13:58:59
...
垃圾回收是Java最大的特点之一,由于垃圾回收是java虚拟机自动进行,在代码开发中不用去管理垃圾什么时候回收。而且现在集群部署及机器物理内存可扩增,内存问题在很多开发场景都被忽略,都是让Java虚拟机自己管理。
怎么确定一个对象可以被回收
最主要的两个垃圾回收算法就是引用计数和跟踪搜索算法,引用计数算法就是给对象添加一个计数器,当被引用时就加1,引用失效时就减1,在任何情况下都为0时,该对象就可以被回收;但这种算法难以解决对象环状循环引用的问题。
跟踪搜索算法在《深入理解Java虚拟机》书中定义为:通过一系列命名为“GC Root”的节点向下搜索,当一个对象到“GC Root”节点没有任何引用,即到“GC Root”节点不可达,则该对象就可以被回收。
至于"GC Root”节点定义
1、虚拟机栈(栈帧中的本地变量表)中的引用的对象。
2、方法区中的类静态属性引用的对象。
3、方法区中的常量引用的对象。
4、本地方法栈中JNI(即一般说的Native方法)的引用的对象。
垃圾回收的方法
标记清除算法(Mark-Sweep)
顾名思义,先将需要回收的对象进行一一标记,完成之后进行统一的回收。这是最基本垃圾回收算法,但是在最初标记的时候以及清除垃圾的时候效率都不高,并且在清除后以前被占用的内存就变成了不连续的内存碎片,在存放大对象时很可以为因为连续的内存不够而引发Full GC。
复制算法
复制算法为了解决效率,将内存划分为相同的两快,每次存放时只存放一边,内存满了之后就将存货的复制到另一边,然后对剩下的进行垃圾清理,每次回收时只用移动对象内存指针,按照顺序分配,且不用考虑内存碎片的问题,简单高效。现在的分代收集算法中新生代基本就是按照这种算法实现。但对存放时间长的对象,每次就要进行多次复制,而且还需要额外的空间担保,所以并不适用于老年代。
标记整理算法
与标记清楚算法前部分一样,在清理对象时,将存活的对象移动并按顺序排列,完成后将存货对象界限意外的删除,这种多用于老年代收集
。
分代收集算法,将内存根据对象不同的生命周期划分为几块,一般分为新生代、老年代、持久区等,然后每个分区选择当前最合适的垃圾回收算法。
垃圾回收
在run configuration 中添加:
意思是运行的初始和最大内存为jvm20m,新生代使用10m。-XX:SurvivorRatio=8 表示新生代中eden和survivor的比例,由于survivor是同时存在2个,所以为8:1:1,-XX:+PrintGCDetails打印GC日志, -XX:+PrintGCTimeStamps 打印时间
运行结果:
在打印3前新生代执行一次Minor GC,由于初始化的静态变量占了3M,后面用new 了1和2 共3M对象,所以第三次执行新生代剩余的不足2M,后面的在new一个3M大对象无法存放时,就会执行一次垃圾会后,回收后新生代空间 “ 6807K->482K(9216K) ”,之前的6m就被放到老年代(之所以不能被清除,是因为所有的对象都是通过New关键字出来);
在3和4被执行后,执行5时,由于此时5的需要的空间为5M,新生代已被占用7M,空间不足,会执行垃圾回收,执行minor GC后,将3放到老年代中 Tenured: 6144K->9216K(10240K) ,但是新生代发现内存还是不够,执行Full GC,最后还是没有可连续的5M内存空间,就只能报“OutOfMemoryError: Java heap space”异常。
从上面可以看出,java垃圾回收的一个具体信息,在上面代码中,如果将 bts4 = null;注释去掉,再次执行
并没有报出异常,主要在放入4后,执行5时,内存不够执行垃圾回收,由于此时4已经属于不存活对象,被回收掉,3转到了老年代;此时新生代的空间足够放入5,所以并不会执行Full GC。
怎么确定一个对象可以被回收
最主要的两个垃圾回收算法就是引用计数和跟踪搜索算法,引用计数算法就是给对象添加一个计数器,当被引用时就加1,引用失效时就减1,在任何情况下都为0时,该对象就可以被回收;但这种算法难以解决对象环状循环引用的问题。
跟踪搜索算法在《深入理解Java虚拟机》书中定义为:通过一系列命名为“GC Root”的节点向下搜索,当一个对象到“GC Root”节点没有任何引用,即到“GC Root”节点不可达,则该对象就可以被回收。
至于"GC Root”节点定义
1、虚拟机栈(栈帧中的本地变量表)中的引用的对象。
2、方法区中的类静态属性引用的对象。
3、方法区中的常量引用的对象。
4、本地方法栈中JNI(即一般说的Native方法)的引用的对象。
垃圾回收的方法
标记清除算法(Mark-Sweep)
顾名思义,先将需要回收的对象进行一一标记,完成之后进行统一的回收。这是最基本垃圾回收算法,但是在最初标记的时候以及清除垃圾的时候效率都不高,并且在清除后以前被占用的内存就变成了不连续的内存碎片,在存放大对象时很可以为因为连续的内存不够而引发Full GC。
复制算法
复制算法为了解决效率,将内存划分为相同的两快,每次存放时只存放一边,内存满了之后就将存货的复制到另一边,然后对剩下的进行垃圾清理,每次回收时只用移动对象内存指针,按照顺序分配,且不用考虑内存碎片的问题,简单高效。现在的分代收集算法中新生代基本就是按照这种算法实现。但对存放时间长的对象,每次就要进行多次复制,而且还需要额外的空间担保,所以并不适用于老年代。
标记整理算法
与标记清楚算法前部分一样,在清理对象时,将存活的对象移动并按顺序排列,完成后将存货对象界限意外的删除,这种多用于老年代收集
。
分代收集算法,将内存根据对象不同的生命周期划分为几块,一般分为新生代、老年代、持久区等,然后每个分区选择当前最合适的垃圾回收算法。
垃圾回收
在run configuration 中添加:
-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+PrintGCTimeStamps
意思是运行的初始和最大内存为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); // bts4 = null; 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
在打印3前新生代执行一次Minor GC,由于初始化的静态变量占了3M,后面用new 了1和2 共3M对象,所以第三次执行新生代剩余的不足2M,后面的在new一个3M大对象无法存放时,就会执行一次垃圾会后,回收后新生代空间 “ 6807K->482K(9216K) ”,之前的6m就被放到老年代(之所以不能被清除,是因为所有的对象都是通过New关键字出来);
在3和4被执行后,执行5时,由于此时5的需要的空间为5M,新生代已被占用7M,空间不足,会执行垃圾回收,执行minor GC后,将3放到老年代中 Tenured: 6144K->9216K(10240K) ,但是新生代发现内存还是不够,执行Full GC,最后还是没有可连续的5M内存空间,就只能报“OutOfMemoryError: Java heap space”异常。
从上面可以看出,java垃圾回收的一个具体信息,在上面代码中,如果将 bts4 = null;注释去掉,再次执行
-----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
并没有报出异常,主要在放入4后,执行5时,内存不够执行垃圾回收,由于此时4已经属于不存活对象,被回收掉,3转到了老年代;此时新生代的空间足够放入5,所以并不会执行Full GC。