三色标记
标记算法
三色标记法把遍历对象图过程中遇到的对象，标记成以下三种颜色：
白色：尚未访问过
灰色：本对象已访问过，但是本对象引用到的其他对象尚未全部访问
黑色：本对象已访问过，而且本对象引用到的其他对象也全部访问完成
当 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