Netty堆外内存泄漏如何应对？

最新推荐文章于 2023-04-23 17:37:27 发布
最新推荐文章于 2023-04-23 17:37:27 发布
阅读量1.3k 收藏 5
点赞数 2
分类专栏： Socket编程生产案例：从NIO到Netty Java实战宝典 文章标签： 内存泄漏 jvm Netty JT/T 905.4-2014
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/l714417743/article/details/119602228
版权

文章目录

一、背景

开发过程中，我们遇到了堆外内存泄漏的问题——服务会出现假死现象（看似服务进程还跑着，但是没有业务响应）。
查看logback的error日志中记录下下面的信息：

[location-center:192.168.5.14:8017] [,] 2021-07-27 09:38:39.640 ERROR 53950 [lettuce-nioEventLoop-8-1] io.netty.util.ResourceLeakDetector 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: 
Created at:
	io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:349)
	io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
	io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
	io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:139)
	io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:114)
	io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:147)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:700)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:635)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:552)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:514)
	io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050)
	io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	java.lang.Thread.run(Thread.java:748)
[location-center:192.168.5.14:8017] [,] 2021-07-27 09:38:39.642 ERROR 53950 [lettuce-nioEventLoop-8-1] io.netty.util.ResourceLeakDetector 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: 
Created at:
	io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:349)
	io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
	io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
	io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:115)
	io.netty.handler.codec.ByteToMessageDecoder.expandCumulation(ByteToMessageDecoder.java:532)
	io.netty.handler.codec.ByteToMessageDecoder$1.cumulate(ByteToMessageDecoder.java:92)
	io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:279)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1422)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:931)
	io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:700)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:635)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:552)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:514)
	io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050)
	io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	java.lang.Thread.run(Thread.java:748)
[location-center:192.168.5.14:8017] [,] 2021-07-27 10:23:56.884 ERROR 53950 [lettuce-nioEventLoop-8-1] io.netty.util.ResourceLeakDetector 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: 
Created at:
	io.netty.buffer.SimpleLeakAwareByteBuf.unwrappedDerived(SimpleLeakAwareByteBuf.java:143)
	io.netty.buffer.SimpleLeakAwareByteBuf.readRetainedSlice(SimpleLeakAwareByteBuf.java:67)
	io.netty.handler.codec.DelimiterBasedFrameDecoder.decode(DelimiterBasedFrameDecoder.java:276)
	io.netty.handler.codec.DelimiterBasedFrameDecoder.decode(DelimiterBasedFrameDecoder.java:218)
	io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:503)
	io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
	io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:281)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1422)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:931)
	io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
	io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:700)
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:635)
	io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:552)
	io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:514)
	io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050)
	io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	java.lang.Thread.run(Thread.java:748)

心急的小伙伴，已经在开始百度的路上了，对不对？此时选择了百度，你就选择了“远路”……

🎃原来，在日志中Netty已经给我们提供了官方文档地址，官方文档对该问题进行了详细的说明。

[danger] 你是否看到了日志中的这个提示？“See https://netty.io/wiki/reference-counted-objects.html for more information.”

二、Netty堆外内存回收机制

什么是堆外内存？

堆外内存也称为直接内存。Netty使用的ByteBuf分配的就是堆外内存，堆外内存是不受JVM垃圾回收机制控制的。

Netty堆外内存回收机制具体如何？谁来负责堆外内存的回收？

If a [sending] component is supposed to pass a reference-counted object to another [receiving] component, the sending component usually does not need to destroy it but defers that decision to the receiving component.
If a component consumes a reference-counted object and knows nothing else will access it anymore (i.e., does not pass along a reference to yet another component), the component should destroy it.

我们可以从官方文档中获取更加清晰的认识，总结如下：

  • Netty堆外内存回收算法是基于引用计数的；
  • 如果一个发送组件（sending component）企图传递一个基于引用计数对象，通常发送组件不需要回收该对象，而是交给消费组件。
  • 如果代码块组件（component）接收基于引用计数的内存对象，且不再使用，该组件应负责引用释放——引用计数会-1。如：ChannelHandler就是典型的引用对象接收组件。

官方提供了判断是否需要引用释放的案例：

public ByteBuf a(ByteBuf input) {
    input.writeByte(42);
    return input;
}

public ByteBuf b(ByteBuf input) {
    try {
        output = input.alloc().directBuffer(input.readableBytes() + 1);
        output.writeBytes(input);
        output.writeByte(42);
        return output;
    } finally {
        input.release();
    }
}

public void c(ByteBuf input) {
    System.out.println(input);
    input.release();
}

