Java虚拟机垃圾回收(一) 基础：回收哪些内存/对象引用计数算法可达性分析算法 finalize()方法 HotSpot实现分析

刺骨的言语ヽ痛彻心扉 2022-07-13 08:41 137阅读 0赞

**Java虚拟机垃圾回收(一) 基础 **

**回收哪些内存/对象 引用计数算法 可达性分析算法 finalize()方法 HotSpot实现分析**

>        
> 
> 
>       在《[Java内存区域 JVM运行时数据区][Java_ JVM]》中了解到各数据区有些什么特点、以及相关参数的调整，知道了：**程序计数器、虚拟机栈、本地方法栈这3个区域是随线程而生而灭的，内存分配和回收都具备确定性，而Java堆和方法区则不一样，各线程共享，在运行时内存的分配与回收都是动态的，垃圾收集器所关注的是这部分内存**。

>        接下来几篇文章我们来详细了解Java堆和方法区的内存分配与回收，下面先来了解Java虚拟机垃圾回收的基础内容：如何判断对象是存活还是已经死亡？ 介绍相关的垃圾回收基础算法：引用计数算法、可达性分析算法，以及说明finalize()方法作用，最后再来说说HotSpot虚拟机中实现对象可达性分析的一些问题。

## **1、Java虚拟机垃圾回收** ##

>        垃圾回收，或称垃圾收集（Garbage Collection，GC）是指自动管理回收不再被引用的内存数据。
> 
>        在1960年诞生于MIT的Lisp语言首次使用了动态内存分配和垃圾收集技术，可以实现垃圾回收的一个基本要求是语言是类型安全的，现在使用的包括Java、Perl、ML等。

### **1-1、为什么需要了解垃圾回收** ###

>        目前内存的动态分配与内存回收技术已经相当成熟，但为什么还需要去了解内存分配与GC呢？
> 
> >        1、当需要排查各种内存溢出、内存泄漏问题时；
> > 
> >        2、当垃圾收集成为系统达到更高并发量的瓶颈时；
> 
>        我们就需要对这些"自动化"技术实话必要的监控和调节；  
>

### **1-2、垃圾回收需要了解什么** ###

>        思考GC完成的3件事：
> 
> > **        1、哪些内存需要回收？即如何判断对象已经死亡；**
> > 
> > **        2、什么时候回收？即GC发生在什么时候？需要了解GC策略，与垃圾回收器实现有关；**
> > 
> > **        3、如何回收？即需要了解垃圾回收算法，及算法的实现--垃圾回收器；**
> 
>       第一点就是本文下面的主题，这是垃圾回收的基础，如：可达性分析算法是后面垃圾回收算法的基础，而判断哪些对象可以回收是垃圾回收的首要任务。

## **2、判断对象可以回收** ##

>        垃圾收集器对堆进行回收前，首先要确定堆中的对象哪些还"存活"，哪些已经"死去"；
> 
>        下面先来了解两种判断对象不再被引用的算法，再来谈谈对象的引用，最后来看如何真正宣告一个对象死亡。

### **2-1、引用计数算法（Recference Counting）** ###

> **1、算法基本思路**
> 
>        给对象添加一个引用计数器，每当有一个地方引用它，计数器加1；
> 
>        当引用失效，计数器值减1；
> 
>        任何时刻计数器值为0，则认为对象是不再被使用的；    
> 
> **2、优点**
> 
>       实现简单，判定高效，可以很好解决大部分场景的问题，也有一些著名的应用案例；
> 
> **3、缺点**
> 
> > （A）、很难解决对象之间相互循环引用的问题
> 
> >        如：
> > 
> > >     ReferenceCountingGC objA = new ReferenceCountingGC();
> > >     ReferenceCountingGC objB = new ReferenceCountingGC();
> > >     objA.instance = objB;
> > >     objB.instance = objA;
> > >     objA = null;
> > >     objB = null;
> > 
> >        当两个对象不再被访问时，因为相互引用对方，导致引用计数不为0；
> > 
> >        更复杂的循环数据结构，如图（《编译原理》7-18）：

