主题 04垃圾回收与调优

04.1为什么 GC 是面试分水岭

同样一句「我们线上用的是 G1」，答得好和答得差差距在能不能说出代价。 下面六个问题，每一个都能靠一次实测回答：

04.2一次 Young GC 的完整账本

先把一次 GC 拆开看。-Xlog:gc+heap=debug 会在回收前后各打一份堆快照，中间夹一行结果：

GC(0) Heap before GC invocations=0 (full 0):
GC(0)  def new generation   total 88512K, used 78720K
GC(0)   eden space 78720K, 100% used
GC(0)   from space  9792K,   0% used
GC(0)   to   space  9792K,   0% used
GC(0)  tenured generation   total 161792K, used 0K
GC(0) DefNew: 78720K(88512K)->776K(88512K) Eden: 78720K(78720K)->0K(78720K)
GC(0) Tenured: 0K(161792K)->0K(161792K)

这份日志的参数是 -Xmx256m -Xmn96m -XX:SurvivorRatio=8，把它翻译成人话：

最关键的是最后两行：

• Eden: 78720K -> 0K——Eden 被整个清空，不留一点垃圾（复制算法：活对象搬走，整块丢掉）；
• From: 0K -> 776K——776K 的活对象被复制到 Survivor，年龄 +1；
• Tenured: 0K -> 0K——老年代一点没动，因为这批对象还没到晋升年龄。

再看两份更细的日志，一个是年龄表，一个是回收后的堆：

GC(0) Desired survivor size 3342336 bytes, new threshold 1 (max threshold 15)
GC(0) Age table with threshold 1 (max threshold 15)
GC(0) - age   1:    5923048 bytes,    5923048 total

三行读法：Survivor 目标是 3.34MB（9792K 的 1/3 左右，由 -XX:TargetSurvivorRatio 默认 50 算出），晋升阈值被压到 1（因为这一轮存活对象超过目标，JVM 临时把阈值降到 1， 让它们下一轮就赶紧走），age 1 有 5.9MB。阈值上限 15 是 -XX:MaxTenuringThreshold 的默认值。

04.3四种收集器，同一份负载

同一份负载（3000 个 1MB 对象 + 300 个长期持有）跑四遍，统计结果：

配置         Y次数    Y总停顿   Y最大   F次数   F总停顿   其它STW   GC总计
serial        37    173.4ms   9.54ms     1     1.9ms     0.0ms  175.3ms
parallel      23     55.2ms   4.69ms     2     8.3ms     0.0ms   63.6ms
g1           156    101.3ms   1.56ms     2     4.0ms    32.1ms  137.3ms
zgc            0      0.0ms   0.00ms     0     0.0ms     0.5ms    0.5ms

程序侧的总耗时：

serial    用时 450 ms
parallel  用时 334 ms
g1        OutOfMemoryError: Java heap space   <-- 注意这里
zgc       用时 546 ms

四行数据，四个结论：

这组对比把「没有最好的收集器，只有最合适的」这句话变成了数字：

• Parallel 的总停顿 63.6ms 最少，因为它一次收得多、次数少。适合批处理、离线任务—— 反正跑完就行，停顿长短无所谓，看总吞吐。
• G1 的单次停顿 1.56ms 最短，代价是收 156 次、总停顿反而 137.3ms。 适合在线服务——用户感知的是单次卡顿，不是总卡顿。
• ZGC 把 STW 压到 0.5ms（几乎全是并发），但总耗时 546ms 比 Parallel 多 63%。 因为它要和业务线程抢 CPU做并发标记。适合大堆 + 低延迟（几十 GB 以上）， 小堆用它纯属浪费。

04.4G1 的 Region，和 512KB 那条分界线

G1 把堆切成等大的 Region，大小在启动时算好：

[gc,init] Heap Region Size: 1M
[gc,init] Heap Min Capacity: 8M
[gc,init] Compressed Oops: Enabled (32-bit)

