循环中大量自动装箱会显著增加对象创建开销和GC压力，导致执行变慢、内存占用升高、Young GC频繁及堆碎片化；实测显示用Long累加比用long慢14倍以上。
在循环里大量使用自动装箱，最直接的性能问题是显著增加对象创建开销和GC压力，进而拖慢执行速度、升高内存占用，甚至引发频繁的 Young GC 或堆内存碎片化。
每次装箱都新建对象，循环次数越多代价越大
Java 中像 Integer i = 100、sum += i（其中 sum 是 Long）这类写法，编译器会自动插入 Integer.valueOf() 或 Long.valueOf() 调用。但注意：
- 超出缓存范围（如
Integer默认是 -128 到 127）时，valueOf()每次都会 new 一个新对象； - 即使在缓存范围内，若涉及多线程或自定义缓存策略，也可能失效；
- 循环执行百万次，就可能产生百万个短命包装对象，全部分配在堆上。
堆内存快速填满，触发高频垃圾回收
这些包装对象生命周期极短，几乎都在本次循环内就不再被引用，很快进入 Young GC 的回收范围：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Eden 区迅速占满，Minor GC 频率上升；
- Survivor 区反复复制、空间不足，导致对象提前晋升到老年代；
- 大量小对象还容易造成内存碎片，尤其在 G1 或 CMS 垃圾收集器下，影响分配效率和停顿时间。
CPU 和时间开销成倍放大
实测数据很说明问题：
立即学习“Java免费学习笔记（深入）”；
- 用
Long sum = 0L在亿级循环中累加，耗时约 470ms； - 改用
long sum = 0L，同样逻辑仅需约 33ms —— 快了 14 倍以上； - 根本差异就在于：前者每轮都经历拆箱 → 计算 → 装箱三步，后者全程在栈上操作原始值，无对象开销。
隐式装箱更危险：你以为没创建，其实已经发生了
有些场景容易被忽略，但同样触发装箱：
-
list.add(i)（i是int，而list是ArrayList<Integer>）； - 泛型方法传入基本类型参数，如
processValue(42)，而方法签名是<T> void processValue(T t)； - 用
==比较两个Integer，看似只是判断，但若涉及计算或条件分支，可能连带触发多次装箱拆箱。