![20170102213856592][]

> > （B）、并且开销较大，频繁且大量的引用变化，带来大量的额外运算；
> 
>       主流的JVM都没有选用引用计数算法来管理内存；

### **2-2、可达性分析算法（Reachability Analysis）** ###

>       也称为传递跟踪算法；  
> 
> 
> **      主流的调用程序语言（Java、C\#等）在主流的实现中，都是通过可达性分析来判定对象是否存活的。**  
> 
> 
> **1、算法基本思路**
> 
>       通过一系列"GC Roots"对象作为起始点，开始向下搜索；
> 
>       搜索所走过和路径称为引用链（Reference Chain）；
> 
>       当一个对象到GC Roots没有任何引用链相连时（从GC Roots到这个对象不可达），则证明该对象是不可用的；

![20170102213857043][]

> **2、GC Roots对象**
> 
>       Java中，GC Roots对象包括：
> 
> >       （1）、虚拟机栈（栈帧中本地变量表）中引用的对象；
> > 
> >       （2）、方法区中类静态属性引用的对象；
> > 
> >       （3）、方法区中常量引用的对象；
> > 
> >       （4）、本地方法栈中JNI（Native方法）引用的对象；
> 
>       主要在执行上下文中和全局性的引用；

> **3、优点**
> 
>       更加精确和严谨，可以分析出循环数据结构相互引用的情况；
> 
> **4、缺点**
> 
>       实现比较复杂；
> 
>       需要分析大量数据，消耗大量时间；
> 
>       分析过程需要GC停顿（引用关系不能发生变化），即**停顿所有Java执行线程**（称为**"Stop The World"，是垃圾回收重点关注的问题**）；
> 
> 后面会针对HotSpot虚拟机实现的可达性分析算法进行介绍，看看是它**如何解决这些缺点的**。

### **2-3、再谈对象引用** ###

>       在《[Java对象在Java虚拟机中的引用访问方式][Java_Java]》曾详细介绍过对象的引用问题，这与对象回收算法有很大关系，下面再来了解下。
> 
>       java程序通过reference类型数据操作堆上的具体对象；
> 
> **1、JVM层面的引用**
> 
>       reference类型是引用类型（Reference Types）的一种；
> 
>       JVM规范规定reference类型来表示对某个对象的引用，可以想象成类似于一个指向对象的指针；
> 
>       对象的操作、传递和检查都通过引用它的reference类型的数据进行操作；
> 
> **2、Java语言层面的引用**
> 
> > **（i）、JDK1.2前的引用定义**
> > 
> >       如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用；
> > 
> >       这种定义太过狭隘，无法描述更多信息；
> > 
> > **（ii）、JDK1.2后，对引用概念进行了扩充，将引用分为：**
> > 
> > > > （1）、强引用（Strong Reference）
> > > > 
> > > >       程序代码普遍存在的，类似"Object obj=new Object()"；
> > > > 
> > > >       只要强引用还存在，GC永远不会回收被引用的对象；
> > > > 
> > > > （2）、软引用（Soft Reference）
> > > > 
> > > >       用来描述还有用但并非必需的对象；
> > > > 
> > > >       直到内存空间不够时（抛出OutOfMemoryError之前），才会被垃圾回收；
> > > > 
> > > >       最常用于实现对内存敏感的缓存；
> > > > 
> > > >       SoftReference类实现；
> > > > 
> > > > （3）、弱引用（Weak Reference）
> > > > 
> > > >       用来描述非必需对象；
> > > > 
> > > >       只能生存到下一次垃圾回收之前，无论内存是否足够；
> > > > 
> > > >        WeakReference类实现；
> > > > 
> > > > （4）、虚引用（Phantom Reference）
> > > > 
> > > >       也称为幽灵引用或幻影引用；
> > > > 
> > > >       完全不会对其生存时间构成影响；
> > > > 
> > > >       唯一目的就是能在这个对象被回收时收到一个系统通知；
> > > > 
> > > >       PhantomRenference类实现；                
> > 
> >       更多请参考JDK相关API说明；

