频繁自动装箱会加剧年轻代GC压力，应精准控制装箱时机：优先复用基本类型，避免在循环计数、中间计算等场景无谓装箱，仅在需Object行为（如null判断、泛型）时才使用包装类。
Java 中自动装箱（如 int → Integer）频繁发生时，会持续创建短生命周期的包装对象，加重年轻代 GC 压力，尤其在循环、集合操作或高并发场景下容易引发 GC 频繁甚至 STW 时间上升。稳住的关键不是禁用装箱，而是**精准控制装箱发生的时机和范围**。
优先复用基本类型，避开无谓装箱
很多装箱其实可以完全避免。比如循环计数、中间计算、方法参数传递等，只要逻辑不依赖 Object 行为（如 null 判断、泛型约束），就坚持用 int、long、boolean 等原始类型。
- 不要为了“统一写法”把
for (int i = 0; i 改成for (Integer i = 0; i —— 后者每次迭代都触发Integer.valueOf()和可能的新对象分配 - 日志拼接中避免
log.info("count=" + count)（count是int）→ 字符串加法会隐式装箱；改用占位符：log.info("count={}", count)（SLF4J）或String.format的显式控制
谨慎使用集合，善用原始类型替代方案
ArrayList 是装箱重灾区：每存一个 int 就新建一个 Integer 对象。高频数值集合场景应切换为原始类型专用库：
-
Eclipse Collections：提供
IntList、LongObjectHashMap等，底层用数组/原生字段存储，零装箱 -
FastUtil：如
IntArrayList、Int2ObjectOpenHashMap，性能高且内存紧凑 - JDK 16+ 可关注
Vector API或等待未来Primitive Generics（仍在孵化），但目前不建议为等特性而妥协
控制 valueOf 缓存边界，避免缓存失效陷阱
Integer.valueOf(int) 在 [-128, 127] 范围内返回缓存实例，超出则 new 对象。看似省事，但容易误判：
- 别假设“小数字一定不 GC”——如果业务中大量使用
Integer.valueOf(200)，每个都 new，缓存毫无意义 - 若必须用
Integer，且值域可控（如状态码 0~99），可提前构建静态缓存池：private static final Integer[] CACHE = IntStream.range(0, 100).mapToObj(Integer::valueOf).toArray(Integer[]::new);，再通过CACHE[i]获取（注意越界检查） - 对
Long、Short等，缓存范围更窄（Long默认只缓存 [-128, 127]），更要警惕
用 JFR + GC 日志定位真实热点
别靠猜。开启 JVM 参数实锤问题来源：
-
-XX:+UseG1GC -Xlog:gc*:file=gc.log:time,uptime,level,tags观察G1 Evacuation Pause频率与 Eden 区存活对象大小 -
-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr，用 JDK Mission Control 分析 “Allocation in New TLAB” 事件，按类名排序，看java.lang.Integer是否排前三 - 配合
jstack或 Arthastrace命令，抓取高频调用栈，确认是哪个方法在密集装箱（例如 JSON 序列化、DTO 转换、统计聚合）
稳的核心在于“可知、可控、可减”：先看清哪来的装箱，再砍掉非必要场景，最后用原始集合兜底高频路径。不复杂但容易忽略细节。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
