一、背景
实际工作中，有一应用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：
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
网上查询资料以及对比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。
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消费没有阻塞的情况，所以应该不会被长期引用。
所以，该猜想不成立。
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) 修改参数
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
五、 内存问题-方法论
我遇过很多类型的内存问题，本篇只是其中一个，后面再逐步补充其他类似的内存问题排查案例。
我花了半个多月，把排查内存问题的经验和方法论整理成一篇《一起探秘JVM内存问题(OOM、内存泄漏、堆外内存等》，一定能给大家带来较大帮助。
六、参考
Java中9种常见的CMS GC问题分析与解决 tech.meituan.com/2020/11/12/…
堆外内存泄漏排查 blog.csdn.net/u022812849/…
【内存】内存池：如何提升内存分配的效率？ www.cnblogs.com/hochan100/p…
一次大量 JVM Native 内存泄露的排查分析（64M 问题） juejin.cn/post/707862…
