经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » Java相关 » Java » 查看文章
生产环境Java应用服务内存泄漏分析与解决
来源:cnblogs  作者:陈国利  时间:2023/3/14 8:48:56  对本文有异议

有个生产环境CRM业务应用服务,情况有些奇怪,监控数据显示内存异常。内存使用率99.%多。通过生产监控看板发现,CRM内存超配或内存泄漏的现象,下面分析一下这个问题过程记录。

1、服务器硬件配置部署情况

生产服务器采用阿里云ECS机器,配置是2HZ、8GB,单个应用服务独占,CRM应用独立部署,即单台服务器仅部署一个java应用服务。

用了6个节点6台机器,每台机器都差不多情况。

监控看板如下:

top命令查看物理占用情况

通过看板情况来看确实存在异常情况,下面进一步分析问题原因。

2、应用启动参数配置

应用启动配置参数如下:

 /usr/bin/java

-javaagent:/home/agent/skywalking-agent.jar

-Dskywalking.agent.service_name=xx-crm

 -XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/tmp/xx-crm.hprof

-Dspring.profiles.active=prod

-server -Xms4884m -Xmx4884m -Xmn3584m

-XX:MetaspaceSize=512m

-XX:MaxMetaspaceSize=512m

-XX:CompressedClassSpaceSize=128m

-jar /home/xxs-crm.jar

 

堆内:最大最小堆内存4884m约4.8G左右,其中新生代-Xmn3584m 约3.5G左右,

非堆: 元数据区配置 512M,类压缩空间 128M, Code Cache、buffer等代码缓存区240M(没有配置参数,通过监控看板看到的)。

 

3、内存分布统计

从监控看板的数据来看,我们简单统计一下内存分配数据情况。

通过JVM配置参数和监控看板数据可知:

堆内存:4.8G

非堆内存:(Metaspace)512M+(CompressedClassSpace)128M+(Code Cache、Buffer等)240M约等1GB左右。

堆内存(heap)+非堆内存(nonHeap)=5.8G

8GB物理内存除去操作系统本身占用大概占500M。即除了操作系统本身占用之外,还有7.5G可用内存。

但是 7.5-5.8=1.7GB,起码至少还有1~2GB空闲才合理呀!怎么内存占用率99%多,就意味着有1~2G不知道谁占去了,有点诡异!

 

4、问题分析

先看一下JVM内存模型,环境是使用JDK8

JVM内存数据分区如下图所示:

堆heap分配结构如下图所示:

堆大家都比较熟悉,也容易理解的,也是java程序接触得最多的一块,不存在什么数据上统计错误,或占用不算之类的。

那说明额外占用也非堆里面,只不过没有统计到非堆里面去,曾经一度怀疑监控prometheus展示的数据有误

其实不是监控统计的问题,那是什么问题呢?

