合肥网站制作方案,常州网站建设公司服务,洛卡博网站谁做的,北京网站开发公司有过痛苦的经历#xff0c;特别能写出深刻的文章 —— 凯尔文. 肖 直接内存是IO框架的绝配#xff0c;但直接内存的分配销毁不易#xff0c;所以使用内存池能大幅提高性能#xff0c;也告别了频繁的GC。但#xff0c;要重新培养被Java的自动垃圾回收惯坏了的惰性。 Netty有…有过痛苦的经历特别能写出深刻的文章 —— 凯尔文. 肖 直接内存是IO框架的绝配但直接内存的分配销毁不易所以使用内存池能大幅提高性能也告别了频繁的GC。但要重新培养被Java的自动垃圾回收惯坏了的惰性。 Netty有一篇必读的文档 官方文档翻译引用计数对象 在此基础上补充一些自己的理解和细节。 1.为什么要有引用计数器 Netty里四种主力的ByteBuf其中UnpooledHeapByteBuf 底下的byte[]能够依赖JVM GC自然回收而UnpooledDirectByteBuf底下是DirectByteBuffer如Java堆外内存扫盲贴所述除了等JVM GC最好也能主动进行回收而PooledHeapByteBuf 和 PooledDirectByteBuf则必须要主动将用完的byte[]/ByteBuffer放回池里否则内存就要爆掉。所以Netty ByteBuf需要在JVM的GC机制之外有自己的引用计数器和回收过程。 一下又回到了C的冰冷时代自己malloc对象要自己free。 但和C时代又不完全一样内有引用计数器外有JVM的GC情况更为复杂。 2. 引用计数器常识 计数器基于 AtomicIntegerFieldUpdater为什么不直接用AtomicInteger因为ByteBuf对象很多如果都把int包一层AtomicInteger花销较大而AtomicIntegerFieldUpdater只需要一个全局的静态变量。所有ByteBuf的引用计数器初始值为1。调用release()将计数器减1等于零时 deallocate()被调用各种回收。调用retain()将计数器加1即使ByteBuf在别的地方被人release()了在本Class没喊cut之前不要把它释放掉。由duplicate(), slice()和order()所衍生的ByteBuf与原对象共享底下的buffer也共享引用计数器所以它们经常需要调用retain()来显示自己的存在。当引用计数器为0底下的buffer已被回收即使ByteBuf对象还在对它的各种访问操作都会抛出异常。 3.谁来负责Release 在C时代我们喜欢让malloc和free成对出现而在Netty里因为Handler链的存在ByteBuf经常要传递到下一个Hanlder去而不复还所以规则变成了谁是最后使用者谁负责释放。 另外更要注意的是各种异常情况ByteBuf没有成功传递到下一个Hanlder还在自己地界里的话一定要进行释放。 3.1 InBound Message 在AbstractNioByteChannel.NioByteUnsafe.read() 处创建了ByteBuf并调用 pipeline.fireChannelRead(byteBuf) 送入Handler链。 根据上面的谁最后谁负责原则每个Handler对消息可能有三种处理方式 对原消息不做处理调用 ctx.fireChannelRead(msg)把原消息往下传那不用做什么释放。将原消息转化为新的消息并调用 ctx.fireChannelRead(newMsg)往下传那必须把原消息release掉。如果已经不再调用ctx.fireChannelRead(msg)传递任何消息那更要把原消息release掉。假设每一个Handler都把消息往下传Handler并也不知道谁是启动Netty时所设定的Handler链的最后一员所以Netty在Handler链的最末补了一个TailHandler如果此时消息仍然是ReferenceCounted类型就会被release掉。 3.2 OutBound Message 要发送的消息由应用所创建并调用 ctx.writeAndFlush(msg) 进入Handler链。在每个Handler中的处理类似InBound Message最后消息会来到HeadHandler再经过一轮复杂的调用在flush完成后终将被release掉。 3.3 异常发生时的释放 多层的异常处理机制有些异常处理的地方不一定准确知道ByteBuf之前释放了没有可以在释放前加上引用计数大于0的判断避免释放失败 有时候不清楚ByteBuf被引用了多少次但又必须在此进行彻底的释放可以循环调用reelase()直到返回true。 4. 内存泄漏检测 所谓内存泄漏主要是针对池化的ByteBuf。ByteBuf对象被JVM GC掉之前没有调用release()把底下的DirectByteBuffer或byte[]归还到池里会导致池越来越大。而非池化的ByteBuf即使像DirectByteBuf那样可能会用到System.gc()但终归会被release掉的不会出大事。 Netty担心大家不小心就搞出个大新闻来因此提供了内存泄漏的监测机制。 Netty默认会从分配的ByteBuf里抽样出大约1%的来进行跟踪。如果泄漏会有如下语句打印 LEAK: ByteBuf.release() was not called before its garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, specify the JVM option -Dio.netty.leakDetectionLeveladvanced or call ResourceLeakDetector.setLevel() 这句话报告有泄漏的发生提示你用-D参数把防漏等级从默认的simple升到advanced就能具体看到被泄漏的ByteBuf被创建和访问的地方。 禁用DISABLED - 完全禁止泄露检测省点消耗。简单SIMPLE - 默认等级告诉我们取样的1%的ByteBuf是否发生了泄露但总共一次只打印一次看不到就没有了。高级ADVANCED - 告诉我们取样的1%的ByteBuf发生泄露的地方。每种类型的泄漏创建的地方与访问路径一致只打印一次。对性能有影响。偏执PARANOID - 跟高级选项类似但此选项检测所有ByteBuf而不仅仅是取样的那1%。对性能有绝大的影响。实现细节 每当各种ByteBufAllocator 创建ByteBuf时都会问问是否需要采样Simple和Advanced级别下就是以113这个素数来取模害我看文档的时候还在瞎担心1万一泄漏的地方有所规律刚好躲过了100这个数字呢比如都是3倍数的命中了就创建一个Java堆外内存扫盲贴里说的PhantomReference。然后创建一个Wrapper包住ByteBuf和Reference。 simple级别下wrapper只在执行release()时调用Reference.clear()Advanced级别下则会记录每一个创建和访问的动作。 当GC发生还没有被clear()的Reference就会被JVM放入到之前设定的ReferenceQueue里。 在每次创建PhantomReference时都会顺便看看有没有因为忘记执行release()把Reference给clear掉在GC时被放进了ReferenceQueue的对象有则以 io.netty.util.ResourceLeakDetector”为logger name写出前面例子里的Error级别的日日志。顺便说一句Netty能自动匹配日志框架先找Slf4j再找Log4j最后找JDK logger。 值得说三遍的事 一定要盯紧log里有没有出现 LEAK: 字样因为simple级别下它只会出现一次所以不要依赖自己的眼睛要依赖grep。如果出现了而且你用的是PooledBuf那一定是问题不要有任何的侥幸立刻用-Dio.netty.leakDetectionLeveladvanced 再跑一次看清楚它创建和访问的地方。 功能测试时最好开着-Dio.netty.leakDetectionLevelparanoid。 但是怎么测试都可能存在没有覆盖到的分支。如果内存尚够可以适当把-XX:MaxDirectMemorySize 调大反正只是max平时也不会真用了你的。然后监控其使用量及时报警。 文章持续修订转载请保留原链接 http://calvin1978.blogcn.com/articles/netty-leak.html
