CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章JVM FULL GC 生产问题 II-如何定位内存泄露？由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

情景回顾 。

我们在上一篇 JVM FULL GC 生产问题笔记 中提出了如何更好的实现一个多线程消费的实现方式.

没有看过的小伙伴建议看一下.

本来以为一切都可以结束的，不过又发生了一点点意外，这里记录一下，避免自己和小伙伴们踩坑.

生产-消费者模式

  。

简介 。

上一节中我们尝试了多种多线程方案，总会有各种各样奇怪的问题.

于是最后决定使用生产-消费者模式去实现.

实现如下:

这里使用 AtomicLong 做了一个简单的计数.

userMapper.handle2(Arrays.asList(user)); 这个方法是同事以前的方法，当然做了很多简化.

就没有修改，入参是一个列表。这里为了兼容，使用 Arrays.asList() 简单封装了一下.

1. import com.github.houbb.thread.demo.dal.entity.User; 
2. import com.github.houbb.thread.demo.dal.mapper.UserMapper; 
3. import com.github.houbb.thread.demo.service.UserService; 
4.  
5. import java.util.Arrays; 
6. import java.util.List; 
7. import java.util.concurrent.*; 
8. import java.util.concurrent.atomic.AtomicLong; 
9.  
10. /** 
11.  * 分页查询 
12.  * @author binbin.hou 
13.  * @since 1.0.0 
14.  */ 
15. public class UserServicePageQueue implements UserService { 
16.  
17.     // 分页大小 
18.     private final int pageSize = 10000; 
19.  
20.     private static final int THREAD_NUM = 20; 
21.  
22.     private final Executor executor = Executors.newFixedThreadPool(THREAD_NUM); 
23.  
24.     private final ArrayBlockingQueue<User> queue = new ArrayBlockingQueue<>(2 * pageSize, true); 
25.  
26.  
27.     // 模拟注入 
28.     private UserMapper userMapper = new UserMapper(); 
29.  
30.     /** 
31.      * 计算总数 
32.      */ 
33.     private AtomicLong counter = new AtomicLong(0); 
34.  
35.     // 消费线程任务 
36.     public class ConsumerTask implements Runnable { 
37.  
38.         @Override 
39.         public void run() { 
40.             while (true) { 
41.                 try { 
42.                     // 会阻塞直到获取到元素 
43.                     User user = queue.take(); 
44.                     userMapper.handle2(Arrays.asList(user)); 
45.  
46.                     long count = counter.incrementAndGet(); 
47.                 } catch (InterruptedException e) { 
48.                     e.printStackTrace(); 
49.                 } 
50.             } 
51.         } 
52.     } 
53.  
54.     // 初始化消费者进程 
55.     // 启动五个进程去处理 
56.     private void startConsumer() { 
57.         for(int i = 0; i < THREAD_NUM; i++) { 
58.             ConsumerTask task = new ConsumerTask(); 
59.             executor.execute(task); 
60.         } 
61.     } 
62.  
63.     /** 
64.      * 处理所有的用户 
65.      */ 
66.     public void handleAllUser() { 
67.         // 启动消费者 
68.         startConsumer(); 
69.  
70.         // 充值计数器 
71.         counter = new AtomicLong(0); 
72.  
73.         // 分页查询 
74.         int total = userMapper.count(); 
75.         int totalPage = total / pageSize; 
76.         for(int i = 1; i <= totalPage; i++) { 
77.             // 等待消费者处理已有的信息 
78.             awaitQueue(pageSize); 
79.  
80.             System.out.println(UserMapper.currentTime() + " 第 " + i + " 页查询开始"); 
81.             List<User> userList = userMapper.selectList(i, pageSize); 
82.  
83.             // 直接往队列里面扔 
84.             queue.addAll(userList); 
85.  
86.             System.out.println(UserMapper.currentTime() + " 第 " + i + " 页查询全部完成"); 
87.         } 
88.     } 
89.  
90.     /** 
91.      * 等待，直到 queue 的小于等于 limit，才进行生产处理 
92.      * 
93.      * 首先判断队列的大小，可以调整为0的时候，才查询。 
94.      * 不过因为查询也比较耗时，所以可以调整为小于 pageSize 的时候就可以准备查询 
95.      * 从而保障消费者不会等待太久 
96.      * @param limit 限制 
97.      */ 
98.     private void awaitQueue(int limit) { 
99.         while (true) { 
100.             // 获取阻塞队列的大小 
101.             int size = queue.size(); 
102.  
103.             if(size >= limit) { 
104.                 try { 
105.                     // 根据实际的情况进行调整 
106.                     Thread.sleep(1000); 
107.                 } catch (InterruptedException e) { 
108.                     e.printStackTrace(); 
109.                 } 
110.             } else { 
111.                 break; 
112.             } 
113.         } 
114.     } 
115.  
116. } 

 测试验证 。

