Dubbo默认用Netty而非JDK原生NIO，因其具备成熟的连接管理、内存池、背压控制和TLS集成能力，而JDK NIO在高并发长连接场景下易出现连接重置或堆外内存溢出；Netty吞吐量高30%~60%，P99延迟低2~5ms。
为什么 Dubbo 默认用 Netty 而不是 JDK 原生 NIO
Dubbo 从 2.6.x 开始将 Netty4 设为默认网络层，不是因为“更时髦”，而是 JDK 原生 java.nio 在高并发长连接场景下支撑不住：它缺少成熟的连接管理、内存池、背压控制和 TLS 集成能力。Netty 提供了开箱即用的 EventLoopGroup 线程模型、PooledByteBufAllocator 内存复用机制，以及对 HTTP/2、gRPC over HTTP/2 的平滑扩展路径。
常见错误现象：IOException: Connection reset by peer 或大量 OutOfDirectMemoryError，往往是因为没关掉 Netty 的堆外内存池（或配得太小），却误以为是连接数问题。
- 使用场景：服务提供方 QPS > 500、平均连接生命周期 > 2 分钟、单机连接数常驻 1k+ 的集群
- 参数差异：
netty4默认启用PooledByteBufAllocator；JDK NIO 只能靠ByteBuffer.allocateDirect()手动管理，极易泄漏 - 性能影响：相同硬件下，Netty 的吞吐量通常比 JDK NIO 高 30%~60%，延迟 P99 低 2~5ms（实测于 16 核 32G 阿里云 ECS）
长连接复用在 Dubbo 中如何真正生效
很多人以为只要用了 Netty 就自动“复用连接”，其实 Dubbo 的连接复用依赖两个关键开关：一是 connections 配置（服务消费者侧），二是 share_connections 行为（2.7.5+）。默认情况下，每个 ReferenceBean 会独占连接，不共享。
常见错误现象：用 jstack 查看线程堆栈，发现大量 NettyClientWorker 线程 + 对应的 SocketChannel，但实际业务调用量不大——说明连接没被复用，而是每个接口代理都建了新连接。
- 必须显式配置：
dubbo.reference.connections=1（或全局dubbo.consumer.connections=1） - 2.7.5+ 版本还需开启共享行为：
dubbo.consumer.share_connections=true（否则即使设了connections=1，多个 Reference 仍各自建连） - 注意兼容性：Spring Cloud Alibaba Dubbo 2.2.x（基于 Dubbo 2.7.8）默认关闭
share_connections，需手动打开
Netty 线程模型与 Dubbo 的交互陷阱
Dubbo 把请求分发给 Netty 的 EventLoop 处理，再转给 DecodeHandler → HeaderExchangeHandler → 业务线程池。这个链路里最容易出问题的是“在 Netty IO 线程里做耗时操作”，比如同步查 DB、调远程 HTTP 接口。
常见错误现象：io.netty.util.internal.OutOfDirectMemoryError 频发，或者监控显示 NettyServerBoss 线程 CPU 占用异常高，但业务日志几乎无输出——大概率是某处 invoke() 方法阻塞了 IO 线程。
- 禁止在
Filter或Invoker实现中调用Thread.sleep()、CountDownLatch.await()、RestTemplate.getForObject() - 异步回调必须交由
ExecutorService（如 Dubbo 自带的sharedExecutor）处理，不能直接在ChannelHandlerContext.fireChannelRead()流程里执行 - 检查自定义
Codec：若重写了encode()，避免在其中做 JSON 序列化（应交给业务线程池预序列化好再传入）
切换 Netty 版本时最易忽略的兼容点
Dubbo 2.7.x 默认绑定 netty-all-4.1.32.Final，升级到 4.1.90+ 或 4.2.x 时，不是改个 Maven 版本号就完事。Netty 4.1 和 4.2 的 ChannelOption 枚举值、SSL 引导方式、甚至 ByteBuf 的引用计数逻辑都有变化。
常见错误现象：java.lang.NoSuchMethodError: io.netty.channel.ChannelConfig.setOption(Lio/netty/channel/ChannelOption;Ljava/lang/Object;)Lio/netty/channel/ChannelConfig; —— 这是因 Dubbo 编译期依赖老 Netty，运行时加载了新 Netty 导致的二进制不兼容。
- 必须统一所有模块的 Netty 版本：包括 dubbo、dubbo-dependencies-netty4、以及你项目里显式引入的
netty-codec-http等 - 禁用 Maven 的
dependencyManagement透传：Dubbo 的 BOM 不包含 Netty，别让它覆盖你自己的版本策略 - 特别注意 Spring Boot Starter：spring-boot-starter-webflux 默认带
netty-reactor，可能引发 classloader 冲突，建议排除netty-buffer等重复 jar
长连接复用不是开个开关就完事，它和线程模型、内存分配、版本对齐绑在一起。少改一处，就可能让连接数翻倍、GC 次数飙升、或者某天凌晨突然连不上注册中心。
