一、背景

实际工作中，有一应用A，每隔几个月就会出现内存告警，甚至OOM，持续一年多，一直以来解决办法是重启。

最后发现问题在于堆外内存泄漏，通过JVM将使用的内存分配器ptmalloc2替换为jemalloc修复。

为分析和解决该堆外内存泄露问题，经历两个月，文章中的截图对应这两个月的不同时间线，大家看截图里的时间可能有些歧义。

所以，大家可以忽略截图里的时间，重点关注问题分析的思路。

二、问题分析

1 问题现状

一共有7个4c8g节点，该应用作用是ELT，大量消费kafka中的所有应用的日志、链路等数据，再存储到ES。

空闲内存慢慢在下降，我们选择了其中1台进行排查。

2 内存分析

之前写过一篇内存问题排查思路的文章：《一起探秘JVM内存问题(OOM、内存泄漏、堆外内存等》。

下面就按照文章的思路逐步排查。

2.1 确定到底是哪个进程占用内存高

ps aux --sort=-%mem

物理内存占用第一的是应用A 约6.5G，第二的是X-agent应用，所以确认了应用A JVM进程占用内存过高导致。

2.2 堆内、堆外内存逐步排查

结合JVM内存分布图，先排查堆内内存、再排查堆外内存。

2.3 堆外到底占用多少？

jcmd GC.heap_info

heap：启动参数里指定了Xmx是4G，从命令结果也可以看出约等于 new generation 1.8G + old geration 2G。

Metaspace: committed 约0.1G左右

通过pmap命令可以看到最真实的JVM heap的物理内存的占有量，因为Heap本质是一个内存池，池子的总大小4G，但是实际物理内存一般达不到4G，而Heap的used也只是池子中使用部分的内存。所以还是要通过操作系统的pmap来查询：

如上图，JVM heap是4G的虚拟内存，启动物理内存约占用3144764K即约3G，50M左右置换到了swap空间。

所以heap实际占用约3G。

2.4 堆外内存占用多少？

堆外物理内存 = 总占用物理内存 - heap占用的物理内存 = 6.5G - 3G = 3.5G

疑点: 怎么会占用这么多堆外内存，是哪块内存占用这么多？

2.5 分析堆外内存大户

逐个分析堆外内存的大户：Metaspace、Direct Memory、JNI Memory、code_cache

通过pmap命令确定每一块空间的内存占用是最真实的，但是比较麻烦，所以通过Arthas的memory命令查看：

Metaspace总量 + Direct Memory总量 + code_cache总量 = 103M + 1M + 59M 约 0.2G，这里计算的是总量，实际物理内存占用没那么大，为方便计算，我们就按0.2G来算。

所以其他堆外内存总量 = 总堆外物理内存 - (Metaspace总量 + Direct Memory总量 + code_cache总量) = 3.5G - 0.2G - 3.3G

那大概率是JNI Memory这块占用了大量内存。

2.6 分析JNI Memory内存

JNI Memory的内存是因为JVM内存调用了Native方法，即C、C++方法，所以需要使用C、C++的思路去解决。

排查过程是两个大方向：

方向1：

1.gpertools分析谁没有释放内存：定位C、C++的函数

2.确认C、C++的函数对应的Java 方法

3.jstack或arthas的stack命令：Java方法对应的调用栈

方向2：

1.pmap定位内存块的分布：查看哪些内存块的Rss、Swap占用大

2.dump出内存块，打印出内存数据：把内存中的数据，打印成字符串，分析是什么数据

2.7 通过google的gperftools工具排查谁在分配内存

gperftools工具会拦截内存分配和释放等场景的函数，然后记录调用的堆栈和内存分配、释放的情况。

使用方式

1.安装gperftools：

bash复制代码yum install gperftools;
yum install gperftools-devel
yum -y install graphviz
yum -y install ghostscript

2.设置环境变量:

可以在应用的启动脚本上

bash复制代码vim app_start.sh
### 加 上 gperftools
export LD_PRELOAD=/usr/lib64/[libtcmalloc.so](http://libtcmalloc.so)
export HEAPPROFILE=/home/admin/gperftools/heap/hprof
..... start app ......

3.重启应用

kill app，再运行app_start.sh

4.持续观察几小时，执行命令：

bash复制代码pprof --pdf --base=/home/admin/gperftools/heap/hprof_27126.1617.heap /usr/local/jdk8/bin/java /home/admin/gperftools/heap/hprof_27126.1619.heap> mem-diff.pdf

其中 /home/admin/gperftools/heap/hprof_27126.1617.heap和/usr/local/jdk8/bin/java /home/admin/gperftools/heap/hprof_27126.1619.heap是gperftools生成的Heap Profiling快照。

diff方式可以对比出哪些函数申请了内存，没有释放。

最大头的是Java_java_util_zip_Inflater_inflateBytes函数在申请堆外内存，共680M，占比680M

网上查询资料以及对比jdk源码，发现对应于java的java.util.zip.Inflater#inflateBytes()方法，该方法是JVM的gzip压缩工具中的。

2.8 确定是被谁调用的Java_java_util_zip_Inflater_inflateBytes呢？

每隔一秒通过jstack不停打印线程堆栈，过滤出java.util.zip.Inflater#inflateBytes方法相关的堆栈

(PS: 也可以通过arthas的stack命令拦截，注意java.util.zip.Inflater#inflateBytes是native方法，无法拦截，但是他是private方法，只会被非java方法java.util.zip.Inflater#inflate调用，所以可以拦截java.util.zip.Inflater#inflate方法)

定位到了源码处是XXKafkaConsumerService类，该类是在大量消费kafka消息，其中kafka的数据压缩方式是gzip，当拉取到消息后，需要解压gzip数据，会调用到Native函数Java_java_util_zip_Inflater_inflateBytes。

java复制代码public void consume() {
    .......
    while (true) {
      ...kafkaConsumer.poll(timeout);
      ......
    }
    ......
}

网上有类似的kafka gzip压缩导致的堆外内存泄漏问题：一次堆外内存泄露的排查过程 developer.aliyun.com/article/657…

2.8 GC后不释放内存？

按理说，JDK肯定考虑到Java_java_util_zip_Inflater_inflateBytes会申请JNI Memory，同时必定也方式去释放内存。

根据网上资料和看源码，发现如果Inflater对象被GC回收时，会调用继承于Object类的finalize()方法，该方法会释放资源，包括释放native的内存。

java复制代码public class Inflater {
  public void end() {
    synchronized (zsRef) {
      // 
      long addr = zsRef.address();
      zsRef.clear();
      if (addr != 0) {
        end(addr);
        buf = null;

      }
    }
  }

  /**
   * 当垃圾回收的时候会执行finalize()，同时会释放资源，包括释放native的内存
   */
  protected void finalize() {
    end();
  }

  private native static void initIDs();
  // ...
  private native static void end(long addr);
}

2.9 GC后不释放内存的几种猜想

那就存在几种可能：

1.Inflater对象没有被回收，例如被其他对象长期引用着，没能被回收。

但是从源码看，Inflater对象的引用链中，父级对象是局部变量，且kafka消费没有阻塞的情况，所以应该不会被长期引用。

所以，该猜想不成立。

2.Inflater对象在新生代中存活了一段时间，之后晋升到老年代了，但是我们长期都没有一次FullGC，所以挤压了很多这样的对象，导致堆外的内存没释放。

这个可以通过手工触发一次FullGC来验证：

jmap -histo:live 1904

但是结果不尽人意，虽然FullGC后，Inflater对象虽然有所减少，但是还是挺多的。

并且，内存占用量还是很高，占用量还有6G多。

3.那会不会是JNI Memory释放了，但是内存没有回收呢？

Linux操作系统默认使用的内存分配器是ptmalloc2，该内存分配器内部有一个内存池。当Inflater释放内存时，ptmalloc2会不会缓存了这部分空闲内存？

查阅了较多资料，发现ptmalloc2在高并发分配内存时，会存在较多内存碎片无法释放的情况，碎片积压到一定程度甚至会导致进程内存不够用，最终OOM。

网上资料发现MySQL、TFS、Tair、Redis这些中间件部署时，指定jemlloc内存分配器替代ptmalloc2可更好地管理内存。

2.10 经典的Linux的64M内存块问题

ptmalloc2内存泄漏泄漏有一个明显的现象，是存在大量的64M的内存块(虚拟内存)。

参考：一次大量 JVM Native 内存泄露的排查分析（64M 问题） juejin.cn/post/707862…

我们通过pmap命令把JVM进程中内存块的分布打印出来：

(pmap -X 1904 | head -2; pmap -X 1904 | awk 'NR>2' | sort -nr -k6) > pmap_1.log

确实存在大量的64M内存占用的内存块，把占用的物理内存(Rss)统计一下，一共约3.4G左右

随意选取几个64M内存的地址，dump出内存

执行strings 103.dump将内存里的数据转为string字符串

通过打印内存中的数据发现，有大量的log、链路的数据，有的数据甚至是几个月前的，可见历史积压了很久。

2.11 手动释放ptmalloc内存

ptmalloc2因为自身设计的原因，在高并发情况下会存在大量内存碎片不释放，通过调用 malloc_trim() 函数可以整理malloc内存池中的内存块，合并、释放空闲内存，可以简单理解为JVM 的GC。

多次执行；gdb --batch --pid 1904 --ex 'call malloc_trim()'

效果非常明显，立马释放出2G(6G减少到4G)左右的物理内存。

3 内存分析的结论

原因在于ptmalloc2存在大量内存碎片，积压了很多历史的数据，没有及时释放。

至于ptmalloc2在高并发的情况会导致内存碎片不释放，这个看过很多资料，尝试了好多工具去验证内存分配的情况，但是目前还没有得出一个确切的根因分析。

三、解决方案

1.经试验发现，kafka的consumer、provider端处理gzip压缩算法时，都是可能出现JNI Memory内存泄露问题。

如果将kafka消息的压缩算法gzip改为其他算法，例如Snappy、LZ4，这些压缩算法可以规避掉JVM的gzip解、压缩使用JNI Memory的问题。

关于Kafka的压缩算法，可以参考，kakka不同压缩算法的性能对比：www.cnblogs.com/huxi2b/p/10…

2.优化ptmalloc2的参数：

(1). export MALLOC_ARENA_MAX=8

结果：未解决问题，最终内存剩余10%左右了

(2) 修改参数

bash复制代码export MALLOC_MMAP_THRESHOLD_=131072 
export MALLOC_TRIM_THRESHOLD_=131072 
export MALLOC_TOP_PAD_=131072 
export MALLOC_MMAP_MAX_=65536

结果：观察数日，上面的参数还是有效果的，虽然还是会降低到10%以下，但是总体还是在13%左右

3.【推荐，效果明细】替换内存分配器为google的tcmalloc或facebook的jemalloc

将内存分配器的库打包到项目部署包中，再用export LD_PRELOAD指定函数库

结果：内存使用量非常稳定，长期都是40%多。由7台机器缩减为4台，也足够支撑现有数据。

四、补充说明

1 为什么linux使用ptmalloc2，而不是jemalloc、tcmalloc？

比如，单线程下分配 257K 字节的内存，Ptmalloc2 的耗时不变仍然是 32 纳秒，但 TCMalloc 就由 10 纳秒上升到 64 纳秒，增长了 5 倍以上！**现在 TCMalloc 反过来比 Ptmalloc2 慢了 1 倍！**这是因为 TCMalloc 特意针对小内存做了优化。

多少字节叫小内存呢？TCMalloc 把内存分为 3 个档次，小于等于 256KB 的称为小内存，从 256KB 到 1M 称为中等内存，大于 1MB 的叫做大内存。TCMalloc 对中等内存、大内存的分配速度很慢，比如我们用单线程分配 2M 的内存，Ptmalloc2 耗时仍然稳定在 32 纳秒，但 TCMalloc 已经上升到 86 纳秒，增长了 7 倍以上。

所以，如果主要分配 256KB 以下的内存，特别是在多线程环境下，应当选择 TCMalloc；否则应使用 Ptmalloc2，它的通用性更好。

而一般的应用没有那么高的并发(申请内存tps高、并发线程多)，对于普通应用而言，ptmalloc性能、稳定性足够。

参考：【内存】内存池：如何提升内存分配的效率？ www.cnblogs.com/hochan100/p…

2 注意事项

(1) 网上说malloc_trim有很小的概率会导致JVM Crash，使用时需要小心，但是我目前未遇到过。

(2) google的gperftools分析内存用到了tcmalloc分配器，即上面配置的export LD_PRELOAD=/usr/lib64/libtcmalloc.so，一旦配置了tcmalloc分配器，就解决上面的JNI Memory存在内存碎片不释放的问题！

如果要验证64M内存块问题，就得去掉export LD_PRELOAD=/usr/lib64/libtcmalloc.so