Netty 参数调优研究：基于问题现象、参数语义与官方文档的系统化分析

概览

系统分析 Netty 4.1 在连接建立、读写缓冲、背压、线程模型、内存分配、连接保活和 Linux native transport 等方面的参数语义、问题现象与调优边界。

摘要

Netty 是一个异步事件驱动网络应用框架，用于构建协议服务器和客户端。Netty 官方文档将其定位为 NIO client-server framework，用于简化 TCP、UDP 等网络编程，并兼顾性能、稳定性和灵活性。(Netty) 本文以 Netty 4.1 系列为主要对象，围绕连接建立、读写缓冲区、背压、线程模型、内存分配、连接保活、Linux native transport 等参数，说明在特定问题现象下应观察和调整的参数。本文仅依据 Netty 官方 API 文档、Netty 官方 Wiki、Linux man-pages 与 Oracle JDK 文档陈述参数语义和适用边界，不把经验值表述为固定结论。

1. 引言

Netty 的参数调优不是单一参数优化，而是应用层事件模型、JDK socket 参数、操作系统 TCP 队列、Netty ChannelConfig、ByteBuf 分配器和业务处理线程之间的联合配置。Netty 官方 ChannelOption 文档说明，ChannelOption 用于以类型安全的方式配置 ChannelConfig，但具体支持哪些选项取决于实际 ChannelConfig 实现以及底层 transport 类型。(Netty) 因此，同一个参数在 NIO、epoll、kqueue、domain socket 或 UDP 场景下，支持情况和实际效果可能不同。

Netty 服务端配置还区分 parent channel 与 child channel。ServerBootstrap.group(parentGroup, childGroup) 中，parent group 处理 ServerChannel，child group 处理已建立连接的 Channel；childOption 应用于 accept 后创建的 child Channel。(Netty) 因此，监听 socket 的参数，例如 SO_BACKLOG，通常配置在 option(...)；连接 socket 的参数，例如 TCP_NODELAY、SO_KEEPALIVE、SO_RCVBUF、SO_SNDBUF、WRITE_BUFFER_WATER_MARK，通常配置在 childOption(...)。

2. 参数调优的分类框架

Netty 参数可以按问题域划分为六类。

第一类是连接建立类参数，主要包括 SO_BACKLOG、Linux somaxconn、tcp_max_syn_backlog、SO_REUSEADDR、epoll transport 下的 SO_REUSEPORT 等。

第二类是连接传输类参数，主要包括 TCP_NODELAY、SO_KEEPALIVE、SO_RCVBUF、SO_SNDBUF、IP_TOS、ALLOW_HALF_CLOSURE 等。Netty ChannelOption 中列出了 SO_KEEPALIVE、SO_SNDBUF、SO_RCVBUF、SO_REUSEADDR、SO_BACKLOG、TCP_NODELAY 等标准 socket 相关参数。(Netty)

第三类是读写背压类参数，主要包括 AUTO_READ、WRITE_BUFFER_WATER_MARK、WRITE_SPIN_COUNT、MAX_MESSAGES_PER_WRITE、RCVBUF_ALLOCATOR 等。Netty ChannelOption 明确包含 AUTO_READ、RCVBUF_ALLOCATOR、WRITE_BUFFER_WATER_MARK、WRITE_SPIN_COUNT 等选项。(Netty)

第四类是线程模型类参数，主要包括 boss/worker EventLoopGroup 线程数、是否为阻塞 handler 配置独立 EventExecutorGroup、是否使用 native epoll transport。ServerBootstrap 文档说明 parent 与 child EventLoopGroup 用于处理 ServerChannel 与 child Channel 的事件和 I/O。(Netty)

第五类是内存与 ByteBuf 类参数，主要包括 ALLOCATOR、是否使用 pooled allocator、direct buffer、ResourceLeakDetector 级别、JVM direct memory 限制等。Netty PooledByteBufAllocator 提供 pinned direct memory 与 pinned heap memory 观测方法，说明 allocator 可能因实现细节 pin 住大于 buffer capacity 的内存。(Netty)

第六类是平台 transport 参数。Netty 官方 native transport 文档说明，Linux 与 macOS/BSD 有平台特定 JNI transport；这些 transport 增加平台特性、减少垃圾并通常提升相对 NIO transport 的性能。(Netty)

