最近一两年但凡聊到Java高并发、网络通信，话题基本都会落到两件事上：NIO到底怎么回事，以及为什么大家都在用Netty。如果你做过接入层、网关、长连接服务，或者面试的时候被人问过“为什么Netty能扛住那么高并发”，就会明白这个标题背后其实是一个完整的知识链条，从操作系统IO模型到Java NIO的Selector机制，再到Netty的架构取舍和线程模型。这篇内容最适合两类人看：一类是刚学完Java基础、想搞明白网络框架到底在解决什么问题的开发者；另一类是已经在项目里用过Netty，但对底层原理和踩坑点还模糊的同行。我会直接从底层通信模型讲起，把NIO的核心组件拆开，再落到Netty的架构和实战代码，最后分享一些排查线上事故的真实经验。
1. 从BIO到NIO：网络编程的第一道分水岭
1.1 BIO为什么撑不住高并发
早期Java网络编程最典型的写法就是服务端accept之后，每个客户端连接直接new一个Thread去处理。这种Blocking I/O模式在连接数少的时候没有太大问题，逻辑也简单清晰。但一旦连接数上来，线程数就跟着线性增长，而线程本身是有成本的：每个线程默认要分配栈空间，Windows下一个线程大概1MB，Linux下默认8MB左右，这还只是内存，线程上下文切换的CPU开销更是随线程数非线性增长。
举个例子，某项目上线时预期5000并发连接，如果按BIO的写法，意味着至少要准备5000个线程来处理读写。JVM堆内存本来就不宽裕，再叠加操作系统线程调度开销，系统吞吐量不但上不去，反而会在连接建立高峰期把CPU全部耗在线程切换上。我见过最典型的现象是：连接数到3000左右，GC频率骤升，接口响应时间从30ms飙升到3秒，整个服务像被堵死一样。
核心问题在于BIO的读操作是阻塞的：线程调用read()之后，如果客户端没有发送数据，线程就会一直挂在那里。连接本身可能有大量是“活跃但数据少”的，比如聊天软件的连接池、心跳连接，它们大多数时间不传数据，却占着一个完整线程。
1.2 NIO的“多路复用”到底复用了什么
NIO出现后，解决思路完全换了一个方向：不再是一个连接一个线程，而是用一个极少数量的线程去管理成千上万个连接。这就是多路复用（Multiplexing）的概念。可以把Selector想象成一台交换机，所有连接的事件都上报到这里，线程只需要不断问Selector“谁有数据可以读了、谁可以写了”，然后只去处理那些真正就绪的连接。
这样的好处是，一个线程就能同时管理多个连接，资源开销从O(连接数)变成了O(活跃连接数)。因为大多数连接不是同时有数据到的，真正同时触发的“活跃事件”其实很少。这个模型的底层由操作系统提供，Java的selector在Linux上依赖epoll实现，在macOS上依赖kqueue实现，都是事件驱动的高性能多路复用机制。
理解了这层，再回头看NIO的几个核心组件就顺理成章了：Buffer用来做数据读写缓冲，Channel代表一个连接通道，Selector负责监听通道上的事件。三者的配合关系是核心。
2. NIO三大件：Buffer、Channel、Selector
2.1 Buffer：数据搬运的容器
Buffer本质是内存块，Java里对应一堆具体实现，比如ByteBuffer、CharBuffer、IntBuffer，最常用的是ByteBuffer。ByteBuffer里有四个核心标记：position（当前读写位置）、limit（可用范围边界）、capacity（总容量）、mark（标记位置）。
很多人刚开始会被flip()和clear()搞晕。简单说，写模式转读模式用flip()，把position回到0，limit设到原来的position位置；读完了想再写，用clear()清空重置。还有个compact()方法，是“读取剩余数据，把未读部分往前挪，然后切换到写模式”，做粘包处理时会很有用。
代码示例：
// 申请一个1024字节的堆外缓冲区 ByteBuffer buffer = ByteBuffer.allocateDirect(1024); // 写入数据 buffer.put("hello nio".getBytes()); // 切换为读模式 buffer.flip(); // 读取数据 byte[] dst = new byte[buffer.remaining()]; buffer.get(dst); System.out.println(new String(dst)); // 切换到写模式继续使用 buffer.clear();这里有个细节容易忽略：allocateDirect()分配的是堆外内存，绕过JVM堆，可以直接和操作系统交互，减少IO过程中的内存拷贝。但是堆外内存的分配和回收成本更高，不能滥用，而且如果忘记释放，会导致堆外内存耗尽。后面聊Netty的ByteBuf时还会再提到这个问题。
2.2 Channel和Selector：连接与选择的门道
Channel在NIO里代表一个到实体的开放连接，最常见的几个是FileChannel、SocketChannel、ServerSocketChannel。Channel最重要的特点是全双工，既能读也能写，而且本身是异步的。
Selector是用来监听Channel事件的核心，可以注册四种事件：OP_ACCEPT（有新连接接入）、OP_CONNECT（连接建立成功）、OP_READ（有数据可读）、OP_WRITE（可以写入数据）。
关键思路是，selector.select()会进入阻塞，直到至少有一个注册的事件就绪。这个阻塞不是连接级别的阻塞，而是事件级别的等待，所以线程仍然被高效利用。拿到就绪事件集合后，遍历处理，处理完必须把事件从selectedKeys里移除，否则会重复处理同一个事件。
2.3 基于Selector的简易服务器骨架
为了把上面的组件串起来，我直接给一个小而完整的NIO服务器示例，这个代码在理解层面比任何理论都有效：
import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.*; import java.util.Iterator; public class NioServer { public static void main(String[] args) throws Exception { Selector selector = Selector.open(); ServerSocketChannel serverChannel = ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(9090)); serverChannel.configureBlocking(false); serverChannel.register(selector, SelectionKey.OP_ACCEPT); ByteBuffer readBuffer = ByteBuffer.allocate(1024); while (true) { // select 会阻塞等待有事件就绪 selector.select(); Iterator<SelectionKey> keys = selector.selectedKeys().iterator(); while (keys.hasNext()) { SelectionKey key = keys.next(); // 这里必须手动移除，否则事件会被重复处理 keys.remove(); if (key.isAcceptable()) { SocketChannel socketChannel = serverChannel.accept(); socketChannel.configureBlocking(false); socketChannel.register(selector, SelectionKey.OP_READ); System.out.println("新连接接入"); } else if (key.isReadable()) { SocketChannel channel = (SocketChannel) key.channel(); readBuffer.clear(); int len = channel.read(readBuffer); if (len == -1) { channel.close(); continue; } readBuffer.flip(); byte[] data = new byte[readBuffer.remaining()]; readBuffer.get(data); System.out.println("收到客户端消息: " + new String(data)); channel.write(ByteBuffer.wrap("ACK".getBytes())); } } } } }这个写法就是最标准的事件循环：accept到连接后注册读事件，之后所有数据读写都通过事件驱动触发，单线程就能处理大量连接。
这个代码能跑通，但不要高兴太早。原生NIO真正放到生产环境，还有很多没说的地方：读取半包数据怎么办？ByteBuffer扩容怎么办？空闲连接怎么超时关闭？业务处理如果阻塞了，selector线程还能不能响应新事件？这些问题逐层叠加，就变成了一笔巨大的维护成本。这也是Netty存在的最直接理由，它不是花架子，而是把NIO生产化过程中遇到的所有坑都填上了。
3. 为什么最终选Netty：烧掉重复轮子的理由
3.1 原生NIO的生产级问题
先说一个最常见也最让人头疼的问题：半包与粘包。TCP是字节流协议，应用层发给对方的数据，对端在哪次读取里收到是不可控的。比如客户端发了一个完整的消息，服务端可能一次read只读到一半，也可能一次read读到了好几条消息。你必须在应用层自己去做消息的拆分和聚合。原生NIO里没有任何现成机制，所有框架都要自己维护ByteBuffer、判断消息长度、缓存半包数据，代码量和bug风险一下就上来了。
再比如空间清理。ByteBuffer一旦申请，用完了如果不重新整理，数据位置就会很乱；堆外内存使用完必须显式释放，否则就泄漏。这些都不是简单的API调用能掩盖的复杂度。
坦率讲，用原生NIO不是不能写，而是每写一行处理半包、扩容、内存管理的代码，基本都是重复造轮子，而且造出来的轮子大概率不够圆。我在早期就干过这种事，后来维护成本高到我一度怀疑人生。
3.2 Netty的架构抽象：EventLoop与Pipeline
Netty的核心设计可以概括为三个抽象：EventLoop、ChannelPipeline、ByteBuf。
EventLoop本质上就是一个线程池里不断循环的线程，它的工作包括accept、read、write、执行handler回调。Netty默认用两个EventLoopGroup：bossGroup负责处理新连接接入，workerGroup负责处理已建立连接上的IO读写。这样设计的好处是职责分离，boss不会因为大量业务读写而被拖慢。
ChannelPipeline是一个责任链模式的双向链表，入站消息会依次经过所有入站Handler处理的，出站消息依次经过所有出站Handler。每一层Handler只关心自己的事，比如解码Handler把字节流变成Java对象，业务Handler只接收对象做逻辑，编码Handler把返回对象变成字节流。想扩展功能，加一个Handler就行，完全不用改其他代码。
这个Pipeline模型是我觉得Netty最优雅的地方。它把网络分层处理的思想发挥到极致，让代码变得很利于扩展和维护。
3.3 内存与编解码：ByteBuf和粘包拆包的解决
Netty没有直接用ByteBuffer，而是自造了ByteBuf。区别主要有几个：
- read/write指针分开，读指针不会影响写指针，不需要flip。
- 支持引用计数和内存池，Netty会自动帮你释放，降低人工管理内存的负担。
- 提供buffer()工具方法，可以方便地申请堆内存或直接内存。
更关键的是，Netty内置了一组Decoder，专门解决半包粘包：
| 解码器 | 使用场景 | 示例 |
|---|---|---|
| LineBasedFrameDecoder | 消息以换行符分隔 | 字符串协议、日志传输 |
| DelimiterBasedFrameDecoder | 消息以自定义分隔符分隔 | 自定义文本协议 |
| FixedLengthFrameDecoder | 消息定长 | 固定长度报文 |
| LengthFieldBasedFrameDecoder | 消息头中包含长度字段 | 绝大多数二进制协议 |
这个设计极大程度上降低了业务开发的负担。你唯一要想清楚的是，自己的协议到底属于哪种形态。
4. 实操：用Netty从零搭一个可伸缩的小服务
4.1 依赖与基础环境准备
Netty的Maven依赖如下：
<dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> <version>4.1.100.Final</version> </dependency>如果只需要基础NIO能力，也可以只引入netty-transport、netty-codec等子模块，但为了省事，一般直接引入all版本。
建议使用JDK 8以上的版本，Netty 4.1.x对JDK 8兼容性最好。如果想要更高性能和更好内存管理，JDK 11配合Netty 4.1.7x以后的表现更佳，因为JVM对堆外内存、并发GC有更多优化。
4.2 服务端主链路写法
下面这个简单的ImServer可以处理基本的字符串消息，并且支持客户端连接。注意看pipeline的注册顺序，Handler顺序是有讲究的：
import io.netty.bootstrap.ServerBootstrap; import io.netty.channel.*; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.SocketChannel; import io.netty.channel.socket.nio.NioServerSocketChannel; import io.netty.handler.codec.string.StringDecoder; import io.netty.handler.codec.string.StringEncoder; public class NettyServer { public static void main(String[] args) throws Exception { EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap bootstrap = new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.TCP_NODELAY, true) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder()); ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() { @Override protected void channelRead0(ChannelHandlerContext ctx, String msg) { System.out.println("收到: " + msg); ctx.writeAndFlush("ok\n"); } @Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { cause.printStackTrace(); ctx.close(); } }); } }); ChannelFuture future = bootstrap.bind(9090).sync(); System.out.println("server start on 9090"); future.channel().closeFuture().sync(); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } } }这里面有几个关键点要说一下：
- bossGroup设置线程数为1就够了，一个线程完全能处理大量新连接接入。
- TCP_NODELAY设为true，关闭Nagle算法，减少小包延迟，对低延迟交互场景很重要。
- SO_BACKLOG表示等待队列长度，在高并发瞬时连接涌入时，队列太短会导致连接失败。
另一个经常被忽略的问题：不要让业务Handler里做耗时操作，比如查数据库、调外部API。因为IO线程一旦被阻塞，该线程上所有连接的处理都会卡住。需要处理的话，要在Handler里把任务提交到单独的业务线程池，或者用Netty提供的DefaultEventExecutorGroup。
比如可以在pipeline里这样用：
EventExecutorGroup bizGroup = new DefaultEventExecutorGroup(16); ch.pipeline().addLast(bizGroup, new BusinessHandler());这样业务处理就落在bizGroup线程上，不会卡住IO线程。
4.3 客户端调试与常见使用细节
一个最简单的客户端，可以用来和服务端配合测试：
import io.netty.bootstrap.Bootstrap; import io.netty.channel.*; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.SocketChannel; import io.netty.channel.socket.nio.NioSocketChannel; import io.netty.handler.codec.string.StringDecoder; import io.netty.handler.codec.string.StringEncoder; public class NettyClient { public static void main(String[] args) throws Exception { EventLoopGroup group = new NioEventLoopGroup(); try { Bootstrap bootstrap = new Bootstrap(); bootstrap.group(group) .channel(NioSocketChannel.class) .handler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder()); ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() { @Override public void channelActive(ChannelHandlerContext ctx) { ctx.writeAndFlush("hello server"); } @Override protected void channelRead0(ChannelHandlerContext ctx, String msg) { System.out.println("服务端响应: " + msg); } }); } }); Channel channel = bootstrap.connect("127.0.0.1", 9090).channel(); channel.closeFuture().sync(); } finally { group.shutdownGracefully(); } } }客户端同样需要注意：断线重连在原生Bootstrap里没有现成机制，要用ChannelFutureListener监听连接失败，手动重试。重连时最好加随机延迟，避免客户端同时断线重连造成服务端拥塞，这也是一个分布式系统里常见的“惊群”隐患。
5. 常见问题排查与踩坑记录
5.1 粘包拆包问题
粘包现象最容易出现在用最简单的ByteBuf直接toString的场景里。比如两个请求“hello”和“world”在同一TCP段里到达，接收方可能一次性读到“helloworld”。解决办法是用现成Decoder，基本都覆盖了。
我之前接手过一个项目，发送的是二进制协议，消息头前4个字节是消息体长度。修复前服务端经常出现消息乱序、解析错误的情况。改成LengthFieldBasedFrameDecoder后，问题立刻消失。它的第一个参数是maxFrameLength，表示最大帧长度，超过直接报错，防止恶意数据打爆内存；第二个参数lengthFieldOffset是长度字段偏移量，第三个参数lengthFieldLength是长度字段占用的字节数。
5.2 内存泄漏排查
Netty用了内存池以后，如果代码不规范，最容易泄漏的是ByteBuf。特别是在自定义Decoder里，如果没把消息传到下一个Handler，也没有release当前ByteBuf，那么堆外内存就永远不会归还。
按照规范，Handler里处理完ByteBuf后如果没有传递下去，必须调用ReferenceCountUtil.release(msg)。如果使用的是SimpleChannelInboundHandler，Netty会在channelRead0执行完后自动释放消息，这也是我推荐用SimpleChannelInboundHandler而不是普通ChannelInboundHandlerAdapter的原因之一。
泄漏排查方面，Netty提供了内存泄漏检测机制，在启动参数里加-Dio.netty.leakDetection.level=paranoid可以开启最强检测级别。线上如果怀疑ByteBuf泄漏，可以临时开启这个参数找定位信息。注意实际生产不要长期开paranoid级别，因为本身也会带来性能开销。
5.3 线程阻塞导致吞吐上不去
Netty的性能瓶颈很多时候不在Netty本身，而在业务Handler把IO线程卡住了。表现就是：某个连接的操作特别慢，其他连接也一起卡住。原因很简单，NioEventLoop是一个线程管理多个Channel，一个Channel的Handler事件阻塞，其他Channel全部排队。
排查方法：先看问题发生期间的线程快照，如果发现大量NioEventLoop线程堆栈都停在某个业务Handler的调用链上，基本就是业务阻塞了。解决办法就是业务逻辑独立线程池，或者把耗时的逻辑扔给后端消息队列处理。
5.4 连接空闲与心跳机制
长连接服务如果不做空闲检测，服务端的连接对象会越积越多，最后把文件描述符耗尽。Netty提供了IdleStateHandler，可以设置读空闲、写空闲、全空闲的检测时间，然后触发IdleStateEvent，由后续的Handler来处理超时关闭。
配置示例：
ch.pipeline().addLast(new IdleStateHandler(60, 0, 0, TimeUnit.SECONDS));这个配置表示60秒内没有读到数据就触发IdleStateEvent。业务Handler里可以这样监听：
@Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent event = (IdleStateEvent) evt; if (event.state() == IdleState.READER_IDLE) { // 超过60秒没有收到心跳，关闭连接 ctx.close(); } else { super.userEventTriggered(ctx, evt); } } }这个地方最容易出问题的是对象的比较。有些人在监听心跳时用evt.instanceof IdleStateEvent来判断，但IdleStateEvent不止一种类型，如果你只想处理读空闲，一定要判断state。我见过有人写错后，把写空闲事件当读空闲处理，服务端疯狂断开活跃连接。
5.5 连接断裂如何感知
还有一个非常经典的坑：客户端掉线后，服务端如果没有配置KeepAlive和心跳，可能要等很长一段时间才能感知到连接已经死了。TCP层有超时重传机制，但应用层如果不主动做探测，服务端可能一直维护一个僵尸连接。
所以对于长连接服务，一定要做两层保障：操作系统层面设置SO_KEEPALIVE，应用层再配合IdleStateHandler做心跳。网络层检测虽然有，但时间粒度不够细，应用层心跳才能真正及时地清理死链。
5.6 一个典型的线上案例
之前参与过一个IM项目的网关改造，用的是老版BIO模型，连接数过万后CPU频繁飙高，GC频率也失控。改造为Netty后，我们做了三件事：boss/worker线程分组、业务线程池隔离、心跳空闲检测。再加上LengthFieldBasedFrameDecoder解决粘包问题，整体吞吐提升了接近10倍，单机能稳定撑住3万以上长连接。
但上线初期还是踩了一个小坑：我们只给workerGroup设了默认线程数（默认是CPU核数乘2），业务高峰期出现了大量连接堆积在ChannelPipeline里等待处理。后来把业务池单独划分，并且控制了read速率，才算稳定下来。Netty不是银弹，线程模型不设计好，照样会被打垮。
6. 选型思考：直接用Netty还是NIO自己造
如果你的项目只是做一个简单的内网端口转发工具，连接数不超过几十个，用原生NIO或者干脆BIO都没问题。但如果涉及以下场景，我的建议很明确：直接上Netty。
- 高并发长连接，比如IM、消息推送、游戏长连接。
- 自定义TCP/私有二进制协议，需要灵活处理编解码和粘包。
- 网关代理类项目，需要高性能IO吞吐和低延迟。
- 需要对连接生命周期做精细化管理（空闲检测、流量控制、连接优雅关闭）。
Netty的学习曲线主要集中在理解EventLoop模型、Pipeline机制、ByteBuf生命周期。一旦过了这几个坎，日常开发效率非常高。它内部已经集成了大量生产级的处理，比如连接池、粘包拆包、协议编解码、流量整形、SSL支持，生态非常完整。
相比而言，原生NIO更适合作为学习底层原理的素材，而不是作为生产项目的首选。
7. 性能调优的几个方向
聊完踩坑，顺带说几个真正对Netty性能影响最大的调优点，不对，是大家问得最多的方向。
第一是线程数配置。workerGroup默认线程数是CPU核数乘2，这个值在大规模长连接场景下不一定最优。线程太多会引入不必要的上下文切换，太少又无法充分利用CPU。建议压测的时候从2倍CPU核数开始，逐步调高或调低，找到当前硬件配置下的最优值。
第二是ByteBuf分配参数。Netty4.1默认使用池化分配器，通过-Dio.netty.allocator.type=pooled可以显式启用。池化最大的好处是减少堆外内存的分配回收频率，对高吞吐场景提升非常明显。如果你的应用堆外内存充足，建议开启池化。
第三是零拷贝的运用。Netty的FileRegion可以用来传输文件，本质上是操作系统级别的sendfile，不经过用户态，CPU占用很低。如果你的业务涉及大量文件传输，不要用传统的流式拷贝方式，直接用FileRegion就好。
第四是避免在IO线程上做任何可能阻塞的操作。这看起来简单，但实际操作中总有人忍不住在Handler里做了同步DB查询。每次同步查询如果在10ms以上，IO线程被占用期间其他几百个连接都在等着，这个损耗是好几倍放大的。从架构上保证IO线程和业务线程严格隔离，是我最想强调的一条。
写在最后的经验提醒
前面讲了这么多，如果你想找一条自己实践的路子，我建议先动手把前面那个简易NIO服务器跑通，感受一遍Selector事件循环是怎么回事，再切到Netty写同样的功能。这个过程中你会发现很多概念变得特别具体，比如“为什么Channel要注册事件”“为什么pipeline的顺序不能乱”“为什么ByteBuf不需要flip”。等你能回答这些问题，再回头看Netty源码，很多设计决定就都能理解了。
我个人这几年折腾下来最深的体会是：网络编程这一块的坑，90%都不是框架的问题，而是对IO模型、内存管理、并发边界理解不透导致的。Netty把这些底层能力封装得很好，但不代表使用者可以不懂。把基础打扎实了，再用Netty就是如虎添翼；基础不牢，出了问题真的很难排查。如果你正准备在自己的项目里引入Netty，记得先把第5部分的那些排查经验和第7部分的调优方向收藏好，等踩到坑的时候回来看一眼，能省不少时间。