>       对于软引用，可以使用命令行选项"-XX：SoftRefLRUPolicyMSPerMB = <N>"来控制清除速率；
> 
>       更多请参考：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html\#sthref65][http_docs.oracle.com_javase_8_docs_technotes_guides_vm_gctuning_considerations.html_sthref65]

### **2-4、判断对象生存还是死亡** ###

>       要真正宣告一个对象死亡，至少要经历两次标记过程。
> 
> **1、第一次标记**
> 
>       在可达性分析后发现到GC Roots没有任何引用链相连时，被第一次标记；
> 
>       并且进行一次筛选：此对象是否必要执行finalize()方法；
> 
> > **（A）、没有必要执行**
> > 
> >       没有必要执行的情况：
> > 
> > >       （1）、对象没有覆盖finalize()方法；
> > > 
> > >       （2）、finalize()方法已经被JVM调用过；
> > 
> >       这两种情况就**可以认为对象已死**，可以回收；
> > 
> > **（B）、有必要执行**
> > 
> >       对有必要执行finalize()方法的对象，被放入F-Queue队列中；
> > 
> >       稍后在JVM自动建立、低优先级的Finalizer线程（可能多个线程）中触发这个方法；
> 
> **2、第二次标记**
> 
>       GC将对F-Queue队列中的对象进行第二次小规模标记；

>       finalize()方法是对象逃脱死亡的最后一次机会：
> 
> >       （A）、如果对象在其finalize()方法中重新与引用链上任何一个对象建立关联，第二次标记时会将其移出"即将回收"的集合；
> > 
> >       （B）、如果对象没有，也可以认为对象已死，可以回收了；                    
> 
>       一个对象的finalize()方法只会被系统自动调用一次，经过finalize()方法逃脱死亡的对象，第二次不会再调用；

### **2-5、finalize()方法** ###

>       上面已经说到finalize()方法与垃圾回收第二次标记相关，下面了解下**在Java语言层面有哪些需要注意的**。
> 
>       finalize()是Object类的一个方法，是Java刚诞生时为了使C/C++程序员容易接受它所做出的一个妥协，但不要当作类似C/C++的析构函数；
> 
>       因为它执行的时间不确定，甚至是否被执行也不确定（Java程序的不正常退出），而且运行代价高昂，无法保证各个对象的调用顺序（甚至有不同线程中调用）；
> 
>       如果需要"释放资源"，可以定义显式的终止方法，并在"try-catch-finally"的finally\{\}块中保证及时调用，如File相关类的close()方法；
> 
>       此外，finalize()方法主要有两种用途：
> 
> > **1、充当"安全网"**
> > 
> >       当显式的终止方法没有调用时，在finalize()方法中发现后发出警告；
> > 
> >       但要考虑是否值得付出这样的代价；
> > 
> >       如FileInputStream、FileOutputStream、Timer和Connection类中都有这种应用；
> > 
> > **2、与对象的本地对等体有关**
> > 
> >       本地对等体：普通对象调用本地方法（JNI）委托的本地对象；
> > 
> >       本地对等体不会被GC回收；
> > 
> >       如果本地对等体不拥有关键资源，finalize()方法里可以回收它（如C/C++中malloc()，需要调用free()）；
> > 
> >       如果有关键资源，必须显式的终止方法；
> 
> **      一般情况下，应尽量避免使用它，甚至可以忘掉它。**
> 
> 更多请参考：
> 
>       《How to Handle Java Finalization's Memory-Retention Issues》：[http://www.devx.com/Java/Article/30192][http_www.devx.com_Java_Article_30192]
> 
>       《Effective Java》第二版 第2章 第7条：避免使用终结方法；
> 
>       《Thinking in Java》第四版 5.5 清理：终结处理和垃圾回收；
> 
>       《Java语言规范》12.6 类实例的终结；

