UseAdaptiveSizePolicy 可能引发对象过早晋升导致频繁 Full GC 和系统假死；应通过 GC 日志分析晋升波动、Survivor 耗尽及 Desired survivor size 频繁重设来确认；建议禁用该参数并手动设置 SurvivorRatio 和 MaxTenuringThreshold，再结合老年代增量与 Full GC 指标验证调优效果。
UseAdaptiveSizePolicy 是 JVM 的一项自动调优机制，它会根据 GC 行为动态调整年轻代各区域（Eden、Survivor）大小，目标是减少 GC 次数、缩短停顿。但当它“乱调”——比如频繁压缩 Survivor 空间、抬高晋升阈值或误判对象生命周期时，就可能引发 对象过早晋升老年代，进而导致老年代快速填满、触发频繁 Full GC，系统响应停滞，表现就像“假死”。
先确认是不是它在捣鬼
打开 GC 日志（-Xlog:gc*:file=gc.log），重点看三类线索：
- 每次 Young GC 后，晋升到老年代的对象大小是否剧烈波动（如从几百 KB 突增至几十 MB）；
- Survivor 区使用率是否长期低于 10%，甚至反复显示 “survivor space exhausted”；
- 日志中是否高频出现 “Desired survivor size” 被反复重设，且数值远小于上一次。
关掉自适应，手动稳住边界
UseAdaptiveSizePolicy 在业务流量突变、对象分布不均的场景下容易“误判”。对稳定性要求高的服务，建议显式关闭它，并固定关键比例：
- 添加 -XX:-UseAdaptiveSizePolicy 彻底禁用自适应；
- 用 -XX:SurvivorRatio=6（即 Eden:Survivor = 6:1:1）替代默认的 8，给 Survivor 留出更安全的缓冲空间；
- 配合 -XX:MaxTenuringThreshold=6 限制晋升年龄，避免短命对象因 Survivor 溢出被“误送”老年代。
配合监控做闭环验证
调参不是一锤子买卖。上线后必须盯住两个指标：
- Young GC 后老年代增量：理想状态应平稳、小幅上升，若单次 GC 晋升超 5MB，说明 Survivor 仍不足或对象生命周期判断有偏差；
- Full GC 频率与耗时：从“每分钟数次”降到“数小时一次”，且单次耗时低于 200ms，基本可判定假死解除。