3. 连接建立阶段的问题与参数

3.1 连接突增时客户端连接失败或连接建立延迟

当服务端瞬时收到大量 TCP 连接请求时，问题可能出现在内核 listen 队列、accept 处理速度或应用层连接处理能力上。Linux listen(2) 文档说明，backlog 参数定义 pending connection 队列可增长到的最大长度；当连接请求到达且队列已满时，客户端可能收到 ECONNREFUSED，或者在底层协议支持重传时请求被忽略并等待后续重试。(man7.org)

在 Netty 中，与该现象直接相关的参数是：

java

serverBootstrap.option(ChannelOption.SO_BACKLOG, backlog);

SO_BACKLOG 是 Netty ChannelOption<Integer>，属于服务端监听 socket 参数。(Netty) 但是，SO_BACKLOG 不是唯一上限。Linux 2.2 以后，TCP socket 的 backlog 表示等待 accept 的已完成连接队列长度；未完成连接请求队列由 /proc/sys/net/ipv4/tcp_max_syn_backlog 设置。(man7.org) 因此，当现象是连接突增下失败、超时或 ECONNREFUSED 时，Netty 层应检查 SO_BACKLOG，系统层应同时检查 net.core.somaxconn 与 tcp_max_syn_backlog。

配置示例：

java

ServerBootstrap bootstrap = new ServerBootstrap();

bootstrap
    .group(bossGroup, workerGroup)
    .channel(NioServerSocketChannel.class)
    // Configure the accept queue length for the server socket.
    .option(ChannelOption.SO_BACKLOG, 1024)
    .childHandler(channelInitializer);

该参数只扩大连接排队能力，不提高业务处理速度。如果 worker 线程被阻塞、accept 之后的 handler 处理过慢，单独扩大 backlog 只能改变排队行为，不能消除处理瓶颈。

3.2 端口重启后短时间内绑定失败

当进程重启后出现地址仍被占用或绑定失败，相关参数是 SO_REUSEADDR。Netty ChannelOption 提供 SO_REUSEADDR。(Netty) Oracle StandardSocketOptions 文档说明，标准 socket options 被 Java network channels 使用，具体选项以字段名定义。(Oracle 文档)

配置示例：

java

bootstrap.option(ChannelOption.SO_REUSEADDR, true);

该参数的行为受操作系统 TCP 状态机影响。它不能替代正确关闭连接，也不能让多个普通 TCP server socket 无条件绑定到同一地址端口。

3.3 Linux 多进程或多 Reactor 监听同一端口

在 Linux native epoll transport 场景下，可以关注 EpollChannelOption.SO_REUSEPORT。Netty native transport 文档说明 Linux native transport 提供平台特定能力。(Netty) 该类参数只适用于 epoll transport，不属于跨平台 NIO 通用参数。使用时需要将 NioEventLoopGroup、NioServerSocketChannel 切换为 EpollEventLoopGroup、EpollServerSocketChannel。Netty 官方 native transport 文档给出的迁移方式正是替换 EventLoopGroup 与 Channel 类型。(Netty)

配置形态如下：

java

ServerBootstrap bootstrap = new ServerBootstrap();

bootstrap
    .group(bossGroup, workerGroup)
    .channel(EpollServerSocketChannel.class)
    // Linux epoll transport only.
    .option(EpollChannelOption.SO_REUSEPORT, true);

该参数不能在非 Linux epoll transport 下作为通用方案使用。

4. 数据发送阶段的问题与参数

4.1 小包请求延迟升高

当业务以小包、低延迟请求为主，且观察到请求响应延迟与 TCP 合包相关时，应检查 TCP_NODELAY。Netty 提供 ChannelOption.TCP_NODELAY，类型为 Boolean。(Netty) Oracle StandardSocketOptions 将 TCP_NODELAY 定义为禁用 Nagle 算法的 socket option。(Oracle 文档)

配置示例：

java

bootstrap.childOption(ChannelOption.TCP_NODELAY, true);

该参数的事实语义是关闭 Nagle 算法。它适合减少小包等待合并导致的延迟，但不会降低应用层序列化成本、handler 执行时间或网络 RTT。

4.2 写入速度高于对端读取速度，内存持续增长

