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

最新推荐文章于 2024-12-23 20:10:47 发布
最新推荐文章于 2024-12-23 20:10:47 发布
阅读量2.9k 收藏
点赞数 1
CC 4.0 BY-SA版权
分类专栏： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lp8800/article/details/80388094
本文探讨了Netty中DirectMemory泄漏的问题，并提供了解决方案。通过调整启动参数关闭DirectMemory使用，有效避免了ByteBuf的泄漏问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

之前一直苦于无法解决这个问题，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

 

 

【netty】netty ResourceLeakDetector 资源泄露检测
九师兄
06-26 648
当你通过 ChannelInboundHandler.channelRead(…) 或者 ChannelOutboundHandler.write(…) 来处理数据，重要的是在处理资源时要确保资源不要泄漏。Netty 使用引用计数器来处理池化的 ByteBuf。所以当 ByteBuf 完全处理后，要确保引用计数器被调整。引用计数的权衡之一是用户时必须小心使用消息。当 JVM 仍在 GC(不知道有这样的消息引用计数)这个消息，以至于可能是之前获得的这个消息不会被放回池中。
netty5.0中bytebuf的方法
qq502948261的博客
03-22 653
1. 概念 Java NIO API自带的缓冲区类功能相当有限，没有经过优化，使用JDK的ByteBuffer操作更复杂。故而Netty的作者Trustin Lee为了实现高效率的网络传输，重新造轮子，Netty中的ByteBuf实际上就相当于JDK中的ByteBuffer，其作用是在Netty中通过Channel传输数据。 2. 优势 可以自定义缓冲类型； 通过内置的复合缓冲类型，实现透明的零拷贝(zero-copy)； 不需要调用flip()来切换读/写模式； 读取和写入索引分开； 方法链
Netty源码解析(四) —— NioEventLoop处理io
fanday的博客
08-23 1916
NioEventLoop处理io的一些操作方法 io.netty.channel.nio.NioEventLoop#run /** * 启动服务 轮询selector */ @Override protected void run() { for (;;) { try { ...
netty LEAK: ByteBuf.release() was not called before it's garbage-collected
weixin_34037173的博客
02-08 4750
背景、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 1502
JVM 增加启动参数 : -Dio.netty.leakDetectionLevel=advanced 让程序一直跑，检测到内存泄漏就报错： 看下面有异常代码了，copy 的之后，没有 ReferenceCountUtil.release(buf) : 见 reference-count
Netty Memory Leak Error
Derek_Zhang_的专栏
11-19 1565
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 1427
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 4872
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 2719
netty direct memory
记netty LEAK: ByteBuf.release() was not called before it‘s garbage-collected异常排查
m0_37927455的博客
04-29 1606
问题描述： this4j-->ERROR {ResourceLeakDetector.java:319} - 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: #1: io.netty.buffer....
netty使用中的LEAK: ByteBuf.release() was not called before it‘s garbage-collected
热门推荐
weixin_45568648的博客
12-31 2万+
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 1万+
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 7557
问题背景： 最近一个项目要对接一个电子秤，电子秤串口转网口直连用户一体机，在用户一体机上写一个程序读取称重数据并以客户端形式发送给服务器上的WCS服务。WCS服务里使用netty写了个服务端接收数据。 问题产生： 刚开始我在建立连接的地方打了个日志，并且将获取到的数据也打了个日志，一切运行正常。后来觉得使用tcp短连接，连接成功的日志一直打印很占日志，影响后期问题定位，就将打的日志给删掉，发现报这个错，加了日志输出就正常运行，感觉很奇怪，也没分析...
java netty 内存泄露_Netty开发调试设置io.netty.leakDetection.level=PARANOID定位内存泄漏问题...
weixin_33002763的博客
03-02 1735
偶然一次再测试环境看到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...
Netty是如何检测资源泄漏的？
程序员小潘
06-16 1011
为了减轻GC的压力、以及避免频繁向OS申请和释放内存，Netty基于JeMalloc思想自己实现了一套内存管理方案。不管是堆内存还是直接内存，都可以交给Netty来统一管理，这带来了两个好处，一是可以减轻GC的压力，二是可以避免向OS频繁申请和释放内存，Netty一次性申请一大块内存，然后按需分配。 同时，也带来一个坏处，就是开发者使用完毕后，必须及时释放掉资源，否则会导致内存泄漏。 综上所述，自己管理内存会带来更好的性能，但是也增大了内存泄漏的可能性。为了尽量避免内存泄漏，Netty提供了Resource
Netty开发调试设置io.netty.leakDetection.level=PARANOID定位内存泄漏问题
qq276726581的博客
04-01 4023
看到这个错误，看不出内存泄漏的位置。但在环境里也没有设置 -Dio.netty.leakDetectionLevel=advanced 这个问题在测试环境出现还好，如果在生产环境那就糟糕了。所以怎么可以今早在开发过程中就发现以及定位到内存泄漏的问题呢？ Netty的内存泄漏检测分为四个级别： DISABLED - 完成禁止检测内存泄漏，这个是不推荐。 SIMPLE - 如果buffer中出现1%的内存泄漏，打印错误日志，就是上面那样。但是日志是看不到详细在什么位置出现了内存泄漏。鉴于性能考虑，这
Netty之有效规避内存泄漏
weixin_33754913的博客
01-29 532
有过痛苦的经历，特别能写出深刻的文章 —— 凯尔文. 肖 直接内存是IO框架的绝配，但直接内存的分配销毁不易，所以使用内存池能大幅提高性能，也告别了频繁的GC。但，要重新培养被Java的自动垃圾回收惯坏了的惰性。 Netty有一篇必读的文档 官方文档翻译：引用计数对象 ，在此基础上补充一些自己的理解和细节。   1.为什么要有引用计数器 Netty里四种主力的ByteBuf，其中Unpo...
netty使用ResourceLeakDetector检测内存泄漏问题
编程随手记
04-11 2851
文章目录相关参数检测级别：junit5+embeddedchannel 检测handler内存泄漏问题 相关参数 -Dio.netty.noResourceLeakDetection=false # 就版本是否禁用泄漏检测， 默认不禁用， 已过时， 新版本建议用检测级别配置设置 -Dio.netty.leakDetectionLevel=PARANOID #旧版本配置, paranoid级别检测 -Dio.netty.leakDetection.level=advanced #新版本配置, advanc
Netty内存泄漏：LEAK: ByteBuf.release() was not called before it‘s garbage-collected.
weixin_46425661的博客
12-23 2027
本文主要介绍Netty中未及时调用ByteBuf.release()导致的内存泄漏问题
redisson-netty-1-1] but has failed to stop it. This is very liredisson-netty-1-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of threadkely to create a memory leak. Stack trace of thread
最新发布
07-11
Redisson 在使用过程中，如果出现 Netty 线程无法正常停止的情况，通常与资源未正确释放有关。此类问题可能引发内存泄漏，并在日志中输出类似以下的堆栈信息： ``` java.lang.IllegalStateException: failed to create a child event loop at io.netty.util.concurrent.MultithreadEventExecutorGroup.newChild(MultithreadEventExecutorGroup.java:...) ... Caused by: java.lang.OutOfMemoryError: unable to create new native thread ... ``` ### 原因分析 1. **线程池未关闭** Redisson 内部依赖 Netty 实现网络通信，默认情况下会创建多个 EventLoop 线程用于处理 I/O 操作。若在应用关闭时未能正确调用 `Redisson.shutdown()` 方法，这些线程将不会被回收，导致线程持续运行并占用系统资源 [^1]。 2. **线程泄漏或重复初始化** 如果 Redisson 客户端实例被多次创建而没有及时销毁，会导致 Netty 的 EventLoopGroup 不断增长，最终耗尽系统线程资源。应确保 RedissonClient 是单例模式使用，并在整个应用生命周期内只初始化一次 [^1]。 3. **JVM 参数配置不当** 默认的线程栈大小（如 `-Xss`）可能设置过小，导致创建大量线程时触发 `OutOfMemoryError`。此外，操作系统的最大线程数限制也可能影响线程创建的成功率。 4. **Netty 版本兼容性问题** 使用的 Netty 版本可能存在 Bug，特别是在旧版本中某些资源释放逻辑存在缺陷，可能导致线程未正确终止。建议升级到最新的稳定版本以修复潜在问题。 ### 解决方案 - **确保正确关闭 Redisson 实例** 应用关闭时必须显式调用 `Redisson.shutdown()` 方法，确保所有内部线程和连接资源被释放： ```java Config config = new Config(); config.useSingleServer().setAddress("redis://127.0.0.1:6379"); RedissonClient redisson = Redisson.create(config); // 应用关闭前 redisson.shutdown(); ``` - **避免重复创建 RedissonClient 实例** 应用中应保证 RedissonClient 的唯一性，推荐通过 Spring 等容器管理其生命周期，确保全局仅初始化一次 [^1]。 - **调整 JVM 和系统参数** 可适当增加 `-Xss` 值以提高每个线程的栈空间，同时检查操作系统的 ulimit 设置，确保允许创建足够的线程数。 - **升级 Netty 和 Redisson 版本** 若当前使用的 Redisson 或 Netty 版本较旧，建议升级至官方推荐的最新稳定版本，以获得更好的兼容性和性能优化。 ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值