本文参考的是周志明的 《深入理解Java虚拟机》第三章 ,为了整理思路,简单记录一下,方便后期查阅。
在垃圾收集器进行回收前,第一件事就是确定这些对象哪些还存活,哪些已经死去。
在对象中添加一个引用计数器,每当有一个地方引用它时,计数器就加1;当引用失效时,计数器减1;其中计数器为0的对象是不可能再被使用的已死对象。
通过一系列的称为GC Roots
的对象作为起始点,从这些节点开始向下搜索,搜索所经过 的路径称为引用链(Reference Chain)
,当一个对象到GC Roots
没有任何引用链相连(在图论中称为对象不可达)时,这个对象就是不可用的。
图片来源于网络如有侵权请私信删除
在java语言中,可作为GC Roots
的对象包括:
java的引用可以分为强引用、软引用、弱引用、虚引用:
new
操作符创建的对象。只要强引用还存在,垃圾收集器就永远不会回收掉被引用的对象。
图片来源于网络如有侵权请私信删除
要真正宣告一个对象死亡,至少要经历两次标记过程:
GC Roots
相连接的引用链,会被 第一次标记 **并且进行一次筛选。筛选的条件是此对象是否有必要执行finalize()
方法(如当对象没有重写finalize()
方法或者finalize()
方法已经被虚拟机调用过**则认为没有必要执行)。
F-Queue
队列中,并在稍后由一个由虚拟机自己建立的、低优先级的Finalizer
线程去执行它;稍后GC
将对F-Queue
中的对象进行第二次标记,如果对象还是没有被引用,则会被回收。
但是作者不建议通过finalize()
方法“拯救”对象,因为它运行代价高、不确定性大、无法保证各个对象的调用顺序。
图片来源于网络如有侵权请私信删除
很多人认为方法区(HotSopt中的永久代)是没有垃圾收集的,java虚拟机规范中也没有要求需要对方法区实现垃圾收集。
永久代(方法区)的垃圾收集主要回收两部分内容:废弃常量和无用的类
“abc”
已经进入了常量池中,但是当前系统没有任何一个String对象是叫 做“abc”
的,换句话说,就是没有任何String对象引用常量池中的“abc”
常量,也没有其他 - 地方引用了这个字面量,如果这时发生内存回收,而且必要的话,这个“abc”
常量就会被系 - 统清理出常量池。
java.lang.Class
对象没有被引用)。
ClassLoader
已经被回收。java.lang.Class
对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。算法分为两个阶段:标记和清除
标记:首先标记所有需要回收的对象 清除:在标记完成后统一回收所有被标记的对象
标记过程在上文宣告一个对象死亡过程中提及
缺点
图片来源于网络如有侵权请私信删除
思路:将可用内存按容量分为两个块,每次只用其中之一。当这一块内存用完之后,将还存活的对象复制到另一边去,然后清除所有已经使用过的部分。
优点
缺点
解决方法
Eden空间
和两块较小的Survivor空间
,每次使用Eden
和其中一块Survivor
。
Eden
和两块Survivor
,默认比例为8:1:1。代价是存在部分内存空间浪费,适合在新生代使用。
图片来源于网络如有侵权请私信删除
标记过程仍然与“标记-清除”算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。
图片来源于网络如有侵权请私信删除
可达性分析的缺点
从GC Roots
节点找引用链这个操作为例,可作为GC Roots
的节点主要在全局性的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中,现在很多应用仅仅方法区就有数百兆,如果要逐个检查这里面的引用,那么必然会消耗很多时间。
由于要确保在一致性的快照中进行可达性分析,从而导致GC
进行时必须要停顿所有Java执行线程;
GC
,当执行系统停顿下来后并不需要一个不漏的检查完所有执行上下文和全局的引用变量,虚拟机应当有办法直接得知哪些地方存着对象的引用
OopMap的数据结构**
来记录哪些地方存着对象的引用
JIT编译
过程中会在特定的位置记录下栈和寄存器中哪些位置是引用
判断对象引用
OopMap
,只是在特定位置记录了这些信息,这些位置称为安全点。
GC
,只有到达安全点时才能暂停。
抢先式中断
GC
发生时,首先把所有线程全部中断,如果发现有线程中断的地方不在安全点上,就恢复线程,让它“跑”到安全点上。 现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC
事件。主动式中断
GC
需要中断线程的时候,不直接对线程操作,仅仅简单地设置一个标志,各个线程执行时主动去轮询这个标志,发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的,另外再加上创建对象需要分配内存的地方。两者的区别在于,抢先式中断是无论如何都进行中断,而主动式中断则是线程执行轮询标志查看是否中断。
GC
都是安全的。
GC
收集器。
JVM
在GC
时就不管这些线程了。
图片来源于网络如有侵权请私信删除
Serial
收集器的多线程版本Server
模式下虚拟机中首选的新生代收集器图片来源于网络如有侵权请私信删除
Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量
-XX:MaxGCPauseMillis
参数。-XX:GCTimeRatio
参数。Serial Old是Serial收集器的老年代版本,它同样是一个单线程收集器,使用“标记-整理”
算法。
图片来源于网络如有侵权请私信删除
Serial Old收集器是Serail收集器的老年代版本,是一个单线程收集器,使用标记-整理算法。
图片来源于网络如有侵权请私信删除
Parallel Old是Parallel Scavenge
收集器的老年代版本,使用多线程和“标记-整理”
算法。
图片来源于网络如有侵权请私信删除
CMS收集器是一种以获取最短的回收停顿时间为目标的收集器。
CMS收集器基于标记-清楚算法实现,分为四个步骤:初始标记、并发标记、重新标记、并发清除。
步骤详解
GC Roots
能直接关联到的对象,速度很快。GC Roots Tracing
。(CMS concurrent sweep)
。图片来源于网络如有侵权请私信删除
G1收集器是一款面向服务端应用的垃圾收集器。 G1收集器具备以下特点:
并行与并发
Stop-The-World
停顿的时间,部分其他收集器原本需要停顿Java线程执行的GC动作,G1收集器仍然可以通过并发的方式让Java程序继续执行。分代收集
G1
中依然得以保留。 虽然G1
可以不需要其他收集器配合就能独立管理整个GC
堆,但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、 熬过多次GC
的旧对象以获取更好的收集效果。空间整合
可预测的停顿
G1
相对于CMS
的另一大优势,降低停顿时间是G1
和CMS
共同的关注点,但G1
除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M
毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒,这几乎已经是实时Java(RTSJ)
的垃圾收集器的特征了。G1
收集器将整个Java堆划分为多个大小相等的独立区域,虽然还保留有新生代和老生代的概念,但新生代和老生代不再是物理隔的了,他们是一部分Region
的集合。
G1收集器可以有计划地避免在整个Java堆中进行全区域的垃圾收集:跟踪各个Region
里面的垃圾堆积的价值大小,在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region
。
在G1
收集器中,使用Remembered Set
来避免全堆扫描
G1
收集器的运作大致可划分为以下几个步骤:
初始标记(Initial Marking)
GC Roots
能直接关联到的对象,并且修改TAMS(Next Top at Mark Start)
的值,让下一阶段用户程序并发运行时,能在正确可用的Region中创建新对象,这阶段需要停顿线程,但耗时很短。并发标记(Concurrent Marking)
GC Root
开始对堆中对象进行可达性分析,找出存活的对象,这阶段耗时较长,但可与用户程序并发执行。最终标记(Final Marking)
Remembered Set Logs
里面,最终标记阶段需要把Remembered Set Logs
的数据合并到Remembered Set
中,这阶段需要停顿线程,但是可并行执行。筛选回收(Live Data Counting and Evacuation)
Region
的回收价值和成本进行排序,根据用户所期望的GC
停顿时间来制定回收计划 图片来源于网络如有侵权请私信删除 图片来源于网络如有侵权请私信删除
GC
发生的时间(虚拟机启动以后的秒杀)
“[GC”
和“[Full GC”
说明停顿类型,有Full
代表的是Stop-The-World
的;“[DefNew”
、“[Tenured”
和“[Perm”
表示GC发生的区域;
“3324K -> 152K(3712K)”
含义是 “GC
前该内存已使用容量 -> GC
后该内存区域已使用容量(该区域总容量)”;
“3324K -> 152K(11904)”
含义是 “GC
前Java堆已使用容量 -> GC
后Java堆已使用容量(Java堆总容量)”;
“0.0025925 secs”
表示该内存区域GC
所占用的时间;垃圾收集器参数总结
-XX:+<option>
启用选项 -XX:-<option>
不启用选项 -XX:<option>=<number>
-XX:<option>=<string>
参数 | 描述 |
---|---|
UserSerialGC | 虚拟机在client模式下的默认值,打开此开关后,用于Serial+Serial Old的收集器组合进行内存回收 |
UserParNewGC | 打开此开关 使用ParNew + Serial Old收集器组合进行内存回收 |
UseConcMarkSweepGC | 打开此开关,使用ParNew+CMS+Serial Old收集器组合进行内存回收。Serial Old在CMS收集器出现concurrent Mode Failure 失败后的后备收集器 |
UseParallelGC | 在server模式下的默认值,打开此开关后使用Scavenge+Serial Old收集器组合进行回收 |
UseParallelOldGC | 打开此开关后使用 Parallel Scavenge+Parallel Old收集器组合进行内存回收 |
SurvivorRatio | 新生代中Eden区域与Survivor区域的比值,默认为8,表示Eden:Survivor=8:1 |
PretenureSizeThreshold | 直接晋升到老年代对象的大小,设置这个参数后大于这个参数的对象直接在老年代中分配 |
MaxTenuringThreshold | 晋升老年代对象的年龄,每个对象坚持一次MnorGC年龄就加一,当超过这个参数值就进入老年代 |
UseAdaptiveSizePolicy | 动态调整java堆各个区域的大小以及进入老年代的年龄 |
HandlePromotionFailure | 是否允许分配担保失败,即老年代剩余空间不足以应付新生代整个对象都存活的特殊情况 |
ParalleGCThreads | 设置并行GC时进行内存回收的线程数 |
GCTimeratio | GC时间占总时间比率,默认值为99,允许1%的GC时间。只在Parallel Seavenge收集器时生效 |
MaxGCPauseMillis | 设置GC的最大停顿时间,只在Parallel Seavenge收集器时生效 |
CMSInitiatingOccupancyFration | 设置CMS老年代空间被使用多少后触发GC,默认值为68%,只在CMS收集器时生效 |
UseCMSCompactAtFullCollection | 设置CMS收集器完成垃圾收集后是否需要进行一次碎片整理,只在CMS垃圾收集器时生效 |
CMSFullGCBeforeCompaction | 设置CMS收集器进行若干次垃圾收集后再启动一次内存碎片整理,只在CMS垃圾收集器时生效 |
对象优先在新生代分配 大对象直接进入老年代 长期存活的对象将进入老年代
大多数情况下,对象优先在新生代的Eden区分配。 当Eden区没有足够的空间时,虚拟机将发起一次Minor GC。 Minor GC与Full GC。
PretenureSizeThreshold
,大于这个参数的对象将直接在老年代分配。
MaxTenuringThreshold
来设置。4.动态对象年龄的判定
为什么程序要跑到安全点时停下来?
Oop(Ordinary Object Pointer)
会需要大量的额外空间,增大GC的空间成本。设置了合适的安全点,有助于虚拟机得知对象引用所在的地方,因此有利于GC对“即将回收”的对象进行扫描。最后上一张本章结构图
图片来源于网络如有侵权请私信删除
《深入理解Java虚拟机:JVM高级特性与最佳实践_周志明.高清扫描版.pdf》
下载地址:链接:http://pan.baidu.com/s/1miBQCBY 密码:9kbn
《深入理解Java虚拟机》(四)虚拟机性能监控与故障处理工具
《深入理解Java虚拟机》(六)堆内存使用分析,GC 日志解读