当应用持续调用 writeAndFlush，但对端读取较慢、网络拥塞或系统发送缓冲区无法及时排空时，Netty outbound buffer 可能积压。Netty WriteBufferWaterMark 文档说明，它用于设置写缓冲区低水位和高水位；当 write buffer 中排队字节数超过高水位时，Channel.isWritable() 开始返回 false；当字节数降到低水位以下时，Channel.isWritable() 开始返回 true。(Netty)

4.3 单次写操作无法完全写出

Netty ChannelOption 提供 WRITE_SPIN_COUNT 与 MAX_MESSAGES_PER_WRITE。(Netty) 这类参数影响单轮事件循环中写操作尝试次数或消息写出数量。它们适用于观察到单连接写出行为与 event loop 调度相关时的分析，但不应作为解决所有吞吐问题的入口参数。若根因是对端接收慢或网络拥塞，应优先使用 WRITE_BUFFER_WATER_MARK 与应用层背压。

5. 数据读取阶段的问题与参数

5.1 入站流量超过业务处理能力

当服务端读取速度高于业务处理速度，可能出现堆积、内存上升、延迟放大。Netty 提供 AUTO_READ 参数。ChannelOption 中 AUTO_READ 是 Boolean 类型。(Netty) 当需要由业务控制读取节奏时，可以关闭自动读，并在处理能力恢复后显式调用 ctx.read()。

配置示例：

java

bootstrap.childOption(ChannelOption.AUTO_READ, false);

handler 示例：

java

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
    try {
        // Process the inbound message.
        process(msg);
    } finally {
        ReferenceCountUtil.release(msg);
    }

    if (canAcceptMore()) {
        // Request the next read explicitly when the application is ready.
        ctx.read();
    }
}

该参数解决的是“读取节奏控制”问题，不解决 handler 内部阻塞、业务线程池耗尽或下游系统慢的问题。

5.2 入站包大小波动导致频繁扩容或内存浪费

Netty AdaptiveRecvByteBufAllocator 文档说明，该 allocator 会根据反馈自动增加或减少预测缓冲区大小：如果上一次读取填满了分配的 buffer，则逐步增加预期可读字节数；如果连续两次读取未达到一定填充量，则逐步降低预期可读字节数；否则保持预测值不变。(Netty)

5.3 单连接读事件占用过多 EventLoop 时间

MAX_MESSAGES_PER_READ 在 ChannelOption 中已标记为 deprecated，并提示使用 MaxMessagesRecvByteBufAllocator 及其 maxMessagesPerRead(int)。(Netty) 因此，在需要控制单轮读事件最多读取消息数时，应基于具体 RecvByteBufAllocator 实现调整，而不是继续依赖废弃参数。

6. 连接存活与异常连接问题

6.1 空闲连接长时间不关闭

Netty 提供 SO_KEEPALIVE 作为 socket 参数。(Netty) 该参数启用的是 TCP keepalive 能力，具体探测周期和行为通常由操作系统参数决定。它适合检测长时间空闲 TCP 连接是否仍有效，但不等同于应用层心跳。

配置示例：

java

bootstrap.childOption(ChannelOption.SO_KEEPALIVE, true);

如果协议需要秒级或业务语义级别的存活检测，应使用 Netty handler，例如 IdleStateHandler 组合业务心跳，而不是只依赖 TCP keepalive。

6.2 半关闭连接处理不符合协议要求

Netty ChannelOption 提供 ALLOW_HALF_CLOSURE。(Netty) 对于需要处理 TCP half-close 的协议，应显式配置并在 handler 中处理输入关闭与输出关闭的差异。对于普通请求响应协议，是否允许半关闭取决于协议语义。

7. 客户端连接超时问题

客户端连接远端服务时，如果出现长时间等待或连接建立超时，应检查：

java

ChannelOption.CONNECT_TIMEOUT_MILLIS

Netty ChannelOption 将 CONNECT_TIMEOUT_MILLIS 定义为 Integer 类型选项。(Netty)

配置示例：

java

Bootstrap bootstrap = new Bootstrap();

bootstrap
    .group(workerGroup)
    .channel(NioSocketChannel.class)
    // Configure TCP connect timeout in milliseconds.
    .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 3000);