## **3、HotSpot虚拟机中对象可达性分析的实现** ##

>       前面对可达性分析算法进行介绍，并看到了它在判断对象存活与死亡的作用，下面看看是HotSpot虚拟机是如何实现可达性分析算法，**如何解决相关缺点的。**

### **3-1、可达性分析的问题** ###

> **1、消耗大量时间**
> 
>       从前面可达性分析知道，GC Roots主要在全局性的引用（常量或静态属性）和执行上下文中（栈帧中的本地变量表）；
> 
>       要在这些大量的数据中，逐个检查引用，会消耗很多时间；
> 
> **2、GC停顿**
> 
>       可达性分析期间需要保证整个执行系统的一致性，对象的引用关系不能发生变化；
> 
> **      导致GC进行时必须停顿所有Java执行线程**（称为**"Stop The World"**）；
> 
>       （几乎不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的）
> 
> **      Stop The World：**
> 
> >       是JVM在后台自动发起和自动完成的；
> > 
> >       在用户不可见的情况下，把用户正常的工作线程全部停掉；

### **3-2、枚举根节点** ###

>       枚举根节点也就是查找GC Roots；
> 
>       目前主流JVM都是准确式GC，可以直接得知哪些地方存放着对象引用，所以执行系统停顿下来后，并不需要全部、逐个检查完全局性的和执行上下文中的引用位置；
> 
>             
> 
>       在HotSpot中，是使用一组称为OopMap的数据结构来达到这个目的的；
> 
> >       在类加载时，计算对象内什么偏移量上是什么类型的数据；
> > 
> >       在JIT编译时，也会记录栈和寄存器中的哪些位置是引用；
> > 
> >       这样GC扫描时就可以直接得知这些信息；

### **3-3、安全点** ###

> **1、安全点是什么，为什么需要安全点**
> 
>       HotSpot在OopMap的帮助下可以快速且准确的完成GC Roots枚举，但是这有一个问题：        
> 
> >       运行中，非常多的指令都会导致引用关系变化；
> > 
> >       如果为这些指令都生成对应的OopMap，需要的空间成本太高；
> 
>       问题解决：
> 
> > **      只在特定的位置记录OopMap引用关系**，这些位置称为**安全点（Safepoint）**；
> > 
> >       即程序执行时并非所有地方都能停顿下来开始GC；
> 
> **2、安全点的选定**
> 
>       不能太少，否则GC等待时间太长；也不能太多，否则GC过于频繁，增大运行时负荷；
> 
>       所以，基本上是以程序"是否具有让程序长时间执行的特征"为标准选定；
> 
>       "长时间执行"最明显的特征就是指令序列复用，如：方法调用、循环跳转、循环的末尾、异常跳转等；
> 
>       只有具有这些功能的指令才会产生Safepoint；

> **3、如何在安全点上停顿**
> 
>       对于Safepoint，如何在GC发生时让所有线程（不包括JNI线程）运行到其所在最近的Safepoint上再停顿下来？
> 
>       主要有两种方案可选：
> 
> > **（A）、抢先式中断（Preemptive Suspension）**
> > 
> >       不需要线程主动配合，实现如下：
> > 
> > >       （1）、在GC发生时，首先中断所有线程；
> > > 
> > >       （2）、如果发现不在Safepoint上的线程，就恢复让其运行到Safepoint上；
> > 
> > **      现在几乎没有JVM实现采用这种方式；**
> > 
> > **（B）、主动式中断（Voluntary Suspension）**
> > 
> >       （1）、在GC发生时，不直接操作线程中断，而是仅简单设置一个标志；
> > 
> >       （2）、让各线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起；
> > 
> >       而轮询标志的地方和Safepoint是重合的；    
> > 
> >       在JIT执行方式下：test指令是HotSpot生成的轮询指令；
> > 
> >       一条test汇编指令便完成Safepoint轮询和触发线程中断；

