项目场景：

多个项目通过sdk调用网关进行数据转发，网关中一系列拦截器处理不同的请求，转发到对应的服务

---

问题描述

在网关打印的日志中，记录了内存的使用量，之前就发现每次请求之后，内存使用容量都会增大，而且没有减少的情况

终于在一次测试过程中，测试给出了如下的日志截图

---

原因分析：

问题转过来之后，发现是netty网关发生了内存泄漏，这个问题在很早之前就提出来过一次，当时由于还没有接手项目，完全不了解，看了之前的记录，发现问题一直没有解决，这次抛到了我这里

先想办法在本地复现，我将本地的jvm参数的最大内存调到刚好够启动netty网关之后，调用了几次sdk，不出意外，最后一次果然内存泄漏了，同时发现给出了See http://netty.io/wiki/reference-counted-objects.html for more information.这句话，于是访问这个网址，看完之后，了解到问题出现的原因是从 Netty 版本 4 开始，某些对象的生命周期由它们的引用计数管理，引用计数法是很容易造成内存泄漏的，即使没有根对象对其引用，但是如果引用计数不为0，还是不能回收对象，如下图所示
按照上述链接给出的jvm参数启动项目后，再次调试，打印了访问泄漏缓冲区的应用程序的最近位置，如下

Recent access records: 
#1:
	io.netty.buffer.AdvancedLeakAwareByteBuf.copy(AdvancedLeakAwareByteBuf.java:700)
	io.netty.handler.codec.http.multipart.HttpPostStandardRequestDecoder.parseBodyAttributesStandard(HttpPostStandardRequestDecoder.java:463)
	io.netty.handler.codec.http.multipart.HttpPostStandardRequestDecoder.parseBodyAttributes(HttpPostStandardRequestDecoder.java:497)
	io.netty.handler.codec.http.multipart.HttpPostStandardRequestDecoder.parseBody(HttpPostStandardRequestDecoder.java:360)
	io.netty.handler.codec.http.multipart.HttpPostStandardRequestDecoder.offer(HttpPostStandardRequestDecoder.java:289)
	io.netty.handler.codec.http.multipart.HttpPostStandardRequestDecoder.(HttpPostStandardRequestDecoder.java:154)
	io.netty.handler.codec.http.multipart.HttpPostRequestDecoder.(HttpPostRequestDecoder.java:99)
	io.netty.handler.codec.http.multipart.HttpPostRequestDecoder.(HttpPostRequestDecoder.java:68)
	gov.zwfw.iam.util.VerifyUtil.getFormParams(VerifyUtil.java:388)
	gov.zwfw.iam.util.VerifyUtil.getPostParamsFromChannel(VerifyUtil.java:366)
	gov.zwfw.iam.handler.ParamVertifyHandler.channelRead(ParamVertifyHandler.java:42)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	gov.zwfw.iam.handler.StartTimeRecordHandler.channelRead0(StartTimeRecordHandler.java:20)
	gov.zwfw.iam.handler.StartTimeRecordHandler.channelRead0(StartTimeRecordHandler.java:15)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

发现代码指向了Post方法协议解析HttpPostRequestDecoder，点进去看源码实现，发现在初始化decoder的时候，有一个ByteBuf undecodedChunk对象，断点发现这个对象的引用数一直是1，没有被释放，导致每次请求都会浪费一点内存。

---

解决方案：

undecodedChunk对象存储的是HttpContent内容，这也是为什么使用同一个sdk接口，新增的内存大小固定为531，请求内容一直没有变过。Netty中按是否使用了池化技术，ByteBuf分为两类，一类是非池化的ByteBuf，包括UnpooledHeapByteBuf、UnpooledDirectByteBuf等等，每次I/O读写都会创建一个新ByteBuf，频繁进行大块内存的分配和回收对性能有一定影响，非池化的ByteBuf可以通过JVM GC自动回收，也推荐手动回收UnpooledDirectByteBuf等使用堆外内存的ByteBuf；另一类是池化的ByteBuf，包括pooledHeapByteBuf、pooledDirectByteBuf等等，其先申请一块大内存池，在内存池中分配空间，对于这种应用级别的内存二次分配，就需要手动对池化的ByteBuf进行释放，否则就有可能出现内存泄露的问题。而在初始化decoder对象时，使用的正式池化的ByteBuf，源码如下，使用offer方法创建对象。因此，当这个ByteBuf对象不再使用时，要将它释放掉。

if (request instanceof HttpContent) {
            this.offer((HttpContent)request);
        } else {
            this.undecodedChunk = Unpooled.buffer();
            this.parseBody();
        }
1
2
3
4
5
6

HttpPostRequestDecoder decoder = new HttpPostRequestDecoder(new DefaultHttpDataFactory(false), fullHttpRequest);
        List postData = decoder.getBodyHttpDatas();
        decoder.destroy();
1
2
3

原来的代码中，并没有decoder.destroy();这一行，加上之后，将decoder对象中的
undecodedChunk销毁，然后再次测试，发现打印的内存使用没有再增加，多次调用之后也没有再出现内存泄漏现象。

public void destroy() {
        this.cleanFiles();
        this.destroyed = true;
        if (this.undecodedChunk != null && this.undecodedChunk.refCnt() > 0) {
            this.undecodedChunk.release();
            this.undecodedChunk = null;
        }
    }
1
2
3
4
5
6
7
8

destroy方法最终也是调用的ByteBuf对象的release方法。