短命对象加重标记开销，因其强制JVM在每次Minor GC时遍历所有装箱对象头（含Mark Word、Klass Pointer），触发缓存行填充与内存带宽占用；频繁分配还导致Eden区迅速填满，提升GC频率、STW总时长及CPU标记负担。
高并发场景下，大量基本类型（如 int、boolean）频繁装箱，会直接生成海量短生命周期的包装类对象（如 Integer、Boolean），这些对象几乎全部落在年轻代（Young Gen）的 Eden 区。它们存活时间极短——往往在下一次 Minor GC 前就已不可达，但分代回收器仍需对 Eden 区所有对象执行标记（Mark）操作，这构成了实质性的“标记压力”。
为什么短命对象反而加重标记开销？
现代分代 GC（如 G1、ZGC 的年轻代阶段，或 CMS/Parallel 的新生代收集）虽不扫描老年代，但仍需遍历 Eden + Survivor 中所有对象头，判断其是否可达。即使 99% 的 Integer 在分配后几毫秒内就变成垃圾，JVM 仍必须：
- 为每个装箱对象分配对象头（12 字节或更多），包含 Mark Word、Klass Pointer 等元数据
- 在 GC 标记阶段逐个访问这些对象头，触发 CPU 缓存行填充和内存带宽占用
- 即使使用卡表（Card Table）或记忆集（Remembered Set），Eden 区内对象间的引用关系仍需扫描
装箱行为如何放大 Eden 区压力？
每次装箱不是简单“多一个对象”，而是引发一连串内存与调度代价：
- 每装箱一次 = 在 Eden 分配一个完整对象（含对象头 + 实际字段），例如
Integer至少占 16 字节（x64 + CompressedOops） - 高并发线程同时装箱 → Eden 快速填满 → 触发更频繁的 Minor GC（可能从 100ms 一次变为 5ms 一次）
- Minor GC 频率升高 → STW 时间总和上升、应用吞吐量下降，且标记阶段 CPU 占用持续冲高
拆箱本身不产生新对象，但加剧标记链路复杂度
看似无害的拆箱操作（如 (int)obj）常隐藏间接压力：
- 若拆箱前对象来自缓存（如
Integer.valueOf(127)），虽避免分配，但缓存命中依赖值范围，超出即回退到新装箱 - 若拆箱发生在集合遍历中（如
ArrayList.get(i)返回Object后强转），则每次 get 都伴随一次潜在的类型检查（Class Cast）和栈上值复制，增加解释执行或 JIT 编译负担 - 更隐蔽的是：某些日志框架或监控 SDK 会对入参自动调用
toString()，而Integer.toString()内部又可能触发额外装箱（如格式化过程中的临时StringBuilderappend 操作）
真实瓶颈不在“回收”，而在“标记+分配”的协同失衡
开发者常误以为问题出在 GC “回收慢”，其实核心矛盾是：
- 分配速率远超 GC 吞吐能力（Allocation Rate > GC Throughput）
- 标记阶段无法跳过大量已知瞬时对象（JVM 无“这是刚装箱的 Integer，三秒后必死”这样的语义提示）
- 结果是：CPU 花大量 cycles 做标记，内存带宽被频繁写入对象头和字段占据，而真正业务逻辑的缓存局部性被严重破坏
