这个系列写到第13期，前面的内容大多在聊基于流（Stream）的阻塞式IO，也就是BIO那一套读写模型。这一期我想换换口味，挑一段非常典型的NIO读写代码来拆。为什么选择现在聊这个？因为我在实际交流中发现，很多朋友对FileChannel、SocketChannel、Selector、Buffer这些类的单独用法都门儿清，但把它们拼到同一段代码里就懵了——API认识，可就是不知道每个调用为什么出现在那个位置，数据到底经过了怎样的流转。
这篇文章会拿一段"从网络接收数据、写入本地文件"的完整代码作为解析对象，把调用链、Buffer的状态切换、Selector的触发条件一条条捋清楚。想真正看懂NIO代码，或者正在为"为什么读出来的是乱码""为什么明明有数据却读不到"这类问题头疼的读者，这篇内容应该能给你一个比较踏实的抓手。
1. 先从整段代码的运行轨迹入手：网络流进入文件的完整调用链
看任何一段IO代码，我习惯先不看细节，而是把"数据从哪来、经过哪些对象、最终到哪去"这条主线画出来。这段示例代码干的事很单纯：监听本机一个端口，每次收到客户端发来的数据，就把这些数据写进当前目录下一个不断递增编号的文件里。
1.1 先把这段代码完整过一遍
import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.*; import java.nio.charset.StandardCharsets; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.StandardOpenOption; import java.util.Iterator; public class IOCodeDemo { public static void main(String[] args) throws IOException { Path fileDir = Path.of("io_output"); Files.createDirectories(fileDir); Selector selector = Selector.open(); ServerSocketChannel server = ServerSocketChannel.open(); server.bind(new InetSocketAddress("127.0.0.1", 8080)); server.configureBlocking(false); server.register(selector, SelectionKey.OP_ACCEPT); ByteBuffer buffer = ByteBuffer.allocate(1024); int fileIndex = 0; System.out.println("server started on 8080"); while (true) { selector.select(); Iterator<SelectionKey> keys = selector.selectedKeys().iterator(); while (keys.hasNext()) { SelectionKey key = keys.next(); keys.remove(); if (key.isAcceptable()) { SocketChannel channel = server.accept(); if (channel != null) { channel.configureBlocking(false); channel.register(selector, SelectionKey.OP_READ); } } else if (key.isReadable()) { SocketChannel channel = (SocketChannel) key.channel(); // 1. 从channel读到buffer int bytesRead = channel.read(buffer); if (bytesRead == -1) { channel.close(); continue; } // 2. 准备从buffer读数据，写入文件 buffer.flip(); String content = buffer.toString(); System.out.println("read from client: " + content); Path file = fileDir.resolve("data_" + fileIndex + ".txt"); try (FileChannel out = FileChannel.open(file, StandardOpenOption.CREATE, StandardOpenOption.WRITE)) { while (buffer.hasRemaining()) { int written = out.write(buffer); if (written == 0) { break; } } } fileIndex++; // 3. 重置buffer状态，继续下一次读取 buffer.compact(); } } } } }说实话，这段代码有两个小地方我特意写得有点"教学痕迹"：一是读取内容后直接调用buffer.toString()来打印，实际项目里多半要按编码解码；二是写入文件时用了新建文件的方式，而不是追加或者复用同一个文件。这些后面逐行拆的时候都会讲到。
1.2 数据在这段代码里到底走了哪条路
整个执行链路可以分成五步理解：
- server.accept()拿到一条已建立的TCP连接对应的
SocketChannel。 - channel.read(buffer)把来自网络的数据灌进程序自己开辟的一块内存（
ByteBuffer）。 - buffer.flip()把Buffer从"写模式"切换到"读模式"，这是NIO代码里最容易漏掉的一步。
- out.write(buffer)把Buffer里的字节从文件通道写入磁盘文件。
- buffer.compact()处理"没读完的数据"，安排缓冲区进入下一次写入的待命状态。
和BIO的思维模型对比一下，差异非常明显：
| 对比维度 | BIO（阻塞流） | NIO（示例代码） |
|---|---|---|
| 数据落点 | 直接read到byte[] | 先进入ByteBuffer，再被消费 |
| 是否阻塞 | read未读到数据时会一直等 | selector.select()等待可读事件 |
| 缓冲区归谁管 | 自己管理byte[]和读写位置 | Buffer内部维护position/limit/capacity |
| 读写的切换 | 靠数组下标和长度参数 | 靠flip()、clear()、compact()等操作 |
核心差别在于：BIO里读和写是两个独立的函数调用，数组里的数据你取完就完事了；而在NIO里，同一块缓冲区在读写之间反复切换状态，读和写通过position、limit两个游标相互配合。如果不理解Buffer的状态机制，你大概率会在某个读取循环里出现数据重复、漏读、乱码一类问题。
2. Channel和Buffer是这段代码的两个主角，理清它们的关系等于看懂一半NIO
很多人看NIO代码第一反应是："我把数据从Buffer写到Channel不就行了吗？"话是没错，但这两个东西的定位完全不同。Channel是数据的通道，本身不存储数据；Buffer是数据的暂存仓，所有字节都得先堆在这里才能被搬走。
2.1 Channel负责"搬运的管道"，Buffer负责"中转的仓库"
把Channel想象成一根水管，Buffer就是接在水管下面的水桶。水管决定水从哪来、往哪去（从网络到程序、从程序到磁盘），但水管本身不存水；水桶决定一次能接多少水、先接哪个位置的水。所以你在FileChannel.open()之后不会看到它内部有什么数组，它只是建立了一条"你可以往里写或往外读"的通道。
对应示例代码中的角色：
ServerSocketChannel：负责等待外部连接，是"入口的入口"。SocketChannel：一条实际TCP连接对应的通道，数据通过它进入程序。FileChannel：一条通往磁盘文件的通道，数据经过它落盘。
这里的ByteBuffer.allocate(1024)是关键，1024字节就是你程序缓冲区的容量上限，也就是一次最多能从网络读取多少数据。如果网络包里塞了3000字节，第一次channel.read(buffer)只会读取最多1024字节，剩下的还在内核缓冲区里等着下次事件触发。这是NIO和BIO差异最大的地方，也是很多人误以为"一次read必须把消息全部读完"的根源。
2.2 Buffer里藏着四个游标：capacity、position、limit、mark
ByteBuffer内部维护着几个关键状态，比普通byte[]高级就高级在这几个游标上：
| 属性 | 含义 | 类比 |
|---|---|---|
| capacity | 缓冲区总容量，创建后固定 | 水桶的总体积 |
| position | 下一次读或写的下标位置 | 当前水桶里读到哪个位置 |
| limit | 读写允许到达的边界 | 这次操作最多能摸到的位置 |
| mark | 一个可选的临时标记 | 书签 |
创建一个容量为10的缓冲区后，初始状态是：capacity=10，limit=10，position=0。此时如果写入5个字节，position变成5，limit仍然是10，表示"还能再写5个字节"。但你想把这5个字节读出来，不能直接用，因为position=5表示下一个读取位置应从5号下标开始，而数据实际在0到4之间。
这时候就用到了flip()。它做两件事：把limit设置成当前position（5），再把position归零。翻转后状态变成：limit=5，position=0，读取时就能从0一直读到limit边界（下标5）为止。
2.3 flip、clear、compact三个开关，各有各的使用场景
示例代码中出现了三次状态切换：
- flip()：读完网络数据、准备消费缓冲区时调用，相当于"发送端告诉接收端，我现在要从写模式切到读模式了"。
- clear()：如果不关心缓冲区里的旧数据，可以直接恢复成"整个缓冲区都能写入"的初始状态：limit=capacity，position=0。
- compact()：读完一部分数据后，把还没读完的数据挪到缓冲区的最前面，然后让position指向这段数据的末尾。这样下次再写入时，新数据会接在未读数据后面，不会覆盖掉它们。
示例代码里用的是compact()而不是clear()，是因为网络数据存在半包的可能性。假设channel.read(buffer)一次塞进来512字节，文件写入时只消费了200字节，剩下312字节如果被clear()清掉，这部分数据就丢了。而compact()会把剩余312字节挪到数组头部，position变成312，等你下次再读新数据进来时，会从312的位置继续写，文件写入循环也会继续消费这312字节，最终保证整段数据完整落盘。
为了方便理解，可以从头模拟一遍Buffer状态的变化：
| 操作 | position | limit | capacity | 备注 |
|---|---|---|---|---|
| 创建分配 allocate(10) | 0 | 10 | 10 | 初始状态 |
| 读入5字节 | 5 | 10 | 10 | 网络数据进来了 |
| flip() | 0 | 5 | 10 | 进入读模式 |
| 消费3字节 | 3 | 5 | 10 | 还剩2字节 |
| compact() | 2 | 10 | 10 | 2字节挪到头部，可继续写入 |
3. 逐行拆解：从"监听端口"到"数据落盘"的每一个关键调用
有了上面的整体框架，现在可以把示例代码一行一行掰开揉碎地看了。我不打算按顺序念代码，而是按"系统初始化、注册监听、事件触发、数据读写、资源收尾"五个环节来走一遍。
3.1 初始化阶段：Selector和ServerSocketChannel为什么要"配合演出"
Selector selector = Selector.open(); ServerSocketChannel server = ServerSocketChannel.open(); server.bind(new InetSocketAddress("127.0.0.1", 8080)); server.configureBlocking(false);这里最关键的是configureBlocking(false)。BIO模式下，server.accept()会一直阻塞到有客户端连上来；非阻塞模式下，accept()会立刻返回，如果没有连接就返回null。所以一定需要有一个"事件通知机制"来告诉我们"什么时候真的有连接来了"，这个机制就是Selector。
Selector本身是一个注册中心，它同时盯着多个通道。通道上发生的事件（有连接进入、有数据可读）会被内核记录下来，程序通过selector.select()查询有没有新事件。它解决的问题是：让一个线程同时管理成千上万个连接，而不会像BIO那样给每个连接分配一个线程傻等着。
这里有个可能误导新人的细节：InetSocketAddress("127.0.0.1", 8080)绑定的是本机回环地址，外部设备无法访问，只适合本地调试。实际部署时一般绑0.0.0.0或者具体的对外网卡地址，端口也要改成不在使用中的端口。
3.2 注册监听阶段：SelectionKey是"你关注什么"的登记表
server.register(selector, SelectionKey.OP_ACCEPT);这行代码做了三件事：把ServerSocketChannel和Selector绑定在一起；声明"我只关心新连接到达这个事件"（OP_ACCEPT）；得到一个叫做SelectionKey的凭证。
SelectionKey可以理解为一张订阅单。四个常见的事件类型是：
OP_ACCEPT：有新的TCP连接可以被接受。OP_CONNECT：客户端连接成功。OP_READ：通道里有数据可读。OP_WRITE：通道可以写入数据。
在示例代码的循环里，key.isAcceptable()和key.isReadable()就是靠这张订阅单来判断当前事件类型的。要注意，事件发生后，你必须在selectedKeys()的迭代里主动把它移除（代码里的keys.remove()），否则下次循环时这个key还会继续返回，导致重复处理同一个事件。这是NIO编程中非常经典的一个坑。
3.3 事件触发阶段：select()阻塞模型的真正含义
selector.select(); Iterator<SelectionKey> keys = selector.selectedKeys().iterator();select()在没有事件时会让当前线程进入等待状态，直到注册过的通道上出现感兴趣的事件，或者被其他线程唤醒。这种"阻塞地等事件"和BIO的"阻塞地等数据"本质区别在于：BIO的阻塞是每个连接都占一个线程；NIO的阻塞是这个线程同时等着所有连接，谁有事谁被唤醒。
这个等待不是忙轮询，所以CPU空转的问题基本不存在。真正危险的是"每次都注册了新事件但旧key没处理完"，会导致select()立即返回一组早已处理过的key，误以为有高并发流量，线程反而忙不过来。代码里每次从迭代器拿到key后立即keys.remove()，就是为了杜绝这个问题。
3.4 读事件分支：accept、configureBlocking、register的组合逻辑
if (key.isAcceptable()) { SocketChannel channel = server.accept(); if (channel != null) { channel.configureBlocking(false); channel.register(selector, SelectionKey.OP_READ); } }这里每个新连接都会执行一次configureBlocking(false)，然后注册OP_READ。为什么不能省略？因为socketChannel默认继承的是阻塞模式，如果不改成非阻塞，后面的channel.read(buffer)会阻塞整个线程。假如线程正阻塞在某一个慢连接的读操作上，其他所有连接的读写都会被卡住，Selector就失去意义了。
注册OP_READ之后，这条连接上的数据何时到达，就由Selector去感知了。这里要注意，accept()返回null的处理不是可选的——虽然理论上OP_ACCEPT触发了就会有连接可accept，但极端情况下事件可能已经失效，不做空判断会抛NullPointerException。
3.5 数据读写分支：read、flip、write、compact组成的闭环
int bytesRead = channel.read(buffer); if (bytesRead == -1) { channel.close(); continue; } buffer.flip(); // ... 把buffer里的字节写入文件 ... buffer.compact();channel.read(buffer)返回的是"实际读到的字节数"。这个数字有几种可能：
- 大于0：确实读到了数据。
- 等于0：当前没有数据可读，这种情况在非阻塞模式下时有发生，代码需要自己能处理。
- 等于-1：连接已经被对端关闭，此时不close的话，文件描述符会一直藏在Selector里，时间长了必然把句柄耗尽。
读到数据后，flip()把Buffer切到读模式。此时文件写入循环做的事情是把position到limit之间的数据全部交给FileChannel：
while (buffer.hasRemaining()) { int written = out.write(buffer); if (written == 0) { break; } }out.write(buffer)每次写入的数据量取决于磁盘状态，并不保证一次就把Buffer里所有字节写干净。所以必须用循环判断hasRemaining()。如果返回0，说明内核缓冲区或磁盘队列暂时满了，再写下去也是徒劳，直接跳出循环，通过compact()保留剩余数据到下一轮处理。
这地方我见过很多简化版写法直接out.write(buffer)然后不管了，在小文件场景下可能没问题，数据量大时会出现文件内容不完整的诡异问题。
3.6 资源收尾：close的时机与异常路径
代码里唯一显式的close是对端关闭后的channel.close()。真实的网络程序还需要处理三种情况：
- 写失败时的部分完成：如果
out.write(buffer)抛异常，FileChannel没有正常关闭，文件锁可能残留。使用try-with-resources是个好习惯。 - 重复注册问题：对一个已经注册过的channel再次调用
register会覆盖旧key，如果旧key还在selectedKeys里，就会出现两个key指向同一个channel的混乱状态。 - Selector本身不自动清理：你调用了
selector.close()时，所有注册的channel并不自动close，需要显式遍历key做清理。
一个更稳妥的收尾模式是定期遍历所有key，检查key.isValid()，一旦失效就调用key.cancel()关闭底层通道。尤其那句"connection reset by peer"很多就是从这来的——对端中断，本端的key状态变了，但代码没有及时感知，仍然尝试read，于是抛出IOException。
4. 这段示例代码放到真实环境后最常见的四个IO坑
把示例直接搬到生产环境，大概率会碰到下面几个问题。每一个我都踩过，也是社区里反复讨论的老话题。
4.1 误用clear()导致读到一半的数据被"重复解释"
场景还原：客户端发送了一条很长的JSON报文，长度超过Buffer容量（比如1024字节）。channel.read(buffer)第一次只读进来500字节，写入文件后调用clear()，第二次再把剩余部分读进来，写入同一个文件。
问题在于：第一次写入文件后调的是clear()，清空了Buffer；第二次读进来的数据会覆盖整个Buffer开头。如果业务上按"一次连接一条消息"来切分文件，第二条数据就会从文件开头重新写，文件里全是断成两截的内容，看起来就像乱序了。
示例代码用compact()在这个场景下是对的，因为它把未处理完的数据保住了。但仍有一个边界问题：单次read可能只读到完整消息的一半，写入文件时却把半段消息当作完整内容写进去了。真实的解决思路是等所有字节凑齐（比如按照Content-Length或者消息末尾标记判断）再落盘，这就在后面说的"半包粘包"范畴里了。
4.2 半包与粘包：NIO的read()不保证一次收到完整业务消息
TCP本身是字节流，不存在"消息边界"。客户端连续发送两条消息A和B时，服务端可能一次read拿到"A半个+B全部"，也可能一次read拿到"AB全部都"，极端情况下一条消息还会分成好多次read。
在示例代码层面，bytesRead只说明"这次拿到了多少字节"，完全不说明"这些字节是不是一条完整消息"。处理方案通常有几种：
- 定长协议：每条消息固定N字节，按长度切分。
- 分隔符协议：遇到换行符或特定标记才算完整消息，BufferedReader思路的NIO版本。
- 长度字段协议：前4字节表示后面内容的长度，先读够4字节再视情况读正文。
每一条都需要额外的缓存管理，不能直接把buffer.flip()之后的所有内容拿去落盘。示例代码之所以能跑通，是因为我们把"客户端发送的内容恰好小于等于Buffer容量，并且一次性发完"当作默认前提。真实环境访问量大一点，这个前提就瞬间失效。
4.3 字符编码的坑：ByteBuffer里的字节和"字符串"差着一堵墙
示例里我用buffer.toString()打印内容，这是在教学场景下的偷懒行为。ByteBuffer.toString()返回的是"Buffer自身状态的描述字符串"，根本不是"里面的字节翻译成的文字"。如果你真把这段代码跑到控制台，看到的会类似：
java.nio.HeapByteBuffer[pos=0 lim=52 cap=1024]而不是你写入的正常文本。这正是NIO新手最容易懵的地方：数据明明进去了，怎么打印出来是这个东西？
正确处理方式是解码，比如：
ByteBuffer copy = buffer.duplicate(); byte[] bytes = new byte[copy.remaining()]; copy.get(bytes); String content = new String(bytes, StandardCharsets.UTF_8);要注意，get(byte[])会改变position，所以在复制品上操作可以避免影响原Buffer的后续状态。如果数据可能被拆成多次，解码就得更谨慎，得借助CharsetDecoder处理字符边界，不然就有在字符中间截断导致乱码的风险。所谓"锟斤拷"一类的乱码，九成是编码解码不一致或者解码时机不对。
4.4 资源泄漏与Selector空转：线上服务卡死前的两大先兆
资源泄漏主要来自两类操作：
- 读事件触发后不读取：
selector.select()一旦被数据唤醒而有事件没被消费，下次调用时它还会立即返回同一批key，线程陷入"被反复唤醒但啥也不干"的忙循环，CPU一下子冲高。 - 异常分支忘记close：网络断连导致的IOException出现在read或write路径上时，如果只是继续循环，这个channel的底层fd永远不会被释放。
我的建议是：凡是SelectionKey失效的地方，都统一走同一个handleDisconnect(key)方法，里面做key.cancel()、关闭channel、清理任何关联的ByteBuffer。不要在两三个分支里各写一份close逻辑，"少写一半"和"重复关闭"这两类问题我都遇过。
另外select()返回0本身不是错误，但要和"一段时间内持续返回0、CPU还很高"结合起来看。后者基本指向没有正确移除key或者有key对应的通道一直不可读却在注册。
5. 跑通示例后还想再进一步，这三条延伸路线可以挨个试试
示例代码只是NIO的骨架。想在实际项目中把NIO用好，还需要在三个方向上做升级，每一条都会让代码在"正确性"和"性能"上跨一个台阶。
5.1 把堆内缓冲区换成堆外内存：allocate()升级成allocateDirect()
示例里用的是ByteBuffer.allocate(1024)，分配在JVM堆内。allocateDirect()分配在JVM堆外，由操作系统直接管理。从堆外Buffer到Channel之间的数据搬运，往往可以绕开JVM堆内的中间拷贝，在大数据量读写场景下能明显降低GC压力和拷贝开销。
代价是需要手动管理内存，过度分配堆外内存可能导致机器物理内存被吃满。入门阶段建议先用小容量（比如16KB）做验证，观察GC日志和内存变化，再决定是否扩大。
5.2 用FileChannel的零拷贝能力简化整段代码
如果目标是"把A文件完整复制到B文件"，完全没必要经过ByteBuffer中转。FileChannel自带transferTo()和transferFrom()，底层可以依赖操作系统的高效拷贝机制。示例那样"读进Buffer再写出去"的方式，在文件复制场景里等于让数据绕了两条路，纯属浪费。
try (FileChannel in = FileChannel.open(Path.of("source.bin")); FileChannel out = FileChannel.open(Path.of("target.bin"), StandardOpenOption.CREATE, StandardOpenOption.WRITE)) { in.transferTo(0, in.size(), out); }两行代码完成复制，而且数据在操作系统内部完成中转，省掉了一次用户态内存的写入和读取。不过要留意：transferTo并不是总能传输所有字节，返回值告诉你实际传了多少，不放心就用循环接着传。
5.3 异步IO与虚拟线程：NIO不是终点，而是一种思维方式
理解NIO的Selector模型后，你会发现它的核心是"用少量线程管理大量等待事件"。这套思路在Java后续版本里演进出两条路线：
- 异步通道（
AsynchronousSocketChannel）：读写操作主动提交，通过CompletionHandler或Future拿到结果，不需要自己写Selector循环。 - 虚拟线程：阻塞代码配合海量轻量级线程，用看起来像BIO的写法，在等待IO时自动释放底层载体线程，既保留可读性又达到并发能力。
这两者都是对"IO等待"的更高层抽象。但很多生产系统里的历史代码还是NIO和BIO混着用的，理解Buffer状态迁移、事件注册清理这些底层基本功，永远都不会过时。
我个人的习惯是：拿到任何一段NIO代码，先画Buffer的状态变化，再看业务逻辑。这个习惯帮我避免了很多个深夜排查"数据怎么少了/多了"的故障。这一期以这段示例代码为解剖对象把整个链路讲透了，下一篇有机会可以专门聊聊Selector在高并发服务里的线程模型设计，把"连接、读写、超时、心跳"这些状态机如何组织成一套完整框架的细节再挖一挖。
