Netty 发生leak时需要解决的方法

最新推荐文章于 2024-07-14 12:30:47 发布
最新推荐文章于 2024-07-14 12:30:47 发布
阅读量2.7k 收藏
点赞数 1
分类专栏： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lp8800/article/details/80388094
版权

之前一直苦于无法解决这个问题，Netty应该结合MQ，分布式多端处理大量密集消息，并且密集消息有可能为耗时操作时，此方式极为有用。而当前方式为单端消息处理，由线程池负责处理和分发压力，所以存在可能的ByteBuf的leak问题。

 

https://netty.io/wiki/reference-counted-objects.html

 

Netty接收消息后的异常为：

ERROR io.netty.util.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected. See http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 4
#4:
	io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:240)
	org.ginryan.udp.impl.core.GZipFirstHandler.channelRead(GZipFirstHandler.java:23)
	org.ginryan.udp.impl.core.NioDatagramThread$1$1.channelRead(NioDatagramThread.java:68)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
	io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:93)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
	io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
	java.lang.Thread.run(Thread.java:748)
#3:
	Hint: 'NioDatagramThread$1$1#0' will handle the message from this point.
	io.netty.channel.DefaultAddressedEnvelope.touch(DefaultAddressedEnvelope.java:117)
	io.netty.channel.socket.DatagramPacket.touch(DatagramPacket.java:85)
	io.netty.channel.socket.DatagramPacket.touch(DatagramPacket.java:27)
	io.netty.channel.DefaultChannelPipeline.touch(DefaultChannelPipeline.java:116)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:345)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
	io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:93)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
	io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
	java.lang.Thread.run(Thread.java:748)
#2:
	Hint: 'DefaultChannelPipeline$HeadContext#0' will handle the message from this point.
	io.netty.channel.DefaultAddressedEnvelope.touch(DefaultAddressedEnvelope.java:117)
	io.netty.channel.socket.DatagramPacket.touch(DatagramPacket.java:85)
	io.netty.channel.socket.DatagramPacket.touch(DatagramPacket.java:27)
	io.netty.channel.DefaultChannelPipeline.touch(DefaultChannelPipeline.java:116)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:345)
	io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
	io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:93)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
	io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
	java.lang.Thread.run(Thread.java:748)
#1:
	io.netty.buffer.AdvancedLeakAwareByteBuf.internalNioBuffer(AdvancedLeakAwareByteBuf.java:732)
	io.netty.channel.socket.nio.NioDatagramChannel.doReadMessages(NioDatagramChannel.java:248)
	io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:75)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
	io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
	java.lang.Thread.run(Thread.java:748)
Created at:
	io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:331)
	io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
	io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:172)
	io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:133)
	io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:80)
	io.netty.channel.socket.nio.NioDatagramChannel.doReadMessages(NioDatagramChannel.java:244)
	io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:75)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
	io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
	java.lang.Thread.run(Thread.java:748)

当前内存泄漏问题是DirectMemory泄漏导致的问题，关掉DirectMemory就可以解决这个问题。

启动时要增加以下属性：

-Dio.netty.noPreferDirect=true  -Dio.netty.allocator.type=unpooled  -Dio.netty.maxDirectMemory=0 -Dio.netty.leakDetectionLevel=advanced

 

 

