JVM 判断对象已死，实践验证GC回收

经过了风风雨雨，看过了男男女女。时间经过的岁月就没有永恒不变的！
在这趟车上有人下、有人上，外在别人给你点评的标签、留下的烙印，都只是这趟车上的故事。只有个人成长了、积累了、沉淀了，才有机会当自己的司机。
可能某个年龄段的你还看不懂，但如果某天你不那么忙了，要思考思考自己的路、自己的脚步。看看这些是不是你想要的，如果都是你想要的，为什么你看起来不开心？
好！加油，走向你想成为的自己！
没有看到实际的例子，往往就很难让理科生接受这类知识。我自己也一样，最好是让我看得见。代码是对数学逻辑的具体实现，没有实现过程源码交易只看答案是没有意义的。
「测试代码」
public class ReferenceCountingGC {

public Object instance = null;
private static final int _1MB = 1024 * 1024;
/**
 * 这个成员属性的唯一意义就是占点内存， 以便能在GC日志中看清楚是否有回收过
 */
private byte[] bigSize = new byte[2 * _1MB];

public static void main(String[] args) {
    testGC();
}

public static void testGC() {
    ReferenceCountingGC objA = new ReferenceCountingGC();
    ReferenceCountingGC objB = new ReferenceCountingGC();
    objA.instance = objB;
    objB.instance = objA;
    objA = null;
    objB = null;
    // 假设在这行发生GC， objA和objB是否能被回收？
    System.gc();
}

}
例子来自于《深入理解Java虚拟机》中引用计数算法章节。
例子要说明的结果是，相互引用下却已经置为null的两个对象，是否会被GC回收。如果只是按照引用计数器算法来看，那么这两个对象的计数标识不会为0，也就不能被回收。但到底有没有被回收呢？
这里我们先采用 jvm 工具指令，jstat来监控。因为监控的过程需要我手敲代码，比较耗时，所以我们在调用testGC()前，睡眠会 Thread.sleep(55000);。启动代码后执行如下指令。
E:\itstack\git\github.com\interview>jps -l
10656
88464
38372 org.itstack.interview.ReferenceCountingGC
26552 sun.tools.jps.Jps
110056 org.jetbrains.jps.cmdline.Launcher

E:\itstack\git\github.com\interview>jstat -gc 38372 2000
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 1288.0 65536.0 0.0 175104.0 8.0 4864.0 3982.6 512.0 440.5 1 0.003 1 0.000 0.003
10752.0 10752.0 0.0 0.0 65536.0 437.3 175104.0 1125.5 4864.0 3982.6 512.0 440.5 1 0.003 1 0.012 0.015
10752.0 10752.0 0.0 0.0 65536.0 437.3 175104.0 1125.5 4864.0 3982.6 512.0 440.5 1 0.003 1 0.012 0.015
S0C、S1C，第一个和第二个幸存区大小
S0U、S1U，第一个和第二个幸存区使用大小
EC、EU，伊甸园的大小和使用
OC、OU，老年代的大小和使用
MC、MU，方法区的大小和使用
CCSC、CCSU，压缩类空间大小和使用
YGC、YGCT，年轻代垃圾回收次数和耗时
FGC、FGCT，老年代垃圾回收次数和耗时
GCT，垃圾回收总耗时
「注意」：观察后面三行，S1U = 1288.0、GCT = 0.003，说明已经在执行垃圾回收。
接下来，我们再换种方式测试。在启动的程序中，加入GC打印参数，观察GC变化结果。
-XX:+PrintGCDetails 打印每次gc的回收情况 程序运行结束后打印堆空间内存信息(包含内存溢出的情况)
-XX:+PrintHeapAtGC 打印每次gc前后的内存情况
-XX:+PrintGCTimeStamps 打印每次gc的间隔的时间戳 full gc为每次对新生代老年代以及整个空间做统一的回收 系统中应该尽量避免
-XX:+TraceClassLoading 打印类加载情况
-XX:+PrintClassHistogram 打印每个类的实例的内存占用情况
-Xloggc:/Users/xiaofuge/Desktop/logs/log.log 配合上面的使用将上面的日志打印到指定文件
-XX：HeapDumpOnOutOfMemoryError 发生内存溢出将堆信息转存起来 以便分析
这回就可以把睡眠去掉了，并添加参数 -XX:+PrintGCDetails
[GC (System.gc()) [PSYoungGen: 9346K->936K(76288K)] 9346K->944K(251392K), 0.0008518 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 936K->0K(76288K)] [ParOldGen: 8K->764K(175104K)] 944K->764K(251392K), [Metaspace: 3405K->3405K(1056768K)], 0.0040034 secs] [Times: user=0.08 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 76288K, used 1966K [0x000000076b500000, 0x0000000770a00000, 0x00000007c0000000)
eden space 65536K, 3% used [0x000000076b500000,0x000000076b6eb9e0,0x000000076f500000)
from space 10752K, 0% used [0x000000076f500000,0x000000076f500000,0x000000076ff80000)
to space 10752K, 0% used [0x000000076ff80000,0x000000076ff80000,0x0000000770a00000)
ParOldGen total 175104K, used 764K [0x00000006c1e00000, 0x00000006cc900000, 0x000000076b500000)
object space 175104K, 0% used [0x00000006c1e00000,0x00000006c1ebf100,0x00000006cc900000)
Metaspace used 3449K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 376K, capacity 388K, committed 512K, reserved 1048576K
从运行结果可以看出内存回收日志，Full GC 进行了回收。
也可以看出JVM并不是依赖引用计数器的方式，判断对象是否存活。 否则他们就不会被回收啦
「有了这个例子，我们再接着看看JVM垃圾回收的知识框架！」
四、JVM 垃圾回收知识框架
垃圾收集（Garbage Collection，简称GC），最早于1960年诞生于麻省理工学院的Lisp是第一门开始使用内存动态分配和垃圾收集技术的语言。
垃圾收集器主要做的三件事：哪些内存需要回收、什么时候回收、怎么回收。
而从垃圾收集器的诞生到现在有半个世纪的发展，现在的内存动态分配和内存回收技术已经非常成熟，一切看起来都进入了“自动化”。但在某些时候还是需要我们去监测在高并发的场景下，是否有内存溢出、泄漏、GC时间过程等问题。所以在了解和知晓垃圾收集的相关知识对于高级程序员的成长就非常重要。
垃圾收集器的核心知识项主要包括：判断对象是否存活、垃圾收集算法、各类垃圾收集器以及垃圾回收过程。

标签：垃圾,0.0,10752.0,已死,GC,回收,JVM,0.000
来源： https://blog.csdn.net/AYANGGG12/article/details/113358247