该参数只约束连接建立阶段，不约束业务读超时、写超时或请求总耗时。读写超时通常需要在 pipeline 中使用超时 handler 或由上层协议客户端实现。

8. 线程模型问题与参数

8.1 EventLoop 线程被业务逻辑阻塞

Netty 的核心模型是事件驱动。ServerBootstrap 文档说明 parent 与 child EventLoopGroup 处理 ServerChannel 和 child Channel 的所有事件与 I/O。(Netty) 因此，如果 ChannelHandler 中执行阻塞 JDBC、阻塞 HTTP 调用、文件 I/O 或长时间 CPU 计算，会占用 EventLoop 线程，影响同一 EventLoop 上其他 Channel 的 I/O 事件处理。

Netty ChannelPipeline API 提供带 EventExecutorGroup 参数的 addFirst、addLast 等方法，该 group 用于执行对应 ChannelHandler 的方法。(Netty) 因此，阻塞或耗时 handler 应放入独立 executor，而不是运行在 I/O EventLoop 上。

示例：

java

EventExecutorGroup businessGroup = new DefaultEventExecutorGroup(32);

pipeline.addLast("decoder", decoder);
pipeline.addLast(businessGroup, "blockingBusinessHandler", blockingBusinessHandler);
pipeline.addLast("encoder", encoder);

该配置的目标是隔离阻塞业务逻辑与 I/O 事件循环。它不能减少业务逻辑本身耗时，也不能替代下游系统限流。

8.2 EventLoop 线程数配置不匹配

NioEventLoopGroup 构造器允许指定 nThreads；不指定时使用默认线程数。(Netty) DefaultEventLoopGroup 也提供默认线程数与显式 nThreads 构造器。(Netty)

配置示例：

java

EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup(8);

线程数问题应通过指标判定：EventLoop pending task 增长、I/O 延迟升高、CPU 使用率、上下文切换、业务 handler 耗时。增加 worker 线程数不保证提升吞吐；如果瓶颈在单连接顺序处理、锁竞争、下游服务或内核队列，线程数变化不能直接消除根因。

8.3 Linux 场景下 NIO transport 开销较高

Netty 官方 native transport 文档说明，Linux native transport 自 4.0.16 起提供，能够增加平台特定特性、产生更少垃圾，并通常比 NIO transport 性能更好。(Netty) Netty 4.0.17 发布说明也指出，native epoll transport 基于 epoll edge-triggered，用于 maximal performance and low latency，并且只工作在 Linux 上。(Netty)

Linux 场景下可切换为：

java

EventLoopGroup bossGroup = new EpollEventLoopGroup(1);
EventLoopGroup workerGroup = new EpollEventLoopGroup();

ServerBootstrap bootstrap = new ServerBootstrap();

bootstrap
    .group(bossGroup, workerGroup)
    .channel(EpollServerSocketChannel.class)
    .childHandler(channelInitializer);

该配置只适用于 Linux，并需要引入 netty-transport-native-epoll 及对应 classifier。它不是跨平台配置。

9. 内存、ByteBuf 与泄漏检测问题

9.1 Direct memory 或堆外内存增长

Netty 使用 ByteBufAllocator 管理 buffer。ChannelOption.ALLOCATOR 是 Netty 提供的 allocator 配置项。(Netty) PooledByteBufAllocator 文档提供 pinnedDirectMemory() 与 pinnedHeapMemory() 指标，其中 pinned direct memory 表示当前被 allocator 分配的 direct buffer pin 住的字节数；文档同时说明，由于 allocator 实现细节，buffer pin 住的内存可能大于其 capacity。(Netty)

配置示例：

java

bootstrap.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT);

9.2 ByteBuf 泄漏定位

Netty ResourceLeakDetector.Level 定义了 DISABLED、SIMPLE、ADVANCED、PARANOID 四种级别。其中 SIMPLE 是默认级别，带有 small overhead；ADVANCED 会报告最近访问位置，代价是 high overhead；PARANOID 用于测试目的，具有最高可能开销。(Netty)

因此，当日志出现 LEAK: ByteBuf.release() 相关信息，或 direct memory 持续增长且无法从业务指标解释时，应在测试、预发或短时间诊断窗口提高泄漏检测级别：

bash

-Dio.netty.leakDetection.level=advanced

或：

bash