### **3-4、安全区域** ###

> **1、为什么需要安全区域**
> 
>       对于上面的Safepoint还有一个问题：
> 
> >       程序不执行时没有CPU时间（Sleep或Blocked状态），无法运行到Safepoint上再中断挂起；    
> 
>       这就需要安全区域来解决；
> 
> **2、什么是安全区域（Safe Region）**
> 
>       指一段代码片段中，引用关系不会发生变化；
> 
>       在这个区域中的任意地方开始GC都是安全的；
> 
> **3、如何用安全区域解决问题**
> 
>       安全区域解决问题的思路：
> 
> >       （1）、线程执行进入Safe Region，首先标识自己已经进入Safe Region；
> > 
> >       （2）、线程被唤醒离开Safe Region时，其需要检查系统是否已经完成根节点枚举（或整个GC）；
> 
> > >       如果已经完成，就继续执行；
> > > 
> > >       否则必须等待，直到收到可以安全离开Safe Region的信号通知；    
> > > 
> > > 这样就不会影响标记结果；
> 
>       虽然HotSpot虚拟机中采用了这些方法来解决对象可达性分析的问题，但只是大大减少了这些问题影响，**并不能完全解决，如GC停顿"Stop The World"是垃圾回收重点关注的问题，后面介绍垃圾回收器时应注意：低GC停顿是其一个关注。**
> 
>

> **      到这里，我们大体了解Java虚拟机垃圾回收的一些基础内容，后面我们将分别去了解JVM垃圾收集算法、垃圾收集器、以及相关调优方法……**

【参考资料】

1、《编译原理》第二版 第7章

2、《深入理解Java虚拟机：JVM高级特性与最佳实践》第二版 第3章

3、《The Java Virtual Machine Specification》Java SE 8 Edition：[https://docs.oracle.com/javase/specs/jvms/se8/html/index.html][https_docs.oracle.com_javase_specs_jvms_se8_html_index.html]

4、《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html][http_docs.oracle.com_javase_8_docs_technotes_guides_vm_gctuning_index.html]

5、《Memory Management in the Java HotSpot™ Virtual Machine》：[http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf][http_www.oracle.com_technetwork_java_javase_tech_memorymanagement-whitepaper-1-150020.pdf]

6、HotSpot虚拟机参数官方说明：[http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html][http_docs.oracle.com_javase_8_docs_technotes_tools_unix_java.html]

7、《Thinking in Java》第四版 5.5 清理：终结处理和垃圾回收；

8、《Java语言规范》12.6 类实例的终结；

9、《Effective Java》第二版 第2章 第7条：避免使用终结方法；

[Java_ JVM]: http://blog.csdn.net/tjiyu/article/details/53915869
[20170102213856592]: /images/20220713/e286581ebef84c27aaf7886897a166ad.png
[20170102213857043]: /images/20220713/93abb164b5e74f1a971a2c5558c387e2.png
[Java_Java]: http://blog.csdn.net/tjiyu/article/details/53932199
[http_docs.oracle.com_javase_8_docs_technotes_guides_vm_gctuning_considerations.html_sthref65]: http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html%23sthref65
[http_www.devx.com_Java_Article_30192]: http://www.devx.com/Java/Article/30192
[https_docs.oracle.com_javase_specs_jvms_se8_html_index.html]: https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
[http_docs.oracle.com_javase_8_docs_technotes_guides_vm_gctuning_index.html]: http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html
[http_www.oracle.com_technetwork_java_javase_tech_memorymanagement-whitepaper-1-150020.pdf]: http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
[http_docs.oracle.com_javase_8_docs_technotes_tools_unix_java.html]: http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html