1.2.native内存泄漏了吗
JVM使用什么native分配器
通过查看机器上安装的JDK的信息，可以看到使用的是jemalloc的内存分配器。是不是它有泄漏、内存碎片、归还不及时的问题？
网上搜索，发现的有一篇文章讲的场景和我们这里的有一些类似：链接
尝试重新下载jemalloc的源码，并进行其参数的调整：
export MALLOC_CONF="dirty_decay_ms:0,muzzy_decay_ms:0"
观察发现内存的占用量有少量的下降，但还是会超过1个G，看起来核心问题不在这里。
谁在分配内存
同时还通过perf工具监控了下调用内存分配的调用栈，想看看有什么线索没有，然而并没有什么线索。毕竟这个内存的增长比较缓慢，perf也不可能抓太长时间了，遂放弃这个思路。
sudo perf probe -x /opt/taobao/install/ajdk11_11.0.23.24/lib/libjemalloc.so.2 malloc
sudo perf record -e probe_libjemalloc:malloc -p pidof java -g -- sleep 10
内存里面装了什么
通过 sudo pmap -x pidof java | sort -k 3 -n 命令查看进程的所有内存块信息，如下图示：
排除最大的4G的这一个（这是Java堆），以及内存标志带x的两个（可执行代码标志，那是CodeCache），把其它的块都dump下来，看看里面都放了啥，有没有什么不平凡的。
使用gdb命令：gdb --batch --pid pidof java -ex "dump memory mem1.log 0x7f0109800000 0x7f0109800000+0x200000"
然后将dump下的内存以字符串的方式输出观察下：cat mem1.log | strings
如图所示，发现里面大量的内容都和RocketMQ有关。不过我发现我草率了，这些dump内容我看了快一天，根本没有发现什么不太对的地方，看起来都是正常的占用。（不过明显能看出来这里面存了一堆消费者信息，表达的比较冗余）
求助JVM专家
还真是从入门到放弃，到这个时候已经没啥信心啦。遂求助于JVM的专家毛亮，他给了大的方向，一是这里不太可能有native的内存泄漏，二是既然怀疑是堆外，把堆外内存减少一点看看情况，明确下是不是native内存分配器的回收特性就是这样。往往native的内存分配器都有自己的管理策略，他会有自己的回收拐点，比应用看到的高一点是合理的。
的确，那么接下来的策略就是把MaxDirectMemeorySize调低到512M观察下效果吧。
1.3.堆外内存调小影响业务了
在堆外内存从1G调小到512M过后，过了个周末，周一的时候业务同学就反馈，调小遇到问题了，存在MQ消息消费不及时而导致消息挤压的问题。结合之前看到的native内存的信息，突然想到，MQ客户端一定是占用了超过512M的内存，内心里出现了两个问题：
1.MQ底层依赖netty，那么netty实际使用的内存是多少？以及这个内存占用量和native的堆外占用量是什么关系？
2.为啥Java的DirectMemory占用这么少，netty的内存占用似乎并没有被看到，这是怎么回事？
带着这两个问题，查看了netty内存管理的核心类 io.netty.buffer.PooledByteBufAllocator，以及机器上启动过程中打印出的信息。
结合这里面涉及的另一个核心类io.netty.util.internal.PlatformDependent，大概明白了这里面的逻辑，netty是直接使用（是有前提条件的，但这个应用通过JVM参数[-Dio.netty.tryReflectionSetAccessible=true]开启了这个特性，这也是大多数应用上面的行为）UNSAFE.allocateMemory分配内存，完全绕过Java的直接内存API。然后它自己实现了内存占用空间的限制，这个值等于JVM参数中的MaxDirectMemorySize。到这里，似乎发现了曙光，莫非就是netty？（netty这么做的原因是为了不依赖JVM机制而加速内存的释放，同时也是为了解决在堆外内存不足时JVM的糟糕的回收机制设计。）
1.4.Netty到底占用了多少内存
好在netty的类中有一个静态变量是可以很容易的看到这个信息的：
io.netty.buffer.PooledByteBufAllocator#DEFAULT。
那么这个时候就是需要上机器去执行它了。Arthas是个不错的工具，可以直接在机器执行表达式看任何静态变量的值，并不需要我们改代码然后去调用上面的对象做日志打印。
登录机器后，通过命令查找netty Allocator的类定义：
sc -d io.netty.buffer.PooledByteBufAllocator
发现有不止一个Allocator，来自于不同的ClassLoader，以及不同的jar包。一共有7个。
然后一个一个的看他们实际占用的大小：
getstatic -c d5bc00 io.netty.buffer.PooledByteBufAllocator DEFAULT
然后把他们占用的内存逐项加起来，发现的确超过了1G，同时和前面通过NMT看到的Other类别的内存大小是比较吻合的。到这里大概就明确具体是怎么回事了，内存是netty用掉的。
1.5.业务应该怎么做呢
到目前为此，问题是明确了，但似乎并没有什么太好的解法。一个是rocketmq-client的内存占用是不是太大了，有没有什么可以优化的地方？（从前面看native内存看到的内容来看，还是有很大的优化空间的，一大堆地址信息都是以字符串的形式写在内存里面），另一个是中间件的调整肯定是长期的，短期业务要怎么办呢？
思考再三，短期来看只能是先让业务把Java堆调小（通过Java dump以及JVM监控可以看出来堆的使用率并不高），来适应当前的现状了【调整Java堆，给堆外更多的内存空间，以保证MQ的高可用】。