-Dio.netty.leakDetection.level=paranoid

PARANOID 的官方说明包含 “for testing purposes only”，因此不应作为生产默认配置。(Netty)

10. 参数与问题现象对应关系

问题现象	需要观察的事实	相关参数	调整方向
连接突增时客户端连接失败、`ECONNREFUSED`、连接建立延迟	listen 队列是否满、accept 是否及时、系统 backlog 上限	`SO_BACKLOG`、`net.core.somaxconn`、`tcp_max_syn_backlog`	增大监听队列上限，并检查 boss/worker 是否阻塞
小包请求延迟异常	是否受 Nagle 合包影响	`TCP_NODELAY`	低延迟小包场景下启用 `TCP_NODELAY=true`
写入堆积、内存增长、`isWritable=false`	outbound buffer 是否超过高水位	`WRITE_BUFFER_WATER_MARK`、`MessageSizeEstimator`	设置合理高低水位，并在业务层基于 writability 做背压
入站流量压垮业务处理	读取速度是否超过处理速度	`AUTO_READ`、`RCVBUF_ALLOCATOR`	关闭自动读并按处理能力显式 `read()`
消息大小波动导致 buffer 浪费或频繁扩容	实际读取大小与预测 buffer 是否匹配	`RCVBUF_ALLOCATOR`	使用或调整 `AdaptiveRecvByteBufAllocator`
EventLoop 延迟升高	handler 是否执行阻塞任务	`EventLoopGroup` 线程数、`DefaultEventExecutorGroup`	阻塞 handler 放入独立 executor
Linux 下 NIO 开销较高	是否运行在 Linux，是否可使用 native transport	`EpollEventLoopGroup`、`EpollServerSocketChannel`	使用 native epoll transport
direct memory 持续增长	是否 ByteBuf 泄漏或 outbound 堆积	`ALLOCATOR`、`ResourceLeakDetector.Level`	观测 allocator 指标，提高泄漏检测级别定位
空闲连接长期不释放	TCP 层或应用层是否有存活检测	`SO_KEEPALIVE`、`IdleStateHandler`	TCP keepalive 处理 TCP 层，应用心跳处理协议层
客户端连接建立耗时过长	是否卡在 TCP connect 阶段	`CONNECT_TIMEOUT_MILLIS`	设置连接建立超时；读写超时另行处理

11. 推荐配置模板

以下模板仅表达参数位置与语义，不代表固定生产值。

java

public final class NettyServerConfig {

    private final int bossThreads = 1;
    private final int workerThreads = Runtime.getRuntime().availableProcessors() * 2;
    private final int backlog = 1024;
    private final int connectTimeoutMillis = 3000;

    public ServerBootstrap newServerBootstrap(ChannelInitializer<SocketChannel> initializer) {
        EventLoopGroup bossGroup = new NioEventLoopGroup(bossThreads);
        EventLoopGroup workerGroup = new NioEventLoopGroup(workerThreads);

        return new ServerBootstrap()
            .group(bossGroup, workerGroup)
            .channel(NioServerSocketChannel.class)

            // Parent channel option: configure the server listen socket.
            .option(ChannelOption.SO_BACKLOG, backlog)
            .option(ChannelOption.SO_REUSEADDR, true)

            // Child channel options: configure accepted client sockets.
            .childOption(ChannelOption.TCP_NODELAY, true)
            .childOption(ChannelOption.SO_KEEPALIVE, true)
            .childOption(ChannelOption.CONNECT_TIMEOUT_MILLIS, connectTimeoutMillis)
            .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)
            .childOption(
                ChannelOption.WRITE_BUFFER_WATER_MARK,
                new WriteBufferWaterMark(32 * 1024, 64 * 1024)
            )
            .childOption(
                ChannelOption.RCVBUF_ALLOCATOR,
                new AdaptiveRecvByteBufAllocator(64, 1024, 64 * 1024)
            )
            .childHandler(initializer);
    }
}

对于存在阻塞业务处理的 pipeline，应将阻塞 handler 放到独立 executor：

java

public final class ServerChannelInitializer extends ChannelInitializer<SocketChannel> {

    private final EventExecutorGroup businessGroup = new DefaultEventExecutorGroup(32);

