【内存泄漏】一个现网问题告诉你血淋淋的事实：java内存泄漏很严重

本文链接：https://blog.youkuaiyun.com/CurWer_SenFor/article/details/128641259

文章介绍了Java中的内存泄漏概念，GC原理，包括引用记数和可达性判断，以及GCRoots的作用。通过一个现网问题案例，展示了由于未正确关闭三方SDK资源导致的内存泄漏，最终通过调用destroy方法解决了问题。总结中提到了几种常见的内存泄漏场景，如静态集合、监听器、未关闭的资源和单例模式。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

什么是内存泄漏

内存泄漏的本质就是对于程序来讲已经没有存在意义的对象继续驻留内存中，无法被GC回收，导致的内存被浪费现象。当无法回收的内存累积到一定程度时会发生性能急剧下降或者OOM。

GC原理

GC通过引用记数和对象可达判断一个对象是否应该被回收。
引用记数：每个对象有一个引用记数属性，新增加一个引用时加1，引用释放时记数减1，计数为0时，对象可以被回收。但是引用记数无法解决循环引用的问题。如下图中对象F和对象E,E和F对象没有被真正使用，但是无法被判定为应该被回收的对象。
可达判断：抽象对象间的引用关系是一个有向图，根节点是GC Roots。从GC Roots沿着引用链搜索，当一个对象到GC Roots没有引用链连接时，则该对象不可达，即该对象没有被引用，是一个可以被回收的对象。判断对象可达，能够解决循环引用的问题。
在这里插入图片描述

GC Roots对象

GC(Garbage Collector) Roots，特指的是垃圾收集器（Garbage Collector）的对象，GC会收集那些不是GC Roots且没有被GC Roots引用的对象。
一个对象可以属于多个GC Roots，GC Roots有几下种：

Class - 由系统类加载器(system class loader)加载的对象，这些类是不能够被回收的，他们可以以静态字段的方式保存持有其它对象。我们需要注意的一点就是，通过用户自定义的类加载器加载的类，除非相应的java.lang.Class实例以其它的某种（或多种）方式成为Roots，否则它们并不是roots。
Thread - 活着的线程
Stack Local - Java方法的local变量或参数
JNI Local - JNI方法的local变量或参数
JNI Global - 全局JNI引用
Monitor Used - 用于同步的监控对象
Held by JVM - 用于JVM特殊目的由GC保留的对象，但实际上这个与JVM的实现是有关的。可能已知的一些类型是：系统类加载器、一些JVM知道的重要的异常类、一些用于处理异常的预分配对象以及一些自定义的类加载器等。然而，JVM并没有为这些对象提供其它的信息，因此需要去确定哪些是属于"JVM持有"的了。

java内存模型

java运行时的内存分配策略为：静态分配、栈式分配、堆式分配，各分配策略对应内存区及存储的数据如下图。
在这里插入图片描述

现网问题

在整体架构上，我们现网环境是一个三方鉴权中心的接入方，在环境上我们有一个模块A，用于和鉴权中心通信，完成用户的单点登录。在系统上线运行两周后，模块A的CPU和内存使用率持续增加，CPU时间累积占用152.62%(8核)、内存占用超过35.80%。导致用户登录较慢或者无法登录，影响较大。以上问题在测试环境还无法模拟出来。
在这里插入图片描述

如何发现和解决

减少线程数
由于本模块里面有大量的鉴权操作及线程操作，每次用户操作都会查询数据库进行鉴权。怀疑是线程过多以及线程中有大量的临时变量导致。初步思路是使用线程池减少随意的线程增长、使用缓存存储权限数据(权限数据基本固定、定时查询即可)。但是整改后，经过一周，CPU和内存使用率依然增长。
Jstack工具
过了一周问题又重现了，由于不能使用过长的时间分析现网问题，只能先用jstack -l 1 > jstack.log保存下当前时刻的线程快照（进程运行在docker容器中，进程ID是1），然后重启A服务，先尽快的恢复服务(万能的重启)。
通过对线程堆栈的分析，发现存在7000多个IdleConnectionMonitorThread，并且线程还是等待状态。
在这里插入图片描述
通过对A模块代码分析，该线程是在与三方鉴权中心对接时通过三方的SDK创建。

    public void init() {
        this.uri = String.format("%s://%s", this.protocal, this.domainName);
        ConnectionSocketFactory plainsf = PlainConnectionSocketFactory.getSocketFactory();
        LayeredConnectionSocketFactory sslsf = SSLConnectionSocketFactory.getSocketFactory();
        Registry<ConnectionSocketFactory> registry = RegistryBuilder.create().register("http", plainsf).register("https", sslsf).build();
        PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(registry);
        cm.setMaxTotal(800);
        cm.setDefaultMaxPerRoute(400);
        HttpClientBuilder httpClientBuilder = HttpClients.custom();
        if (null != this.getRoutePlanner()) {
            httpClientBuilder = httpClientBuilder.setRoutePlanner(this.getRoutePlanner());
        }

        this.httpClient = httpClientBuilder.setConnectionManager(cm).setConnectionManagerShared(true).build();
        this.idleConnectionMonitorThread = new ExecutableClient.IdleConnectionMonitorThread(cm, this.idletime);
        this.idleConnectionMonitorThread.start();
    }

继续排查代码。发现A模块在每次使用完毕后，没有调用destroy方法导致。

    public void destroy() {
        if (this.idleConnectionMonitorThread != null) {
            this.idleConnectionMonitorThread.shutdown();
            try {
                this.idleConnectionMonitorThread.join();
            } catch (InterruptedException var3) {
            }
        }
        if (this.httpClient != null) {
            try {
                this.httpClient.close();
            } catch (IOException var2) {
            }
        }
    }

解决方法
每次使用完毕三方SDK的资源对象后，调用destroy()方法。这是个典型的资源使用完毕没有释放，导致内存泄漏的问题。
修改后，内存使用率从35.80%降至4.6%。CPU也下降50%，但是依然有92.4%，肯定也有问题，请见我另一篇博客记一次由于临时变量导致的CPU使用率过高问题。

在这里插入图片描述