目录
一、如何判定对象“生死”？
1. 引用计数算法（理论参考）
2. 可达性分析算法（JVM 实际使用）
3. 对象的“缓刑”机制
二、引用类型与回收策略
三、何时触发垃圾回收？
1. 分代回收策略
2. 手动触发与注意事项
四、垃圾回收算法与实现
1. 基础算法对比
2. 分代收集理论
3. 新生代回收：Apple式复制算法
五、主流垃圾收集器详解
1. CMS 收集器（低停顿优先）
2. G1 收集器（平衡吞吐与延迟）
3. 收集器对比
六、调优建议与工具推荐
1. 参数配置示例
2. 常见问题排查
3. 工具推荐
七、总结
一、如何判定对象“生死”？
垃圾收集（GC）的核心是识别无用对象。JVM 通过两种算法判断对象是否存活：
1. 引用计数算法（理论参考）
-
原理：
每个对象维护一个引用计数器，被引用时计数器 +1，引用失效时 -1。计数器为 0 时判定为可回收。 -
缺点：
无法解决循环引用问题（如对象 A 引用 B，B 也引用 A）。 -
Java 未采用：主流 JVM 均使用 可达性分析算法。
2. 可达性分析算法（JVM 实际使用）
-
原理：
从 GC Roots 出发，遍历对象引用链。若对象无法被 GC Roots 关联，则判定为可回收。 -
GC Roots 对象类型：
-
虚拟机栈中的局部变量（如方法参数、局部变量）。
-
方法区中静态变量引用的对象。
-
方法区中常量引用的对象（如字符串常量池）。
-
本地方法栈中 JNI 引用的对象（Native 方法）。
-
同步锁持有的对象（
synchronized锁对象）。 -
Java 虚拟机内部对象（如系统类加载器、异常对象）。
-
3. 对象的“缓刑”机制
-
finalize()方法：
若对象重写finalize()且未被调用过，JVM 会将其放入F-Queue，由 Finalizer 线程触发该方法。 -
逃脱机会：
在finalize()中重新建立与 GC Roots 的引用链，可避免被回收（仅一次）。
public class RescueObject {
public static RescueObject hook;
@Override
protected void finalize() throws Throwable {
super.finalize();
hook = this; // 在 finalize 中自我拯救
}
}二、引用类型与回收策略
Java 提供 四种引用类型，控制对象生命周期与回收优先级：
| 引用类型 | 特点 | 回收时机 | 典型场景 |
|---|---|---|---|
| 强引用 | Object obj = new Object()，默认引用类型 | 对象不可达时回收 | 普通对象创建 |
| 软引用 | SoftReference<Object> ref = new SoftReference<>(obj) | 内存不足时回收（OOM 前触发） | 缓存（如图片缓存） |
| 弱引用 | WeakReference<Object> ref = new WeakReference<>(obj) | 下一次 GC 时回收 | 临时缓存（如 WeakHashMap） |
| 虚引用 | PhantomReference<Object> ref = new PhantomReference<>(obj, queue) | 随时可能回收，需配合 ReferenceQueue 使用 | 堆外内存回收监听（如 DirectByteBuffer） |
三、何时触发垃圾回收？
GC 触发时机由 内存区域分配策略 和 JVM 配置参数 共同决定：
1. 分代回收策略
| 区域 | GC 类型 | 触发条件 |
|---|---|---|
| 新生代 | Minor GC | Eden 区空间不足 |
| 老年代 | Major GC | 老年代空间不足（通常伴随 Full GC） |
| 整堆 | Full GC | 方法区不足、老年代空间不足、手动调用 System.gc() |
2. 手动触发与注意事项
-
System.gc()：建议 JVM 触发 Full GC（不保证立即执行）。 -
风险：频繁 Full GC 会导致应用停顿（Stop-The-World），需谨慎使用。
四、垃圾回收算法与实现
1. 基础算法对比
| 算法 | 步骤 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 标记-清除 | 标记存活对象 → 清除未标记对象 | 简单 | 内存碎片化 | 老年代（CMS） |
| 复制算法 | 存活对象复制到新区域 → 清空原区域 | 无碎片，高效 | 内存利用率 50% | 新生代（Survivor） |
| 标记-整理 | 标记存活对象 → 整理到内存一端 | 无碎片化 | 整理耗时 | 老年代（Serial Old） |
2. 分代收集理论
-
弱分代假说：绝大多数对象朝生夕灭（新生代）。
-
强分代假说：熬过多次 GC 的对象难以消亡（老年代）。
-
分代设计：
-
新生代：使用复制算法（Eden + Survivor）。
-
老年代：使用标记-清除或标记-整理算法。
-
3. 新生代回收：Apple式复制算法
-
内存划分：
-
Eden : Survivor1 : Survivor2 = 8:1:1（默认）。
-
-
回收流程：
-
新对象分配至 Eden 区。
-
Eden 满时触发 Minor GC，存活对象复制到 Survivor1。
-
下次 Minor GC 时，Eden 和 Survivor1 存活对象复制到 Survivor2，并清空原区域。
-
对象年龄达到阈值（默认 15）后晋升老年代。
-
五、主流垃圾收集器详解
1. CMS 收集器（低停顿优先）
-
目标：最小化应用停顿时间。
-
算法：标记-清除。
-
工作流程：
-
初始标记（STW）：标记 GC Roots 直接关联对象。
-
并发标记：遍历对象图（与用户线程并发）。
-
重新标记（STW）：修正并发标记期间变动的引用。
-
并发清除：清理垃圾（与用户线程并发）。
-
-
缺点：
-
内存碎片化（需定期 Full GC 整理）。
-
并发阶段占用 CPU 资源。
-
2. G1 收集器（平衡吞吐与延迟）
-
目标：可预测的停顿时间（如 200ms 内）。
-
内存布局：将堆划分为多个 Region（默认 2048 个）。
-
工作流程：
-
初始标记（STW）：标记 GC Roots 直接关联对象。
-
并发标记：遍历对象图（与用户线程并发）。
-
最终标记（STW）：处理剩余引用变更。
-
筛选回收（STW）：选择性价比高的 Region 回收。
-
-
优势：
-
支持大内存（TB 级）。
-
通过 Region 划分减少碎片化。
-
3. 收集器对比
| 收集器 | 算法 | 区域 | 特点 | 适用场景 |
|---|---|---|---|---|
| CMS | 标记-清除 | 老年代 | 低停顿，但碎片化严重 | 响应敏感型应用 |
| G1 | 标记-整理 | 全堆 | 可预测停顿，兼顾吞吐与延迟 | 大内存、低延迟应用 |
六、调优建议与工具推荐
1. 参数配置示例
# 使用 G1 收集器，堆内存 4G，目标停顿 200ms
java -Xmx4G -Xms4G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar app.jar
# 启用 CMS 收集器
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode2. 常见问题排查
-
频繁 Full GC：
-
检查内存泄漏（如静态集合未清理）。
-
调整新生代与老年代比例（
-XX:NewRatio）。
-
-
长时间 STW：
-
切换低延迟收集器（如 G1/ZGC）。
-
减少堆内存大小（权衡吞吐与停顿）。
-
3. 工具推荐
-
监控工具：VisualVM、JConsole、Prometheus + Grafana。
-
日志分析：GCeasy、GCViewer。
-
诊断工具：Arthas、MAT（Memory Analyzer Tool）。
七、总结
-
生死判定：可达性分析是核心，
finalize()是最后的逃生机会。 -
引用分级：软、弱引用优化内存敏感场景。
-
算法选择：分代理论平衡效率与资源利用率。
-
收集器选型：CMS 适合低延迟，G1 适合大内存与可预测停顿。
核心原则：结合业务需求与监控数据动态调优，避免盲目配置。
