Java GC 机制与内存分配策略详解

2017/2/20 来源:www.arpun.com 作者:小白

Java GC 机制与内存分配策略详解

收集算法是内存回收的方法论, 垃圾收集器是内存回收的具体实现

自动内存管理解决的是:给对象分配内存 以及 回收分配给对象的内存

为什么我们要了解学习 GC 与内存分配呢?

在 JVM 自动内存管理机制的帮助下, 不再需要为每一个new操作写配对的delete/free代码。 但出现内存泄漏和溢出的问题时, 如果不了解虚拟机是怎样使用内存的, 那么排查错误将是一项非常艰难的工作。

GC(垃圾收集器)在对堆进行回收前, 会先确定哪些对象“存活”, 哪些已经“死去”。 那么就有了 对象存活判定算法 。

对象存活判定算法

引用计数算法:

算法思想:给对象中添加一个引用计数器, 每当有一个地方引用它时, 计数器值加1, 当引用失效时, 计数器值减1, 任何时刻计数器为0的对象就是不可能再被使用的。

优点:实现简单, 判断效率也很高

缺点:很难解决对象之间相互循环引用的问题

可达性分析算法:

算法思想:通过一系列的“GC Roots”对象作为起始点, 从这些节点开始向下搜索, 搜索所走过的路径称为引用链, 当一个对象到 GC Roots 没有任何引用链相连时, 则证明此对象是不可用的。

如图:object5、object6、object7虽然互相有关联, 但是它们到GC Roots是不可达的, 所以它们将会被判定为是可回收的对象。

Java GC 机制与内存分配策略详解图片描述

可作为 GC Roots 的对象包括以下:

1.虚拟机栈中引用的对象

2.方法区中类静态属性引用的对象

3.方法区中常量引用的对象

4.本地方法栈中 JNI 引用的对象

生存还是死亡?

即使在可达性分析算法中不可达的对象, 也并非是“非死不可”的, 这时候他们暂时处于“缓刑”阶段, 要真正宣告一个对象死亡, 至少要经历两次标记过程:

如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链, 那它将会被第一次标记并且进行一次筛选, 筛选的条件是此对象是否有必要执行finalize()方法, 当对象没有覆盖finalize()方法, 或者finalize()方法已经被虚拟机调用过, 虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行finalize()方法, 那么这个对象将会放置在一个叫做F-Queue的队列中, 并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它, 这里所谓的“执行”是指虚拟机会触发这个方法, 但并不承诺会等待它运行结束, 这样做的原因是:如果一个对象在finalize()方法中执行缓慢, 或者发生了死循环, 将很可能会导致F-Queue队列中其他对象永久处于等待, 甚至导致整个内存回收系统的奔溃。

finalize()方法是对象逃脱死亡命运的最后一次机会, 稍后GC将对F-Queue中的对象进行第二次小规模的标记, 如果对象要在finalize()方法中成功拯救自己, 只需重新与引用链上的任何一个对象建立关联即可, 比如把自己(this关键字)赋值给某个类变量或者对象的成员变量, 那在第二次标记时它将被移除出“即将回收“的集合, 如果对象这时候还没有逃脱, 那基本上它就真的被回收了。

另外, 任何一个对象的finalize()方法都只会被系统自动调用一次。 finalize()能做的所有工作, 使用try-finally或者其他方式都可以做的更好, 更及时, 所以建议大家完全可以忘掉Java语言中有这个方法的存在。 详见《深入理解Java虚拟机》

垃圾收集算法

标记-清除算法:

算法分为“标记“和”清除“两个阶段:

首先标记出所有需要回收的对象, 在标记完成后统一回收所有被标记的对象

不足之处:

1.效率问题, 标记和清除两个过程的效率都不高。

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

复制算法:

算法实现:将可用内存按容量划分为大小相等的两块, 每次只使用其中的一块。 当这一块的内存用完了, 就将还存活着的对象复制到另一块上面, 然后再把已使用过的内存空间一次清理掉。

这样使得每次都是对整个半区进行内存回收, 内存分配时也就不用考虑内存碎片等复杂情况, 只要移动堆顶指针, 按顺序分配内存即可。 实现简单, 运行高效。 算法的代价是讲内存缩小为了原来的一半, 未免太高了点。

标记-整理算法:

算法实现:标记出所有需要回收的对象、让所有存活的对象都向一端移动。 然后直接清理掉端边界以外的内存。

分代收集算法:

算法实现:根据对象存活周期的不同将内存划分为几块, 一般是把Java堆分为新生代和老年代, 这样就可以根据各个年代的特点采用最适当的收集算法。

在新生代中, 每次垃圾收集时都发现有大批对象死去, 只有少量存活, 那就选用复制算法。 只需要付出少量存活对象的复制成本就可以完成收集。

而老年代中因为对象存活率高、没有额外空间对它进行分配担保, 就必须使用“标记-清理“或者”标记-整理“算法来进行回收。

新生代 :分为三个空间, 一个Eden空间 , 两个Survivor空间。

绝大多数最新被创建的对象会被分配到这里, 由于大部分对象在创建后会很快变得不可到达, 所以很多对象被创建在新生代, 然后消失。 对象从这个区域消失的过程我们称之为”minor GC“。

老年代 :对象没有变得不可达, 并且从新生代中存活下来, 会被拷贝到这里。 其所占用的空间要比新生代多。 也正由于其相对较大的空间, 发生在老年代上的GC要比新生代少得多。 对象从老年代中消失的过程, 我们称之为”major GC“(或者”full GC“)

