dubbo扩展http协议后FullGC
问题
dubbo内部定制的版本中，在处理大于10K的包的时候，会出现内存溢出的现象
原因是我们在定制dubbo http协议的时候，使用了jboss包里面的HttpRequestDecoder的http decoder方法来解析http协议内容
该方法在解析非http协议的大内容时，会出现内存溢出的情况
某个服务因为这个问题，出现了full gc 的情况
复现问题
根据描述复现该问题
- 指定dubbo版本
- dubbo请求，非http请求
- 消息体大于10K
jvm堆配置，jmap -heap pid
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 2147483648 (2048.0MB)
NewSize = 44564480 (42.5MB)
MaxNewSize = 715653120 (682.5MB)
OldSize = 89653248 (85.5MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
构造provider和consumer，然后在consumer的入参约100K，启动tomcat（JVM）的时候添加打印gc详细信息的参数，发起调用的时候观察gc情况
-XX:+PrintGCDetails -XX:+PrintGCDateStamps
第一次调用的时候并没有出现Full GC的情况，想着是不是并发有点小，毕竟线上还是有一定并发量的，所以consumer端启动线程来调用，启动线程个数1、10、100、1000，线程数是1000的时候provider侧出现了FullGC的情况
2018-01-19T21:01:23.758-0800: [GC (Allocation Failure) [PSYoungGen: 454144K->696K(468992K)] 1394833K->1383056K(1867264K), 0.1343399 secs] [Times: user=0.26 sys=0.01, real=0.14 secs]
2018-01-19T21:01:23.892-0800: [Full GC (Ergonomics) [PSYoungGen: 696K->0K(468992K)] [ParOldGen: 1382359K->940805K(1398272K)] 1383056K->940805K(1867264K), [Metaspace: 52098K->52098K(1097728K)], 0.2305879 secs] [Times: user=0.54 sys=0.01, real=0.23 secs]
2018-01-19T21:01:24.629-0800: [Full GC (Ergonomics) [PSYoungGen: 464621K->0K(468992K)] [ParOldGen: 1382601K->941472K(1398272K)] 1847223K->941472K(1867264K), [Metaspace: 52098K->52098K(1097728K)], 0.2063340 secs] [Times: user=0.59 sys=0.00, real=0.21 secs]
2018-01-19T21:01:25.305-0800: [Full GC (Ergonomics) [PSYoungGen: 454693K->0K(468992K)] [ParOldGen: 1383395K->499265K(1398272K)] 1838088K->499265K(1867264K), [Metaspace: 52098K->52098K(1097728K)], 0.1478104 secs] [Times: user=0.34 sys=0.01, real=0.15 secs]
2018-01-19T21:01:25.945-0800: [Full GC (Ergonomics) [PSYoungGen: 457504K->0K(468992K)] [ParOldGen: 1383424K->499950K(1398272K)] 1840928K->499950K(1867264K), [Metaspace: 52098K->52098K(1097728K)], 0.1390671 secs] [Times: user=0.36 sys=0.00, real=0.14 secs]
2018-01-19T21:01:26.585-0800: [Full GC (Ergonomics) [PSYoungGen: 456673K->0K(468992K)] [ParOldGen: 1384488K->499639K(1398272K)] 1841162K->499639K(1867264K), [Metaspace: 52098K->52098K(1097728K)], 0.1344279 secs] [Times: user=0.32 sys=0.01, real=0.14 secs]
jstat -gc pid -t 1s
Timestamp S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
1438.8 1024.0 5120.0 0.0 0.0 443392.0 430848.7 1398272.0 478878.3 53464.0 52117.3 6144.0 5945.4 1733 97.928 949 166.820 264.748
1440.0 1024.0 5120.0 0.0 0.0 443392.0 435843.6 1398272.0 1321492.8 53464.0 52117.3 6144.0 5945.4 1733 97.928 950 166.962 264.889
1441.0 1024.0 5120.0 0.0 0.0 443392.0 433460.4 1398272.0 900800.9 53464.0 52117.3 6144.0 5945.4 1733 97.928 952 167.226 265.153
1441.9 1024.0 5120.0 0.0 0.0 443392.0 0.0 1398272.0 479419.0 53464.0 52117.3 6144.0 5945.4 1733 97.928 954 167.491 265.419
1443.0 1024.0 5120.0 0.0 0.0 443392.0 438270.0 1398272.0 1324328.4 53464.0 52117.3 6144.0 5945.4 1733 97.928 955 167.632 265.560
1444.0 1024.0 5120.0 0.0 0.0 443392.0 437239.3 1398272.0 902696.2 53464.0 52117.3 6144.0 5945.4 1733 97.928 957 167.902 265.830
1445.0 1024.0 5120.0 0.0 0.0 443392.0 440249.7 1398272.0 1326030.9 53464.0 52117.3 6144.0 5945.4 1733 97.928 959 168.046 265.974
1446.0 1024.0 5120.0 0.0 0.0 443392.0 434997.3 1398272.0 903830.7 53464.0 52117.3 6144.0 5945.4 1733 97.928 960 168.341 266.269
1447.0 1024.0 5120.0 0.0 0.0 443392.0 423591.6 1398272.0 480931.8 53464.0 52117.3 6144.0 5945.4 1733 97.928 962 168.610 266.537
问题原因
发生了FullGC，先拿出现在的Heap Dump看看当前JVM的堆内存使用情况
jmap -dump:format=b,file=dump.bin pid
拿到dump文件，拿到MAT中分析下，在dominator_tree视图中找到占用内存较多的对象，这里是byte数组，接下来找到byte数组属于哪一个类，在byte数据上右键"Path To GC Roots" -> "with all reference"就是下图
看到org.jboss.netty.handler.codec.frame.FrameDecoder#cumulation这个对象很大，这个类是HttpRequestDecoder的超类，接下来就是调试源码，查看为什么这个字段会这么大
找到这个字段的所有引用的地方，查看哪里往byte数组（cumulation这个字段包含一个byte数组）中写，主要是下面两个方法
// 这个方法只是把原来的cumulation和新增的input复合到一个对象中，CompositeChannelBuffer
org.jboss.netty.handler.codec.frame.FrameDecoder#appendToCumulation
// 这个方法会对cumulation重新赋值，并把input写入cumulation中，也就是这个时候byte数组会增大
org.jboss.netty.handler.codec.frame.FrameDecoder#updateCumulation
org.jboss.netty.handler.codec.replay.ReplayingDecoder#messageReceived方法中调用上面这两个方法，ReplayingDecoder是HttpRequestDecoder的超类，在接收到请求的时候会调用messageReceived方法，所以在接收到请求的时候就会向cumulation中写数据。
那么现在问题基本清晰了，不断往byte数组中写数据导致byte数组不断增大，问题应该出在byte数组没有被清空上，所以现在的问题是
为什么cumulation没有被清空？
查找所有cumulation被清空的方法
org.jboss.netty.handler.codec.replay.ReplayingDecoder#cleanup
看看谁调用了这个方法
// 连接断开的时候调用这个方法
org.jboss.netty.handler.codec.frame.FrameDecoder#channelDisconnected
// 连接关闭的时候调用这个方法
org.jboss.netty.handler.codec.frame.FrameDecoder#channelClosed
所以只有在连接断开或者关闭的时候才会清空cumulation，结论已经呼之欲出了，回到一开始出现的问题
- dubbo请求，非http请求
- 大量并发请求
在接收到dubbo请求的时候，虽然不是http协议，但是还是会执行HttpRequestDecoder这个handler，也就会往cumulation中写数据，但是dubbo协议使用的是长连接（netty维护的长连接），所以dubbo请求的内容都会被加入到cumulation中，直到连接关闭或者断开才会清空，如果并发量大的话就会导致有多个cumulation大对象，如果对空间不够的时候就会引起FullGC。
而http协议一般都是短连接，或者有超时时间（服务端超时或者客户端超时），这样cumulation就会被及时清空，所以http协议不容易出现这种问题，而dubbo协议更容易出现的原因。
解决问题
既然是非http请求就不需要使用HttpRequestDecoder做进一步处理，所以新建一个类HttpRequestWrapDecoder继承自HttpRequestDecoder，重写messageReceived方法，在该方法里面判断是否是http请求，如果是http请求才会进一步处理，否则直接返回不处理，执行pipeline中下一个handler
