服务器之家:专注于服务器技术及软件下载分享
分类导航

PHP教程|ASP.NET教程|Java教程|ASP教程|编程技术|正则表达式|C/C++|IOS|C#|Swift|Android|VB|R语言|JavaScript|易语言|vb.net|

服务器之家 - 编程语言 - Java教程 - JVM FULL GC 生产问题 II-如何定位内存泄露?

JVM FULL GC 生产问题 II-如何定位内存泄露?

2021-04-15 01:04老马啸西风 Java教程

生产 full gc 是一个比较麻烦的问题,一个是难以复现,另一个是如果是偶发性的,又是实时链路,可能也不好执行 dump 命令。所以写代码还是写的尽可能简单的好,不然会有各种问题。

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.  

 测试验证

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

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

一看 GC 日志,梅开二度,FULL GC。

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

JVM FULL GC 生产问题 II-如何定位内存泄露?

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.     } 

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

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

  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.     // 其他处理逻辑 

 代码存在的问题

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

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

有应该如何改进呢?

看堆栈

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

堆栈的查看方式

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.     // 日志记录结果 

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.     // 其他处理逻辑 

这里在判断是否存在的时候构建了一个 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.     // 其他业务逻辑 

 调整之后的代码

这里的 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.     } 

 生产验证

全部改完之后,重新部署验证,一切顺利。

希望不会有第三篇。:)

小结

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

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

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

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

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

架构,就是权衡。

希望本文对你有所帮助!

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

延伸 · 阅读

精彩推荐