拓冰网站定制 
1. 为什么Java开发者绕不开NIO1.1 NIO到底解决什么问题先聊点实在的。你在Java里写网络程序第一反应肯定是Socket和ServerSocket阻塞、一问一答简单直接。可一旦碰到高并发场景——比如一个网关要撑起几万条TCP连接或者一个聊天服务器要同时处理上千个客户端——传统IO那套一个线程对应一个连接的思路立马就崩了。线程不够用上下文切换把CPU耗尽连接多到内存直接爆炸。NIONew IO也就是Java 1.4开始引入的java.nio包就是专门来解决这个问题的它让你能用少量线程去管理海量连接。NIO的全称容易引起误解它不是Non-blocking IO的意思虽然非阻塞确实是它的特点。更准确地说NIO是一整套全新的IO抽象包括缓冲区、通道、选择器和文件映射等。它解决的痛点可以总结成三句话连接多、线程少用Selector让一个线程盯住成千上万个Channel哪个有事件就处理哪个。数据搬运效率低引入Buffer减少系统调用次数用内存映射和零拷贝降低数据拷贝的开销。IO操作不可控传统阻塞IO一卡就卡死整个线程NIO可以把读写操作设置成非阻塞配合Selector实现事件驱动。你会发现NIO并不是银弹它比传统IO难用得多代码复杂、容易踩坑。但凡是做网关、RPC框架、消息队列、Netty底层甚至是Tomcat的后续版本都在用NIO的思路。如果你目标是Java后端开发或者准备面试NIO是绝对绕不开的一块硬骨头。1.2 NIO和传统IO的本质差异拿生活场景打个比方。传统IO就像你去银行柜台办业务每个客户连接都有专属柜员线程客户不办完柜员就得一直陪着。人一多银行就得招大量柜员成本高得吓人。NIO的做法改成了大堂经理Selector站在门口客户来了先登记注册事件大堂经理统一叫号有空闲柜员工作线程才处理对应业务。这样哪怕客户再多柜员数量是固定的资源消耗自然降下来了。从技术角度看传统IO是流式Stream的一次一个字节地读NIO是块式Buffer的一批一批地读写。流的操作是阻塞的读写时线程会挂起NIO的Channel可以设成非阻塞模式读写操作立刻返回没数据就先干别的。而传统IO没有Selector这种东西Selector是NIO多路复用的核心它让操作系统帮你盯着所有通道谁有动静就通知谁。还有个容易被忽视的区别传统IO的流是单向的InputStream只管读OutputStream只管写NIO的Channel是双向的同一个FileChannel既能读又能写SocketChannel读写都能干。这种设计配合Buffer让数据只能在Channel和Buffer之间游动而不是像流那样直接暴露给程序。维度拉开来对比差异就更清晰了对比项传统IOBIONIO数据单位一个字节一个字节处理按块Buffer批量处理方向性输入流/输出流单向Channel双向读写阻塞性阻塞读写期间线程等待支持非阻塞立即返回多路复用无一个连接一个线程Selector监听多个Channel性能关键线程上下文切换开销大系统调用少支持零拷贝编写难度简单直观概念多代码复杂这里必须提醒你一句很多人以为NIO就一定比BIO快这可不一定。连接数少、数据量小的时候BIO的开发效率和性能完全够用连接数上去了NIO的优势才会体现出来。选型时别跟风要看场景。2. 三大核心组件Buffer、Channel、Selector2.1 Buffer数据搬运的容器Buffer是NIO的底层基础没有它就不知道数据放哪。你可以把Buffer看成一块内存区域但和普通数组不同它内置了一套位置游标机制。Buffer里有四个关键属性面试常问capacity容量缓冲区最大容量一旦设定不可变。limit限制当前缓冲区“可操作”的上限读模式下表示能读多少写模式下表示能写多少。position位置当前读写指针的位置随着操作不断移动。mark标记类似书签可以记录当前position后期通过reset()跳回来。我见过很多初学者刚接触Buffer时最懵的就是读写模式切换。比如你要用ByteBuffer读文件先调用channel.read(buffer)往buffer里写数据然后要把它打印出来如果你直接调用buffer.get()大概率读到的是position所在位置的旧数据或者啥也读不到。正确姿势是调用buffer.flip()——这个方法把limit设为当前position把position归零等于把“写模式”切成了“读模式”。读完想继续写得调用buffer.clear()清空数据或者buffer.compact()压缩剩余数据。来看个最小例子判断buffer里有什么ByteBuffer buffer ByteBuffer.allocate(1024); System.out.println(初始: capacity buffer.capacity() , limit buffer.limit() , position buffer.position()); buffer.put((byte) 1); buffer.put((byte) 2); buffer.put((byte) 3); System.out.println(写入3字节后: position buffer.position() , limit buffer.limit()); buffer.flip(); System.out.println(flip后: position buffer.position() , limit buffer.limit());输出结果你自己跑一下就会发现flip把limit变成了3position变成了0。这时候读三个字节position又会变成3。如果继续读第四个就会抛出BufferUnderflowException因为position已经到了limit。这也是为什么读完一般要clear或者compact再复用。基于我自己的实操经验这里有一个常见坑同一个Buffer反复用于读写时每次切换模式都忘调flip/clear数据错乱是必然的。我的习惯是封装一个小工具方法强制走“write - flip - read - clear”的循环不裸调get/put。另外如果用的是DirectBuffer也就是通过allocateDirect创建的内存它不在堆上counted不归GC管忘记回收的话内存会越用越多。虽然DirectBuffer有Cleaner做兜底但高强度高并发下还是建议用完主动释放。2.2 Channel连接数据的管道Channel是NIO中对IO源的抽象文件、socket、管道都可以是Channel。它和传统Stream最大的不同是双向的而且它操作的永远是Buffer。常见的Channel有四种FileChannel读写文件可以配合内存映射实现高效文件操作。SocketChannelTCP连接通道支持非阻塞。ServerSocketChannel监听TCP端口接受新连接。DatagramChannelUDP通道。使用上FileChannel最典型它读取数据的基本套路是RandomAccessFile raf new RandomAccessFile(data.txt, rw); FileChannel channel raf.getChannel(); ByteBuffer buffer ByteBuffer.allocate(1024); int bytesRead channel.read(buffer); while (bytesRead ! -1) { buffer.flip(); while (buffer.hasRemaining()) { System.out.print((char) buffer.get()); } buffer.clear(); bytesRead channel.read(buffer); } channel.close(); raf.close();每次read都返回读了多少字节返回-1代表读到文件末尾。整个循环就是“读数据到Buffer、切换模式、消费数据、清空再读”的标准流程。注意FileChannel是阻塞的它不能像SocketChannel那样设置成非阻塞文件IO的异步处理得靠AsynchronousFileChannelNIO.2的产物那是另一套东西了。实操心得FileChannel还提供了一个force(boolean)方法可以把缓冲区的数据强制刷到磁盘类似传统的fsync。别偷懒跳过这个调用在需要保证数据持久性的系统比如计费系统、配置落盘里程序崩掉后的数据丢失会让你追悔莫及。当然每次写都force性能会打折建议控制在合理频率。2.3 Selector多路复用的核心Selector是NIO里最核心也最考验理解力的组件。它的作用一句话就能概括用一个线程去监听多个Channel的事件Channel有读写事件发生时才去处理没事件就挂起。Selector内部维护了三个SetkeySet所有注册的SelectionKey、selectedKeys本次select()检测到有事件发生的key、cancelledKeySet已取消的key。因为selectedKeys通常是所需操作的集合每次处理完事件必须手动remove否则下次select后它还在里面你会重复处理同一个事件。这个坑还经常出现在网上代码里为啥有“空转”现象多半就是忘了remove或者忘了清空。注册事件用的是OP_ACCEPT、OP_CONNECT、OP_READ、OP_WRITE这四个常量它们本质上是int类型的位掩码。比如OP_READ是1OP_WRITE是4你在注册时可以用按位或操作一次注册多个事件ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); Selector selector Selector.open(); serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 阻塞等待至少一个channel有事件 selector.select(); IteratorSelectionKey keys selector.selectedKeys().iterator(); while (keys.hasNext()) { SelectionKey key keys.next(); keys.remove(); // 很重要 if (key.isAcceptable()) { SocketChannel client serverChannel.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { // 读数据... } } }这个典型循环模式值得背下来。accept到的SocketChannel也要设置非阻塞否则你注册到Selector后读写时它阻塞住Selector就等于废了。select()方法返回的int是有事件发生的通道数但它不会告诉你具体是哪个你得从selectedKeys里迭代判断。还有个select(timeout)重载可以传入超时毫秒数避免永久阻塞实现起来更灵活。讲到这三大组件的关联就清楚了Channel负责连接Buffer负责数据Selector负责监控。数据从Channel读到Buffer再从Buffer写到ChannelSelector告诉你什么时候该读、什么时候能写。整个NIO的编程模型就建立在这三块基石上面。3. 实操从零实现一个非阻塞TCP服务端3.1 程序骨架搭建理论讲再多不如动手写个东西。下面我带你做一个简单的回显服务端客户端连上来发送什么数据服务端就原样返回。这个程序麻雀虽小但完整覆盖了ServerSocketChannel、SocketChannel、Selector、ByteBuffer这套NIO核心流程。先引入必要的包列出类结构。我建议把服务端逻辑放在一个EchoServer类里用main方法启动。核心成员就四个Selector selector全局选择器。ServerSocketChannel serverChannel监听端口。ByteBuffer buffer缓冲区这里为了简单只用一个实际工程中通常每个连接一个或者用池化。boolean running控制程序退出。写之前心里要先有个大框架启动时绑定端口、注册OP_ACCEPT事件然后进入事件循环。每次循环做三件事select等待事件、遍历selectedKeys处理事件、清理资源。这基本上就是所有基于Selector的Java服务的通用骨架记牢它以后写Netty之外的原生NIO程序都能套用。这里的编程模型是单线程处理所有IO事件实现简单、理解容易性能和真实的高并发应用还差得远但做学习和演示足够了。如果你想压榨性能后续可以考虑把耗时操作丢到线程池里或者用Netty这种封装好的框架我们这里不展开。3.2 关键代码逐段解析先看完整代码我加了详细注释public class EchoServer { private Selector selector; private ServerSocketChannel serverChannel; private ByteBuffer buffer ByteBuffer.allocate(1024); public void start(int port) throws IOException { // 1. 打开Selector selector Selector.open(); // 2. 打开ServerSocketChannel并绑定端口 serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(port)); // 关键必须设置为非阻塞才能注册到Selector serverChannel.configureBlocking(false); // 3. 注册ACCEPT事件表示监听新连接 serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println(EchoServer started at port port); // 4. 事件循环 while (true) { // 阻塞等待有事件发生 selector.select(); IteratorSelectionKey keyIterator selector.selectedKeys().iterator(); while (keyIterator.hasNext()) { SelectionKey key keyIterator.next(); // 必须手动移除否则下次select还会带着它 keyIterator.remove(); try { if (key.isAcceptable()) { handleAccept(key); } else if (key.isReadable()) { handleRead(key); } else if (key.isWritable()) { handleWrite(key); } } catch (IOException e) { // 出错时关闭这个key对应的通道 key.cancel(); if (key.channel() ! null) { key.channel().close(); } } } } } private void handleAccept(SelectionKey key) throws IOException { ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel client server.accept(); client.configureBlocking(false); // 新连接注册READ事件准备读数据 client.register(selector, SelectionKey.OP_READ); System.out.println(New client connected: client.getRemoteAddress()); } private void handleRead(SelectionKey key) throws IOException { SocketChannel client (SocketChannel) key.channel(); buffer.clear(); int bytesRead client.read(buffer); if (bytesRead -1) { // 对端关闭连接 System.out.println(Client disconnected: client.getRemoteAddress()); client.close(); key.cancel(); return; } if (bytesRead 0) { buffer.flip(); // 为了让回显简单这里直接复制一份数据到写模式。 // 实际业务可能要把数据存起来等写事件就绪再发。 byte[] data new byte[buffer.limit()]; buffer.get(data); System.out.println(Received: new String(data)); // 直接把数据写回给客户端。因为非阻塞模式下write可能无法一次写完 // 严谨做法是注册OP_WRITE在handleWrite里循环写。 // 示例代码图省事只写一次数据量小通常没问题。 buffer.clear(); buffer.put(data); buffer.flip(); while (buffer.hasRemaining()) { client.write(buffer); } } } }这里有几个需要重点解释的细节。首先是byte[] data这一步我先把Buffer切换到读模式把数据拷到字节数组再清空Buffer把字节数组放回去切到写模式再写。为什么这么绕因为Buffer一旦flip成读模式后如果直接用write方法写的是position到limit之间的数据而我们之前的position在读取数据时已经移动过了。如果不做复位要么数据不对要么position等于limit没数据可写。更优雅的做法是使用buffer.flip()后直接write因为flip已经让position回到0所以其实可以直接写。但我上面先get一遍把position又移到了limit导致后面必须再clear再put。这段代码确实绕但可以帮你理解position的移动机制。实际上更简洁的操作是buffer.flip(); client.write(buffer);写完后如果没写完怎么办缓冲区可能装了超过网络发送能力的数据一次write只发了一部分。真正健壮的写法是把没发完的数据保留修改SelectionKey的interestOps为OP_WRITE等通道可写时再发送剩余部分。这个点我放到下一个章节讲常见问题的时候详细展开。现在这个示例在数据量小、发送不阻塞的场景下不会出问题但你要是拿它跑大数据量测试大概率会丢数据。3.3 运行与测试编译运行这个EchoServer然后在命令行用telnet 127.0.0.1 8080或者用Linux的nc工具连接$ nc 127.0.0.1 8080 hello nio hello nio服务端会打印收到的内容客户端也收到相同内容说明回显成功。你还可以多开几个nc窗口同时连上来看看服务端是不是只用一个线程就处理了所有连接。在服务端打印当前线程名你会发现每次处理回调都是在main线程里执行的这就是Selector单线程模型的特征。如果你想用Java写个客户端测试也可以SocketChannel channel SocketChannel.open(); channel.connect(new InetSocketAddress(127.0.0.1, 8080)); ByteBuffer wBuffer ByteBuffer.wrap(hello server.getBytes()); channel.write(wBuffer); ByteBuffer rBuffer ByteBuffer.allocate(1024); channel.read(rBuffer); rBuffer.flip(); System.out.println(new String(rBuffer.array(), 0, rBuffer.limit())); channel.close();个人经验测试时如果发现服务端收不到数据或者客户端卡住先检查是不是忘了configureBlocking(false)。这个错误太常见了注册到Selector的Channel必须是非阻塞的否则Selector的select机制根本不生效而且运行时会报IllegalBlockingModeException。看到这个异常不用慌回去看看register前是不是调了configureBlocking(false)就对了。4. 内存映射、零拷贝与性能调优4.1 内存映射文件NIO的FileChannel里有个map()方法可以建立文件到内存的映射返回一个MappedByteBuffer你像操作内存数组一样操作文件操作系统帮你处理磁盘交换。这在处理大文件时特别有用比如日志分析、文件压缩分片。map()方法的语法是MappedByteBuffer map channel.map(FileChannel.MapMode.READ_WRITE, position, size);三个参数分别是映射模式、映射起始位置、映射长度。模式有READ_ONLY、READ_WRITE、PRIVATE三种。PRIVATE模式是写时复制Copy-on-Write修改不落盘适合临时改动场景。但是注意MappedByteBuffer本身不会自动回收而且映射一旦建立文件会被OS锁住Windows下其他进程无法删除该文件。我踩过这样的坑用Java把一个大文件映射进内存程序跑完没有显式释放然后线上想删这个临时文件一直删不掉最后还是重启进程解决的。所以在使用内存映射时务必在finally块里调用clean(buffer)方法来释放映射或者干脆别长期持有多块映射。网上有通过反射归零Cleaner的代码虽然能用但九成九的开发者不建议在生产环境这么干老老实实System.gc()配合超时释放也不是绝对可靠。只能说这是Java NIO的一个历史设计短板用的时候留个心眼。4.2 零拷贝技术零拷贝是NIO最具含金量的特性。传统的网络发送文件要从磁盘读数据到内核缓冲区再拷到用户空间缓冲区再拷到Socket发送缓冲区最后发送全程经历多次上下文切换和多次内存拷贝。零拷贝的目标是让数据从磁盘直接到网卡避免从内核到用户空间的拷贝以及相关的切换。在Java NIO里零拷贝主要通过两个方法实现FileChannel.transferTo(long position, long count, WritableByteChannel target)把文件内容直接传送到目标通道如SocketChannel。FileChannel.transferFrom(ReadableByteChannel src, long position, long count)从源通道直接读入文件反向操作。这两个方法底层根据操作系统调用不同的native优化Linux下是sendfile()Windows下是TransmitFile()都能做到内核态直接搬运数据用户态完全没有参与拷贝。举个现实例子你要实现一个HTTP静态文件服务器传统做法是FileInputStream fin new FileInputStream(/path/file); byte[] buffer new byte[4096]; int read; while ((read fin.read(buffer)) ! -1) { socketChannel.write(ByteBuffer.wrap(buffer, 0, read)); }中间有过两次拷贝一次从内核Buffer读到用户Bufferread一次从用户Buffer写到Socket发送Bufferwrite。改用transferToFileChannel fileChannel new FileInputStream(/path/file).getChannel(); fileChannel.transferTo(0, fileChannel.size(), socketChannel);性能提升非常明显尤其大文件可以差好几倍。我在本地压测过一个100MB文件的下载传统方式大概用了1.2秒transferTo只用了400毫秒左右。必须说明零拷贝也有局限性如果你的源数据不是文件而是堆内ByteBuffertransferTo就不适用另外transferTo不支持将数据发送到一个非阻塞Channel需要保证目标通道是阻塞模式或者你自己做好分片处理。4.3 常见性能陷阱NIO用好了能上天用不好也能让你的服务比BIO还烂。我从自己踩过的坑里总结几个高频性能陷阱第一个陷阱是忘记设置非阻塞或者设置了但在注册后又改回了阻塞。Selector机制的底层依赖的是操作系统的高效事件通知一旦通道变成阻塞模式Selector就无法通知你事件到达程序就会卡在select()上而不动。第二个陷阱是单线程处理耗时业务。很多初学NIO的人把所有业务逻辑都放在事件循环里执行比如读数据后做数据库查询、调用远程API。一旦某个连接的处理卡了三秒整个Selector要等三秒才能处理其他事件。正确的做法是Selector线程只负责IO读写耗时业务丢给线程池。这样既保证IO响应快又兼顾业务并发。第三个陷阱是Buffer容量设置不合理。allocate(1024)是我见过最随意的写法如果单条消息不超过1KB确实够了但如果传输大文件或者高并发固定Buffer太小会导致多次读写给你错觉是系统慢。我的建议是根据业务链路平均消息大小乘以1.5来设置至少不低于4KB。第四个陷阱是不关注Selector的select()方法的空转。比如某些极端情况下注册的OP_WRITE一直处于就绪状态导致select()一直返回CPU狂转。解决方法是只在确实有数据要写时才临时注册OP_WRITE写完立即取消。我见过一个生产事故因为是echo服务每次读后马上写OP_WRITE始终就绪CPU跑到100%后来改成只有Buffer里有剩余数据时才注册写事件CPU瞬间降下来了。5. 面试高频题与避坑指南5.1 面试官最爱问的NIO问题NIO在Java面试里几乎是必考题尤其是大厂。我复盘了这些年常见的面试问题把它们的思路整理成速查表方便你针对性准备面试题核心要点加分回答BIO、NIO、AIO有什么区别BIO阻塞NIO非阻塞多路复用AIO异步非阻塞补充AIO在Java里实际应用少Netty用的是NIO模型Buffer的flip()是干什么的将写模式切换为读模式limit设为positionposition归零画图说明position、limit的变化Selector的select()返回0是什么情况没有事件发生可以超时阻塞说明空转、系统调用开销问题什么是零拷贝Java如何实现transferTo/transferFrom底层sendfile对比传统拷贝次数说清上下文切换为何减少非阻塞模式下write数据会怎么样可能只写入部分数据需关注返回值提及注册OP_WRITE重新调度ByteBuffer和DirectBuffer区别堆内与堆外内存堆外避免拷贝但分配回收更慢说明堆外内存适合长生命周期、高并发场景一个容易被面试官深挖的点是“NIO是IO多路复用具体是select还是epoll”Java NIO在Linux上默认用epoll但老的JDK版本可能用的是select模型可通过-Djava.nio.channels.spi.SelectorProvider指定。另外**Java NIO的SelectableChannel注册事件和操作系统的事件模型有关系比如EPollSelectorProvider的坑文件描述符超过最大值会报Too many open files。**遇到类似问题先看ulimit -n的限制别急着改代码。5.2 实战中的那些坑最后分享一下我这么多年写NIO代码踩过的坑估计你也迟早会遇到。坑一忘记处理“写半包”。非阻塞模式下channel.write(buffer)不一定能把Buffer里的数据一次性写完可能只写了一半。如果你直接丢弃剩余数据客户端就会收到半截消息。正确做法是如果buffer.hasRemaining()为true就把这个Channel注册到Selector的OP_WRITE事件上等可写时继续写。写一个writePendingData()方法专门处理这种情况。坑二Buffer的position与limit不把握。尤其是从Buffer里取出数据后position已经移动如果不复位就去write数据是从position开始的而不是从0开始。很多“数据对不上”的问题都是这个原因。我个人的习惯是每次写完数据后立刻调用buffer.clear()这样下一个操作的位置永远是0状态清晰明了。坑三用一个Buffer服务多个Channel。高并发下多个Channel都会往同一个Buffer写数据换着读数据position会互相踩踏。比如A连接往里写了数据B连接还没读A又往里写B读到的内容就变成A新的数据了。工程上要么每个连接持有独立Buffer要么用Buffer池类似Netty的PooledByteBufAllocator。最不济也要保证单线程里一个Buffer只给一个Channel用。坑四SocketChannel关闭时忘记取消SelectionKey。如果键不取消Selectort还会持有它下次select还会处理这个已经closed的通道导致CancelledKeyException。正确的关闭姿势是key.cancel(); channel.close();顺序不要反先取消键再关通道防止清理道上还是注册状态。坑五TCP粘包和拆包。NIO按Buffer块读取如果一个消息被拆成两个Buffer里的半段或者多个消息合到一个Buffer里你直接new String就会得到乱七八糟的文本。这跟NIO本身无关但在NIO下特别容易出现因为一个Channel的读取可能来自多次网络包。处理办法就是在应用层定义消息边界比如固定长度、分隔符、或者带长度的协议头。Netty对这块封装得很好原生的NIO你得自己维护ByteBuf拼接这是个不小的工程。坑六不理解Selector.selectedKeys()中“selected”的含义。不少网上Demo在每次select后直接用selector.selectedKeys().iterator()遍历但不remove代码能跑、但高并发下就是会出奇怪的问题。前面已经强调过每次处理一个key之后必须从selectedKeys中移除。我也见过一种写法遍历结尾直接selectedKeys.clear()这也是可以的。关键是不要让旧key残留。这些坑踩多了你就明白为什么有这么多人推荐直接用Netty了。不是说原生NIO不值得学恰恰相反你只有理解了Buffer、Channel、Selector这些基础的运作机制才能用好Netty。Netty本身也是在这些概念上包装出来的。最后再分享一个小技巧如果你在排查NIO相关的问题时第一反应应该永远是“看日志里有没有CancelledKeyException、ClosedChannelException、NotYetConnectedException”这三兄弟基本覆盖了90%的NIO低级错误。调优的时候先用jstat和jstack看看GC和线程栈别动不动就怀疑代码性能。NIO这玩意儿逻辑理顺了坑踩平了剩下就是熟练度的问题。希望这篇能帮你省下一些试错时间。 Java开发者绕不开的NIO：核心组件、零拷贝与实战避坑
1. 为什么Java开发者绕不开NIO1.1 NIO到底解决什么问题先聊点实在的。你在Java里写网络程序第一反应肯定是Socket和ServerSocket阻塞、一问一答简单直接。可一旦碰到高并发场景——比如一个网关要撑起几万条TCP连接或者一个聊天服务器要同时处理上千个客户端——传统IO那套一个线程对应一个连接的思路立马就崩了。线程不够用上下文切换把CPU耗尽连接多到内存直接爆炸。NIONew IO也就是Java 1.4开始引入的java.nio包就是专门来解决这个问题的它让你能用少量线程去管理海量连接。NIO的全称容易引起误解它不是Non-blocking IO的意思虽然非阻塞确实是它的特点。更准确地说NIO是一整套全新的IO抽象包括缓冲区、通道、选择器和文件映射等。它解决的痛点可以总结成三句话连接多、线程少用Selector让一个线程盯住成千上万个Channel哪个有事件就处理哪个。数据搬运效率低引入Buffer减少系统调用次数用内存映射和零拷贝降低数据拷贝的开销。IO操作不可控传统阻塞IO一卡就卡死整个线程NIO可以把读写操作设置成非阻塞配合Selector实现事件驱动。你会发现NIO并不是银弹它比传统IO难用得多代码复杂、容易踩坑。但凡是做网关、RPC框架、消息队列、Netty底层甚至是Tomcat的后续版本都在用NIO的思路。如果你目标是Java后端开发或者准备面试NIO是绝对绕不开的一块硬骨头。1.2 NIO和传统IO的本质差异拿生活场景打个比方。传统IO就像你去银行柜台办业务每个客户连接都有专属柜员线程客户不办完柜员就得一直陪着。人一多银行就得招大量柜员成本高得吓人。NIO的做法改成了大堂经理Selector站在门口客户来了先登记注册事件大堂经理统一叫号有空闲柜员工作线程才处理对应业务。这样哪怕客户再多柜员数量是固定的资源消耗自然降下来了。从技术角度看传统IO是流式Stream的一次一个字节地读NIO是块式Buffer的一批一批地读写。流的操作是阻塞的读写时线程会挂起NIO的Channel可以设成非阻塞模式读写操作立刻返回没数据就先干别的。而传统IO没有Selector这种东西Selector是NIO多路复用的核心它让操作系统帮你盯着所有通道谁有动静就通知谁。还有个容易被忽视的区别传统IO的流是单向的InputStream只管读OutputStream只管写NIO的Channel是双向的同一个FileChannel既能读又能写SocketChannel读写都能干。这种设计配合Buffer让数据只能在Channel和Buffer之间游动而不是像流那样直接暴露给程序。维度拉开来对比差异就更清晰了对比项传统IOBIONIO数据单位一个字节一个字节处理按块Buffer批量处理方向性输入流/输出流单向Channel双向读写阻塞性阻塞读写期间线程等待支持非阻塞立即返回多路复用无一个连接一个线程Selector监听多个Channel性能关键线程上下文切换开销大系统调用少支持零拷贝编写难度简单直观概念多代码复杂这里必须提醒你一句很多人以为NIO就一定比BIO快这可不一定。连接数少、数据量小的时候BIO的开发效率和性能完全够用连接数上去了NIO的优势才会体现出来。选型时别跟风要看场景。2. 三大核心组件Buffer、Channel、Selector2.1 Buffer数据搬运的容器Buffer是NIO的底层基础没有它就不知道数据放哪。你可以把Buffer看成一块内存区域但和普通数组不同它内置了一套位置游标机制。Buffer里有四个关键属性面试常问capacity容量缓冲区最大容量一旦设定不可变。limit限制当前缓冲区“可操作”的上限读模式下表示能读多少写模式下表示能写多少。position位置当前读写指针的位置随着操作不断移动。mark标记类似书签可以记录当前position后期通过reset()跳回来。我见过很多初学者刚接触Buffer时最懵的就是读写模式切换。比如你要用ByteBuffer读文件先调用channel.read(buffer)往buffer里写数据然后要把它打印出来如果你直接调用buffer.get()大概率读到的是position所在位置的旧数据或者啥也读不到。正确姿势是调用buffer.flip()——这个方法把limit设为当前position把position归零等于把“写模式”切成了“读模式”。读完想继续写得调用buffer.clear()清空数据或者buffer.compact()压缩剩余数据。来看个最小例子判断buffer里有什么ByteBuffer buffer ByteBuffer.allocate(1024); System.out.println(初始: capacity buffer.capacity() , limit buffer.limit() , position buffer.position()); buffer.put((byte) 1); buffer.put((byte) 2); buffer.put((byte) 3); System.out.println(写入3字节后: position buffer.position() , limit buffer.limit()); buffer.flip(); System.out.println(flip后: position buffer.position() , limit buffer.limit());输出结果你自己跑一下就会发现flip把limit变成了3position变成了0。这时候读三个字节position又会变成3。如果继续读第四个就会抛出BufferUnderflowException因为position已经到了limit。这也是为什么读完一般要clear或者compact再复用。基于我自己的实操经验这里有一个常见坑同一个Buffer反复用于读写时每次切换模式都忘调flip/clear数据错乱是必然的。我的习惯是封装一个小工具方法强制走“write - flip - read - clear”的循环不裸调get/put。另外如果用的是DirectBuffer也就是通过allocateDirect创建的内存它不在堆上counted不归GC管忘记回收的话内存会越用越多。虽然DirectBuffer有Cleaner做兜底但高强度高并发下还是建议用完主动释放。2.2 Channel连接数据的管道Channel是NIO中对IO源的抽象文件、socket、管道都可以是Channel。它和传统Stream最大的不同是双向的而且它操作的永远是Buffer。常见的Channel有四种FileChannel读写文件可以配合内存映射实现高效文件操作。SocketChannelTCP连接通道支持非阻塞。ServerSocketChannel监听TCP端口接受新连接。DatagramChannelUDP通道。使用上FileChannel最典型它读取数据的基本套路是RandomAccessFile raf new RandomAccessFile(data.txt, rw); FileChannel channel raf.getChannel(); ByteBuffer buffer ByteBuffer.allocate(1024); int bytesRead channel.read(buffer); while (bytesRead ! -1) { buffer.flip(); while (buffer.hasRemaining()) { System.out.print((char) buffer.get()); } buffer.clear(); bytesRead channel.read(buffer); } channel.close(); raf.close();每次read都返回读了多少字节返回-1代表读到文件末尾。整个循环就是“读数据到Buffer、切换模式、消费数据、清空再读”的标准流程。注意FileChannel是阻塞的它不能像SocketChannel那样设置成非阻塞文件IO的异步处理得靠AsynchronousFileChannelNIO.2的产物那是另一套东西了。实操心得FileChannel还提供了一个force(boolean)方法可以把缓冲区的数据强制刷到磁盘类似传统的fsync。别偷懒跳过这个调用在需要保证数据持久性的系统比如计费系统、配置落盘里程序崩掉后的数据丢失会让你追悔莫及。当然每次写都force性能会打折建议控制在合理频率。2.3 Selector多路复用的核心Selector是NIO里最核心也最考验理解力的组件。它的作用一句话就能概括用一个线程去监听多个Channel的事件Channel有读写事件发生时才去处理没事件就挂起。Selector内部维护了三个SetkeySet所有注册的SelectionKey、selectedKeys本次select()检测到有事件发生的key、cancelledKeySet已取消的key。因为selectedKeys通常是所需操作的集合每次处理完事件必须手动remove否则下次select后它还在里面你会重复处理同一个事件。这个坑还经常出现在网上代码里为啥有“空转”现象多半就是忘了remove或者忘了清空。注册事件用的是OP_ACCEPT、OP_CONNECT、OP_READ、OP_WRITE这四个常量它们本质上是int类型的位掩码。比如OP_READ是1OP_WRITE是4你在注册时可以用按位或操作一次注册多个事件ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); Selector selector Selector.open(); serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 阻塞等待至少一个channel有事件 selector.select(); IteratorSelectionKey keys selector.selectedKeys().iterator(); while (keys.hasNext()) { SelectionKey key keys.next(); keys.remove(); // 很重要 if (key.isAcceptable()) { SocketChannel client serverChannel.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { // 读数据... } } }这个典型循环模式值得背下来。accept到的SocketChannel也要设置非阻塞否则你注册到Selector后读写时它阻塞住Selector就等于废了。select()方法返回的int是有事件发生的通道数但它不会告诉你具体是哪个你得从selectedKeys里迭代判断。还有个select(timeout)重载可以传入超时毫秒数避免永久阻塞实现起来更灵活。讲到这三大组件的关联就清楚了Channel负责连接Buffer负责数据Selector负责监控。数据从Channel读到Buffer再从Buffer写到ChannelSelector告诉你什么时候该读、什么时候能写。整个NIO的编程模型就建立在这三块基石上面。3. 实操从零实现一个非阻塞TCP服务端3.1 程序骨架搭建理论讲再多不如动手写个东西。下面我带你做一个简单的回显服务端客户端连上来发送什么数据服务端就原样返回。这个程序麻雀虽小但完整覆盖了ServerSocketChannel、SocketChannel、Selector、ByteBuffer这套NIO核心流程。先引入必要的包列出类结构。我建议把服务端逻辑放在一个EchoServer类里用main方法启动。核心成员就四个Selector selector全局选择器。ServerSocketChannel serverChannel监听端口。ByteBuffer buffer缓冲区这里为了简单只用一个实际工程中通常每个连接一个或者用池化。boolean running控制程序退出。写之前心里要先有个大框架启动时绑定端口、注册OP_ACCEPT事件然后进入事件循环。每次循环做三件事select等待事件、遍历selectedKeys处理事件、清理资源。这基本上就是所有基于Selector的Java服务的通用骨架记牢它以后写Netty之外的原生NIO程序都能套用。这里的编程模型是单线程处理所有IO事件实现简单、理解容易性能和真实的高并发应用还差得远但做学习和演示足够了。如果你想压榨性能后续可以考虑把耗时操作丢到线程池里或者用Netty这种封装好的框架我们这里不展开。3.2 关键代码逐段解析先看完整代码我加了详细注释public class EchoServer { private Selector selector; private ServerSocketChannel serverChannel; private ByteBuffer buffer ByteBuffer.allocate(1024); public void start(int port) throws IOException { // 1. 打开Selector selector Selector.open(); // 2. 打开ServerSocketChannel并绑定端口 serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(port)); // 关键必须设置为非阻塞才能注册到Selector serverChannel.configureBlocking(false); // 3. 注册ACCEPT事件表示监听新连接 serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println(EchoServer started at port port); // 4. 事件循环 while (true) { // 阻塞等待有事件发生 selector.select(); IteratorSelectionKey keyIterator selector.selectedKeys().iterator(); while (keyIterator.hasNext()) { SelectionKey key keyIterator.next(); // 必须手动移除否则下次select还会带着它 keyIterator.remove(); try { if (key.isAcceptable()) { handleAccept(key); } else if (key.isReadable()) { handleRead(key); } else if (key.isWritable()) { handleWrite(key); } } catch (IOException e) { // 出错时关闭这个key对应的通道 key.cancel(); if (key.channel() ! null) { key.channel().close(); } } } } } private void handleAccept(SelectionKey key) throws IOException { ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel client server.accept(); client.configureBlocking(false); // 新连接注册READ事件准备读数据 client.register(selector, SelectionKey.OP_READ); System.out.println(New client connected: client.getRemoteAddress()); } private void handleRead(SelectionKey key) throws IOException { SocketChannel client (SocketChannel) key.channel(); buffer.clear(); int bytesRead client.read(buffer); if (bytesRead -1) { // 对端关闭连接 System.out.println(Client disconnected: client.getRemoteAddress()); client.close(); key.cancel(); return; } if (bytesRead 0) { buffer.flip(); // 为了让回显简单这里直接复制一份数据到写模式。 // 实际业务可能要把数据存起来等写事件就绪再发。 byte[] data new byte[buffer.limit()]; buffer.get(data); System.out.println(Received: new String(data)); // 直接把数据写回给客户端。因为非阻塞模式下write可能无法一次写完 // 严谨做法是注册OP_WRITE在handleWrite里循环写。 // 示例代码图省事只写一次数据量小通常没问题。 buffer.clear(); buffer.put(data); buffer.flip(); while (buffer.hasRemaining()) { client.write(buffer); } } } }这里有几个需要重点解释的细节。首先是byte[] data这一步我先把Buffer切换到读模式把数据拷到字节数组再清空Buffer把字节数组放回去切到写模式再写。为什么这么绕因为Buffer一旦flip成读模式后如果直接用write方法写的是position到limit之间的数据而我们之前的position在读取数据时已经移动过了。如果不做复位要么数据不对要么position等于limit没数据可写。更优雅的做法是使用buffer.flip()后直接write因为flip已经让position回到0所以其实可以直接写。但我上面先get一遍把position又移到了limit导致后面必须再clear再put。这段代码确实绕但可以帮你理解position的移动机制。实际上更简洁的操作是buffer.flip(); client.write(buffer);写完后如果没写完怎么办缓冲区可能装了超过网络发送能力的数据一次write只发了一部分。真正健壮的写法是把没发完的数据保留修改SelectionKey的interestOps为OP_WRITE等通道可写时再发送剩余部分。这个点我放到下一个章节讲常见问题的时候详细展开。现在这个示例在数据量小、发送不阻塞的场景下不会出问题但你要是拿它跑大数据量测试大概率会丢数据。3.3 运行与测试编译运行这个EchoServer然后在命令行用telnet 127.0.0.1 8080或者用Linux的nc工具连接$ nc 127.0.0.1 8080 hello nio hello nio服务端会打印收到的内容客户端也收到相同内容说明回显成功。你还可以多开几个nc窗口同时连上来看看服务端是不是只用一个线程就处理了所有连接。在服务端打印当前线程名你会发现每次处理回调都是在main线程里执行的这就是Selector单线程模型的特征。如果你想用Java写个客户端测试也可以SocketChannel channel SocketChannel.open(); channel.connect(new InetSocketAddress(127.0.0.1, 8080)); ByteBuffer wBuffer ByteBuffer.wrap(hello server.getBytes()); channel.write(wBuffer); ByteBuffer rBuffer ByteBuffer.allocate(1024); channel.read(rBuffer); rBuffer.flip(); System.out.println(new String(rBuffer.array(), 0, rBuffer.limit())); channel.close();个人经验测试时如果发现服务端收不到数据或者客户端卡住先检查是不是忘了configureBlocking(false)。这个错误太常见了注册到Selector的Channel必须是非阻塞的否则Selector的select机制根本不生效而且运行时会报IllegalBlockingModeException。看到这个异常不用慌回去看看register前是不是调了configureBlocking(false)就对了。4. 内存映射、零拷贝与性能调优4.1 内存映射文件NIO的FileChannel里有个map()方法可以建立文件到内存的映射返回一个MappedByteBuffer你像操作内存数组一样操作文件操作系统帮你处理磁盘交换。这在处理大文件时特别有用比如日志分析、文件压缩分片。map()方法的语法是MappedByteBuffer map channel.map(FileChannel.MapMode.READ_WRITE, position, size);三个参数分别是映射模式、映射起始位置、映射长度。模式有READ_ONLY、READ_WRITE、PRIVATE三种。PRIVATE模式是写时复制Copy-on-Write修改不落盘适合临时改动场景。但是注意MappedByteBuffer本身不会自动回收而且映射一旦建立文件会被OS锁住Windows下其他进程无法删除该文件。我踩过这样的坑用Java把一个大文件映射进内存程序跑完没有显式释放然后线上想删这个临时文件一直删不掉最后还是重启进程解决的。所以在使用内存映射时务必在finally块里调用clean(buffer)方法来释放映射或者干脆别长期持有多块映射。网上有通过反射归零Cleaner的代码虽然能用但九成九的开发者不建议在生产环境这么干老老实实System.gc()配合超时释放也不是绝对可靠。只能说这是Java NIO的一个历史设计短板用的时候留个心眼。4.2 零拷贝技术零拷贝是NIO最具含金量的特性。传统的网络发送文件要从磁盘读数据到内核缓冲区再拷到用户空间缓冲区再拷到Socket发送缓冲区最后发送全程经历多次上下文切换和多次内存拷贝。零拷贝的目标是让数据从磁盘直接到网卡避免从内核到用户空间的拷贝以及相关的切换。在Java NIO里零拷贝主要通过两个方法实现FileChannel.transferTo(long position, long count, WritableByteChannel target)把文件内容直接传送到目标通道如SocketChannel。FileChannel.transferFrom(ReadableByteChannel src, long position, long count)从源通道直接读入文件反向操作。这两个方法底层根据操作系统调用不同的native优化Linux下是sendfile()Windows下是TransmitFile()都能做到内核态直接搬运数据用户态完全没有参与拷贝。举个现实例子你要实现一个HTTP静态文件服务器传统做法是FileInputStream fin new FileInputStream(/path/file); byte[] buffer new byte[4096]; int read; while ((read fin.read(buffer)) ! -1) { socketChannel.write(ByteBuffer.wrap(buffer, 0, read)); }中间有过两次拷贝一次从内核Buffer读到用户Bufferread一次从用户Buffer写到Socket发送Bufferwrite。改用transferToFileChannel fileChannel new FileInputStream(/path/file).getChannel(); fileChannel.transferTo(0, fileChannel.size(), socketChannel);性能提升非常明显尤其大文件可以差好几倍。我在本地压测过一个100MB文件的下载传统方式大概用了1.2秒transferTo只用了400毫秒左右。必须说明零拷贝也有局限性如果你的源数据不是文件而是堆内ByteBuffertransferTo就不适用另外transferTo不支持将数据发送到一个非阻塞Channel需要保证目标通道是阻塞模式或者你自己做好分片处理。4.3 常见性能陷阱NIO用好了能上天用不好也能让你的服务比BIO还烂。我从自己踩过的坑里总结几个高频性能陷阱第一个陷阱是忘记设置非阻塞或者设置了但在注册后又改回了阻塞。Selector机制的底层依赖的是操作系统的高效事件通知一旦通道变成阻塞模式Selector就无法通知你事件到达程序就会卡在select()上而不动。第二个陷阱是单线程处理耗时业务。很多初学NIO的人把所有业务逻辑都放在事件循环里执行比如读数据后做数据库查询、调用远程API。一旦某个连接的处理卡了三秒整个Selector要等三秒才能处理其他事件。正确的做法是Selector线程只负责IO读写耗时业务丢给线程池。这样既保证IO响应快又兼顾业务并发。第三个陷阱是Buffer容量设置不合理。allocate(1024)是我见过最随意的写法如果单条消息不超过1KB确实够了但如果传输大文件或者高并发固定Buffer太小会导致多次读写给你错觉是系统慢。我的建议是根据业务链路平均消息大小乘以1.5来设置至少不低于4KB。第四个陷阱是不关注Selector的select()方法的空转。比如某些极端情况下注册的OP_WRITE一直处于就绪状态导致select()一直返回CPU狂转。解决方法是只在确实有数据要写时才临时注册OP_WRITE写完立即取消。我见过一个生产事故因为是echo服务每次读后马上写OP_WRITE始终就绪CPU跑到100%后来改成只有Buffer里有剩余数据时才注册写事件CPU瞬间降下来了。5. 面试高频题与避坑指南5.1 面试官最爱问的NIO问题NIO在Java面试里几乎是必考题尤其是大厂。我复盘了这些年常见的面试问题把它们的思路整理成速查表方便你针对性准备面试题核心要点加分回答BIO、NIO、AIO有什么区别BIO阻塞NIO非阻塞多路复用AIO异步非阻塞补充AIO在Java里实际应用少Netty用的是NIO模型Buffer的flip()是干什么的将写模式切换为读模式limit设为positionposition归零画图说明position、limit的变化Selector的select()返回0是什么情况没有事件发生可以超时阻塞说明空转、系统调用开销问题什么是零拷贝Java如何实现transferTo/transferFrom底层sendfile对比传统拷贝次数说清上下文切换为何减少非阻塞模式下write数据会怎么样可能只写入部分数据需关注返回值提及注册OP_WRITE重新调度ByteBuffer和DirectBuffer区别堆内与堆外内存堆外避免拷贝但分配回收更慢说明堆外内存适合长生命周期、高并发场景一个容易被面试官深挖的点是“NIO是IO多路复用具体是select还是epoll”Java NIO在Linux上默认用epoll但老的JDK版本可能用的是select模型可通过-Djava.nio.channels.spi.SelectorProvider指定。另外**Java NIO的SelectableChannel注册事件和操作系统的事件模型有关系比如EPollSelectorProvider的坑文件描述符超过最大值会报Too many open files。**遇到类似问题先看ulimit -n的限制别急着改代码。5.2 实战中的那些坑最后分享一下我这么多年写NIO代码踩过的坑估计你也迟早会遇到。坑一忘记处理“写半包”。非阻塞模式下channel.write(buffer)不一定能把Buffer里的数据一次性写完可能只写了一半。如果你直接丢弃剩余数据客户端就会收到半截消息。正确做法是如果buffer.hasRemaining()为true就把这个Channel注册到Selector的OP_WRITE事件上等可写时继续写。写一个writePendingData()方法专门处理这种情况。坑二Buffer的position与limit不把握。尤其是从Buffer里取出数据后position已经移动如果不复位就去write数据是从position开始的而不是从0开始。很多“数据对不上”的问题都是这个原因。我个人的习惯是每次写完数据后立刻调用buffer.clear()这样下一个操作的位置永远是0状态清晰明了。坑三用一个Buffer服务多个Channel。高并发下多个Channel都会往同一个Buffer写数据换着读数据position会互相踩踏。比如A连接往里写了数据B连接还没读A又往里写B读到的内容就变成A新的数据了。工程上要么每个连接持有独立Buffer要么用Buffer池类似Netty的PooledByteBufAllocator。最不济也要保证单线程里一个Buffer只给一个Channel用。坑四SocketChannel关闭时忘记取消SelectionKey。如果键不取消Selectort还会持有它下次select还会处理这个已经closed的通道导致CancelledKeyException。正确的关闭姿势是key.cancel(); channel.close();顺序不要反先取消键再关通道防止清理道上还是注册状态。坑五TCP粘包和拆包。NIO按Buffer块读取如果一个消息被拆成两个Buffer里的半段或者多个消息合到一个Buffer里你直接new String就会得到乱七八糟的文本。这跟NIO本身无关但在NIO下特别容易出现因为一个Channel的读取可能来自多次网络包。处理办法就是在应用层定义消息边界比如固定长度、分隔符、或者带长度的协议头。Netty对这块封装得很好原生的NIO你得自己维护ByteBuf拼接这是个不小的工程。坑六不理解Selector.selectedKeys()中“selected”的含义。不少网上Demo在每次select后直接用selector.selectedKeys().iterator()遍历但不remove代码能跑、但高并发下就是会出奇怪的问题。前面已经强调过每次处理一个key之后必须从selectedKeys中移除。我也见过一种写法遍历结尾直接selectedKeys.clear()这也是可以的。关键是不要让旧key残留。这些坑踩多了你就明白为什么有这么多人推荐直接用Netty了。不是说原生NIO不值得学恰恰相反你只有理解了Buffer、Channel、Selector这些基础的运作机制才能用好Netty。Netty本身也是在这些概念上包装出来的。最后再分享一个小技巧如果你在排查NIO相关的问题时第一反应应该永远是“看日志里有没有CancelledKeyException、ClosedChannelException、NotYetConnectedException”这三兄弟基本覆盖了90%的NIO低级错误。调优的时候先用jstat和jstack看看GC和线程栈别动不动就怀疑代码性能。NIO这玩意儿逻辑理顺了坑踩平了剩下就是熟练度的问题。希望这篇能帮你省下一些试错时间。