Java 服务内存占用过高的一次排查过程

ゝ一纸荒年。 2023-10-07 11:27 70阅读 0赞

#### 文章目录 ####

*  1. 缘由
 *  2. 线上排查
 *  3. 代码排查
 *  4. 解决方法

## 1. 缘由 ##

日常敲代码时，运维同事突然把小组人员都拉进了一个群里，说一台线上机器内存耗尽，OOM 导致服务注册的 Mesh 客户端被干掉了，部分服务调用异常。运维同事查看机器负载，发现我们组内一个Java 服务占用的内存有点异常，启动命令`-Xmx128m` 指定了最大堆内存只有 128M，但是整个进程占用的内存达到了 640M，显然是有问题的

## 2. 线上排查 ##

运维截图一扔，锅是甩不掉的，老老实实登录到线上机器排查。内存占用过高首先想到的就是发生了`内存泄露`，使用 `jmap -histo $pid > heap.log` 输出堆内对象统计情况到文件中，查看文件发现堆中占用内存最多的是各种数组，没有发现明显的问题。没法子，使用 `top -H p $pid`命令检查该进程内运行的线程状况，终于发现了可疑点，在这个Java 服务里面运行的子线程居然有 5000 个，并且几乎全部都在 Sleeping 状态  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTUwNTMxMw_size_16_color_FFFFFF_t_70]  
这种情况首先想到的是发生了线程死锁，资源争用导致大量线程被阻塞了。使用 `jstack -l $pid > stack.log` 将线程栈相关状况输出到文件中，打开文件一搜索却大失所望，根本没有死锁发生。线程状态大都在 `TIMED_WAITING`，不过随着一行行往下看，也发现了一个可疑点，以下这种 `OkHttp ConnectionPool` 的线程出现得太多了，线程序号甚至达到了1082707

"OkHttp ConnectionPool" #1082707 daemon prio=5 os_prio=0 tid=0x00007f564c18f000 nid=0x1a4d in Object.wait() [0x00007f5602cb4000]
       java.lang.Thread.State: TIMED_WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            at java.lang.Object.wait(Object.java:460)
            at okhttp3.ConnectionPool$1.run(ConnectionPool.java:67)
            - locked <0x00000000fc30fb30> (a okhttp3.ConnectionPool)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
            at java.lang.Thread.run(Thread.java:748)
    
       Locked ownable synchronizers:
            - <0x00000000fc305f98> (a java.util.concurrent.ThreadPoolExecutor$Worker)

此时回过头来看堆内存文件，发现以下记录，`okhttp3.ConnectionPool` 这个连接池对象实例占用的内存虽然不多，只有300K，但是实例总数居然有 7876 个，毫无疑问是有问题的

40:          7876         315040  okhttp3.ConnectionPool

## 3. 代码排查 ##

可疑点在于 `ConnectionPool` 这个对象的数量，在项目中搜索 `ConnectionPool` 对象初始化调用点，发现 `OkHttpClient` 初始化时会调用 `ConnectionPool` 的构造方法，也就是每一个 `OkHttpClient` 实例被创建出来都会伴随着一个连接池 `ConnectionPool`的创建。而在项目代码中，每次进行 RPC 调用的时候都会重新创建一个 `OkHttpClient` 对象，至此一切豁然开朗

*  **原因剖析**  
    `OkHttpClient` 对象在使用过后会被 JVM 回收，但是 `OkHttp`源码中`ConnectionPool`的构造方法里默认最大线程空闲数是5，keepAlive 时间为5分钟，也就是发起一次网络连接后，5分钟内不会断开连接。这样当`OkHttpClient` 对象被 JVM 回收时，`ConnectionPool` 因为有线程还保持着与服务端的连接，处于`Active`状态，5 分钟内不会被回收，自然也不会释放线程资源。线程会占用内存空间，这样随着时间积累，线程数量越来越多，进程占用的内存自然也越来越多了
    
        /**
        * Create a new connection pool with tuning parameters appropriate for a single-user application.
        * The tuning parameters in this pool are subject to change in future OkHttp releases. Currently
        * this pool holds up to 5 idle connections which will be evicted after 5 minutes of inactivity.
        */
        public ConnectionPool() {
              
         this(5, 5, TimeUnit.MINUTES);
        }

## 4. 解决方法 ##

问题根源找到了，修复自然简单。项目代码中每次进行 RPC 调用都重新创建一个 `OkHttpClient` 对象，这实际上是极大的性能浪费，只要在代码中保存一个静态 `OkHttpClient` 对象，每次网络请求都复用这个对象就可以了

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTUwNTMxMw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200320164642143.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTUwNTMxMw==,size_16,color_FFFFFF,t_70