先看一下dump文件数据,这里使用MAT工具(一个开源免费的内存分析工具,个人认为比较好用,推荐大家使用。下载地址:https://www.eclipse.org/mat/downloads.php)。

通过下载内存dump镜像观察到,如下图所示:

 

有个offHeapStore,这个东西堆外内存,可以初步判断是 ehcahe引起的。

通过ehcahe源码分析,发现ehcache里面也使用了netty的NIO方法内存,ehcache磁盘缓存写数据时会用到DirectByteBuffer。

DirectByteBuffer是使用非堆内存,不受GC影响。

??在网络编程中,为避免频繁的在用户空间与内核空间拷贝数据,通常会直接从内核空间中申请内存,存放数据,在Java中,把内核空间的内存称之为直接内存,nio包中的ByteBuffer的allocateDirect方法,就是申请直接内存。

直接打开JDK源代码 

  1. ByteBuffer
  1. /**
  2. * Allocates a new direct byte buffer.
  3. *
  4. * <p> The new buffer's position will be zero, its limit will be its
  5. * capacity, its mark will be undefined, and each of its elements will be
  6. * initialized to zero. Whether or not it has a
  7. * {@link #hasArray backing array} is unspecified.
  8. *
  9. * @param capacity
  10. * The new buffer's capacity, in bytes
  11. *
  12. * @return The new byte buffer
  13. *
  14. * @throws IllegalArgumentException
  15. * If the <tt>capacity</tt> is a negative integer
  16. */
  17. public static ByteBuffer allocateDirect(int capacity) {
  18. return new DirectByteBuffer(capacity);
  19. }

DirectByteBuffer对象是ByteBuffer的子类,对于直接内存的分配,就是在这个类中实现的。

在java中

  • 直接内存的申请与释放是通过Unsafe类的allocateMemory方法和freeMemory方法
  • 处置从allocateMemory或reallocateMemory获得的本地内存块。 传递给此方法的地址可以为null,在这种情况下,不采取任何措施。

 

??分配给定大小的新本地内存块(以字节为单位)。 存储器的内容未初始化; 它们通常是垃圾。 结果本机指针永远不会为零,并且将针对所有值类型进行对齐。 通过调用freeMemory处理此内存,或使用reallocateMemory调整其大小。

??DirectByteBuffer帮我们简化了直接内存的使用,我们不需要直接操作Unsafe类来进行直接内存的申请与释放,那么其是如何实现的呢?

直接内存的申请:

??在DirectByteBuffer实例通过构造方法创建的时候,会通过Unsafe类的allocateMemory方法 帮我们申请直接内存资源。

直接内存的释放:

??DirectByteBuffer本身是一个Java对象,其是位于堆内存中的,JDK的GC机制可以自动帮我们回收,但是其申请的直接内存,不再GC范围之内,无法自动回收。好在JDK提供了一种机制,可以为堆内存对象注册一个钩子函数(其实就是实现Runnable接口的子类),当堆内存对象被GC回收的时候,会回调run方法,我们可以在这个方法中执行释放DirectByteBuffer引用的直接内存,即在run方法中调用Unsafe 的freeMemory 方法。注册是通过sun.misc.Cleaner类来实现的。

  1. // Primary constructor
  2. DirectByteBuffer(int cap) {
  3. super(-1, 0, cap, cap);
  4. boolean pa = VM.isDirectMemoryPageAligned();
  5. int ps = Bits.pageSize();
  6. long size = Math.max(1L, (long)cap + (pa ? ps : 0));
  7. Bits.reserveMemory(size, cap);
  8. long base = 0;
  9. try {
  10. base = unsafe.allocateMemory(size);
  11. } catch (OutOfMemoryError x) {
  12. Bits.unreserveMemory(size, cap);
  13. throw x;
  14. }
  15. unsafe.setMemory(base, size, (byte) 0);
  16. if (pa && (base % ps != 0)) {
  17. // Round up to page boundary
  18. address = base + ps - (base & (ps - 1));
  19. } else {
  20. address = base;
  21. }
  22. cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
  23. att = null;
  24. }

从代码中我们可以看到构造方法中的确是用了unsafe.allocateMemory方法帮我们分配了直接内存,另外,在构造方法的最后,通过 Cleaner.create方法注册了一个钩子函数,用于清除直接内存的引用。

Cleaner.create方法声明如下所示:

  1. public static Cleaner create(Object heapObj, Runnable task)

其中第一个参数是一个堆内存对象,第二个参数是一个Runnable任务,表示这个堆内存对象被回收的时候,需要执行的回调方法。我们可以看到在DirectByteBuffer的最后一行中,传入的这两个参数分别是this,和一个Deallocator(实现了Runnable接口),其中this表示就是当前DirectByteBuffer实例,也就是当前DirectByteBuffer被回收的时候,回调Deallocator的run方法

Deallocator就是用于清除DirectByteBuffer引用的直接内存,代码如下所示:

  1. private static class Deallocator
  2. implements Runnable
  3. {
  4. private static Unsafe unsafe = Unsafe.getUnsafe();
  5. private long address;
  6. private long size;
  7. private int capacity;
  8. private Deallocator(long address, long size, int capacity) {
  9. assert (address != 0);
  10. this.address = address;
  11. this.size = size;
  12. this.capacity = capacity;
  13. }
  14. public void run() {
  15. if (address == 0) {
  16. // Paranoia
  17. return;
  18. }
  19. unsafe.freeMemory(address);
  20. address = 0;
  21. Bits.unreserveMemory(size, capacity);
  22. }
  23. }

在DirectByteBuffer实例创建时,分配内存之前调用了Bits.reserveMemory,如果分配失败调用了Bits.unreserveMemory,同时在Deallocator释放完直接内存的时候,也调用了Bits.unreserveMemory方法。

这两个方法,主要是记录jdk已经使用的直接内存的数量,当分配直接内存时,需要进行增加,当释放时,需要减少,源码如下:

  1. static void reserveMemory(long size, int cap) {
  2. if (!memoryLimitSet && VM.isBooted()) {
  3. maxMemory = VM.maxDirectMemory();
  4. memoryLimitSet = true;
  5. }
  6. // optimist!
  7. if (tryReserveMemory(size, cap)) {
  8. return;
  9. }
  10. final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();
  11. // retry while helping enqueue pending Reference objects
  12. // which includes executing pending Cleaner(s) which includes
  13. // Cleaner(s) that free direct buffer memory
  14. while (jlra.tryHandlePendingReference()) {
  15. if (tryReserveMemory(size, cap)) {
  16. return;
  17. }
  18. }
  19. // trigger VM's Reference processing
  20. System.gc();
  21. // a retry loop with exponential back-off delays
  22. // (this gives VM some time to do it's job)
  23. boolean interrupted = false;
  24. try {
  25. long sleepTime = 1;
  26. int sleeps = 0;
  27. while (true) {
  28. if (tryReserveMemory(size, cap)) {
  29. return;
  30. }
  31. if (sleeps >= MAX_SLEEPS) {
  32. break;
  33. }
  34. if (!jlra.tryHandlePendingReference()) {
  35. try {
  36. Thread.sleep(sleepTime);
  37. sleepTime <<= 1;
  38. sleeps++;
  39. } catch (InterruptedException e) {
  40. interrupted = true;
  41. }
  42. }
  43. }
  44. // no luck
  45. throw new OutOfMemoryError("Direct buffer memory");
  46. } finally {
  47. if (interrupted) {
  48. // don't swallow interrupts
  49. Thread.currentThread().interrupt();
  50. }
  51. }
  52. }
  53. //释放内存时,减少引用直接内存的计数
  54. static void unreserveMemory(long size, int cap) {
  55. long cnt = count.decrementAndGet();
  56. long reservedMem = reservedMemory.addAndGet(-size);
  57. long totalCap = totalCapacity.addAndGet(-cap);
  58. assert cnt >= 0 && reservedMem >= 0 && totalCap >= 0;
  59. }

 

通过上面代码的分析,可以认为Bits类是直接内存的分配担保,当有足够的直接内存可以用时,增加直接内存应用计数,否则,调用System.gc,进行垃圾回收,需要注意的是,System.gc只会回收堆内存中的对象,但是 DirectByteBuffer对象被回收时,那么其引用的直接内存也会被回收,试想现在刚好有其他的DirectByteBuffer可以被回收,那么其被回收的直接内存就可以用于本次DirectByteBuffer直接的内存的分配。

 ??回到本问题上来,当有文件需要暂存到ehcache的磁盘缓存时,使用到了NIO中的FileChannel来读取文件,默认ehcache使用了堆内的HeapByteBuffer来给FileChannel作为读取文件的缓冲,FileChannel读取文件使用的IOUtil的read方法,针对HeapByteBuffer底层还用到一个临时的DirectByteBuffer来和操作系统进行直接的交互。

 

ehcache使用HeapByteBuffer作为读文件缓冲:

 

IOUtil对于HeapByteBuffer实际会用到一个临时的DirectByteBuffer来和操作系统进行交互。

 

 

DirectByteBuffer泄漏根因分析

默认情况下这个临时的DirectByteBuffer会被缓存在一个ThreadLocal的bufferCache里不会释放,每一个bufferCache有一个DirectByteBuffer的数组,每次当前线程需要使用到临时DirectByteBuffer时会取出自己bufferCache里的DirectByteBuffer数据,选取一个不小于所需size的,如果bufferCache为空或者没有符合的,就会调用Bits重新创建一个,使用完之后再缓存到bufferCache里。

这里的问题在于 :这个bufferCache是ThreadLocal的,意味着极端情况下有N个调用线程就会有N组 bufferCache,就会有N组DirectByteBuffer被缓存起来不被释放,而且不同于在IO时直接使用DirectByteBuffer,这N组DirectByteBuffer连GC时都不会回收。我们的文件服务在读写ehcache的磁盘缓存时直接使用的tomcat的worker线程池,

这个worker线程池的配置上限是2000,我们的配置中心上的配置的参数:

 

所以,这种隐藏的问题影响所有使用到HeapByteBuffer的地方而且很隐秘,由于在CRM服务中大量使用了ehcache存在较大的sizeIO且调用线程比较多的场景下容易暴露出来。

 

获取临时DirectByteBuffer的逻辑:


bufferCache从ByteBuffer数组里选取合适的ByteBuffer:

 

将ByteBuffer回种到bufferCache:

 

NIO中的FileChannelSocketChannelChannel默认在通过IOUtil进行IO读写操作时,除了会使用HeapByteBuffer作为和应用程序的对接缓冲,但在底层还会使用一个临时的DirectByteBuffer来和系统进行真正的IO交互,为提高性能,当使用完后这个临时的DirectByteBuffer会被存放到ThreadLocal的缓存中不会释放,当直接使用HeapByteBuffer的线程数较多或者IO操作的size较大时,会导致这些临时的DirectByteBuffer占用大量堆外直接内存造成泄漏。

那么除了减少直接调用ehcache读写的线程数有没有其他办法能解决这个问题?并发比较高的场景下意味着减少业务线程数并不是一个好办法。

在Java1.8_102版本开始,官方提供一个参数jdk.nio.maxCachedBufferSize,这个参数用于限制可以被缓存的DirectByteBuffer的大小,对于超过这个限制的DirectByteBuffer不会被缓存到ThreadLocal的bufferCache中,这样就能被GC正常回收掉。唯一的缺点是读写的性能会稍差一些,毕竟创建一个新的DirectByteBuffer的代价也不小,当然通过测试验证对比分析,性能也没有数量级的差别。

增加参数:

-XX:MaxDirectMemorySize=1600m
-Djdk.nio.maxCachedBufferSize=500000    ---注意不能带单位

就是调整了-Djdk.nio.maxCachedBufferSize=500000(注意这里是字节数,不能用mkg等单位

增加调整参数之后,运行一段时间,持续观察整体DirectByteBuffer稳定控制在1.5G左右,性能也几乎没有衰减。

一切恢复正常,再看监控看板没有看到占满内存告警。

 

 

5、解决办法

调整应用启动参数配置,业务系统调整后的启动命令参数如下:

 java

-javaagent:/home/agent/skywalking-agent.jar

-Dskywalking.agent.service_name=xx-crm

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/tmp/xx-crm.hprof

-Dspring.profiles.active=prod

-server -Xms4608m -Xmx4608m -Xmn3072m

-XX:MetaspaceSize=300m

-XX:MaxMetaspaceSize=512m

-XX:CompressedClassSpaceSize=64m

-XX:MaxDirectMemorySize=1600m

-Djdk.nio.maxCachedBufferSize=500000

-jar /home/xx-crm.jar

 

6、总结

碰到这类非堆内存问题有两种解决办法:

1、在业务允许条件下减少IO线程数。

2、调整配置应用启动参数,-Djdk.nio.maxCachedBufferSize=xxx 记住 -XX:MaxDirectMemorySize 参数也要配置上。

如果不配置 -XX:MaxDirectMemorySize 这个参数(最大直接内存),JVM就默认取-Xmx的值当作它的最大值(可能就会像我一样遇到超配的情况)。

3、遇到问题多读一下JDK源码,并学会内存分析工具。

 

参考文章Troubleshooting Problems With Native (Off-Heap) Memory in Java Applications

 

原文链接:https://www.cnblogs.com/cgli/p/17201943.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号