Java垃圾回收机制

最新推荐文章于 2024-01-22 19:06:01 发布

weixin_30477797

最新推荐文章于 2024-01-22 19:06:01 发布

阅读量92

点赞数

文章标签： java 运维数据结构与算法

原文链接：http://www.cnblogs.com/yzwall/p/6637160.html

版权

判断对象是否存活

引用计数法：

实现方式：为每个对象创建一个私有的引用计数器，当引用计数器为0时，标记为可被回收对象，
存在问题：无法解决对象之间相互引用的问题。当两个可被回收对象彼此引用时，引用计数器永远不为0，极易发生内存泄露；

可达性分析法(Reachability Analysis)/根追踪算法(GC Roots Tracing)

实现方式：通过一系列称为“GC Roots”的对象作为起始点，沿着引用链索搜索对象；当GC Roots到某个对象不可达时，证明该对象可被回收；

使用该算法后，内存中的存活对象都会和GC Roots在一个连通分量中；

当一个对象被可达性分析法判定为不可达对象后，该对象会被第一次标记，然后根据是否需要调用finalize()方法决定是否最终回收；

当对象没有重写finalize()方法或者对象的finalize()方法已被调用过（finalize()方法至多被调用一次），虚拟机判定可回收并最终回收；
当对象调用finalize()方法并在执行过程中，与引用链上的任何对象建立关联，虚拟机将其移除出“即将回收”集合；

在HotSpot中，可作为GC Roots的对象包括：

栈中引用对象（栈帧中的本地变量表）；
方法区中static成员引用的对象；
方法区中常量引用的对象；
本地方法栈中Native方法引用的对象；
与一个类对象的唯一的Class对象；

垃圾收集算法（分代收集算法）

为什么分代

分代原因：不同对象的生命周期时不一样的，因此对不同周期的对象采取对应的收集方式，提高回收效率；
不分代：如果不进行分代，每次垃圾回收都将对整个堆进行回收，花费实际较长；

分代收集算法

分带收集算法根据对象存活周期的不同将堆区内存划分为新生区，养老区和永久区，然后根据各自特点分别采用最合适GC算法，当前主流虚拟机的GC都采用分代收集算法；

	标记-清除算法	复制算法	标记-整理算法
实现	标记出全部需要回收的对象，最后统一清理所有被标记对象	将当前内存区域内的存活对象全部复杂到另一片内存区，然后请理全部内存空间	首先标记出全部需要回收的对象，然后将所剩余的所有存活对象都移动到一端，最后直接清理边界外的所有内存；指针碰撞：执行整理后，已用内存和未用内存各自一边，维护一个分界指针，当新对象分配内存时，使用指针碰撞技术将新对象分配在第一个空闲内存位置上；
不足	效率低，造成内存碎片，不利于内存分配	在对象存活率较高时，复制操作频繁，效率较低；
应用	适用于CMS收集器进行Full GC	新生区中进行Minor GC主要采用不适用于养老区GC	在标记-清除算法上改进，有效避免内存碎片适用于Serial, ParNew等收集器进行Full GC

新生区Minor GC过程

新生区内存较小，存储的对象生命周期非常短暂，因此高频率采用速度优先的复制算法进行GC

1. 执行MinorGC时，

if (存活对象分带年龄 >= MaxTenuringThreshold || To Survivor区容量达到阈值) {

Eden区和From区中的存活对象===>>>养老区

} else {

Eden区存活对象===>>>To Survivor区

From区中存活对象===>>> To Survivor区

}

2. 清理Eden和From区全部内存；
3. 执行完Minor GC后，Eden区和From Survivor区清空，所有存活对象保存在To Survivor or 养老区区中；
4. 交换From Survivor区和To Survivor区位置（保证有一块Survivor必须是空的）

养老区Full GC过程

养老区存储的对象生命周期非常长，并且养老区占据大部分堆区空间，因此养老区Full GC不采用复制算法

垃圾收集器/Garbage Collector

上图为JDK 1.7 Update14之后HotSpot中存在的收集器，两个收集器之间存在连线说明可以搭配使用；