XellossRyan
关注
专栏目录
【netty】netty ResourceLeakDetector 资源泄露检测
九师兄
06-26 386
当你通过 ChannelInboundHandler.channelRead(…) 或者 ChannelOutboundHandler.write(…) 来处理数据，重要的是在处理资源时要确保资源不要泄漏。Netty 使用引用计数器来处理池化的 ByteBuf。所以当 ByteBuf 完全处理后，要确保引用计数器被调整。引用计数的权衡之一是用户时必须小心使用消息。当 JVM 仍在 GC(不知道有这样的消息引用计数)这个消息，以至于可能是之前获得的这个消息不会被放回池中。
netty使用ResourceLeakDetector检测内存泄漏问题
编程随手记
04-11 2324
文章目录相关参数检测级别：junit5+embeddedchannel 检测handler内存泄漏问题 相关参数 -Dio.netty.noResourceLeakDetection=false # 就版本是否禁用泄漏检测， 默认不禁用， 已过时， 新版本建议用检测级别配置设置 -Dio.netty.leakDetectionLevel=PARANOID #旧版本配置, paranoid级别检测 -Dio.netty.leakDetection.level=advanced #新版本配置, advanc
java netty 内存泄露_Netty开发调试设置io.netty.leakDetection.level=PARANOID定位内存泄漏问题...
weixin_33002763的博客
03-02 1568
偶然一次再测试环境看到netty出现内存泄漏的日志，报错信息如下：LEAK: ByteBuf.release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak repor...
ByteBuf.release() was not called before it‘s garbage-collected
最新发布
Java程序员的知识博客
07-14 650
本文讨论了什么是引用技术对象，已经在netty中的应用和内存泄漏发生场景、检测、排除修复等技术手段
netty LEAK: ByteBuf.release() was not called before it's garbage-collected
weixin_34037173的博客
02-08 4680
背景、netty抛出完整的error信息如下： 2018-02-08 14:30:43.098 [nioEventLoopGroup-5-1] ERROR io.netty.util.ResourceLeakDetector:176 - LEAK: ByteBuf.release() was not called before it's garbage-collected. Enable adva...
Netty -LEAK: ByteBuf.release()
WGYHAPPY的博客
01-25 1449
JVM 增加启动参数 : -Dio.netty.leakDetectionLevel=advanced 让程序一直跑，检测到内存泄漏就报错： 看下面有异常代码了，copy 的之后，没有 ReferenceCountUtil.release(buf) : 见 reference-count
Netty Memory Leak Error
Derek_Zhang_的专栏
11-19 1503
1. java.lang.OutOfMemoryError: GC overhead limit exceeded at com.jcraft.jzlib.InfBlocks.(InfBlocks.java:114) at com.jcraft.jzlib.Inflate.inflateInit(Inflate.java:181) at com.j
Netty Thread Leak?
Derek_Zhang_的专栏
11-13 1370
1. Problem 我们的netty程序既是client也是server，从upstream server拿数据再提供给downstream clients。 现在的情况是运行一段时间后就不再能拿到新的数据了，所以downstream clients也只能拿到初始化数据了。 2. Analysis 2.1 Monitor and Static Analysis 用jvisualvm监控
netty: LEAK: ByteBuf.release() was not called before it‘s garbage-collected
weixin_43926508的博客
09-06 4598
Netty中 LEAK: ByteBuf.release() was not called before it‘s garbage-collected 导致OutOfMemoryError 排查解决 为了节省成本公司需要在内部搭建一个代理服务器用于传输服务数据,由于大部分是视频数据也并发所以选用了netty框架, 却在部署上服务器试运行后内存溢出了,具体: 这边很容易看出是内存溢出了而且是netty的直接内存分配不够导致的 netty的数据读取写入确实是以一个个内存块方式进行的,问题是netty对于
netty 4.0.24版本Direct Memory Leak
Tom的专栏
07-13 2629
netty direct memory
LEAK: ByteBuf.release() Netty引起的堆外内存溢出报错
地平线
09-28 4627
最终解决方式：升级spring cloud版本和spring boot版本 因为我的框架一直使用的是H版， 所以spring cloud升级到了 Hoxton.SR12 ， 对应的spring boot是 : 2.3.12.RELEASE两类报错：LEAK: ByteBuf.release() was not called before it’s garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for
netty使用中的LEAK: ByteBuf.release() was not called before it‘s garbage-collected
热门推荐
weixin_45568648的博客
12-31 1万+
1.问题描述 使用netty做底层的tcp数据收发的项目时候，当对象上升到一定的时候（我这里是每秒1400的tcp包）会偶尔出现：LEAK: ByteBuf.release() was not called before it’s garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.Recent access records: 2.问题分析 我们是在数量多了以后遇到了
netty报错：LEAK: ByteBuf.release() was not called before it‘s garbage-collected
雅俗共赏的博客
08-22 9185
netty报错：LEAK: ByteBuf.release() was not called before it's garbage-collected
netty报错LEAK: ByteBuf.release() was not called before it‘s garbage-collected.的解决方法
流苏打的博客
05-12 7192
问题背景： 最近一个项目要对接一个电子秤，电子秤串口转网口直连用户一体机，在用户一体机上写一个程序读取称重数据并以客户端形式发送给服务器上的WCS服务。WCS服务里使用netty写了个服务端接收数据。 问题产生： 刚开始我在建立连接的地方打了个日志，并且将获取到的数据也打了个日志，一切运行正常。后来觉得使用tcp短连接，连接成功的日志一直打印很占日志，影响后期问题定位，就将打的日志给删掉，发现报这个错，加了日志输出就正常运行，感觉很奇怪，也没分析...
Netty是如何检测资源泄漏的？
程序员小潘
06-16 808
为了减轻GC的压力、以及避免频繁向OS申请和释放内存，Netty基于JeMalloc思想自己实现了一套内存管理方案。不管是堆内存还是直接内存，都可以交给Netty来统一管理，这带来了两个好处，一是可以减轻GC的压力，二是可以避免向OS频繁申请和释放内存，Netty一次性申请一大块内存，然后按需分配。 同时，也带来一个坏处，就是开发者使用完毕后，必须及时释放掉资源，否则会导致内存泄漏。 综上所述，自己管理内存会带来更好的性能，但是也增大了内存泄漏的可能性。为了尽量避免内存泄漏，Netty提供了Resource
Netty开发调试设置io.netty.leakDetection.level=PARANOID定位内存泄漏问题
qq276726581的博客
04-01 3210
看到这个错误，看不出内存泄漏的位置。但在环境里也没有设置 -Dio.netty.leakDetectionLevel=advanced 这个问题在测试环境出现还好，如果在生产环境那就糟糕了。所以怎么可以今早在开发过程中就发现以及定位到内存泄漏的问题呢？ Netty的内存泄漏检测分为四个级别： DISABLED - 完成禁止检测内存泄漏，这个是不推荐。 SIMPLE - 如果buffer中出现1%的内存泄漏，打印错误日志，就是上面那样。但是日志是看不到详细在什么位置出现了内存泄漏。鉴于性能考虑，这
Netty之有效规避内存泄漏
weixin_33754913的博客
01-29 487
有过痛苦的经历，特别能写出深刻的文章 —— 凯尔文. 肖 直接内存是IO框架的绝配，但直接内存的分配销毁不易，所以使用内存池能大幅提高性能，也告别了频繁的GC。但，要重新培养被Java的自动垃圾回收惯坏了的惰性。 Netty有一篇必读的文档 官方文档翻译：引用计数对象 ，在此基础上补充一些自己的理解和细节。   1.为什么要有引用计数器 Netty里四种主力的ByteBuf，其中Unpo...
Netty源码解析(四) —— NioEventLoop处理io
fanday的博客
08-23 1858
NioEventLoop处理io的一些操作方法 io.netty.channel.nio.NioEventLoop#run /** * 启动服务 轮询selector */ @Override protected void run() { for (;;) { try { ...
解决缓冲区泄漏
h_big_tiger的博客
12-15 967
解决缓冲区泄漏 引用计数的缺点是容易泄漏引用计数的对象。因为JVM不了解Netty实现的引用计数，所以一旦它们无法访问，即使它们的引用计数不为零，它也会自动对它们进行GC。一旦回收了垃圾，就无法将其复活，因此不能将其返回到它来自的池中，从而会导致内存泄漏。 幸运的是，尽管难以发现泄漏，但Netty默认情况下会抽样大约1％的缓冲区分配，以检查应用程序中是否存在泄漏。如果发生泄漏，您将发现以下日志消息...
Netty线程膨胀问题分析与解决
当发现Netty的NIO线程达到3000多个时，这表明可能存在配置不当或代码逻辑错误，需要进行问题分析和定位。 为了排查此类问题，开发者可以使用像JMC（Java Mission Control）这样的工具，它提供了飞行记录器功能，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值