PretenureSizeThreshold 的合理边界是3MB：阈值从0升至1MB时RT降30%，1MB到3MB时RT平稳且Minor GC稳定，3MB升至5MB反出现Promotion failed；这表明3MB在拦截大对象与避免误伤中等对象间取得最佳平衡。
面试中用性能曲线证明 -XX:PretenureSizeThreshold 的边界配置，关键不是画一条“完美曲线”，而是通过三组对比实验，用 GC 日志和响应时间数据讲清楚“阈值设低了会怎样、设高了会怎样、设在中间点为什么更稳”。重点展示你对机制的理解深度，而非工具操作熟练度。
明确实验对照组：三档阈值 + 统一收集器
先锁定前提，避免被反问绕晕：
- 只用 ParNew + CMS（或 Serial GC），因为该参数对 G1/ZGC 无效；加
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC - 堆配置固定：
-Xms200m -Xmx200m -Xmn60m，确保老年代≈140MB，避免空间不足干扰判断 - 测试对象统一为
new byte[N]，N 分别取 1MB、3MB、5MB（对应阈值设为 0/1048576/3145728/5242880） - 每组跑 100 次分配 + 强制 Minor GC，用
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps记录日志
抓取核心指标：看 GC 日志里的“行为指纹”
不用画复杂图表，直接从日志里挑出三类关键行，就能定位阈值是否生效、是否过界：
-
生效证据：日志中出现
ParOldGen: [PSYoungGen: ...] => [ParOldGen: ...]，且PSYoungGen使用量没突增，但ParOldGen立即增长 N MB → 说明对象跳过新生代，直入老年代 -
失效证据：
PSYoungGen使用量飙升（如 Eden 占用从 40MB → 78MB），接着触发 Minor GC，日志出现Desired survivor size ...和Promotion failed→ 说明对象仍在 Eden 分配，但 Survivor 装不下，被迫晋升，已失去“直入”意义 -
过界风险：老年代连续增长后，出现
concurrent mode failure或Full GC频次上升 → 说明太多中等对象被误判为大对象，挤占老年代空间
用响应时间拐点说明“最优边界”
把三次实验的平均 RT（毫秒）和 GC 总停顿时间（秒）做成简易折线图（手绘或 PPT 插入），横轴是阈值设置（0 / 1M / 3M / 5M），纵轴是两项指标：
- 当阈值从 0→1MB：RT 下降明显（复制开销减少），GC 停顿缩短约 30% → 证明“启用有效”
- 从 1MB→3MB：RT 基本持平，Minor GC 次数稳定 → 说明业务中典型大对象（如 2–3MB 缓存块）已被覆盖
- 从 3MB→5MB：RT 反而微升，且出现 1–2 次
Promotion failed→ 说明漏掉的 3–5MB 对象仍在 Eden 复制，Minor GC 停顿反弹
结论就落在 3MB 这个拐点：它平衡了“拦截足够多大对象”和“不误伤中等对象”，是当前堆配置与业务特征下的合理边界。
收尾强调机制本质，不陷参数细节
最后补一句：“这个边界不是绝对的，它依赖于老年代碎片程度和对象分配节奏。所以线上我们会配合 -XX:+PrintAdaptiveSizePolicy 观察动态晋升阈值变化，再反推是否需要微调 PretenureSizeThreshold——毕竟参数只是开关，真正起作用的是 JVM 对内存压力的实时响应。”
