《深入理解Java虚拟机：JVM高级特性与最佳实践（最新第二版）》第三章（一：对象判断是否可以被回收）

左手的ㄟ右手 2021-09-23 06:10 280阅读 0赞

## 《深入理解Java虚拟机：JVM高级特性与最佳实践（最新第二版）》第三章（一：对象判断是否可以被回收） ##

### 文章目录 ###

*   *  《深入理解Java虚拟机：JVM高级特性与最佳实践（最新第二版）》第三章（一：对象判断是否可以被回收）
     *   *   *  1、判定对象是否可以被回收
             *   *  1.1、引用计数算法
                 *  1.2、可达性分析算法
                 *  1.3、再谈引用
                 *  1.4生存还是死亡
                 *  1.5、回收方法区
             *  2.垃圾收集算法
             *   *  2.1、标记-清除算法
                 *  2.2、复制算法
                 *  2.3、标记-整理算法
                 *  2.4分代收集算法
             *  3、HotSpot的算法实现
             *   *  3.1、枚举根节点
                 *  3.2、安全点
                 *  3.3、安全区域

#### 1、判定对象是否可以被回收 ####

##### 1.1、引用计数算法 #####

给对象中添加一个引用计时器，每当有一个地方引用它时，计数器就加1，当引用失效时，计数器就减1；任何时刻计数器为0的对象就是不可能再被使用的；引用计数算法（Reference Counting）的实现简单，判断效率也跟高，但是**无法解决对象见的循环引用问题**，循环引用，会导致对象无法回收。

##### 1.2、可达性分析算法 #####

在主流的商用语言（java、C\#）的主流实现中，都是称通过可达性（Reachability Analysis）分析来判断对象是否存活。这个算法的基础思路就是通过一系列的称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（GC Roots 到这个对象不可达）时，则证明此对象是不可用的。

![format_png][]

在java语言中，可作为GC Roots的对象包括下面几种：

1.  虚拟机栈（栈帧中的本地变量表）中引用的对象
2.  方法区中类静态属性引用的对象
3.  方法区中常量引用的对象
4.  本地方法栈中JNI（一般谁的Native方法）引用的对象

##### 1.3、再谈引用 #####

jdk1.2之后，java将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。

1.  强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
2.  软引用是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围中进行第二次回收，如没有这次回收还没有足够的内存，才会抛出内存溢出异常。在jdk1.2之后，提供了SoftReference类来实现软引用。
3.  弱引用也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当GC工作时候，无论内存是否足够，都会回收掉被弱引用关联的对象。jdk1.2之后，提供WeakReference类来实现弱引用。
4.  虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被GC回收时，收到一个系统通知。在jdk1.2之后，提供PhantomReference类来实现虚引用。

##### 1.4生存还是死亡 #####

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候要他们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经理两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象**没有覆盖finalize()方法**或者**finalize()方法已经被虚拟机调用过**，**虚拟机将这两种情况都视为“没有必要执行”。**

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在意个叫做F-Queue的队列之中，并在稍后由一个虚拟机自动建立的、低优先级发Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，并不承诺会等待它运行结束，如果以个对象在finalize()方法中执行缓慢，或者发生死循环，将很有可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡的最后一次机会，稍后GC将对F-Queue中的对象进行二次小规模的标记，如果对象对象要在finalize()方法中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可，例如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那么在第二次标记时它将被移除“即将回收”的集合；如果对象这个时候还没有逃脱，那基本上它就真的被回收了。

**
     * 1.对象可以在被GC时，自我拯救
     * 2.这种自我拯救的机会只有一次，因为一个对象的finalize（）方法最多只被系统自动调用一次
     * @author liqi
     *
     */
    public class FinalizeEscapeGC { 
        public static FinalizeEscapeGC SAVE_HOOK = null;
    
        public void isAlive() { 
            System.out.println("yes,i am still alive !!");
        }
    
        @Override
        protected void finalize() throws Throwable { 
            super.finalize();
            System.out.println("finalize method executed!");
            FinalizeEscapeGC.SAVE_HOOK = this;
        }
        
        public static void main(String[] args) throws Exception { 
            SAVE_HOOK = new FinalizeEscapeGC();
            //对象第一次拯救自己
            SAVE_HOOK= null;
            System.gc();
            //因为finalize方法优先级很低，所有暂停一会，等待它执行
            Thread.sleep(500);
            if(SAVE_HOOK!=null ) { 
                SAVE_HOOK.isAlive();
            }else { 
                System.out.println("no, i am dead");
            }
            //下面代码跟上面完全相同，拯救失败
            SAVE_HOOK= null;
            System.gc();
            //因为finalize方法优先级很低，所有暂停一会，等待它执行
            Thread.sleep(500);
            if(SAVE_HOOK!=null ) { 
                SAVE_HOOK.isAlive();
            }else { 
                System.out.println("no, i am dead");
            }
            
        }
    }

执行结果：

![format_png 1][]

##### 1.5、回收方法区 #####

很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区中进行垃圾收集的性价比一般比较低。

永久代的垃圾收集主要回收两部分内容：\*\*废弃常量和无用的类。\*\*回收废弃常量与回收java堆中的对象非常类似。以常量池字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象叫做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这个时候发生了GC，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

判断一个常量是否是“废弃常量”比较简单，而要判断一个类是否是“无用的类”的条件则相对苛刻很多。需要同时满足三个条件：

1.  该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
2.  加载该类的ClassLoader已经被回收。
3.  该类对应的java.lang.Class 对象没有再任何地方被引用，无法在任何地方通过反射访问该类的方法。

**HotSpot虚拟：-Xnoclassgc 参数进行控制，**