当然这个方法在集成环境跑没有任何的问题.

于是就开始直接上生产验证，结果开始很快，然后就可以变慢了.

一看 GC 日志，梅开二度，FULL GC.

可恶，圣斗士竟然会被同一招打败 2 次吗？

FULL GC 的产生 。

一般要发现 full gc，最直观的感受就是程序很慢.

这时候你就需要添加一下 GC 日志打印，看一下是否有 full gc 即可.

这个最坑的地方就在于，性能问题是测试一般无法验证的，除非你进行压测.

压测还要同时满足两个条件:

(1)数据量足够大，或者说 QPS 足够高。持续压 。

(2)资源足够少，也就是还想马儿跑，还想马儿不吃草.

好巧不巧，我们同时赶上了两点.

那么问题又来了，如何定位为什么 FULL GC 呢？

内存泄露 。

程序变慢并不是一开始就慢，而是开始很快，然后变慢，接着就是不停的 FULL GC.

这就和自然的想到是内存泄露.

如何定位内存泄露呢？

你可以分成下面几步:

(1)看代码，是否有明显存在内存泄露的地方。然后修改验证。如果无法解决，则找出可能存在问题的地方，执行第二步.

(2)把 FULL GC 时的堆栈信息 dump 下来，分析到底是什么数据过大，然后结合 1 去解决.

接下来，让我们一起看一下这个过程的简化版本记录.

问题定位

  。

看代码 。

最基本的生产者-消费者模式确认了即便，感觉没啥问题.

于是就要看一下消费者模式中调用其他人的方法问题.

方法的核心目的 。

(1)遍历入参列表，执行业务处理.

(2)把当前批次的处理结果写入到文件中.

方法实现 。

简化版本如下:

1. /** 
2.  * 模拟用户处理 
3.  * 
4.  * @param userList 用户列表 
5.  */ 
6. public void handle2(List<User> userList) { 
7.     String targetDir = "D:\\data\\"; 
8.     // 理论让每一个线程只读写属于自己的文件 
9.     String fileName = Thread.currentThread().getName()+".txt"; 
10.     String fullFileName = targetDir + fileName; 
11.     FileWriter fileWriter = null; 
12.     BufferedWriter bufferedWriter = null; 
13.     User userExample; 
14.     try { 
15.         fileWriter = new FileWriter(fullFileName); 
16.         bufferedWriter = new BufferedWriter(fileWriter); 
17.         StringBuffer stringBuffer = null; 
18.         for(User user : userList) { 
19.             stringBuffer = new StringBuffer(); 
20.  
21.             // 业务逻辑 
22.             userExample = new User(); 
23.             userExample.setId(user.getId()); 
24.             // 如果查询到的结果已存在，则跳过处理 
25.             List<User> userCountList = queryUserList(userExample); 
26.             if(userCountList != null && userCountList.size() > 0) { 
27.                 return; 
28.             } 
29.             // 其他处理逻辑 
30.  
31.             // 记录最后的结果 
32.             stringBuffer.append("用户") 
33.                     .append(user.getId()) 
34.                     .append("同步结果完成"); 
35.             bufferedWriter.newLine(); 
36.             bufferedWriter.write(stringBuffer.toString()); 
37.         } 
38.         // 处理结果写入到文件中 
39.         bufferedWriter.newLine(); 
40.         bufferedWriter.flush(); 
41.         bufferedWriter.close(); 
42.         fileWriter.close(); 
43.     } catch (Exception exception) { 
44.         exception.printStackTrace(); 
45.     } finally { 
46.         try { 
47.             if (null != bufferedWriter) { 
48.                 bufferedWriter.close(); 
49.             } 
50.             if (null != fileWriter) { 
51.                 fileWriter.close(); 
52.             } 
53.         } catch (Exception e) { 
54.         } 
55.     } 
56. } 

