自动装箱本身不直接导致内存泄漏，但会放大引用持有问题：当包装类对象被静态集合、ThreadLocal等长生命周期容器强持有且未清理时，引发泄漏；排查重点是识别这些被意外保留的Integer、Long等实例。
自动装箱本身不会直接导致内存泄漏，但它在特定组合场景下会放大引用持有问题，成为泄漏的“帮凶”。关键不在“装箱”动作，而在装箱后产生的对象被长生命周期容器意外强持有——比如放进静态集合、缓存或未清理的ThreadLocal中。排查重点是识别这些被“悄悄留住”的包装类实例（Integer、Long、Boolean等），而非盯着装箱语法本身。
盯住高频泄漏载体：静态集合 + 包装类
这是最典型场景。例如用 static Map<integer user></integer> 缓存用户，但 key 用的是循环中不断装箱生成的 Integer.valueOf(i)。虽然 Integer 有缓存池（-128~127），但超出范围的值会新建对象；若 map 不清理，这些 Integer 实例就永远无法回收。
- 检查所有
static集合声明，确认其泛型是否含基本类型包装类 - 搜索代码中
map.put(xxx, ...)或list.add(...)的调用点，看入参是否来自循环变量、计数器、ID生成器等易重复装箱的来源 - 特别注意
ConcurrentHashMap—— 它线程安全，但开发者常误以为“安全=可无限增长”，忽略清理逻辑
查 ThreadLocal 中的包装类残留
ThreadLocal 常用于传递上下文，如 ThreadLocal<long></long> 存 traceId。若线程来自线程池（如 Tomcat 的 worker 线程），且未在请求结束时调用 remove()，那么每次请求装箱生成的 Long 对象就会累积在该线程的 ThreadLocalMap 中。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 定位所有
ThreadLocal>声明，尤其是泛型为Integer、Long、Boolean的 - 检查每个使用处：是否在 filter / interceptor / finally 块中配对调用了
threadLocal.remove() - 注意 Spring 的
@Transactional或 AOP 切面可能绕过常规清理路径，需额外验证
用工具抓“异常多”的包装类实例
内存快照里，Integer、Long 实例数远超预期，就是强信号。不要只看数量，要看它们被谁引用着。
立即学习“Java免费学习笔记（深入）”；
- 用 VisualVM 或 MAT 打开 heap dump，在 Histogram 中按 class 排序，重点关注
java.lang.Integer、java.lang.Long的实例数和 shallow heap 占比 - 右键某个高占比的包装类实例 → “Path to GC Roots”，看它是否挂在
static字段、java.lang.ThreadLocal$ThreadLocalMap或大型缓存对象下 - 若发现大量相同值（如全是
10001、10002）的Integer，基本可断定是循环装箱+未清理集合所致
代码层面快速验证与修复
不依赖工具也能快速缩小范围：
- 临时加日志：在疑似装箱位置（如
map.put(id, user)）打印id.getClass().getName()和System.identityHashCode(id)，确认是否每次都是新对象 - 把静态集合换成
WeakHashMap（key 为弱引用）做对比测试——若泄漏缓解，说明确实是 key 持有问题 - 对 ThreadLocal，统一封装一个工具类：
public static <t> void setAndRemove(ThreadLocal<t> tl, T value) { tl.set(value); /* 注册 request completed 后 remove */ }</t></t>
