三色标记
标记算法
三色标记法把遍历对象图过程中遇到的对象,标记成以下三种颜色:
-
白色:尚未访问过
-
灰色:本对象已访问过,但是本对象引用到的其他对象尚未全部访问
-
黑色:本对象已访问过,而且本对象引用到的其他对象也全部访问完成
当 Stop The World (STW) 时,对象间的引用是不会发生变化的,可以轻松完成标记,遍历访问过程为:
-
初始时,所有对象都在白色集合
-
将 GC Roots 直接引用到的对象挪到灰色集合
-
从灰色集合中获取对象:
-
将本对象引用到的其他对象全部挪到灰色集合中
-
将本对象挪到黑色集合里面
-
-
重复步骤 3,直至灰色集合为空时结束
-
结束后,仍在白色集合的对象即为 GC Roots 不可达,可以进行回收
并发标记
并发标记时,对象间的引用可能发生变化,多标和漏标的情况就有可能发生
多标情况:当 E 变为灰色或黑色时,其他线程断开的 D 对 E 的引用,导致这部分对象仍会被标记为存活,本轮 GC 不会回收这部分内存,这部分本应该回收但是没有回收到的内存,被称之为浮动垃圾
-
针对并发标记开始后的新对象,通常的做法是直接全部当成黑色,也算浮动垃圾
-
浮动垃圾并不会影响应用程序的正确性,只是需要等到下一轮垃圾回收中才被清除
漏标情况:
-
条件一:灰色对象断开了对一个白色对象的引用(直接或间接),即灰色对象原成员变量的引用发生了变化
-
条件二:其他线程中修改了黑色对象,插入了一条或多条对该白色对象的新引用
-
结果:导致该白色对象当作垃圾被 GC,影响到了程序的正确性
代码角度解释漏标:
Object G = objE.fieldG; // 读
objE.fieldG = null; // 写
objD.fieldG = G; // 写
为了解决问题,可以操作上面三步,将对象 G 记录起来,然后作为灰色对象再进行遍历,比如放到一个特定的集合,等初始的 GC Roots 遍历完(并发标记),再遍历该集合(重新标记)
所以重新标记需要 STW,应用程序一直在运行,该集合可能会一直增加新的对象,导致永远都运行不完
解决方法:添加读写屏障,读屏障拦截第一步,写屏障拦截第二三步,在读写前后进行一些后置处理:
-
写屏障 + 增量更新:黑色对象新增引用,会将黑色对象变成灰色对象,最后对该节点重新扫描
增量更新 (Incremental Update) 破坏了条件二,从而保证了不会漏标
缺点:对黑色变灰的对象重新扫描所有引用,比较耗费时间
-
写屏障 (Store Barrier) + SATB:当原来成员变量的引用发生变化之前,记录下原来的引用对象
保留 GC 开始时的对象图,即原始快照 SATB,当 GC Roots 确定后,对象图就已经确定,那后续的标记也应该是按照这个时刻的对象图走,如果期间对白色对象有了新的引用会记录下来,并且将白色对象变灰(说明可达了,并且原始快照中本来就应该是灰色对象),最后重新扫描该对象的引用关系
SATB (Snapshot At The Beginning) 破坏了条件一,从而保证了不会漏标
-
读屏障 (Load Barrier):破坏条件二,黑色对象引用白色对象的前提是获取到该对象,此时读屏障发挥作用
以 Java HotSpot VM 为例,其并发标记时对漏标的处理方案如下:
-
CMS:写屏障 + 增量更新
-
G1:写屏障 + SATB
-
ZGC:读屏障
finalization
Java 语言提供了对象终止(finalization)机制来允许开发人员提供对象被销毁之前的自定义处理逻辑
垃圾回收此对象之前,会先调用这个对象的 finalize() 方法,finalize() 方法允许在子类中被重写,用于在对象被回收时进行后置处理,通常在这个方法中进行一些资源释放和清理,比如关闭文件、套接字和数据库连接等
生存 OR 死亡:如果从所有的根节点都无法访问到某个对象,说明对象己经不再使用,此对象需要被回收。但事实上这时候它们暂时处于缓刑阶段。一个无法触及的对象有可能在某个条件下复活自己,所以虚拟机中的对象可能的三种状态:
-
可触及的:从根节点开始,可以到达这个对象
-
可复活的:对象的所有引用都被释放,但是对象有可能在 finalize() 中复活
-
不可触及的:对象的 finalize() 被调用并且没有复活,那么就会进入不可触及状态,不可触及的对象不可能被复活,因为 finalize() 只会被调用一次,等到这个对象再被标记为可回收时就必须回收
永远不要主动调用某个对象的 finalize() 方法,应该交给垃圾回收机制调用,原因:
-
finalize() 时可能会导致对象复活
-
finalize() 方法的执行时间是没有保障的,完全由 GC 线程决定,极端情况下,若不发生 GC,则 finalize() 方法将没有执行机会,因为优先级比较低,即使主动调用该方法,也不会因此就直接进行回收
-
一个糟糕的 finalize() 会严重影响 GC 的性能
引用分析
无论是通过引用计数算法判断对象的引用数量,还是通过可达性分析算法判断对象是否可达,判定对象是否可被回收都与引用有关,Java 提供了四种强度不同的引用类型
-
强引用:被强引用关联的对象不会被回收,只有所有 GCRoots 都不通过强引用引用该对象,才能被垃圾回收
-
强引用可以直接访问目标对象
-
虚拟机宁愿抛出 OOM 异常,也不会回收强引用所指向对象
-
强引用可能导致内存泄漏
Object obj = new Object();//使用 new 一个新对象的方式来创建强引用
-
-
软引用(SoftReference):被软引用关联的对象只有在内存不够的情况下才会被回收
-
仅(可能有强引用,一个对象可以被多个引用)有软引用引用该对象时,在垃圾回收后,内存仍不足时会再次出发垃圾回收,回收软引用对象
-
配合引用队列来释放软引用自身,在构造软引用时,可以指定一个引用队列,当软引用对象被回收时,就会加入指定的引用队列,通过这个队列可以跟踪对象的回收情况
-
软引用通常用来实现内存敏感的缓存,比如高速缓存就有用到软引用;如果还有空闲内存,就可以暂时保留缓存,当内存不足时清理掉,这样就保证了使用缓存的同时不会耗尽内存
Object obj = new Object(); SoftReference<Object> sf = new SoftReference<Object>(obj); obj = null; // 使对象只被软引用关联
-
-
弱引用(WeakReference):被弱引用关联的对象一定会被回收,只能存活到下一次垃圾回收发生之前
-
仅有弱引用引用该对象时,在垃圾回收时,无论内存是否充足,都会回收弱引用对象
-
配合引用队列来释放弱引用自身
-
WeakHashMap 用来存储图片信息,可以在内存不足的时候及时回收,避免了 OOM
Object obj = new Object(); WeakReference<Object> wf = new WeakReference<Object>(obj); obj = null;
-
-
虚引用(PhantomReference):也称为幽灵引用或者幻影引用,是所有引用类型中最弱的一个
ThreadLocal 内部是虚引用
-
一个对象是否有虚引用的存在,不会对其生存时间造成影响,也无法通过虚引用得到一个对象
-
为对象设置虚引用的唯一目的是在于跟踪垃圾回收过程,能在这个对象被回收时收到一个系统通知
-
必须配合引用队列使用,主要配合 ByteBuffer 使用,被引用对象回收时会将虚引用入队,由 Reference Handler 线程调用虚引用相关方法释放直接内存
Object obj = new Object(); PhantomReference<Object> pf = new PhantomReference<Object>(obj, null); obj = null;
-
-
终结器引用(finalization)
-
无需手动编码,但其内部配合引用队列使用,在垃圾回收时,终结器引用入队(被引用对象暂时没有被回收),再由 Finalizer 线程通过终结器引用找到被引用对象并调用它的 finalize 方法,第二次 GC 时才能回收被引用对象
-
无用属性
无用类
方法区主要回收的是无用的类
判定一个类是否是无用的类,需要同时满足下面 3 个条件:
-
该类所有的实例都已经被回收,也就是 Java 堆中不存在该类的任何实例
-
加载该类的
ClassLoader
已经被回收 -
该类对应的
java.lang.Class
对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法
虚拟机可以对满足上述 3 个条件的无用类进行回收,这里说的仅仅是可以,而并不是和对象一样不使用了就会必然被回收
废弃常量
在常量池中存在字符串 "abc",如果当前没有任何 String 对象引用该常量,说明常量 "abc" 是废弃常量,如果这时发生内存回收的话而且有必要的话(内存不够用),"abc" 就会被系统清理出常量池
静态变量
类加载时(第一次访问),这个类中所有静态成员就会被加载到静态变量区,该区域的成员一旦创建,直到程序退出才会被回收
如果是静态引用类型的变量,静态变量区只存储一份对象的引用地址,真正的对象在堆内,如果要回收该对象可以设置引用为 null
本站资源均来自互联网,仅供研究学习,禁止违法使用和商用,产生法律纠纷本站概不负责!如果侵犯了您的权益请与我们联系!
转载请注明出处: 免费源码网-免费的源码资源网站 » JVM之标记算法的详细解析
发表评论 取消回复