长生命周期线程本身不直接导致内存泄漏，但会因隐式强引用（如非静态内部类持外部类引用）、threadlocal未remove、静态集合滥用及资源未关闭等问题引发内存泄漏。
长生命周期线程（比如线程池中的复用线程）本身不会直接“泄漏内存”，但它们会成为内存泄漏的温床——关键在于线程持有不该长期持有的对象引用，导致这些对象无法被回收。
线程池复用引发的隐式强引用
线程池里的线程被反复使用，生命周期远超单次任务。如果任务中创建了非静态内部类、匿名类（如 Runnable、Handler、监听器），它们会隐式持有所在外部类的引用（通过 this$0 字段）。一旦这个内部类实例被注册到静态容器、提交给全局线程池、或作为回调长期存活，它就变成 GC Roots 的延伸路径，连带把整个外部类“钉”在内存里。
- 典型场景：Activity 中定义的匿名 Handler 提交到静态线程池；Service 中的非静态 AsyncTask 被缓存；Fragment 内部的 Callback 注册后未注销
- 验证方式：用 MAT 打开堆转储，找到疑似泄漏的 Activity 实例 → 右键 “Path to GC Roots” → 排除弱/软引用 → 若路径中出现某个 Runnable 或 Listener，且其 this$0 指向该 Activity，即确认泄漏
ThreadLocal 是高危区
ThreadLocal 本质是每个线程维护一个 ThreadLocalMap，key 是 ThreadLocal 实例（弱引用），value 是你存的数据（强引用）。问题出在 value 上：线程复用时，若没调用 remove()，value 就一直留在 map 里，无法被回收。
- 尤其危险的是存了大对象（如 Map、缓存数据、数据库连接）或持有外部类引用的对象
- 即使把 ThreadLocal 变量设为 null，只清除了 key，value 仍因 map 对它的强引用而滞留
- 修复必须显式调用
threadLocal.remove()，最好放在 try-finally 或使用 try-with-resources 包裹逻辑
静态变量 + 线程组合成“内存锚点”
静态集合（如 static List、static Map）本身生命周期与 JVM 同级。当线程向其中添加对象，或把线程局部对象存进去，就等于把短命对象“绑定”到长命容器上。
- 例如：静态队列接收 Runnable，Runnable 内部又持有 Activity 引用 → Activity 永远无法回收
- 再如：单例类中维护一个 static ConcurrentHashMap，put 进去的对象没设计过期或清理机制 → 缓存无限膨胀
- 对策不是禁用静态变量，而是严格控制写入内容：只存轻量 ID、避免存业务实体；或搭配 WeakReference、定时清理策略
资源未关闭加剧泄漏后果
线程执行过程中打开的资源（InputStream、Connection、Socket），若未 close，不仅自身对象无法回收，还会占用操作系统级资源（文件句柄、端口等），进一步拖慢 GC 效率，放大内存压力。
- 常见于异步任务中：线程从数据库查完数据后，忘记关闭 ResultSet 和 Connection
- Java 7+ 推荐用 try-with-resources 自动释放；旧代码务必在 finally 块中 close，并判空
- 注意：close() 失败也要确保资源引用被置 null，防止残留强引用干扰 GC
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
