高 QPS 接口创建了大量临时对象，Young GC 非常频繁，你会怎么分析对象分配过程？
我的判断
Young GC 频繁先看每秒分配了什么、从哪条调用链产生，再判断是正常高吞吐还是可以消掉的对象洪峰。
我会把接口 RT、吞吐、allocation rate 和 GC 日志对齐，再用 JFR 的 Object Allocation in New TLAB / Outside TLAB 找出分配热点。常见来源是大结果一次映射成多层 DTO、日志字符串提前拼接、正则和 JSON 临时对象、循环里的装箱。
优化顺序通常是：减少不必要字段和中间集合，改成流式处理；把循环中重复创建的格式化器或解析器移出热路径；避免无意义装箱；大数组和大对象单独关注 humongous allocation。
我不会一看到分配多就做对象池。短命小对象由 TLAB 分配很快，池化反而增加生命周期、同步和内存泄漏风险。也不会先调大 Young 区掩盖问题，因为暂停时间和晋升可能一起变差。
改完用相同吞吐比较 MB/s 分配率、Young GC 次数、暂停总时间和接口 P99，确认不是用更多 CPU 换了更少 GC。