Java内存泄漏主因是废弃对象被强引用滞留于GC Roots路径：静态集合、ThreadLocal残留、未关闭资源、闭包捕获均会导致。须用WeakHashMap、remove()、try-with-resources、局部final变量等修复，并用jmap+VisualVM查支配树定位根源。
Java中内存泄漏不是“没调用free”，而是对象明明业务上已废弃，却因被某个存活对象**强引用着**，始终挂在GC Roots可达路径上，导致JVM不敢回收——这才是最常被误解的起点。
静态集合类：最隐蔽的“永久房东”
静态集合（如static Map、static List）生命周期与类加载器一致，只要类没卸载，里面存的对象就永远可达。哪怕你只存了一次，后续再没访问过，GC也无权动它。
- 典型错误：
private static final Map<string object> cache = new HashMap();</string>无清理逻辑、无过期机制 - 真实后果：缓存对象持有大量业务实体（如
User、Order），这些实体又引用DAO、上下文、甚至整个Spring容器Bean - 修复动作：改用
WeakHashMap（key弱引用）、或搭配ConcurrentHashMap+ 定时清理线程 +remove()显式淘汰；更推荐用Caffeine等带LRU+TTL的成熟缓存库
ThreadLocal：线程池里的“幽灵残留”
在Web应用中，ThreadLocal配合线程池使用极易泄漏——因为线程复用，而ThreadLocal的value是强引用，key虽为弱引用，但一旦线程不退出，value就一直卡在ThreadLocalMap里出不去。
- 高危写法：
threadLocal.set(new BigObject());后未调用threadLocal.remove() - 现象：压测后堆内存缓慢上涨，
OutOfMemoryError: Java heap space，但对象直方图里满是BigObject实例 - 必须做：每次使用完必须
remove()，尤其在Filter、Interceptor、AOP环绕通知等横切位置；不要依赖initialValue()自动创建后就撒手不管
未关闭资源：不只是IO，还有监听器和连接
资源泄漏不只发生在InputStream或Connection上。任何注册了回调但没注销的行为，都会让被监听对象无法释放。
立即学习“Java免费学习笔记（深入）”；
- 常见漏点：
addWindowListener()、addPropertyChangeListener()、registerReceiver()（Android）、eventBus.register(this) - 数据库/Redis连接：用完不
close()，连接对象本身可能不大，但它背后持有着Socket、Buffer、SSLContext等重型资源 - 正确姿势：优先用
try-with-resources；非AutoCloseable资源（如监听器），务必在onDestroy()、finally或@PreDestroy中显式反注册
闭包与内部类：Lambda不是“免费的”
Lambda表达式会隐式捕获所在作用域的this或局部变量。如果这个Lambda被长生命周期对象（如定时器、静态线程池）持有，那它捕获的外部对象就跟着“锁死”了。
- 危险示例：
public class Service { private final List<String> data = new ArrayList<>(); public void start() { scheduler.scheduleAtFixedRate(() -> { System.out.println(data.size()); // 捕获了this，Service实例无法回收 }, 0, 1, SECONDS); } } - 解法一：把要访问的字段提取成局部变量并声明为
final（避免捕获this）；解法二：改用静态方法引用；解法三：用WeakReference包装外部对象再访问
真正难排查的从来不是“哪里没关”，而是“谁还在悄悄引用着它”。一次jmap -dump:format=b,file=heap.hprof <pid> + VisualVM打开分析“支配树（Dominators Tree）”，往往比读十遍代码更快定位到那个不肯放手的引用源头。