512MB 堆、16 核，Region 就是 1MB。规则是：对象大小 ≥ Region 的一半， 就叫 Humongous，必须占用整数个 Region。1MB 的 Region，一半就是 512KB。

把四个尺寸各分配 100 个，看堆上实际占了多少：

 300 KB × 100 个：理论 29 MB，堆上实际 29 MB
 512 KB × 100 个：理论 50 MB，堆上实际 100 MB
 520 KB × 100 个：理论 50 MB，堆上实际 100 MB
1024 KB × 100 个：理论 100 MB，堆上实际 200 MB

300KB 正常，从 512KB 开始全部翻倍。因为：

• 300KB < 512KB，是普通对象，塞进 Eden 的 Region 里，按实际大小算；
• 512KB 恰好等于 Region 的一半，判为 Humongous，独占 1 个 Region（1MB），浪费一半；
• 520KB 超了一半，必须占 2 个连续 Region（2MB），浪费 1.48MB；
• 1MB 正好占 2 个 Region，200 个 Region 装 100MB 数据。

现在回头看 04.3 的 OOM：3000 个 1MB 对象里活下来 300 个，按 2 倍算就是 600MB， 而堆只有 512MB —— 撑爆是必然的。同一份负载在 Serial 下只要 300MB。

04.5对象什么时候进老年代

四条路，缺一不可：

第 2 条最容易被忽略，但它在日志里天天出现。04.2 那份日志的 new threshold 1 (max threshold 15) 就是证据：阈值不是固定 15，是每轮动态算的。

04.6什么时候会 Full GC

Full GC 是「整个堆 + 元空间」都扫一遍，停顿通常是 Young GC 的 10 倍以上。 它的触发条件有五种，前两种最常见：

第 3 条可以现场复现。用一个手写的 class 生成器不停 defineClass，把 -XX:MaxMetaspaceSize=32m 撑爆：

已加载 5000 个类，Metaspace 已用 4 MB
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace

5000 个空类吃掉 4MB，平均每个类约 0.8KB。32MB 的上限在四万个类左右见底。 这类 OOM 的典型现场是 CGLIB 动态代理、热部署、脚本引擎—— 每次生成的类都要占元空间，而它们只有对应的 ClassLoader 被回收才会释放。

04.7内存泄漏：GC 之后为什么不降

「内存泄漏」和「内存不够」在监控图上长得一样（都是堆曲线一路上涨），区分方法只有一个： 强制 Full GC，看它降不降。降了是不够用，不降是泄漏。

已持有  60 MB，堆已用 123 MB / 最大 256 MB
已持有  80 MB，堆已用 163 MB / 最大 256 MB
GC 前堆占用 201 MB
连做 3 次 Full GC 之后堆占用 201 MB（HOLD 仍持有 100 MB）

100 个 1MB 数组，GC 前 201MB、GC 后还是 201MB，一字节没降。 为什么是 201MB 而不是 100MB？因为 1MB 对象在 G1 里是 Humongous，每个占 2 个 Region ——正好是 04.4 那条 512KB 分界线的又一次实证。

这段代码的「泄漏点」只有一行：

static final List<byte[]> HOLD = new ArrayList<>();
...
HOLD.add(new byte[1024 * 1024]);   // 只加不减，且 HOLD 是 GC Root 可达的

static 集合是最经典的泄漏形态：它被类对象引用，类对象被 ClassLoader 引用， ClassLoader 被 GC Root 引用——整条链都活着，里面的元素自然回收不掉。

04.8调优的三个旋钮，和一个禁忌

调优不是背参数，是按顺序拧三个旋钮。顺序错了会白忙：

第 3 个旋钮的现象在 04.3 已经能看到：G1 的 Young GC 次数是 Parallel 的 6.8 倍（156 vs 23）。 默认目标 200ms，它每次只收一小块 Region 就停手，所以次数多、单次短—— 「低延迟」和「少次数」在 G1 里是同一个旋钮的两端。

04.9速记卡与自查

动手清单与自查表