【深入浅出JVM】——垃圾回收机制

曾经终败给现在 2022-05-17 02:59 234阅读 0赞

# 哪些内存需要回收？ #

JVM的内存结构包括五大区域:程序计数器，虚拟机栈，本地方法栈，堆区，方法区。其中程序计数器，虚拟机栈，本地方法栈随线程而生，随线程而灭，所以这几个区域的内存分配和回收都是具备确定性，不需要过多考虑回收的问题，因为方法结束或线程结束时，内存自然就跟随着回收 。堆区存放的是对象实例，也是GC回收的主要区域。  
主要回收废弃常量和无用的类  
判断废弃常量；没有地方再引用即为废弃常量  
无用的类：该类的所有实例都被回收，在Java堆中不存在无用的类  
加载类的ClassLoader已经被回收  
该类对应的java.lang.class对象没有在任何地方被引用，无法在任何地方通过反射方位该类的方法  
满足上述条件可以进行类回收，但是不代表必然会被回收，在HotSpot虚拟机配置了-Xnoclassgc参数。

--------------------

# 判断对象是否存活 #

两种方式  
1、引用计数算法  
每多一个地方应用，则在计数器上加1，少一个应用，计数器减1，当计数器为0时，则对象不可能再被使用。实现简单，执行效率高，可以交织在程序中运行。  
缺点：如果对象之间出现循环引用，那么涉及到的对象将永远都不会被销毁。  
2、可达性分析算法  
通过一系列的GC Roots对象作为起始点，从这些节点向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连，判断可进行回收对象了。  
**GC Roots主要包含如下**  
虚拟机栈中引用的对象  
方法区中类静态属性引用的对象  
方法区中常量引用的对象  
本地方法栈中JNI引用的对象

--------------------

# 四种引用类型 #

**1、强引用**  
代码中Object obj = new Object(),只要强引用存在，一定不会被回收  
**2、软引用**  
有用但是不必需，SoftReference类实现软引用。如果虚拟机堆内存足够，则不会被回收，但内存空间不够，则会被回收  
使用场景  
    例如博客系统，为了提升访问性能，当用户在点击博文时，如果文章没有被缓存在内存中，则需要缓存，否则直接在内存中读取，降低响应时间。可以通过数据库级别的缓存做到这点，但是也能通过软引用来实现。将文章用软引用实现，如果空间足够，则利用缓存来提升性能，如果内存空间不够，可以释放内存，满足系统的需求。  
**3、弱引用WeakReference**  
弱引用 比软引用更弱，只能存活到下次GC之前  
**4、虚引用**  
    虚引用无论是否存在虚引用，不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。设置虚引用的目的让这个对象在被收集器回收时收到一个系统通知。拥有虚引用的对象可以在任何时候被垃圾回收器回收。

--------------------

# 垃圾回收算法 #

1、标记-清除算法Mark-Sweep  
将需要被回收的内存进行标记，然后清除标记的内容。  
问题：效率低，标记和清除的效率低；会产生大量不连续的内存碎片  
2、复制算法-Copying  
将可用内存容量划分为两个相同大小的块，每次只是用其中一块。当一块内存用完了，就将存活的对象复制到另一块上面，把已经用使用过的内存空间清理掉。  
实现简单，效率高，但是有一半的内存空间被浪费。  
一般用于新生代在HotSpot虚拟机默认Eden和survivor为8:1  
3、标记-整理算法Mark-Compact  
与标记清除算法一样，但是让存活的对象向一端移动，直接清理掉端边界的内存。  
一般用于老年代，先标记后移动  
4、分代收集算法  
根据对象存活生命周期的不同，将内存划分为几块，每块采用不同的垃圾回收算法。

--------------------

# 垃圾收集器 #

**新生代**  
1、serial收集器  
单线程收集器，只会使用一个cpu或一条收集线程去完成垃圾收集工作，而且在垃圾收集的时候必须暂停所有的工作线程知道收集结束，即stop the world。  
在实际中，它依旧是虚拟机运行在client模式下默认的新生代收集器。相比其他收集器：简单而高效，对于限定单个CPU来说，Serial收集器由于没有线程相互开销，专心做垃圾回收。  
2、parNew收集器  
就是serial的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与serial一致。目前是运行在Server模式下的虚拟机首选新生代收集器，因为除了Serial只有它能与CMS配合工作。但是在单CPU不会有比Serial更好的收集效果。parNew在默认情况下开启的收集线程数与CPU的数量相同，但是可以通过使用-XX:ParallelGCThreads参数来限制。  
3、parallel Scavenge收集器  
新生代收集器，采用复制算法，多线程，注重吞吐量，吞吐量优先的收集器，具有自适应调节能力  
需配置参数-XX：UseAdaptiveSizePolicy，就可以进行自适应。  
**老年代**  
1、serial-old收集器  
标记-整理算法，serial的老年代版本，在jdk1.5以及之前的版本配合parallel scavenge收集器搭配使用。作为cms收集器的后备预案  
2、paralle-old  
标记-整理，在jdk1.6中开始提供，适用于注重吞吐量以及CPU资源敏感的场合。  
3、CMS  
标记-清除算法，获取最短回收停顿时间为目标的收集器  
GC过程短暂停，适合对时延要求较高的服务，用户线程不允许长时间的停顿  
**回收流程分为4步骤**

