直接改用基本类型能同时缓解元空间压力和堆内存GC频率；因包装类型高频装箱会触发类加载并维持元空间引用，导致堆与元空间垃圾对流，而基本类型可切断该隐性耦合链。
直接改用基本类型，能同时缓解元空间压力和堆内存 GC 频率——这不是权衡取舍，而是切断一条隐性耦合链。
包装类型高频更新会意外加剧元空间负担
Integer、Long 等包装类每次自动装箱，都会触发 ClassLoader 加载 java.lang.Integer 类（如果尚未加载）；更关键的是，JVM 为每个新创建的包装对象分配堆内存的同时，还会在元空间中维护其对应的 Class 元数据引用。尤其在循环中反复 Long sum = sum + item.value 这类操作，每轮都经历：拆箱 → 计算 → 装箱 → 新对象 → 引用入局部变量槽。这不仅制造大量短命堆对象，还持续触碰类加载器的缓存与引用链，间接拖慢类卸载节奏。
堆与元空间的“垃圾对流”真实存在
你看到的“频繁 Full GC + 元空间缓慢上涨”，往往不是两个独立问题。当大量包装对象堆积（如百万次循环生成百万个 Integer），GC 清理堆时若其 Class 对象仍被类加载器强引用（比如自定义类加载器未释放、或线程上下文类加载器污染），该 Class 就无法卸载 → 元空间不释放 → 下次装箱又复用同一类 → 但新对象仍需堆空间 → 堆又涨 → GC 更勤……形成跨区域正反馈。
重构实操四步到位
- 把循环内累加、计数、状态标记等场景的
Integer/Long/Boolean全部换成int/long/boolean - 检查方法签名：避免
public void process(List<integer> ids)</integer>这类接口强制引入包装类型；如需泛型兼容，用int[]或IntArrayList（如 Eclipse Collections）替代List<integer></integer> - 清理缓存层：
Map<string integer></string>改为Object2IntOpenHashMap（fastutil）或Int2ObjectOpenHashMap，避开Integer实例化 - 禁用无意义的
valueOf()显式调用：Integer.valueOf(x)在循环里等价于new Integer(x)（超出缓存范围时），直接写x即可
注意边界：别误伤必须用包装类型的场景
- 集合元素、泛型容器、JSON 序列化字段、可空语义（如
Integer port表示“未配置”）仍应保留包装类型 - 重构重点是“高频局部计算变量”，不是全局模型字段
本质上，这是把本该在栈上完成的整数运算，从堆+元空间协同开销中解耦出来。改完后，堆 GC 次数下降明显，元空间增长曲线也会趋于平缓——因为少了那层“为临时对象反复确认类定义”的开销。