★ STW(Stop-the-World)机制： 运行GC时，GC收集器暂停所有的工作线程，直到GC完成后才恢复之前被暂停的工作线程；

串行/并行回收方式：在GC过程中，单线程/多线程收集器采用Stop-the-World机制；
并发回收：工作线程和垃圾回收线程并发执行；

直至目前，最新的G1收集器也无法做到完全不需要Stop-the-World，因此收集器的设计目的在于程序高吞吐量，GC低延迟；

常用垃圾收集器汇总

	Serial收集器	Serial Old收集器	ParNew收集器	Parallel收集器	Parallel Old收集器	CMS收集器	G1收集器
回收方式	单线程串行回收	单线程串行回收	并行回收	并行回收	并行回收	并发回收	并发回收
工作场合	新生区	养老区	新生区	新生区	养老区	养老区	新生区，养老区
回收算法	复制算法	标记-整理算法	复制算法	复制算法	标记-整理算法	标记-清除算法	复制算法
是否STW机制	是	是	是	是	是	是	是
适用场景	单CPU宿主环境	单CPU宿主环境	多CPU宿主环境	多CPU宿主环境	多CPU宿主环境		Full GC次数频繁或消耗时间长对GC时间敏感的场合
设计目标	GC低延迟	GC低延迟	GC低延迟	控制GC频率追求程序高吞吐量	控制GC频率追求程序高吞吐量		在实现高吞吐量的同时，尽可能满足GC低暂停时间
补充说明	缺省作为HopSpot Client模式下的新生区垃圾收集器	Serial收集器的养老区版本 Serial Old收集器缺省作为HopSpot Client模式下的养老区垃圾收集器当CMS收集器发生Concurrent Mode Failure时使用	Serial收集器的多线程版本只有ParNew收集器可以与CMS收集器配合工作	与ParNew的区别在于追求程序的高吞吐量能够动态调整进行JVM的调优任务无法与CMS收集器配合工作

CMS收集器

CMS(Concurrent Mark Sweep) 收集器在JDK1.5中发布，工作在养老区，执行过程分为4步：

1. 初始标记(Initial-Mark)/ Stop-the-World

标记所有和GC Roots连通的对象，标记期间采用Stop-the-World机制（短暂暂停）；

2. 并发标记(Concurrent-Mark)

进行根追踪(GC-Roots-Tracing)，将上一阶段中的不可达对象标记为垃圾对象；标记期间，标记线程和工作线程并发执行；

3. 再次标记(Re-Mark)/ Stop-the-World

为防止并发标记阶段中被标记的垃圾对象的引用关系遭到修改，再次标记修正遭到修改的对象标记，标记期间采用Stop-the-World机制（短暂暂停）；

4. 并发清除(Concurrent-Sweep)

经过前3个标记阶段，CMS并发清除掉所有垃圾对象的内存空间；
清除期间，为保证用户线程正常工作，CMS会预留足够内存空间给用户线程，当预留内存无法满足需要，出现Concurrent Mode Failure失败，虚拟机临时启动Serial Old收集器进行GC；

CMS缺陷

产生大量内存碎片：由于CMS采用标记-清除算法，不可避免地会产生内存碎片，因此CMS分配内存空间时只能采用空闲链表法；
无法实时处理垃圾：CMS并发清除阶段，无法实时处理用户工作线程产生的新垃圾，只能等待下一次GC时清理；
对CPU资源非常敏感：并发阶段会占用CPU资源，尤其当发生Concurrent Mode Failure，调用Serial Old收集器后，延迟较大，导致程序吞吐量下降；

G1收集器(Garbage First)

分代方式

G1与其他收集器不同，没有选择在物理上隔离的新生区和养老区划分方式，而是在逻辑上划分为新生区和养老区；

G1将整个堆区划分为2048个大小相同的独立区域(Region)；
Region块大小根据堆空间的实际大小决定（控制在1MB~32MB）；
新生区和养老区不再物理隔离，都是逻辑概念，都由一部分非连续的Region组成；
- Eden Regions
- Survivor Regions
- Old generation Regions
- Humongous Regions：专门用于存放大小超过Region 50%的巨型对象；