该问题本质是短命对象在高频路径中批量生成导致的“分配风暴”，需通过GC日志特征（如高频率Minor GC、低Survivor占用）反推装箱代码模式，并借助Profiler定位循环添加、三元运算、日志拼接等隐式装箱热点，最终以原始类型容器或占位符日志等方式根治。
这类问题本质是短命对象在高频路径中批量生成，直接冲击 Eden 区容量底线。它不表现为内存泄漏，而是“分配风暴”，必须从 GC 行为特征反推代码模式。
看 GC 日志确认装箱型分配特征
启用 -XX:+PrintGCDetails -Xloggc:gc.log 后，重点盯以下组合信号：
- Minor GC 频率极高（例如每秒 3～5 次以上），但每次回收量很小（Eden 区 GC 前几乎总达 95%+）
- Survivor 区占用长期低于 5%，说明绝大多数对象没活过一次 GC
- GC 日志中频繁出现 ParNew 或 G1 Evacuation Pause，且 pause 时间稳定在几毫秒（符合复制算法特性）
定位高频装箱发生位置
装箱不是写在代码里的 new Integer()，而是藏在看似自然的表达式里。重点关注以下场景：
- 循环中对基本类型调用集合方法：如
list.add(i)（i 是int）、map.put(key, value)中任一参数为基本类型 - 三元运算返回包装类：如
Integer x = flag ? 1000 : null（1000 超出-128 ~ 127缓存范围，每次执行都 new） - 日志拼接中混入基本类型或包装类：如
Log.d("tag", "id=" + id)（触发String.valueOf(long)→ 内部 new char[]） - 方法签名是包装类型，但调用传入基本类型：如
process(Long v)被调用为process(123L)
用 Profiler 快速验证分配热点
在 Android Studio Profiler 或 JFR 中录制典型操作（如列表快速滑动、按钮连点），开启 Allocation Tracking：
- 筛选
java.lang.Integer、java.lang.Long、java.lang.Boolean等类，观察是否在毫秒级内分配数百甚至上千次 - 点击高分配样本，查看 Call Stack —— 若堆栈落在
onBindViewHolder、onDraw、网络回调解析等高频方法内，基本可锁定 - 临时改用基本类型数组或
SparseArray替代ArrayList，对比分配次数下降幅度
轻量验证与根因修复
避免只换写法不改语义的伪优化：
- 用
javap -c反编译可疑代码，确认是否真调用了Integer.valueOf(int)（而非直接字面量缓存） - 对循环体做最小化剥离：注释掉疑似装箱逻辑，观察 GC 频率是否显著回落
- 集合操作优先使用原始类型容器（如
LongSparseArray、androidx.collection:collection） - 日志拼接改用占位符方式：
Log.d("tag", "id=%d", id)，避免隐式字符串拼接触发装箱链