public void main() {
    ...
    ByteBuf buf = ...;
    // This will print buf to System.out and destroy it.
    c(b(a(buf)));
    assert buf.refCnt() == 0;
}
事件说明什么对象应该释放？什么对象释放成功了？
1.main()createsbufbuf→main()
2.main()callsa()withbufbuf→a()
3.a()returnsbufmerely.buf→main()
4.main()callsb()withbufbuf→b()
5.b()returns the copy ofbufbuf→b(),copy→main()b()releasesbuf
6.main()callsc()withcopycopy→c()
7.c()swallowscopycopy→c()c()releasescopy

翻看netty源码，我们可以找到堆外内存回收的一些入口：
io.netty.buffer.AbstractReferenceCountedByteBuf#release()。

入队消息对象如何回收？

上面的内容是不是看着有点绕，在Netty中Bytebuf一般用在ChannelHandler中，官方文档也提供了较为详细的案例。

  1. 入队消息（Inbound messages）触发读取（channelRead()），消费收到消息的handler应该负责调用release()方法：
    如：
public void channelRead(ChannelHandlerContext ctx, Object msg) {
    ByteBuf buf = (ByteBuf) msg;
    try {
        ...
    } finally {
        buf.release();
    }
}
  1. 消息解析器也会产生引用计数。
// Assuming your handler is placed next to `HttpRequestDecoder`
public void channelRead(ChannelHandlerContext ctx, Object msg) {
    if (msg instanceof HttpRequest) {
        HttpRequest req = (HttpRequest) msg;
        ...
    }
    if (msg instanceof HttpContent) {
        HttpContent content = (HttpContent) msg;
        try {
            ...
        } finally {
            content.release();
        }
    }
}

以上两种情况，在判别上有难度的话，Netty还提供更加简洁的方式来释放引用：

public void channelRead(ChannelHandlerContext ctx, Object msg) {
    try {
        ...
    } finally {
        ReferenceCountUtil.release(msg);
    }
}

当然，出队消息对象引用释放不当，也会造成堆外内存泄漏，更多内容欢迎自行查看官方文档，子涵再此也就不再一一翻译了。

三、堆外内存监控配置

堆外内存到底有没有被回收，那么，在netty中如何进行监控？Netty中有个对象PlatformDependent.class，其中的"DIRECT_MEMORY_COUNTER"记录了堆外内存占用的情况，我们可以通过反射获取该对象的值，从而达到监控的目的。

反射监控堆外内存

在Springboot项目中，我们可以定义一个定时任务，实时打印堆外内存的情况到日志中。

import io.netty.util.internal.PlatformDependent;
import lombok.extern.slf4j.Slf4j;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.EnableScheduling;
import org.springframework.scheduling.annotation.Scheduled;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;

@Configuration      //1.主要用于标记配置类，兼备Component的效果。
@EnableScheduling   // 2.开启定时任务
@Slf4j
public class SaticScheduleTask {
    private static final int _1K = 1024;
    private static final String BUSINESS_KEY = "netty-direct-memory";
    private AtomicLong directMemory;
    
