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 对内存压力的实时响应。”