绝大多数刚刚被创建的对象会存放在Eden空间。 在Eden空间执行了第一次GC之后, 存活的对象被移动到其中一个Survivor空间。 此后, 在Eden空间执行GC之后, 存活的对象会被堆积在同一个Survivor空间。 当一个Survivor空间饱和, 还在存活的对象会被移动到另一个Survivor空间。 之后会清空已经饱和的那个Survivor空间。

在以上的步骤中重复几次依然存活的对象, 就会被移动到老年代。

垃圾收集器

Java GC 机制与内存分配策略详解图片描述

如图是作用于不同分代的垃圾收集器, 如果两个收集器之间存在连线, 就可以搭配使用。 虚拟机所在的区域, 则表示它是属于新生代收集器还是老年代收集器。

学习各种垃圾收集器之前先了解下“Stop the World“。 “Stop the World“会在任何一种GC算法中发生。 “Stop the World“意味着 JVM 因为要执行GC而停止了应用程序的执行。 当“Stop the World“发生时, 除了GC所需的线程以外, 所有线程都处于等待状态, 直到GC任务完成。 GC优化很多时候就是指减少“Stop the World“发生的时间。

“Stop the World“这样理解很形象:你妈妈在给你打扫房间的时候, 肯定也会让你老老实实地在椅子上或者房间外等待着, 如果她一边打扫, 你一边乱扔纸屑, 这房间还能打扫完?

Serial收集器:单线程, 新生代收集器, 使用复制算法。 它只会使用一个CPU或一条收集线程去完成垃圾收集工作, 在进行垃圾收集时, 必须“Stop the World“, 暂停替他所有的工作线程, 直到它收集结束。

ParNew收集器:Serial收集器的多线程版本, 控制参数、收集算法、Stop the World、对象分配规则、回收策略都与Serial收集器完全一样

Parallel Scavenge收集器:生代收集器, 使用复制算法, 并行多线程。

Serial Old收集器:Serial收集器的老年代版本, 单线程, 使用标记-整理算法。

Parallel Old收集器:Parallel Scavenge收集器的老年代版本, 多线程, 使用标记-整理算法

CMS收集器:一种以获取最短回收停顿时间为目标的收集器, 基于“标记-清除”算法。 运作过程分四个步骤:初始标记 、并发标记、重新标记、并发清除。

初始标记、重新标记这两个步骤仍然需要“Stop the World”。 初始标记仅仅只是标记一下GC Roots能直接关联到的对象, 速度很快。 并发标记阶段就是进行GC Roots Tracing 的过程, 而重新标记阶段则是为了修正并发标记期间因为用户程序继续运作而导致标记产生变动的那一部分对象的标记记录, 这一阶段的停顿时间一般会比初始标记阶段稍长一些, 但远比并发标记的时间段。

整个过程中耗时最长的并发标记和并发清除过程, 收集器线程都可以与用户线程一起工作, 所以, CMS收集器的内存回收过程是与用户线程一起并发执行的。

优点:并发收集, 低停顿

缺点:对CPU资源非常敏感、无法处理浮动垃圾、基于标记清除算法, 收集结束时有大量控件碎片产生

G1收集器:G1收集器是当今收集器技术发展最前沿成果之一, 一种面向服务端应用的垃圾收集器。

G1的特点:并行与并发、分代手机、空间整合、可预测的停顿

运作过程如下:初始标记、并发标记、最终标记、筛选回收。

初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象, 并且修改TAMS的值, 让下一阶段用户程序并发运行时, 能在正确可用的Region中创建新对象, 这阶段需要停顿线程, 但耗时很短。

并发标记阶段是从GC Roots开始对堆中对象进行可达性分析, 找出存活的对象, 这阶段耗时较长, 但可与用户程序并发执行。

而最终标记阶段则是则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录, 虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面。 最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中, 这阶段需要停顿线程, 但是可并行执行。

最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序。 根据用户所期望的GC停顿时间来制定回收计划。

内存分配与回收策略

对象优先在Eden分配:大多数情况下, 对象在新生代Eden区中分配。 当Eden区没有足够空间进行分配时, 虚拟机将发起一次Minor GC。

大对象直接进入老年代:大对象是指需要大量连续内存控件的Java对象, 最典型的大对象就是那种很长的字符串以及数组。

长期存活的对象将进入老年代:虚拟机采用了分代收集的思想来管理内存, 那么内存回收时就必须能识别哪些对象应放在新生代, 哪些对象应放在老年代。 为了做到这点, 虚拟机给每个对象定义了一个对象年龄计数器。 如果对象在Eden出生并经过第一次Minor GC后仍然存活, 并且能被Survivor容纳的话, 将被移动到Survivor空间中, 并且对象年龄设为1, 对象在Survivor区中每“熬过”一次Minor GC, 年龄就增加1岁, 当它的年龄增加到一定程度(默认为15岁), 就将会被晋升到老年代。

动态对象年龄判定:虚拟机并不是永远要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代, 如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半, 年龄大于或等于该年龄的对象就可以直接进入老年代, 无须等到MaxTenuringThreshold中要求的年龄。

空间分配担保:在发生Minor GC之前, 虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间, 如果这个条件成立, 那么Minor GC可以确保是安全的。 如果不成立, 则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。

总结

内存回收与垃圾收集器在很多时候都是影响系统性能、并发能力的主要因素之一, 虚拟机之所以提供多种不同的收集器以及提供大量的调节参数, 是因为只有根据实际应用需求、实现方式选择最优的收集方式才能获取最高的性能。 没有固定收集器、参数组合, 也没有最优的调优方法, 虚拟机也就没有什么必然的内存回收行为。

以上是我学习《深入理解Java虚拟机》一书的整理笔记。

参考资料《深入理解Java虚拟机》

感谢阅读, 希望能帮助到大家, 谢谢大家对本站的支持!

网友评论
评论(...
全部评论