Java自动装箱拆箱性能影响须通过JMH压测量化：对比Integer与int在执行耗时、GC压力、内存占用及CPU时间分布的差异，确保仅数值类型不同、逻辑与数据规模完全一致。
Java 自动装箱与拆箱对性能的影响，不能只靠理论推测，必须通过可控、可比、可复现的压测来量化。核心思路是：构造相同逻辑但数据类型策略不同的两组代码，用统一压测工具在相同环境运行，对比关键指标差异。
明确压测目标和对比维度
压测不是“跑一遍看快慢”，而是聚焦几个可测量的点：
-
执行耗时：同一计算任务（如累加、遍历、映射）使用
Integervsint的总耗时差异（毫秒级需取多次平均） - GC 压力：关注 Young GC 频次、每次 GC 时间、晋升到老年代的对象量——频繁装箱会大量创建短生命周期的包装对象
- 内存占用：堆内存峰值、Eden 区使用率、对象分配速率（可用 JFR 或 VisualVM 实时采集）
- CPU 时间分布：是否因对象创建/销毁导致更多 safepoint 停顿或 JIT 编译开销上升
设计可隔离的压测用例
避免干扰因素，确保变量唯一：
- 禁用 JVM 预热干扰：用 JMH（Java Microbenchmark Harness）做基准测试，它自动处理预热、Fork、统计校验
- 对比组严格一致：仅替换数值类型，其余逻辑、循环结构、数据规模完全相同
- 典型例子：
// 对比组 A：使用包装类（触发自动装箱/拆箱）
public long sumWithInteger() {
Long sum = 0L;
for (int i = 0; i sum += i; // 每次 += 触发拆箱 + 装箱
}
return sum;
}
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
// 对比组 B：使用基本类型（零装箱开销）
public long sumWithLong() {
long sum = 0L;
for (int i = 0; i sum += i; // 纯栈上运算
}
return sum;
}
执行压测并采集真实指标
推荐组合工具链：
- JMH + -prof gc：直接输出吞吐量（ops/s）、平均延迟、GC 次数和时间
- JFR（Java Flight Recorder）：开启 `Allocation Profiling`，查看 `Object Allocation Outside TLAB` 和 `java.lang.Integer` 实例分配热点
- jstat -gc：在长时间循环中定期采样，观察 Eden 区增长速度和 YGC 频率变化
示例 JMH 结果常显示：装箱版本耗时高出 5–10 倍，GC 次数多出 2–3 个数量级——尤其当循环体小、迭代次数大时，差异更显著。
关注边界场景下的放大效应
某些场景会让装箱/拆箱代价被严重放大，压测时要特别覆盖：
-
集合高频读写：如
ArrayList<integer>.get(i)</integer>在 tight loop 中反复调用，每次 get 都隐含一次拆箱 -
数值比较误用：用
==比较两个Integer，可能触发意外拆箱（还伴随空指针风险） -
缓存失效路径：超出
Integer.valueOf()缓存范围（-128~127）时，每次装箱都 new 对象，压测中可故意用 200、500 等值验证
这些不是“偶尔慢一点”，而是在线上高并发批量处理、实时计算等场景下，成为 CPU 和 GC 的隐形瓶颈。
