包装类在堆中分配并参与gc，基本类型在栈中分配无gc开销；高频装箱引发小对象雪崩，加剧young gc频次与内存碎片；逃逸分析优化不可控，应从设计源头避免包装类滥用。
包装类和基本类型在 JVM 中的内存分配路径与 GC 行为差异显著，压测时这些差异会直接反映在延迟、吞吐和 GC 频次上——不是“有没有影响”，而是“在哪条路径上爆发”。关键不在语法写法，而在对象是否真实落堆、是否参与可达性分析、是否触发年轻代频繁晋升。
堆 vs 栈：分配位置决定生命周期起点
基本类型（如 int、boolean）默认在栈上分配，值直接存储，无引用、无 GC 参与；而包装类（如 Integer、Long）是普通 Java 对象，实例一定落在堆中，哪怕只是循环里一句 Integer i = j，只要超出缓存范围（-128~127），就会新建堆对象。
- 栈变量随方法退出自动销毁，零 GC 开销
- 每个 Integer 实例占用约 24 字节堆空间（对象头 16B + int 字段 4B + 对齐填充 4B）
- 哪怕只多创建 1000 个 Integer，就额外增加约 24KB 堆压力，Young GC 触发阈值更容易被击穿
GC 压力来源：短命对象堆泛滥是主因
压测中 RT 波动、Stop-The-World 时间拉长，往往源于高频装箱产生的“小对象雪崩”——它们不进老年代，但疯狂挤占 Eden 区，导致 Minor GC 频次陡增。例如每秒 5000 次调用的接口，若参数 DTO 用 Integer status，每次反序列化 + 条件判断（status == 1）都会触发一次拆箱，若值为 200，则每次都是新对象。
- Integer.valueOf(200) → 新建堆对象（不复用缓存）
- status + 1 → 自动拆箱再装箱，又一个新对象
- 这些对象存活时间通常不足一次 GC，但持续申请/释放会加剧内存碎片，拖慢后续分配速度
逃逸分析与栈上分配：JIT 的“补救”有限且不可控
虽然 JVM 启用 -XX:+DoEscapeAnalysis 后，可能将未逃逸的短生命周期包装对象优化为栈上分配（避免堆分配），但这依赖代码结构稳定、JIT 编译充分，且仅对局部变量有效。一旦对象被放入集合、作为返回值、或跨方法传递，逃逸即发生，优化失效。
- 循环内
new Integer(i)几乎不可能被栈上分配 - DTO 字段、Feign 响应体中的包装类字段必然逃逸，必定落堆
- 不能把性能赌在 JIT 优化上，而应从设计源头规避
真实压测对比建议：聚焦可测量指标
不要只比单次操作耗时，要观察高并发下系统级表现：
- 开启 -XX:+PrintGCDetails，对比 Young GC 次数与平均暂停时间（重点关注 G1 Evacuation Pause 或 ParNew 阶段）
- 用 JFR 或 VisualVM 监控 “Allocation Rate”（MB/sec），包装类密集场景常高出 3–5 倍
- 对比堆内存使用曲线：基本类型路径更平滑；包装类路径易出现锯齿状波动，伴随频繁 GC
- 注意 Full GC 是否提前触发——大量小对象加速老年代碎片积累，尤其在 CMS 或 G1 Mixed GC 不足时
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