    @Override
    protected void initChannel(SocketChannel ch) {
        ChannelPipeline pipeline = ch.pipeline();

        pipeline.addLast("decoder", new MyProtocolDecoder());

        // Execute blocking business logic outside the I/O EventLoop.
        pipeline.addLast(businessGroup, "businessHandler", new BlockingBusinessHandler());

        pipeline.addLast("encoder", new MyProtocolEncoder());
    }
}

12. 结论

Netty 参数调优应从问题现象出发，而不是从固定参数模板出发。连接建立失败对应 SO_BACKLOG 与 Linux listen 队列；小包延迟对应 TCP_NODELAY；写入堆积对应 WRITE_BUFFER_WATER_MARK 与业务背压；读取压垮业务处理对应 AUTO_READ 与 RCVBUF_ALLOCATOR；EventLoop 延迟对应 handler 阻塞与线程模型隔离；direct memory 增长对应 allocator 指标与泄漏检测；Linux 高性能传输场景可使用 native epoll transport。

从官方文档语义看，Netty 参数的有效性依赖 ChannelConfig 实现和 transport 类型。(Netty) 因此，调优结论必须绑定运行环境、协议类型、连接规模、消息大小分布、业务 handler 耗时、内核参数与 JVM 内存参数共同判断。固定参数值不能构成通用结论；可验证的指标、官方参数语义和压测结果才是调优依据。

Netty 参数调优研究：基于问题现象、参数语义与官方文档的系统化分析 ​

概览 ​

摘要 ​

1. 引言 ​

2. 参数调优的分类框架 ​

3. 连接建立阶段的问题与参数 ​

3.1 连接突增时客户端连接失败或连接建立延迟 ​

3.2 端口重启后短时间内绑定失败 ​

3.3 Linux 多进程或多 Reactor 监听同一端口 ​

4. 数据发送阶段的问题与参数 ​

4.1 小包请求延迟升高 ​

4.2 写入速度高于对端读取速度，内存持续增长 ​

4.3 单次写操作无法完全写出 ​

5. 数据读取阶段的问题与参数 ​

5.1 入站流量超过业务处理能力 ​

5.2 入站包大小波动导致频繁扩容或内存浪费 ​

5.3 单连接读事件占用过多 EventLoop 时间 ​

6. 连接存活与异常连接问题 ​

6.1 空闲连接长时间不关闭 ​

6.2 半关闭连接处理不符合协议要求 ​

7. 客户端连接超时问题 ​

8. 线程模型问题与参数 ​

8.1 EventLoop 线程被业务逻辑阻塞 ​

8.2 EventLoop 线程数配置不匹配 ​

8.3 Linux 场景下 NIO transport 开销较高 ​

9. 内存、ByteBuf 与泄漏检测问题 ​

9.1 Direct memory 或堆外内存增长 ​

9.2 ByteBuf 泄漏定位 ​

10. 参数与问题现象对应关系 ​

11. 推荐配置模板 ​

12. 结论 ​

参与讨论

Netty 参数调优研究：基于问题现象、参数语义与官方文档的系统化分析

概览

摘要

1. 引言

2. 参数调优的分类框架

3. 连接建立阶段的问题与参数

3.1 连接突增时客户端连接失败或连接建立延迟

3.2 端口重启后短时间内绑定失败

3.3 Linux 多进程或多 Reactor 监听同一端口

4. 数据发送阶段的问题与参数

4.1 小包请求延迟升高

4.2 写入速度高于对端读取速度，内存持续增长

4.3 单次写操作无法完全写出

5. 数据读取阶段的问题与参数

5.1 入站流量超过业务处理能力

5.2 入站包大小波动导致频繁扩容或内存浪费

5.3 单连接读事件占用过多 EventLoop 时间

6. 连接存活与异常连接问题

6.1 空闲连接长时间不关闭

6.2 半关闭连接处理不符合协议要求

7. 客户端连接超时问题

8. 线程模型问题与参数

8.1 EventLoop 线程被业务逻辑阻塞

8.2 EventLoop 线程数配置不匹配

8.3 Linux 场景下 NIO transport 开销较高

9. 内存、ByteBuf 与泄漏检测问题

9.1 Direct memory 或堆外内存增长

9.2 ByteBuf 泄漏定位

10. 参数与问题现象对应关系

11. 推荐配置模板

12. 结论