（k8s中）docker netty OOM问题记录
1、首先查看docker的内存占用情况：
docker top 容器名 -u 查看内存cpu占用率（容器名来自kubectl describe pod xxx或者docker ps）
可以看出内存一直增长，作为IO代理这是不正常的。
2、修改启动参数和配置文件
需要注意的是为了安全考虑，docker默认是不能使用一些调试手段的，需要修改启动参数和yaml
docker file中增加启动参数（yaml中应该也可以）：
ENTRYPOINT ["java", "-jar", "/usr/local/bin/access-1.0-SNAPSHOT.jar", "-XX:NativeMemoryTracking=detail"]
yaml增加：
apiVersion: apps/v1
kind: Deployment
.......
spec:........template:........spec: containers:- name: access......... securityContext:capabilities:add: ["SYS_PTRACE"]
3、查看具体内存占用
各类内存增长情况：
#建立内存基线
jcmd 1 VM.native_memory baseline
#与基线对比
jcmd 1 VM.native_memory summary.diff
其中1是pid，可以通过jps查看
查看当前内存具体申请源：
jcmd 1 VM.native_memory detail scale=MB
查看结果是Other的内存增长比较明显：
[0x00007f76b2143b77] Unsafe_AllocateMemory0+0x87
[0x00007f769577c4ba](malloc=732MB type=Other #228)
Unsafe_AllocateMemory0一般是ByteBuf申请的内存，jvm不管理，也就是不会gc，需要自己关注申请和释放
4、自己申请的ByteBuf
自己申请的ByteBuf要么往下传递（通过ctx write或者fire read）由后面的pipe节点释放，要么自己通过release释放。
如果是写入服务器response中的content，通过ctx.writeAndFlush往下传递，由netty去管就行了。
5、在pipe的handle中收到的msg
比如服务器上收到的request，如果不是最后一个节点，则必须显式传递：ctx.fireChannelRead(msg);
如果是最后一个节点则自己手动释放，可以content.release也可以ReferenceCountUtil.release(msg);
也可以继承SimpleChannelInboundHandler，SimpleChannelInboundHandler中会释放，不用自己释放了。
如果是服务器处理一个请求回复一个响应，一般是作为最后一个节点，可以继承SimpleChannelInboundHandler。