该问题本质是短命对象在高频路径中批量生成导致的“分配风暴”，需通过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<integer></integer>，对比分配次数下降幅度

轻量验证与根因修复

避免只换写法不改语义的伪优化：

• 用 javap -c 反编译可疑代码，确认是否真调用了 Integer.valueOf(int)（而非直接字面量缓存）
• 对循环体做最小化剥离：注释掉疑似装箱逻辑，观察 GC 频率是否显著回落
• 集合操作优先使用原始类型容器（如 LongSparseArray、androidx.collection:collection）
• 日志拼接改用占位符方式：Log.d("tag", "id=%d", id)，避免隐式字符串拼接触发装箱链