自动装箱非bug但高频触发会拖慢程序、抖动GC、引发空指针；高危场景包括循环中泛型集合塞基本类型、日志拼接隐式装箱、三元运算混用字面量与null；需用Profiler或JMC定位，修复应语义降级——改用原始类型容器、占位符日志、基本类型变量，并警惕装箱与空值叠加导致的NPE。
自动装箱本身不是 bug，但高频、无意识地触发它，会实实在在拖慢程序、抖动 GC、甚至引发空指针——这些问题往往在线上才暴露，定位难、修复急。关键不在“会不会装箱”，而在“哪里不该装箱却装了”。
先盯住三类高危代码模式
这些写法在 IDE 里完全正常，编译无错，运行也大多没问题，但正是它们在后台疯狂 new 对象：
-
循环中往泛型集合塞基本类型：比如
list.add(i)（i是int），每次调用都走Integer.valueOf(i)；若i超出 -128～127 缓存范围，就真实分配新对象 -
日志或字符串拼接中隐式装箱：像
Log.d("tag", "id=" + id)，编译后实际执行String.valueOf(id)，内部新建char[]和包装类实例 -
三元运算混用基本字面量与 null：如
Integer x = cond ? 500 : null，500 不在缓存池内，每次执行都 new 一个Integer
用工具快速确认是不是它在作祟
别靠经验猜，拿数据说话：
-
Android 开发：在 Android Studio Profiler 中开启 Allocation Tracking，做一次典型操作（比如列表滑动），按类名排序，重点看
java.lang.Integer、java.lang.Long的分配次数——单次操作超 200 次，基本可判定为瓶颈 -
JVM 后端服务：加 JVM 参数
-XX:+FlightRecorder -XX:StartFlightRecording=duration=30s，用 JMC 打开录制文件，查看 “Allocation in young gen” 列表，如果包装类排进 Top 3，问题大概率坐实 -
快速验证：临时把可疑逻辑替换成纯基本类型版本（例如用
int[]替ArrayList<Integer>），对比 YGC 频率变化，抖动明显下降就能锁定根源
修复核心是语义降级，不是语法微调
不是把 list.add(i) 改成 list.add(Integer.valueOf(i)) 就完事——这没解决本质问题。真正有效的是让“本不该对象化”的地方彻底脱离对象生命周期：
立即学习“Java免费学习笔记（深入）”；
-
集合优先用原始类型容器：Android 上用
SparseArray<String>替HashMap<Integer, String>；Java 后端引入IntArrayList（如 Eclipse Collections）或IntObjectMap -
日志统一走占位符：SLF4J 写成
log.info("count={}, flag={}", count, flag)，避免字符串拼接触发装箱；Android 的Log建议封装一层，参数传入前做预处理（例如Objects.toString(x, "null")） -
数值计算坚决用基本类型变量：累加、比对、状态判断等场景，声明用
long sum = 0L而非Long sum = 0L；实测同样一亿次循环，后者耗时可能是前者的 10 倍以上
特别警惕装箱和空值的叠加陷阱
很多 NPE 并非来自对象为空，而是拆箱时突然炸：
- 数据库字段允许为空，用
Integer接收后直接参与sum += value，value 为 null 时瞬间抛NullPointerException - RPC 或缓存返回值未判空，直接赋给基本类型变量（如
int id = user.getId()），一旦getId()返回 null，强制拆箱即崩溃 - 三目运算一边是基本字面量、一边是可能为 null 的包装类，编译器会统一提升为包装类型，后续任何未检空的使用都埋雷
不复杂，但容易忽略。
