自动装箱拆箱本身不直接消耗大量CPU，但会因频繁对象创建、valueOf()/xxxValue()调用及GC压力间接推高CPU使用率；优化需减少对象分配、优先用基本类型、善用缓存范围并配合JVM监控定位瓶颈。
自动装箱和拆箱本身不直接消耗大量CPU，但它们会间接推高CPU使用率——核心在于频繁的对象创建、方法调用（valueOf()、xxxValue()）以及由此引发的GC压力。当GC频繁执行（尤其是Minor GC），JVM会暂停应用线程（Stop-The-World），导致CPU在GC线程上密集运行，同时业务线程等待，整体表现为CPU使用率异常升高。优化的关键是减少不必要的对象分配和避免隐式转换开销。
优先用基本类型替代包装类
这是最直接有效的手段。只要场景允许，就别用List<integer></integer>，改用原始类型集合或流：
- 循环累加、统计等计算逻辑中，全程使用
int、long等基本类型变量，避免在循环内对Integer做算术运算（会反复拆箱） - 批量处理数值时，改用
IntStream代替Stream<integer></integer>，例如：IntStream.range(0, 1000000).sum()比Stream.iterate(...).mapToInt(...).sum()更轻量 - 若需高性能数值集合，引入
Trove（TIntArrayList）或FastUtil（IntArrayList），它们完全绕过装箱，内存连续、缓存友好
警惕集合遍历中的隐式拆箱
for (Integer x : list) 或 list.get(i) % 2 == 0 看似简洁，实则每次访问都触发intValue()调用。高频循环下开销明显：
- 把拆箱操作提到循环外：先
int val = list.get(i)，再用val参与计算 - 对只读场景，考虑用数组
int[]替代List<integer></integer>，消除泛型擦除+装箱双重成本 - 避免在
if条件或switch中直接使用Integer（如if (obj != null && obj > 0)），先判空再拆箱
理解并善用整数缓存范围
Integer.valueOf(int)对[-128, 127]范围内的值复用缓存对象，超出则新建实例。这虽不直接影响CPU，但影响GC频率：
立即学习“Java免费学习笔记（深入）”；
- 若业务中大量使用固定小常量（如状态码、类型标识），尽量落在缓存区间内，减少对象创建
- 不要依赖
==比较Integer值（缓存外会失败），统一用.equals()或先拆箱再比，避免因误用引发逻辑错误和额外判断 - 对非小范围数值，明确使用基本类型接收，不保留
Integer引用，让对象尽早不可达
配合JVM监控定位真实瓶颈
优化不能靠猜测。确认是否真由装箱拆箱引发CPU升高：
- 开启GC日志（
-XX:+PrintGCDetails -Xlog:gc*），观察是否Minor GC极频繁且Eden区快速填满 - 用
async-profiler采样热点，过滤出Integer.valueOf、intValue或Object.clone（部分装箱触发）的调用栈占比 - 结合
jstat -gc <pid></pid>查看YGC次数和耗时，若YGC频次高、平均耗时短，大概率是短期对象爆炸