这种代码怎么说呢，大概就是祖传代码吧，不晓得大家有没有见过，或者写过呢？

我们可以不看文件部分，核心部分实际上只有:

1. User userExample; 
2. for(User user : userList) { 
3.     // 业务逻辑 
4.     userExample = new User(); 
5.     userExample.setId(user.getId()); 
6.     // 如果查询到的结果已存在，则跳过处理 
7.     List<User> userCountList = queryUserList(userExample); 
8.     if(userCountList != null && userCountList.size() > 0) { 
9.         return; 
10.     } 
11.     // 其他处理逻辑 
12. } 

 代码存在的问题 。

你觉得上面的代码有哪些问题？

什么地方可能存在内存泄露呢？

有应该如何改进呢？

看堆栈 。

如果你看代码已经确定了疑惑的地方，那么接下来就是去看一下堆栈，验证下自己的猜想.

堆栈的查看方式 。

jvm 堆栈查看的方式很多，我们这里以 jmap 命令为例.

(1)找到 java 进程的 pid 。

你可以执行 jps 或者 ps ux 等，选择一个你喜欢的.

我们 windows 本地测试了下(实际生产一般是 linux 系统):

1. D:\Program Files\Java\jdk1.8.0_192\bin>jps 
2. 11168 Jps 
3. 3440 RemoteMavenServer36 
4. 4512 
5. 11660 Launcher 
6. 11964 UserServicePageQueue 

UserServicePageQueue 是我们执行的测试程序，所以 pid 是 11964 。

(2)执行 jmap 获取堆栈信息 。

命令:

1. jmap -histo 11964 

效果如下:

