JVM中怎么判断对象是否已死

这篇文章给大家介绍JVM中怎么判断对象是否已死，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

在山城等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供做网站、成都网站建设网站设计制作定制开发,公司网站建设,企业网站建设,高端网站设计,营销型网站建设,成都外贸网站建设公司,山城网站建设费用合理。

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();
    }

}

例子要说明的结果是，相互引用下却已经置为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时间过程等问题。所以在了解和知晓垃圾收集的相关知识对于高级程序员的成长就非常重要。

垃圾收集器的核心知识项主要包括：判断对象是否存活、垃圾收集算法、各类垃圾收集器以及垃圾回收过程。如下图；

原图下载链接：http://book.bugstack.cn/#s/6jJp2icA

1. 判断对象已死

1.1 引用计数器

为每一个对象添加一个引用计数器，统计指向该对象的引用次数。
当一个对象有相应的引用更新操作时，则对目标对象的引用计数器进行增减。
一旦当某个对象的引用计数器为0时，则表示此对象已经死亡，可以被垃圾回收。

从实现来看，引用计数器法（Reference Counting）虽然占用了一些额外的内存空间来进行计数，但是它的实现方案简单，判断效率高，是一个不错的算法。

也有一些比较出名的引用案例，比如：微软COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、 Python语言等。

「但是」，在主流的Java虚拟机中并没有选用引用技术算法来管理内存，主要是因为这个简单的计数方式在处理一些相互依赖、循环引用等就会非常复杂。可能会存在不再使用但又不能回收的内存，造成内存泄漏

1.2 可达性分析法

Java、C#等主流语言的内存管理子系统，都是通过可达性分析（Reachability Analysis）算法来判定对象是否存活的。

它的算法思路是通过定义一系列称为 GC Roots 根对象作为起始节点集，从这些节点出发，穷举该集合引用到的全部对象填充到该集合中（live set）。这个过程教过标记，只标记那些存活的对象好，那么现在未被标记的对象就是可以被回收的对象了。

GC Roots 包括；

全局性引用，对方法区的静态对象、常量对象的引用
执行上下文，对 Java方法栈帧中的局部对象引用、对 JNI handles 对象引用
已启动且未停止的 Java 线程

「两大问题」

误报：已死亡对象被标记为存活，垃圾收集不到。多占用一会内存，影响较小。
漏报：引用的对象（正在使用的）没有被标记为存活，被垃圾回收了。那么直接导致的就是JVM奔溃。（STW可以确保可达性分析法的准确性，避免漏报）

2. 垃圾回收算法

2.1 标记-清除算法(mark-sweep)

标记无引用的死亡对象所占据的空闲内存，并记录到空闲列表中（free list）。
当需要创建新对象时，内存管理模块会从 free list 中寻找空闲内存，分配给新建的对象。
这种清理方式其实非常简单高效，但是也有一个问题内存碎片化太严重了。
「Java 虚拟机的堆中对象」，必须是连续分布的，所以极端的情况下可能即使总剩余内存充足，但寻找连续内存分配效率低，或者严重到无法分配内存。重启汤姆猫！
在CMS中有此类算法的使用，GC暂停时间短，但存在算法缺陷。