**Product版的虚拟机：-verbose:class -XX:+TraceClassLoading （查看类的加载信息）**

**FastDubug版的虚拟机：–XX:+TraceClassUnLoading（查看类的卸载信息）**

在大量使用反射，动态代理，CGLib等的ByteCode框架，动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载功能，以保证永久代不会溢出。

#### 2.垃圾收集算法 ####

##### 2.1、标记-清除算法 #####

最基础的手机算法是“标记-清除”（Mark-Sweep）算法，如同它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

不足：效率问题，标记和清除两个过程的效率都不高；

空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大的对象时，无法找到足够大的连续内存而不得不提前触发另一次垃圾收集动作。

![format_png 2][]

##### 2.2、复制算法 #####

将可用内存按照容量划分为大小相等的两块，每次只使用其中的一块。当这块的内存用完了，就将还存活着的对象复制到另外块上面，然后再把已经使用的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

不足：将内存缩小为原来的一半，每次只使用一半的内存。代价过高。

![format_png 3][]

现在的商业虚拟机都采用这种收集算法来回收新生代，新生代中的对象98%都是“朝生夕死”，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时候，当Eden和Survivor中还存活的对象一次性复制到另外一块Survivor空间上，最后清理掉Eden和刚刚使用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是说每次新生代可使用内存空间为整个新生代容量的90%；每次回收，没有办法保证存活对象都小于10%，当Survivor空间不够时候，需要依赖其他内存（老年代）进行分配担保（Handle promotion）。

不足：复制收集算法在对象存活率较高时，就要进行较多的复制操作，效率将会变低。Survivor空间不够时候，也需要额外的担保操作。

##### 2.3、标记-整理算法 #####

标记-整理（Mark-Compact）算法，标记过程和“标记-清除”算法一样，整理就是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。主要用于老年代的回收

![format_png 4][]

##### 2.4分代收集算法 #####

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象存活周期的不用将内存划分为几块。一般是把java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在**新生代中**，每次垃圾收集时都有大批对象死去，只有少量存活，就选择**复制算法**。而**老年代**对象存活高，没有额外空间对它进行分配担保，就必须使用\*\*“标记-清理”或者“标记-整理”算法\*\*来进行回收。

#### 3、HotSpot的算法实现 ####

##### 3.1、枚举根节点 #####

从可达性分析中GC Roots节点找引用链这个操作为例，可作为GC Roots的节点主要在全局性引用（例如常量或者类静态属性）与执行上下文（例如栈帧中的本地变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。

另外，可达性分析对执行时间的敏感还题现在GC停顿上，因为这项分析工作必须在意个能确保一致性的快照中进行–这里“一致性”的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。这点是导致GC进行时必须停顿所有java执行线程（Sun将这件事情称为”Stop The World“）的其中一个重要原因，即使在号称不会发生停顿的CMS收集器中，枚举根节点时也是必要停顿的。

由于目前的主流java虚拟机使用的都是准确式GC，所以当执行系统停顿后，并不需要一个不漏的检查完所有实行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象的引用。在HotSpot的实现中，是使用一组为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时候就可以直接得知这些信息了。

##### 3.2、安全点 #####

在OopMap的协助下，HotSpot可以快速准确的完成GC Roots枚举，但可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，这个GC的空间成本将会变得很高。

实际上，HotSpot也的确没有为每条指令都生成OopMap，前面也提到，只是在特定的位置记录了信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，也只有在到达安全点时才能暂停。 Safepoint的选定不能太少，让GC等待时间太长，也不能过于频繁，过分增大运行的负荷。所有，安全点的选定基本上是以程序”是否具有让程序长时间执行的特征“为标准进行选定的—因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长原因而长时间运行，”长时间执行“的特征就是指令序列复用，例如：方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safepoint。

对于Safepoint，另一个需要考虑到问题是如何在GC发生时让所有线程（这里不包括执行JNI调用的线程）都跑到最近的安全点再停顿下来，这里两种方案选择：抢先式中断（Preemptive Suspension）和主动式中断（Voluntary Suspension），其中抢先式中断不需要线程的执行代码主动配合，在GC发生时候，首先把所有线程都中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它跑到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。

而追董事中断的思想是当GC需要中断的时候，不直接对线程操作，仅仅简单的设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标记就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

##### 3.3、安全区域 #####

Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是程序没有分配到CPU时间（线程处于Sleep或者Blocked状态），就会”不执行“，这个时候线程无法响应jvm中断请求，”跑“到安全点去中断，JVM也不可能等待线程重新被分配CPU时间，这种就需要安全区域（Safe Region）来解决。

安全区域是指在一段时间片段中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的，我们也可以把Safe Region 看做是扩展的Safepoint。

在线程执行到Safe Region中的代码时候，标记自己进入Safe Region，当在这段时间jvm发起GC时，就不用管标记为Safe Region状态的线程了。在线程要离开Safe Region时，它就要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成，那线程继续执行，否则就必须等待直到收到可以离开Safe Region的信息为止。

本文内容来源于《深入理解Java虚拟机：JVM高级特性与最佳实践（最新第二版）》的读书笔记，供大家参考学习

[format_png]: /images/20210923/b79df6ef8ff044c49f33512ee64d0987.png
[format_png 1]: /images/20210923/535cf5231cd8418d88262a30cc439866.png
[format_png 2]: /images/20210923/586cfda830454e79a6fa80d89ca16b3a.png
[format_png 3]: /images/20210923/8ce47693b0d848f4af08d07b74b49b8e.png
[format_png 4]: /images/20210923/d3d76e74f9a74f87a3de5244bed3ce37.png