> 1、初始标记  
> 只标记GC Roots可以直接关联到的对象，stop the world，速度非常快  
> 2、并发标记  
> 发生在GC Tracing的过程中（追踪的过程中）  
> 3、重新标记  
> 修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，stop the world  
> 4、并发清除  
> 耗时比较长的阶段为并发标记和并发清除

**CMS的缺点**

> 1、CMS对CPU敏感，会占用cpu资源导致程序变慢，默认启动的回收线程数是（cpu数量+3）/5，如果cpu个数过少，会导致程序更慢。  
> 2、CMS无法处理浮动垃圾，可能Concurrent mode failure失败，导致另一GC  
> 1.6中cms默认当老年代使用92%进行，可以通过配置-XX:CMSInitiatingOccupancyFraction的值来修改，如果设定过高，会导致大量Concurrent mode failure，会到临时启用Serial Old 性能反而下降。  
> 3、标记-清除算法，会产生大量碎片，如果无法找到足够连续空间来分配当前对象，会提前触发Full GC。为了解决，配置-XX：+UseMSCompactAtFullCollection开关参数，默认开启，用于在进行FullGC的时候开启内存碎片的合并整理过程，通过配置参数-XX：CMSFullGCsBeforeCompaction，用于设置执行多少次不压缩FullGC后，跟着来一次带压缩的。

4、G1收集器  
面向服务端应用的垃圾收集器，采用标记-整理算法，目标替换CMS。  
特点：  
1、并行与并发  
2、分代收集  
3、空间整合，标记-整理算法  
4、可预测停顿。  
**运行步骤**  
1、初始标记 stop the world  
2、并发标记  
3、最终标记stop the world  
4、筛选回收 stop the world  
优点：利用多cpu，多核环境下的硬件优势，缩短stop the world时间

--------------------

# 内存回收流程 #

JVMHeap区和方法区结构图  
![这里写图片描述][70]  
**Heap区GC流程**  
1、新创建的对象会先进入Eden区（如果对象过大也会直接进入Old区）。  
2、GC之前对象存在Eden和From区，进行GC的时候Eden中的对象被拷贝到To这样一个survive空间(包括from和to，它们两个空间大小一致，又称为s1和s2)中，From中的对象GC幸存一定的次数（每次GC之后这个对象依旧存在，GC一次Age就加1，默认15）后进入Old区，除此之外还有一种额外的可能性，进行GC的时候会对survive中的对象进行判断，Survive空间中存在一些对象Age一样，而且年龄相同的这一部分空间占用大于Survivor，这组对象就会进入Old区。当Eden复制到To区的时候，To空间不足够的时候也会直接进入到Old区。  
3、进入To区或Old区之后，Eden和From中无效的对象就会通过MinorGC进行回收。  
4、当Old区的空间占满后，就会进行Full GC。  
**方法区GC流程**  
类的实例对象全部被GC了，同时它的类加载也被GC了，那么方法区中对象将会进行GC。  
**一般引发Full GC的原因主要有**  
from survive中对象的生命周期到一定的阈值  
分配的对象都是大对象  
To 空间的不够，进行GC直接把对象拷贝的Old区。  
**注意：**  
如果Young Generation大小分配不合理或空间比较小，这个时候导致对象很容易进入Old Generation中，而Old Generation中回收具体对象的时候速度是远远低于Young Generation回收速度。  
因此实际分配要考虑年老代和新生代的比例，考虑Eden和survives的比例  
Permanent Generation中发生GC的时候也对性能影响非常大，也是Full GC

推荐博客JVM相关博客:  
[https://blog.csdn.net/aijiudu/article/details/72991993][https_blog.csdn.net_aijiudu_article_details_72991993]  
[https://www.cnblogs.com/1024Community/p/honery.html][https_www.cnblogs.com_1024Community_p_honery.html]

[70]: /images/20220517/8c13f15ecfbe4ec1b70f4aa87d5be58c.png
[https_blog.csdn.net_aijiudu_article_details_72991993]: https://blog.csdn.net/aijiudu/article/details/72991993
[https_www.cnblogs.com_1024Community_p_honery.html]: https://www.cnblogs.com/1024Community/p/honery.html