泛型本身不导致装箱拆箱，真正开销来自泛型边界上的隐式类型转换，如list的add(int)触发装箱、get(i)赋值给int触发拆箱，且valueof(128)无缓存加剧gc压力。
泛型本身不直接导致装箱拆箱，真正带来性能开销和 GC 压力的是**在泛型边界上发生的隐式类型转换**——尤其是把基本类型塞进泛型集合（如 List<integer></integer>）或从其中读取时。
关键评估点：装箱拆箱是否真实发生
Java 泛型存在类型擦除，List<integer></integer> 运行时仍是 List，但编译器会在必要位置插入 Integer.valueOf() 和 intValue()。是否触发，取决于两点：
-
写入时：向
List<integer></integer>add(int) → 必须装箱（调用valueOf） -
读取时：从
List<integer></integer>get(i) 赋值给 int → 必须拆箱（调用intValue） -
缓存范围外的值：
Integer.valueOf(128)每次都 new 对象，而valueOf(100)复用缓存对象，影响 GC 频率
量化评估方法
不能只看代码行数，要结合运行时行为测量：
-
内存分配率：用 JFR（Java Flight Recorder）或 VisualVM 观察年轻代每秒分配 KB 数；循环中
list.add(i)每万次可能新增几 MB 短命对象 -
GC 日志分析：开启
-XX:+PrintGCDetails，关注 Young GC 频次与每次回收对象数；频繁 minor GC 往往是装箱暴增的信号 -
热点方法采样：用 async-profiler 抓火焰图，
Integer.valueOf或Integer.intValue出现在高频路径中，就是瓶颈
典型高风险场景
这些写法看似简洁，实则暗藏开销：
- for (int i = 0; i → 十万次装箱，十万新
Integer对象 -
int sum = list.get(0) + list.get(1); → 两次拆箱 + 一次装箱（如果结果又存回
List<integer></integer>） -
map.put("key", 42);（
Map<string integer></string>）→ 42 自动装箱
替代方案与优化方向
不是禁用泛型，而是避开“基本类型 ↔ 包装类”这个转换桥：
- 数值密集场景改用
int[]、long[]等原始数组 - 需要动态扩容时，选用 Eclipse Collections 的
IntArrayList或 Trove 的TIntArrayList - 若必须用
List<integer></integer>，尽量批量操作、减少单元素读写；避免在 tight loop 中反复 get/set - 警惕隐式运算：
Integer a = 1; Integer b = 2; Integer c = a + b;→ 拆箱 ×2 + 装箱 ×1
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