    @PostConstruct
    public void init(){
        Field field = ReflectUtil.getField(PlatformDependent.class,"DIRECT_MEMORY_COUNTER");
        field.setAccessible(true);
        try {
            directMemory = (AtomicLong) field.get(PlatformDependent.class);
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
    }

    /**
     * 每隔5s统计一下堆外直接内存
     */
    @Scheduled(fixedRate = 30000)
    public void report(){
        int memoryInKb = (int) (directMemory.get()/_1K);
        log.info("{}:{}k",BUSINESS_KEY,memoryInKb);
    }
}

服务器上监控堆外内存

cat location-center-info.log |grep netty-direct

结果如下：

[root@localhost location-center]# cat location-center-info.log |grep netty-direct
[location-center:192.168.5.12:8017] [dce11c40a9bc3f77,dce11c40a9bc3f77] 2021-08-02 09:05:42.332 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:32768k
[location-center:192.168.5.12:8017] [f486d613826fab3c,f486d613826fab3c] 2021-08-02 09:06:12.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [a94a3c3012804430,a94a3c3012804430] 2021-08-02 09:06:42.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [2c1e844ae37e00e0,2c1e844ae37e00e0] 2021-08-02 09:07:12.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [67106bcae0fb116d,67106bcae0fb116d] 2021-08-02 09:07:42.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [b9a673e7118c05d7,b9a673e7118c05d7] 2021-08-02 09:08:12.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [ddfe5f1003ac4514,ddfe5f1003ac4514] 2021-08-02 09:08:42.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [cd1fbb7b9c84423d,cd1fbb7b9c84423d] 2021-08-02 09:09:12.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [fd897a29ec939f7f,fd897a29ec939f7f] 2021-08-02 09:09:42.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k
[location-center:192.168.5.12:8017] [48893694a422f0ae,48893694a422f0ae] 2021-08-02 09:10:12.285 INFO 29468 [pool-3-thread-1] com.keyou.evm.location.task.SaticScheduleTask netty-direct-memory:131072k

四、其他案例

Netty堆外内存泄漏还有一些其他场景。本小册不再一一列举，我读过的一些优秀文章希望可以作为大家的参考。

本文已收录在《从NIO到Netty，实战出租车905.4协议》

子涵先生
关注
  • 2
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
【netty】Netty堆外内存泄露排查盛宴
九师兄
10-13 1029
遇到堆外内存泄露不要怕，仔细耐心分析，总能找到思路，要多看日志，多分析。如果使用了 Netty 堆外内存，那么可以自行监控堆外内存的使用情况，不需要借助第三方工具，我们是使用的“反射”拿到的堆外内存的情况。逐渐缩小范围，直到 Bug 被找到。当我们确认某个线程的执行带来 Bug 时，可单步执行，可二分执行，定位到某行代码之后，跟到这段代码，然后继续单步执行或者二分的方式来定位最终出 Bug 的代码。这个方法屡试不爽，最后总能找到想要的 Bug。
netty 堆外内存泄露排查盛宴
weixin_34407348的博客
09-03 1771
这篇文章对于排查使用了 netty 引发的堆外内存泄露问题，有一定的通用性，希望对你有所启发 背景 最近在做一个基于 websocket 的长连中间件，服务端使用实现了 socket.io 协议（基于websocket协议，提供长轮询降级能力） 的 netty-socketio 框架，该框架为 netty 实现，鉴于本人对 netty 比较熟，并且对比同样实现了 socket.io 协议的其他...
Netty堆外内存泄漏排查，这一篇全讲清楚了(转载)
weixin_41778440的博客
06-16 5490
Netty堆外内存泄漏排查，这一篇全讲清楚了(转载)
Netty堆外内存泄漏排查，这一篇全讲清楚了
Java笔记虾
01-05 4905
上篇文章介绍了Netty内存模型原理，由于Netty使用不当会导致堆外内存泄漏，网上关于这方面的资料比较少，所以写下这篇文章，基于Netty4.1.43.Final，专门介绍排查Nett...
堆外内存部分代码
08-11
4. **内存泄漏预防**：由于堆外内存不由JVM管理，开发者需要自行负责内存的释放，避免内存泄漏。在使用JNI或NIO时，必须确保正确地释放不再使用的直接缓冲区。 5. **性能优化**：堆外内存的使用可以提高大数据处理...
详解SpringCloudGateway内存泄漏问题
08-18
Spring Cloud Gateway 内存泄漏问题主要是由于堆外内存的问题，通过调整堆外内存大小、使用 Arthas 分析内存快照、使用 pmap 查看内存等方法，可以解决内存泄漏问题。同时，修改请求头的代码也需要注意内存的使用，...
Netty 25道面试题你和答案.docx
最新发布
06-15
2. 堆外内存：使用直接内存减少复制操作。 3. 内存池：ByteBuf的循环利用，减少对象创建和销毁的开销。 4. 参数可配置：支持I/O线程数、TCP参数调整，适应不同场景。 5. 无锁并发：采用环形数组缓冲区实现无锁化并发...
精通并发与netty 无加密视频
04-13
第60讲：Netty的自适应缓冲区分配策略与堆外内存创建方式 第61讲：Reactor模式5大角色彻底分析 第62讲：Reactor模式组件调用关系全景分析 第63讲：Reactor模式与Netty组件对比及Acceptor组件的作用分析 第64讲：...
netty4.1开发jar和api说明
08-25
- **资源管理**：正确关闭EventLoopGroup和其他资源以避免内存泄漏。 - **错误处理**：使用ChannelHandler的exceptionCaught()方法捕获和处理异常。 - **性能调优**：根据实际场景调整EventLoop数量、ByteBuf大小...
堆外内存泄露
奋斗、
08-25 5579
原文：https://mp.weixin.qq.com/s?__biz=MzIzNzQzNjEwMw==&mid=2247484816&idx=1&sn=2e60a5afffcbcec401c10a3c85c91173&chksm=e8c9e838dfbe612e8134613b37bf739d22de242482a758dcfdbb55b0beff6c819e9bbb392f9d&mpshare
Netty堆外内存泄露排查盛宴
一个有情怀的程序猿博客
06-21 338
导读 Netty 是一个异步事件驱动的网络通信层框架，用于快速开发高可用高性能的服务端网络框架与客户端程序，它极大地简化了 TCP 和 UDP 套接字服务器等网络编程。 Netty 底层基于 JDK 的 NIO，我们为什么不直接基于 JDK 的 NIO 或者其他NIO框架： 使用 JDK 自带的 NIO 需要了解太多的概念，编程复杂。 Netty 底层 IO 模型随意切换，而这一切只需要做微小的改动。 Netty自带的拆包解包，异常检测等机制让我们从 NIO 的繁重细节中脱离出来，只需关心..
netty4.1.30-4.1.85版本内存泄漏问题解决
l1016337816的博客
12-02 555
1.netty-transport-4.1.30.Final.jar的AbstractNioByteChannel类的read方法存在内存泄漏的问题。
netty-grpc一次DirectByteBuffer内存泄露
xihuanyuye的博客
11-01 1004
当前怀疑在发送突然超过DirectByteBuffer总大小时，发生了Om，并且会导致后续一直无法回收内存。增大XX:MaxDirectMemorySize为512M，进行观察。观察到，其中buffer Pools稳定在40M+，重启后恢复。计算了一下，大概是64M，正好是jvm启动时设置的参数大小。当前应用会采用grpc大量发送数据，并且并发量并不固定。
gateway报 netty堆外内存溢出问题解决io.netty.util.internal.OutOfDirectMemoryError
qq_18630487的博客
04-21 4379
gateway报 netty堆外内存溢出问题解决，很多博客都是一知半解并不能解决我的问题。但是大概得到一个信息，这bug是有netty导致的，一般是用了ByteBuf对象没有调用release()释放内存。如上图已经提示了错误发生的地方，自行去代码中改就好。本地把把项目跑起来，记得加JVM参数 -Dio.netty.leakDetectionLevel=paranoid 开启netty自带检测，级别调到最高（火力全开！事实证明，我的问题恰恰不在大部分里面。经过一番激烈的研究（百度），应该是依赖版本的bug。
(转载)Netty 防止内存泄漏措施
楠之枫雪的博客
06-08 495
背景 直播平台内存泄漏问题： 某直播平台，一些网红的直播间在业务高峰期，会有 10W+ 的粉丝接入，如果瞬间发生大量客户端连接掉线、或者一些客户端网络比较慢，发现基于 Netty 构建的服务端内存会飙升，发生内存泄漏（OOM），导致直播卡顿、或者客户端接收不到服务端推送的消息，用户体验受到很大影响。 问题分析 首先对 GC 数据进行分析，发现老年代已满，发生多次 Full GC，耗时达 3 分多，系统已经无法正常运行（示例）： Dump 内存堆栈进行分析，发现大量的发送任务堆积，导致内存溢出（示例）：
JVM学习小结(一)
ls_wifi的博客
07-05 248
类加载器ClassLoader：负责加载class文件，class文件在文件开头有特定的文件标示，将class文件字节码内容加载到内存中，并将这些内容转换成方法区中的运行时数据结构并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定 虚拟机自带的加载器：启动类加载器（Bootstrap） C++ 扩展类加载器（Extension） Java ...
netty使用异常，nio使用DirectBuffer导致内存溢出
闫玉林的博客
04-23 1945
Netty是基于NIO的框架，因此在使用Netty时可能会出现DirectBuffer导致内存溢出问题。这是因为DirectBuffer是使用操作系统的内存空间，而不是JVM内存空间，因此如果不及时释放，就会导致内存泄漏。解决这个问题的方法有以下几种：及时释放DirectBuffer：在使用完DirectBuffer后，一定要及时释放。可以使用ReferenceCountUtil.release()方法手动释放，也可以通过Netty的内存池机制自动释放。
Netty实战：netty 堆外内存泄露排查盛宴
大JAVA解决方案
04-20 1507
搬运工来架构2018-09-05 以下文章来源于闪电侠的博客，作者super flash 闪电侠的博客 交流intellij idea，netty，java进阶技术栈以及源码阅读方面的心得和体会，一起学习，共同进步！ netty 堆外内存泄露，有没有一个通用的排查思路？本篇是闪电侠大神亲身经历的Netty实战问题，对于排查bug的思路有一定的结晶，非常值得一看...
介绍下Netty，它为什么快？Netty的零拷贝是什么？
04-26
比如，当从磁盘读取数据后，传统方式需要将数据复制到操作系统的缓存中，再将其复制到应用程序的内存空间中，最后再将其复制到网络套接字缓存中，而Netty则可以避免这些多余的复制，从而提高了性能。具体的实现方式...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

子涵先生

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值