1. D:\Program Files\Java\jdk1.8.0_192\bin>jmap -histo 11964 
2.  
3.  num     #instances         #bytes  class name 
4. ---------------------------------------------- 
5.    1:        161031       20851264  [C 
6.    2:        157949        3790776  java.lang.String 
7.    3:          1709        3699696  [B 
8.    4:          3472        3688440  [I 
9.    5:        139358        3344592  com.github.houbb.thread.demo.dal.entity.User 
10.    6:        139614        2233824  java.lang.Integer 
11.    7:         12716         508640  java.io.FileDescriptor 
12.    8:         12714         406848  java.io.FileOutputStream 
13.    9:          7122         284880  java.lang.ref.Finalizer 
14.   10:         12875         206000  java.lang.Object 
15.   ... 

当然下面还有很多，你可以使用 head 命令过滤.

当然，如果服务器不支持这个命令，你可以把堆栈信息输出到文件中:

1. jmap -histo 11964 >> dump.txt 

堆栈分析 。

我们可以很明显发现不合理的地方:

[C 这里指的是 chars，有 161031.

String 是字符串，有 157949.

当然还有 User 对象，有 139358.

我们每一次分页是 1W 个，queue 中最多是 19999 个，这么多对象显然不合理.

代码中的问题

  。

chars 和 String 为什么这么多 。

代码给人的第一感受，就是和业务逻辑没啥关系的写文件了.

很多小伙伴肯定想到了可以使用 TWR 简化一下代码，不过这里存在两个问题:

(1)最后文件中能记录所有的执行结果吗？

(2)有没有更好的方式呢？

对于问题1，答案是不能。虽然我们为每一个线程创建一个文件，但是实际测试，发现文件会被覆盖.

实际上比起我们自己写文件，更应该使用 log 去记录结果，这样更加优雅.

于是，最后把代码简化如下:

1. //日志 
2.  
3. User userExample; 
4. for(User user : userList) { 
5.     // 业务逻辑 
6.     userExample = new User(); 
7.     userExample.setId(user.getId()); 
8.     // 如果查询到的结果已存在，则跳过处理 
9.     List<User> userCountList = queryUserList(userExample); 
10.     if(userCountList != null && userCountList.size() > 0) { 
11.         // 日志 
12.         return; 
13.     } 
14.     // 其他处理逻辑 
15.  
16.     // 日志记录结果 
17. } 

user 对象为什么这里多？

我们看一下核心业务代码:

1. User userExample; 
2. for(User user : userList) { 
3.     // 业务逻辑 
4.     userExample = new User(); 
5.     userExample.setId(user.getId()); 
6.     // 如果查询到的结果已存在，则跳过处理 
7.     List<User> userCountList = queryUserList(userExample); 
8.     if(userCountList != null && userCountList.size() > 0) { 
9.         return; 
10.     } 
11.     // 其他处理逻辑 
12. } 

这里在判断是否存在的时候构建了一个 mybatis 中常用的 User 查询条件，然后判断查询的列表大小.

这里有两个问题:

(1)判断是否存在，最好使用 count，而不是判断列表结果大小.

(2)User userExample 的作用域尽量小一点.

调整如下:

1. for(User user : userList) { 
2.     // 业务逻辑 
3.     User userExample = new User(); 
4.     userExample.setId(user.getId()); 
5.     // 如果查询到的结果已存在，则跳过处理 
6.     int count = selectCount(userExample); 
7.     if(count > 0) { 
8.         return; 
9.     } 
10.     // 其他业务逻辑 
11. } 

 调整之后的代码 。

这里的 System.out.println 实际使用时用 log 替代，这里只是为了演示.

1. /** 
2.  * 模拟用户处理 
3.  * 
4.  * @param userList 用户列表 
5.  */ 
6. public void handle3(List<User> userList) { 
7.     System.out.println("入参：" + userList); 
8.     for(User user : userList) { 
9.         // 业务逻辑 
10.         User userExample = new User(); 
11.         userExample.setId(user.getId()); 
12.         // 如果查询到的结果已存在，则跳过处理 
13.         int count = selectCount(userExample); 
14.         if(count > 0) { 
15.             System.out.println("如果查询到的结果已存在，则跳过处理"); 
16.             continue; 
17.         } 
18.         // 其他业务逻辑 
19.         System.out.println("业务逻辑处理结果"); 
20.     } 
21. } 

 生产验证 。

全部改完之后，重新部署验证，一切顺利.

希望不会有第三篇。:) 。

小结 。

当然验证的过程中还发生过一点小插曲，比如开发没有权限看堆栈信息，执行命令时程序已经假死等等.

生产 full gc 是一个比较麻烦的问题，一个是难以复现，另一个是如果是偶发性的，又是实时链路，可能也不好执行 dump 命令.

所以写代码还是写的尽可能简单的好，不然会有各种问题.

能复用已有的工具、中间件尽量复用.

这样看来，我们自己写的生产-消费者模式也不太好，因为复用性不强，所以建议使用公司已有的 mq 工具，不过如何选择，还是看具体的业务场景.

架构，就是权衡.

希望本文对你有所帮助.

【原文地址】：https://www.toutiao.com/i6949465946352255525/ 。

最后此篇关于JVM FULL GC 生产问题 II-如何定位内存泄露？的文章就讲到这里了,如果你想了解更多关于JVM FULL GC 生产问题 II-如何定位内存泄露？的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。