标记-清除算法易致oom因内存碎片化，无法满足大对象连续空间需求；新生代用标记-复制因存活率低且需survivor区容下幸存者；老年代稳态选标记-整理，但g1/zgc已通过分区+局部整理兼顾低停顿与防碎片。
标记-清除算法为什么容易导致 OOM？
不是 GC 没干活，而是它清完垃圾后，内存被切成了一堆“小块”，就像把一整张纸撕成碎屑——总空间够，但拼不出一张 A4 大小的连续区域。new byte[1024 * 1024] 这样的大对象申请时，JVM 找不到连续空闲页，直接抛 OutOfMemoryError。
- 典型触发场景：老年代长期运行后频繁分配中等大小对象（如缓存 entry、JSON 解析 buffer）
- CMS 收集器在老年代就用标记-清除，一旦碎片率 >92%，会强制降级为 Serial Old（STW 时间飙升）
- 监控关键指标不是“已用内存”，而是
ConcurrentMarkSweep日志里的promotion failed或 GC 日志中的defrag字样
为什么新生代必须用标记-复制？
因为新生代里 98% 的对象活不过一次 GC，复制存活对象的成本远低于遍历+清理全部对象。但这个算法有个硬约束：Survivor 区必须预留足够空间容纳所有幸存者，否则就会 Minor GC 失败并触发 Full GC。
-
-XX:SurvivorRatio=8表示 Eden:Survivor = 8:1:1，若 Survivor 不够用，对象直接“担保分配”进老年代，加速老年代膨胀 - 避免隐式扩容：不要在循环里 new
StringBuilder()而不复用，它内部 char[] 容易触发复制失败 - 验证方式：加
-XX:+PrintGCDetails，观察每次 Minor GC 后PSYoungGen区的 “used” 是否稳定在 10%~30%，突增说明对象存活率异常升高
标记-整理 vs 标记-清除：老年代选哪个更稳？
标记-整理（如 Serial Old、Parallel Old）会移动对象、消除碎片，但移动过程需要 STW；标记-清除（如 CMS）停顿短，但碎片不可控。现在 OpenJDK 17+ 默认的 G1 和 ZGC 其实都绕开了二选一——它们用分区+局部整理，既控停顿又防碎片。
- CMS 已在 JDK 14 被移除，别再为它调优；JDK 17 后默认是 G1，
-XX:+UseG1GC实际已冗余 - 如果还在用 Parallel GC，老年代用的是标记-整理，但它的整理是全堆级的，单次 STW 可能长达数秒，不适合低延迟服务
- 真正要注意的不是算法名，而是 GC 日志里
Pause时间是否稳定：G1 的 mixed GC 若持续 >200ms，大概率是 Humongous 对象（≥½ region）太多，得查humongous allocation日志
ThreadLocal 真的能防碎片吗？
能，但只对特定模式有效：线程生命周期内反复分配同尺寸缓冲区。它本质是把“高频小对象创建”转为“单次分配 + 复用”，避开 Eden 区快速填满、Survivor 溢出、提前晋升这一连串连锁反应。
- 别滥用：
ThreadLocal不释放会导致内存泄漏，尤其在线程池场景下，务必配合remove() - 尺寸要合理：设成
new byte[4096]比1024更友好——4KB 是多数 OS 内存页大小，减少跨页分配 - 替代方案更简单：用
ByteBuffer.allocateDirect()做堆外缓冲，或直接上org.apache.commons.io.IOUtils的静态 buffer 池，比手写 ThreadLocal 更可靠
实际调参时，最常被忽略的是对象年龄阈值与晋升行为的耦合关系——-XX:MaxTenuringThreshold 设太高，小对象在 Survivor 待太久，浪费空间；设太低，又让本该回收的对象早早进老年代。这和算法选择一样，不是孤立参数，得看 GC 日志里每轮 Minor GC 后的 age 分布直方图。
