在Java中什么是内存泄漏_Java资源无法释放原因解析_技术教程

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 cache = new HashMap(); 无清理逻辑、无过期机制
真实后果：缓存对象持有大量业务实体（如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上。任何注册了回调但没注销的行为，

都会让被监听对象无法释放。

常见漏点：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 data = new ArrayList<>();
    public void start() {
        scheduler.scheduleAtFixedRate(() -> {
            System.out.println(data.size()); // 捕获了this，Service实例无法回收
        }, 0, 1, SECONDS);
    }
}