高频装箱拆箱隐患表现为压测时CPU突增、GC频繁、内存翻倍；需通过JFR/VisualVM定位Integer/Long分配热点，结合SpotBugs扫描null拆箱，检查集合遍历、算术比较、DTO冗余包装等场景，并用JMH量化成本。
老代码里自动装箱拆箱的性能隐患往往藏得深、爆发晚——不是编译报错，也不是运行崩溃，而是某次压测时 CPU 突增、GC 频繁、内存占用翻倍，才被注意到。重构时不能靠“感觉”，得有明确路径去识别和定位。
从高频集合操作入手查装箱热点
泛型集合是装箱最密集的区域。重点关注以下写法：
- List<Integer>、Map<String, Long> 等包装类泛型声明，尤其在循环中反复 add/get 的场景
- 用 for (int i : list) 遍历 List<Integer> —— 每次迭代都隐含一次拆箱
- 用 stream().mapToInt(...).sum() 却传入 List<Integer> —— 中间会经历多次装箱/拆箱转换
建议用 JFR（Java Flight Recorder）或 VisualVM 抓取 GC 日志和对象分配热点，筛选出 java.lang.Integer、java.lang.Long 等短生命周期对象的高频创建记录。
盯紧算术与比较运算中的隐式拆箱
这些地方看似简单，实则极易触发意外拆箱：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
if (obj != null && obj.getValue() > 0) —— 若
getValue()返回 Integer，比较前自动拆箱，一旦为 null 就 NPE - a + b 其中 a 或 b 是 Integer/Long —— 编译器强制拆箱后做基本类型运算，null 时直接抛异常
- return x >= y ? x : y; 若 x 是 Integer、y 是 int，x 会被拆箱；若 x 为 null，此处 crash
这类代码在单元测试中可能因数据全非 null 而漏掉，建议用 SpotBugs 或 ErrorProne 插件扫描 Unboxing of null value 类警告。
检查缓存与 DTO 层是否过度包装
老项目常见“为统一而包装”：比如把所有数值字段都定义成 Integer，哪怕业务上绝不会为 null。
- 数据库映射层（如 MyBatis）返回 Integer id，但主键永远非空 → 改用 int id 更安全高效
- DTO 中大量使用 Boolean status 表达开关，却从未接收 null → 改用 boolean 可省去拆箱开销和判空逻辑
- 缓存 key/value 使用 Long 存 ID，但 Redis 原生只认字符串 → 实际多了一次
toString()和valueOf()来回转换
重构时可配合 IDE 的“Find Usages”，统计某个包装类字段的全部读写点，判断其是否真有 null 场景需求。
用 -XX:+PrintCompilation 和 -XX:+UnlockDiagnosticVMOptions 辅助验证
启动 JVM 时加上这些参数，能观察到：
- 频繁调用 Integer.valueOf(int) 或 Long.valueOf(long) 的热点方法
- 大量 Integer.intValue() 出现在热点栈帧中
- 编译器对小整数（-128~127）做了缓存优化，但超出范围仍频繁 new 对象 —— 这正是性能拐点
结合 JMH 写微基准测试，对比 int[] vs ArrayList<Integer> 在相同计算逻辑下的吞吐量差异，量化装箱成本，推动团队共识。
