一、背景

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

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

为剖析和解决该堆外内存走漏问题，经历两个月，文章中的截图对应这两个月的不一起刻线，咱们看截图里的时刻或许有些歧义。

所以，咱们能够忽略截图里的时刻，要点关注问题剖析的思路。

二、问题剖析

1 问题现状

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

闲暇内存渐渐在下降，咱们挑选了其间1台进行排查。

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

2 内存剖析

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

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

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

ps aux –sort=-%mem

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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

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

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

2.3 堆外到底占用多少？

jcmd GC.heap_info

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

heap：发动参数里指定了Xmx是4G，从指令成果也能够看出约等于 new generation 1.8G + old geration 2G。

Metaspace: committed 约0.1G左右

经过pmap指令能够看到最实在的JVM heap的物理内存的占有量，由于Heap实质是一个内存池，池子的总大小4G，可是实践物理内存一般达不到4G，而Heap的used也仅仅池子中运用部分的内存。所以仍是要经过操作系统的pmap来查询：

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

如上图，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指令检查：

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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：

yum install gperftools;
yum install gperftools-devel
yum -y install graphviz
yum -y install ghostscript

2.设置环境变量:

能够在运用的发动脚本上

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.继续调查几小时，履行指令：

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

网上查询材料以及对比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办法)

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

定位到了源码处是XXKafkaConsumerService类，该类是在许多消费kafka消息，其间kafka的数据紧缩办法是gzip，当拉取到消息后，需求解压gzip数据，会调用到Native函数Java_java_util_zip_Inflater_inflateBytes。

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的内存。

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消费没有阻塞的状况，所以应该不会被长时间引证。

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

所以，该猜测不成立。

2.Inflater目标在新生代中存活了一段时刻，之后提高到老时代了，可是咱们长时间都没有一次FullGC，所以挤压了许多这样的目标，导致堆外的内存没开释。

这个能够经过手艺触发一次FullGC来验证：

jmap -histo:live 1904

可是成果不尽人意，尽管FullGC后，Inflater目标尽管有所削减，可是仍是挺多的。

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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

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

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

ptmalloc2内存泄漏泄漏有一个显着的现象，是存在许多的64M的内存块(虚拟内存)。

参阅：一次许多 JVM Native 内存走漏的排查剖析（64M 问题） /post/707862…

咱们经过pmap指令把JVM进程中内存块的分布打印出来：

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

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

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

经过打印内存中的数据发现，有许多的log、链路的数据，有的数据乃至是几个月前的，可见前史积压了很久。

2.11 手动开释ptmalloc内存

ptmalloc2由于自身设计的原因，在高并发状况下会存在许多内存碎片不开释，经过调用 malloc_trim() 函数能够收拾malloc内存池中的内存块，合并、开释闲暇内存，能够简略理解为JVM 的GC。

屡次履行；gdb –batch –pid 1904 –ex ‘call malloc_trim()’

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

作用十分显着，立马开释出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%左右了

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

(2) 修正参数

export MALLOC_MMAP_THRESHOLD_=131072
export MALLOC_TRIM_THRESHOLD_=131072 
export MALLOC_TOP_PAD_=131072 
export MALLOC_MMAP_MAX_=65536

成果：调查数日，上面的参数仍是有作用的，尽管仍是会降低到10%以下，可是总体仍是在13%左右

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

3.【引荐，作用明细】替换内存分配器为google的tcmalloc或facebook的jemalloc

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

成果：内存运用量十分安稳，长时间都是40%多。由7台机器缩减为4台，也满足支撑现有数据。

【JVM案例篇】堆外内存(JNI Memory)泄漏(经典64M内存块问题)

四、弥补阐明

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

五、 内存问题-办法论

我遇过许多类型的内存问题，本篇仅仅其间一个，后面再逐步弥补其他相似的内存问题排查案例。

我花了半个多月，把排查内存问题的经历和办法论收拾成一篇《一同探秘JVM内存问题(OOM、内存泄漏、堆外内存等》，必定能给咱们带来较大协助。

六、参阅

Java中9种常见的CMS GC问题剖析与解决 tech.meituan.com/2020/11/12/…

堆外内存泄漏排查 blog.csdn.net/u022812849/…

【内存】内存池：怎么提高内存分配的功率？ www.cnblogs.com/hochan100/p…

一次许多 JVM Native 内存走漏的排查剖析（64M 问题） /post/707862…