做Java开发这些年IO模型一直是绕不开的话题。面试官爱问线上问题排查也绕不过一说到BIO和NIO很多人能背出“阻塞和非阻塞”这两句话但要真的讲透缓冲区、通道、选择器、线程模型、内核态和用户态切换……每一层都是坑。这篇文章不打算照搬教科书而是围绕我在模拟项目X里排查高并发服务时踩过的坑把BIO和NIO从设计思路到落地代码完整拆一遍。适合正在准备面试、刚开始学网络编程或者是被线上连接数打崩过的后端开发者。1. 内容整体设计与思路拆解从一次read说起1.1 一次read调用数据怎么从网卡到用户空间很多人把IO理解成“调一个read函数数据就拿到了”这个理解在应用层没错但一分析阻塞视角就必须往下放。一次读操作大体经历这些阶段程序发起read系统调用数据从网卡到达内核缓冲区内核再把数据拷贝到用户空间。BIO和NIO的分歧主要发生在第二阶段当内核缓冲区没有数据或数据不完整时调用线程要不要挂起等待。这句话是整个IO模型的钥匙。BIO选择挂起线程线程被阻塞在那里直到内核告诉它“数据准备好了”NIO选择不挂起系统调用立即返回用户线程可以继续干别的事至于数据什么时候到由后续的轮询或事件通知来判断。理解了这点再去看线程模型、性能差异、代码写法所有的问题都能串起来。还有一点很多人忽略阻塞不单是业务线程等待真正影响性能的是线程在等待期间占用的资源。一个线程通常占用独立栈空间默认大小按不同系统的设置可能从MB级别起步。线程数量多了光是内存开销就非常可观更不要说线程上下文切换的CPU成本。所以BIO和NIO之争本质上是在争“用最少线程处理最多连接”。1.2 餐厅点餐类比一个服务员盯一桌还是一个服务员管一片我用餐厅点餐来解释可能更好理解。传统BIO的服务方式是给每一桌客人都配一个专属服务员。服务员站在桌边客人不点完菜他就不能走哪怕客人翻菜单翻十分钟他也得陪着等。这样做的优点是简单服务员思路很直一桌一盯不会乱缺点是只要餐厅客人多服务员数量就得跟着涨桌椅板凳可能不够服务员之间还会互相挤餐厅老板很快会发现成本控制不住。NIO的服务方式则是另一种做法一个服务员同时看好几桌客人要点菜的时候举手示意服务员看到示意才过来没示意的时候就忙别的桌。这个“举手示意”的机制在Java NIO里就是Selector选择器。客人就是连接服务员就是处理线程举手动作就是可读或可写事件。所以NIO能用较少的服务人员覆盖大量客人核心不在于服务员的处理速度变快了而在于等待时间不再被白白占用。这个类比虽然简化了内核细节却把BIO和NIO的线程模型差异讲清楚了。实际用代码写起来BIO比NIO直观得多但NIO也并没有想象中那么神秘它只是把“等待”这个动作集中起来统一管理让真正干活的线程更聚焦。2. BIO核心细节解析与实操要点2.1 BIO标准实现连接和线程一一对应先看一段最原始的BIO服务端代码很多初学网络编程的人都写过类似逻辑ServerSocket serverSocket new ServerSocket(8080); while (true) { Socket socket serverSocket.accept(); new Thread(() - handle(socket)).start(); }这个写法最大的特点就是“来一个连接开一个线程”。accept()方法会阻塞在循环里直到有客户端连上来拿到socket之后为了让主线程继续接受下一个连接每个连接都单独扔进一个新线程处理。客户端不发数据这个线程就卡在read()上什么也做不了。如果连接很少只有几十个这套代码完全没问题逻辑简单、调试方便。但连接数一上来问题就很明显。假设一台服务器同时在线500个客户端就要起500个线程每个线程哪怕什么都不干也要占用栈空间操作系统调度这么多线程时上下文切换的开销会直接拖垮CPU。我之前帮A同学排查过一个服务连接数从一百涨到三百之后CPU不高但响应极慢jstack一看大量线程都停在java.net.SocketInputStream.read上。线程是起了但都在等数据属于典型的“线程利用率为零”的浪费。2.2 线程池只是止痛药不是根治方案既然来一个连接就开线程不行很多人会引入线程池把代码改成这样ExecutorService executor new FixedThreadPool(32); while (true) { Socket socket serverSocket.accept(); executor.submit(() - handle(socket)); }线程池确实限制了线程总数避免了无限创建线程导致的资源耗尽但它没有解决“线程被阻塞”的问题。线程池一共32个线程这32个线程如果同时被32个慢客户端的read()阻塞住后面的连接就算来了也排不进线程池只能堆积在队列里。队列一旦满了新请求直接被拒绝表现就是大量Connection refused或者等待超时。所以线程池的做法本质上是在“用排队换取存活”而不是提升并发能力。BIO的瓶颈不在线程池参数怎么调而在它的线程模型本身就是为低并发场景设计的。连接一旦做成长连接并且客户端发消息不规律很大概率会出现一组线程被少数几个慢连接拖死的情况。这里最需要理解的逻辑是线程被阻塞期间不能处理任何其他任务资源是绝对独占的这在低并发下不是问题高并发下就是灾难。2.3 BIO真正合适的场景连接数可控、读写周期短BIO也不是一无是处。我到现在仍然会在某些模块里直接用它比如内部管理系统的短连接接口、定时器上报一类的服务。这类场景连接数少、连接建立后很快完成读写就关闭非常适合BIO。它的优点非常明显代码清晰、可读性好、后续维护容易且不容易出现NIO里那些底层的缓冲区问题。另一个适合BIO的场景是“一个连接对应一个长时间操作”例如文件传输工具服务端需要针对每个连接持续处理接收完再返回。这种时候用NIO反而要把数据切分成多个事件来处理状态管理复杂度高收益很小。说白了选型要看线程数量能不能压得住。如果预估最大连接数在几十到几百且处理逻辑是请求-响应式的短连接BIO完全够用。不要为了追赶技术而强行上NIO复杂度也是成本。3. NIO核心细节解析与实操要点3.1 Channel、Buffer、Selector三件套怎么配合NIO有三个核心组件Channel、Buffer、Selector。很多人刚学时记不住关系我提供一个直观类比Channel是管道Buffer是桶Selector是管道的监控台。管道Channel负责和底层IO设备连接最常见的是SocketChannel和ServerSocketChannel。它和BIO里的Socket最大的区别是支持非阻塞模式可以注册到Selector上。数据不会像BIO那样直接读进字节数组而是先读到Buffer这个桶里再由程序从桶里取数据。所以NIO里读写数据永远绕不开Buffer而ByteBuffer是其中最常用的实现。Selector则是整个NIO的点睛之笔。它会把所有注册到自己身上的Channel统一管理程序只需要在一个死循环里调用selector.select()这个方法会返回当前有事件发生的Channel数量。事件类型大致有连接就绪、可读、可写、接收新连接。Selector从一堆Channel里挑出真正需要处理的那些避免程序对每个连接都主动去读一次。这样大量的空等待被过滤掉了一个线程可以高效处理成千上万个连接。用表格把三者的职责放在一起会更容易理解组件作用常见类型比喻Channel建立底层IO连接SocketChannel、ServerSocketChannel、FileChannel管道Buffer读写数据的临时容器ByteBuffer、CharBuffer、LongBuffer桶Selector监听多个Channel的事件Selector监控台3.2 手写一个NIO服务端Selector事件驱动的核心流程光讲概念不够我写一个可运行的NIO服务端骨架重点不是业务逻辑而是事件处理框架Selector selector Selector.open(); ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 阻塞等待事件最多等1秒 int readyCount selector.select(1000); if (readyCount 0) { continue; } SetSelectionKey selectedKeys selector.selectedKeys(); IteratorSelectionKey iter selectedKeys.iterator(); while (iter.hasNext()) { SelectionKey key iter.next(); iter.remove(); if (key.isAcceptable()) { // 有新连接通过ServerSocketChannel接收 ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel client server.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { SocketChannel client (SocketChannel) key.channel(); ByteBuffer buffer ByteBuffer.allocate(1024); int len client.read(buffer); if (len 0) { buffer.flip(); // 在这里解析buffer中的数据 } else if (len 0) { key.cancel(); client.close(); } } } }有几个细节必须注意。第一每次处理完selectedKeys()里的key一定要手动iter.remove()如果不移除下一次select()返回时这个key还会留在集合里重复处理同一事件。第二server.accept()在非阻塞模式下不会阻塞如果没有新连接会返回null但因为我们是在OP_ACCEPT事件里接收所以正常不会出现null。第三每次新建一个ByteBuffer并进行拷贝是不推荐的做法后面我会专门说复用问题。这段代码里selector.select(1000)是阻塞等待但它等待的是“任意一个注册Channel有事件”不是等待某个连接的数据。这就是NIO和BIO在阻塞上的本质区别BIO的线程阻塞在具体连接上NIO的线程阻塞在事件轮询上。等连接空闲时线程并不会被那个连接占住。3.3 ByteBuffer的读写切换position、limit、capacity一次讲通ByteBuffer对新手来说容易绕晕主要因为它有三个位置指针capacity、position、limit。capacity是容量创建后固定不变position是当前读写位置limit是读写边界。我理解它有一个很简单的规律方向决定limit。往Buffer里写数据时数据从position开始放写完后position移到末尾limit是capacity。接着要从Buffer里读数据不能直接用而要先flip()。flip()会做两件事把limit设为当前position把position归零。简而言之flip()就是把“写模式”切成“读模式”把数据范围锁定在刚才写入的这部分。读完之后如果还想继续写要调用clear()把position归零、limit恢复成capacity相当于清空整个缓冲区如果只想把已读的部分清掉保留未读的部分应该用compact()这个方法会把未读数据移到头部position设为未读数据长度limit设为capacity便于继续追加写入。我遇到过很多次问题都是因为忘记调用flip()直接从写模式去读数据结果读出来一堆空字节或者解析出乱码。还有人在循环里面反复allocate新的ByteBuffer导致大量临时对象产生GC压力非常大。正确做法是在初始化时分配一块合理大小的Buffer写完后flip()读完clear()或compact()复用。3.4 零拷贝NIO里被误用最多的优化聊NIO必然绕不过“零拷贝”。Java NIO提供了FileChannel.transferTo()和transferFrom()可以在文件与网络Socket之间直接传输数据省去了用户态和内核态之间的多次拷贝。比如下载场景传统方式要先把文件数据从内核读到用户空间再经Socket写回内核而transferTo()能让内核直接完成数据搬运。零拷贝确实能显著提升大文件传输效率但它有使用边界。transferTo()是底层系统调用的封装不同操作系统和不同文件系统下表现不一样可能实际被传输的数据量小于你传入的长度。所以使用后要判断返回值如果返回值小于请求的字节数还要循环调用剩余部分。另外它主要优化的是“文件到Socket”的路径对于小包高频传输零拷贝的优势并不明显反而可能因为系统调用的额外开销而变慢。我的建议是不要一听说零拷贝就觉得所有IO问题都能解决。绝大多数业务系统瓶颈在协议处理、线程竞争、数据库交互上而不是一次内核拷贝。真遇到大文件传输再上transferTo并做好回退逻辑。4. BIO和NIO的对比从线程模型到真实选型4.1 一张表看懂关键差异把两个模型的核心差异列成一张对比表选型的时候可以直接对照对比项BIONIO阻塞方式阻塞式非阻塞式并发模型一个连接一个线程一个线程管理多个连接核心组件Socket、ServerSocketChannel、Buffer、Selector线程占用高空闲连接也占线程低空闲连接不占线程编程复杂度低较高需要处理事件状态吞吐量低受线程数限制高适合高并发适用场景连接数少、短连接连接数多、长连接排查难度相对直观jstack能看阻塞事件逻辑复杂问题更隐蔽这张表只是参考不是绝对标准。BIO在高并发下并非完全不可用但要付出极大的资源代价NIO也不是万能的如果每次都把所有Channel的OP_WRITE事件注册上去随时可能触发大量虚假唤醒反而增加CPU开销。4.2 什么场景该用BIO什么场景该换NIO我在实际项目里总结出的选型标准核心是看两个维度连接数和连接的活动频率。如果连接数小比如一个服务最多几十个客户端且每个客户端建立连接后会持续发送请求用BIO就够了。线程数不会失控代码可读性又好出了问题也容易排查。如果连接数大比如网关、IM推送、物联网设备接入客户端成千上万但大部分时间都在空等这时必须用NIO。空等连接不消耗线程是NIO最宝贵的特性。再补充一种情况连接数不大但单连接里数据流量很大比如文件传输、视频流这种场景用BIO同样可行因为每个线程都在稳定干活没有太多浪费。反而NIO的异步事件处理要维护传输进度、缓冲区分片复杂度成倍增加。选型要看瓶颈在“连接数量”还是“处理速度”不要人云亦云。4.3 别急着上NIO成本与复杂度也要算清楚NIO最大的成本不是代码本身而是状态管理。BIO的代码是线性的读数据、处理、写结果清清楚楚。NIO的代码往往是事件驱动的同一个连接的数据可能分多次到达你需要维护一个连接上下文把半包数据留在缓冲区等后续数据来了一起处理。加个协议解析比如判断消息是否完整NIO的复杂度立刻上一个台阶。很多业务团队从BIO改NIO第一个月都在跟粘包、半包、缓冲区扩容较劲。如果只是想把并发数撑上去又不想维持这么高的复杂度可以考虑在Java层面先引入Netty大多数NIO的底层细节已经被它包装好了。但我仍然建议所有做服务端的人哪怕不用Netty也至少手写一遍原生NIO服务端。只有手写过一遍你才能真正理解Netty里的EventLoop、ChannelHandler、ByteBuf这些概念到底解决了什么问题。5. 常见问题与排查技巧实录5.1 线上服务卡死应该从哪里开始查我之前在模拟项目X里遇到过一个“服务偶尔卡住几秒”的问题。一开始大家都怀疑数据库慢查询但排查后数据库那边毫无压力。后来我把线程dump下来发现大量线程卡在socketRead0这个本地方法上这就是BIO的典型阻塞现场。阻塞IO的线程栈信息往往很清晰直接指向具体端口和业务代码比较适合快速定位。如果看到大量线程都停在select或poll方法上则说明程序用的是NIO单线程正在等待事件。这种等待是正常的不一定是故障。真正需要警惕的是CPU占用极高同时线程栈里频繁出现select这多半是空轮询或事件风暴。排查IO问题有个基础顺序先top -H看哪个线程消耗CPU高再jstack拿到线程栈顺着栈里的Socket/Channel类名和行号找对应代码。千万不要在一开始就盯着GC日志很多时候GC压力是线程阻塞导致请求堆积后引发的间接结果。5.2 NIO空轮询导致CPU飙高怎么处理NIO的Selector.select()有一个众所周知的坑在某些内核版本下即使没有事件发生select()也可能立即返回0导致循环里的while(true)变成空转CPU占用直接打满。这种现象在JDK早期版本里出现过虽然高版本有所改善但高负载下依然可能复现。处理空轮询的通用办法是记录select()返回0的次数。如果连续多次返回0说明可能进入了空轮询状态不再继续依赖这个Selector而是重建一个Selector并把所有已经注册的Channel重新注册到新Selector上。Netty内部也做了类似处理它会统计连续空轮询的次数超过阈值就重建Selector避免CPU被白白消耗。我个人的实践是除了做空轮询计数还会给select()设置一个超时时间例如传一个1到10毫秒的超时参数。这样即使底层发生了空轮询线程至少每隔一小段时间就会被唤醒一次CPU空转的概率会低很多。当然这只能缓解不能根治真正要根治还是得在关键依赖上做好Selector重建机制。5.3 ByteBuffer使用不当造成的内存和GC隐患NIO里最常见的低级错误是每次处理数据都新建ByteBuffer.allocate()。这个方法在堆内分配如果并发上来短生命周期对象剧增GC会非常频繁。有人以为用allocateDirect()就好直接内存虽然能减少一次内核拷贝但它不受堆大小控制创建和释放成本更高如果频繁分配再释放很容易触发堆外内存溢出。我看到的不少线上OOM其实就是DirectByteBuffer大量堆积造成的。某个系统为了追求高性能每个请求都新建一个直接缓冲区结果堆正常程序却报OutOfMemoryError: Direct buffer memory。排查时用NMT或JMX查看direct内存占用就能看到明显的持续上涨。正确做法是复用Buffer。比如在事件循环里每个连接维护一个专用的ByteBuffer读写完成后clear()重新使用。如果你处理的协议消息长度差异很大可以在一开始分配一个中等大小的Buffer不够再扩容扩容后把旧数据拷进去。Buffer不是越大越好太大浪费内存太小频繁扩容影响性能。5.4 慢客户端拖垮整个服务的排查思路BIO场景下慢客户端是一个经典问题。早期通信框架里一个连接读数据时会同步等待如果客户端迟迟不读取服务端的响应服务端写缓冲区会被慢慢填满写操作变成阻塞进而占用线程。当这样的慢连接超过线程池数量服务端整个进程都会受到影响。排查慢客户端问题我一般先在操作系统层面看发送和接收队列netstat -anp或者ss -anp如果发现某个连接状态异常或发送队列特别大基本就能定位到慢客户端。再进一步看服务端日志里有没有某个连接长时间占用某条线程找到对应IP后可以在网关或接入层限制连接空闲时间。在NIO模型下慢客户端的影响要小很多因为一个线程不会为一个连接无限等待。但写数据时仍然可能出现问题如果客户端读得慢服务端写缓冲区会满OP_WRITE事件频繁触发导致处理线程一直处理同一个连接的写事件形成不公平的资源占用。这时候要设置每个连接可写字节数或者限制事件处理次数把机会让给其他连接。最后说一点我自己的体会。刚学IO模型时我也试图死记硬背BIO和NIO的区别但真正理解之后才发现所有的设计都是为了解决同一个问题不要让宝贵的线程资源浪费在等待上。BIO用线程换简单NIO用复杂度换并发没有绝对的好坏只有合不合适的业务场景。如果你现在还在为阻塞、连接数、线程池头疼可以先从手写一个BIO服务端开始观察它撑不住时的线程状态再切换成NIO重写一遍亲自感受两者在资源占用上的差异。这个对比做完你基本就掌握了服务端高并发设计的底层直觉。
做Java开发这些年IO模型一直是绕不开的话题。面试官爱问线上问题排查也绕不过一说到BIO和NIO很多人能背出“阻塞和非阻塞”这两句话但要真的讲透缓冲区、通道、选择器、线程模型、内核态和用户态切换……每一层都是坑。这篇文章不打算照搬教科书而是围绕我在模拟项目X里排查高并发服务时踩过的坑把BIO和NIO从设计思路到落地代码完整拆一遍。适合正在准备面试、刚开始学网络编程或者是被线上连接数打崩过的后端开发者。1. 内容整体设计与思路拆解从一次read说起1.1 一次read调用数据怎么从网卡到用户空间很多人把IO理解成“调一个read函数数据就拿到了”这个理解在应用层没错但一分析阻塞视角就必须往下放。一次读操作大体经历这些阶段程序发起read系统调用数据从网卡到达内核缓冲区内核再把数据拷贝到用户空间。BIO和NIO的分歧主要发生在第二阶段当内核缓冲区没有数据或数据不完整时调用线程要不要挂起等待。这句话是整个IO模型的钥匙。BIO选择挂起线程线程被阻塞在那里直到内核告诉它“数据准备好了”NIO选择不挂起系统调用立即返回用户线程可以继续干别的事至于数据什么时候到由后续的轮询或事件通知来判断。理解了这点再去看线程模型、性能差异、代码写法所有的问题都能串起来。还有一点很多人忽略阻塞不单是业务线程等待真正影响性能的是线程在等待期间占用的资源。一个线程通常占用独立栈空间默认大小按不同系统的设置可能从MB级别起步。线程数量多了光是内存开销就非常可观更不要说线程上下文切换的CPU成本。所以BIO和NIO之争本质上是在争“用最少线程处理最多连接”。1.2 餐厅点餐类比一个服务员盯一桌还是一个服务员管一片我用餐厅点餐来解释可能更好理解。传统BIO的服务方式是给每一桌客人都配一个专属服务员。服务员站在桌边客人不点完菜他就不能走哪怕客人翻菜单翻十分钟他也得陪着等。这样做的优点是简单服务员思路很直一桌一盯不会乱缺点是只要餐厅客人多服务员数量就得跟着涨桌椅板凳可能不够服务员之间还会互相挤餐厅老板很快会发现成本控制不住。NIO的服务方式则是另一种做法一个服务员同时看好几桌客人要点菜的时候举手示意服务员看到示意才过来没示意的时候就忙别的桌。这个“举手示意”的机制在Java NIO里就是Selector选择器。客人就是连接服务员就是处理线程举手动作就是可读或可写事件。所以NIO能用较少的服务人员覆盖大量客人核心不在于服务员的处理速度变快了而在于等待时间不再被白白占用。这个类比虽然简化了内核细节却把BIO和NIO的线程模型差异讲清楚了。实际用代码写起来BIO比NIO直观得多但NIO也并没有想象中那么神秘它只是把“等待”这个动作集中起来统一管理让真正干活的线程更聚焦。2. BIO核心细节解析与实操要点2.1 BIO标准实现连接和线程一一对应先看一段最原始的BIO服务端代码很多初学网络编程的人都写过类似逻辑ServerSocket serverSocket new ServerSocket(8080); while (true) { Socket socket serverSocket.accept(); new Thread(() - handle(socket)).start(); }这个写法最大的特点就是“来一个连接开一个线程”。accept()方法会阻塞在循环里直到有客户端连上来拿到socket之后为了让主线程继续接受下一个连接每个连接都单独扔进一个新线程处理。客户端不发数据这个线程就卡在read()上什么也做不了。如果连接很少只有几十个这套代码完全没问题逻辑简单、调试方便。但连接数一上来问题就很明显。假设一台服务器同时在线500个客户端就要起500个线程每个线程哪怕什么都不干也要占用栈空间操作系统调度这么多线程时上下文切换的开销会直接拖垮CPU。我之前帮A同学排查过一个服务连接数从一百涨到三百之后CPU不高但响应极慢jstack一看大量线程都停在java.net.SocketInputStream.read上。线程是起了但都在等数据属于典型的“线程利用率为零”的浪费。2.2 线程池只是止痛药不是根治方案既然来一个连接就开线程不行很多人会引入线程池把代码改成这样ExecutorService executor new FixedThreadPool(32); while (true) { Socket socket serverSocket.accept(); executor.submit(() - handle(socket)); }线程池确实限制了线程总数避免了无限创建线程导致的资源耗尽但它没有解决“线程被阻塞”的问题。线程池一共32个线程这32个线程如果同时被32个慢客户端的read()阻塞住后面的连接就算来了也排不进线程池只能堆积在队列里。队列一旦满了新请求直接被拒绝表现就是大量Connection refused或者等待超时。所以线程池的做法本质上是在“用排队换取存活”而不是提升并发能力。BIO的瓶颈不在线程池参数怎么调而在它的线程模型本身就是为低并发场景设计的。连接一旦做成长连接并且客户端发消息不规律很大概率会出现一组线程被少数几个慢连接拖死的情况。这里最需要理解的逻辑是线程被阻塞期间不能处理任何其他任务资源是绝对独占的这在低并发下不是问题高并发下就是灾难。2.3 BIO真正合适的场景连接数可控、读写周期短BIO也不是一无是处。我到现在仍然会在某些模块里直接用它比如内部管理系统的短连接接口、定时器上报一类的服务。这类场景连接数少、连接建立后很快完成读写就关闭非常适合BIO。它的优点非常明显代码清晰、可读性好、后续维护容易且不容易出现NIO里那些底层的缓冲区问题。另一个适合BIO的场景是“一个连接对应一个长时间操作”例如文件传输工具服务端需要针对每个连接持续处理接收完再返回。这种时候用NIO反而要把数据切分成多个事件来处理状态管理复杂度高收益很小。说白了选型要看线程数量能不能压得住。如果预估最大连接数在几十到几百且处理逻辑是请求-响应式的短连接BIO完全够用。不要为了追赶技术而强行上NIO复杂度也是成本。3. NIO核心细节解析与实操要点3.1 Channel、Buffer、Selector三件套怎么配合NIO有三个核心组件Channel、Buffer、Selector。很多人刚学时记不住关系我提供一个直观类比Channel是管道Buffer是桶Selector是管道的监控台。管道Channel负责和底层IO设备连接最常见的是SocketChannel和ServerSocketChannel。它和BIO里的Socket最大的区别是支持非阻塞模式可以注册到Selector上。数据不会像BIO那样直接读进字节数组而是先读到Buffer这个桶里再由程序从桶里取数据。所以NIO里读写数据永远绕不开Buffer而ByteBuffer是其中最常用的实现。Selector则是整个NIO的点睛之笔。它会把所有注册到自己身上的Channel统一管理程序只需要在一个死循环里调用selector.select()这个方法会返回当前有事件发生的Channel数量。事件类型大致有连接就绪、可读、可写、接收新连接。Selector从一堆Channel里挑出真正需要处理的那些避免程序对每个连接都主动去读一次。这样大量的空等待被过滤掉了一个线程可以高效处理成千上万个连接。用表格把三者的职责放在一起会更容易理解组件作用常见类型比喻Channel建立底层IO连接SocketChannel、ServerSocketChannel、FileChannel管道Buffer读写数据的临时容器ByteBuffer、CharBuffer、LongBuffer桶Selector监听多个Channel的事件Selector监控台3.2 手写一个NIO服务端Selector事件驱动的核心流程光讲概念不够我写一个可运行的NIO服务端骨架重点不是业务逻辑而是事件处理框架Selector selector Selector.open(); ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 阻塞等待事件最多等1秒 int readyCount selector.select(1000); if (readyCount 0) { continue; } SetSelectionKey selectedKeys selector.selectedKeys(); IteratorSelectionKey iter selectedKeys.iterator(); while (iter.hasNext()) { SelectionKey key iter.next(); iter.remove(); if (key.isAcceptable()) { // 有新连接通过ServerSocketChannel接收 ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel client server.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { SocketChannel client (SocketChannel) key.channel(); ByteBuffer buffer ByteBuffer.allocate(1024); int len client.read(buffer); if (len 0) { buffer.flip(); // 在这里解析buffer中的数据 } else if (len 0) { key.cancel(); client.close(); } } } }有几个细节必须注意。第一每次处理完selectedKeys()里的key一定要手动iter.remove()如果不移除下一次select()返回时这个key还会留在集合里重复处理同一事件。第二server.accept()在非阻塞模式下不会阻塞如果没有新连接会返回null但因为我们是在OP_ACCEPT事件里接收所以正常不会出现null。第三每次新建一个ByteBuffer并进行拷贝是不推荐的做法后面我会专门说复用问题。这段代码里selector.select(1000)是阻塞等待但它等待的是“任意一个注册Channel有事件”不是等待某个连接的数据。这就是NIO和BIO在阻塞上的本质区别BIO的线程阻塞在具体连接上NIO的线程阻塞在事件轮询上。等连接空闲时线程并不会被那个连接占住。3.3 ByteBuffer的读写切换position、limit、capacity一次讲通ByteBuffer对新手来说容易绕晕主要因为它有三个位置指针capacity、position、limit。capacity是容量创建后固定不变position是当前读写位置limit是读写边界。我理解它有一个很简单的规律方向决定limit。往Buffer里写数据时数据从position开始放写完后position移到末尾limit是capacity。接着要从Buffer里读数据不能直接用而要先flip()。flip()会做两件事把limit设为当前position把position归零。简而言之flip()就是把“写模式”切成“读模式”把数据范围锁定在刚才写入的这部分。读完之后如果还想继续写要调用clear()把position归零、limit恢复成capacity相当于清空整个缓冲区如果只想把已读的部分清掉保留未读的部分应该用compact()这个方法会把未读数据移到头部position设为未读数据长度limit设为capacity便于继续追加写入。我遇到过很多次问题都是因为忘记调用flip()直接从写模式去读数据结果读出来一堆空字节或者解析出乱码。还有人在循环里面反复allocate新的ByteBuffer导致大量临时对象产生GC压力非常大。正确做法是在初始化时分配一块合理大小的Buffer写完后flip()读完clear()或compact()复用。3.4 零拷贝NIO里被误用最多的优化聊NIO必然绕不过“零拷贝”。Java NIO提供了FileChannel.transferTo()和transferFrom()可以在文件与网络Socket之间直接传输数据省去了用户态和内核态之间的多次拷贝。比如下载场景传统方式要先把文件数据从内核读到用户空间再经Socket写回内核而transferTo()能让内核直接完成数据搬运。零拷贝确实能显著提升大文件传输效率但它有使用边界。transferTo()是底层系统调用的封装不同操作系统和不同文件系统下表现不一样可能实际被传输的数据量小于你传入的长度。所以使用后要判断返回值如果返回值小于请求的字节数还要循环调用剩余部分。另外它主要优化的是“文件到Socket”的路径对于小包高频传输零拷贝的优势并不明显反而可能因为系统调用的额外开销而变慢。我的建议是不要一听说零拷贝就觉得所有IO问题都能解决。绝大多数业务系统瓶颈在协议处理、线程竞争、数据库交互上而不是一次内核拷贝。真遇到大文件传输再上transferTo并做好回退逻辑。4. BIO和NIO的对比从线程模型到真实选型4.1 一张表看懂关键差异把两个模型的核心差异列成一张对比表选型的时候可以直接对照对比项BIONIO阻塞方式阻塞式非阻塞式并发模型一个连接一个线程一个线程管理多个连接核心组件Socket、ServerSocketChannel、Buffer、Selector线程占用高空闲连接也占线程低空闲连接不占线程编程复杂度低较高需要处理事件状态吞吐量低受线程数限制高适合高并发适用场景连接数少、短连接连接数多、长连接排查难度相对直观jstack能看阻塞事件逻辑复杂问题更隐蔽这张表只是参考不是绝对标准。BIO在高并发下并非完全不可用但要付出极大的资源代价NIO也不是万能的如果每次都把所有Channel的OP_WRITE事件注册上去随时可能触发大量虚假唤醒反而增加CPU开销。4.2 什么场景该用BIO什么场景该换NIO我在实际项目里总结出的选型标准核心是看两个维度连接数和连接的活动频率。如果连接数小比如一个服务最多几十个客户端且每个客户端建立连接后会持续发送请求用BIO就够了。线程数不会失控代码可读性又好出了问题也容易排查。如果连接数大比如网关、IM推送、物联网设备接入客户端成千上万但大部分时间都在空等这时必须用NIO。空等连接不消耗线程是NIO最宝贵的特性。再补充一种情况连接数不大但单连接里数据流量很大比如文件传输、视频流这种场景用BIO同样可行因为每个线程都在稳定干活没有太多浪费。反而NIO的异步事件处理要维护传输进度、缓冲区分片复杂度成倍增加。选型要看瓶颈在“连接数量”还是“处理速度”不要人云亦云。4.3 别急着上NIO成本与复杂度也要算清楚NIO最大的成本不是代码本身而是状态管理。BIO的代码是线性的读数据、处理、写结果清清楚楚。NIO的代码往往是事件驱动的同一个连接的数据可能分多次到达你需要维护一个连接上下文把半包数据留在缓冲区等后续数据来了一起处理。加个协议解析比如判断消息是否完整NIO的复杂度立刻上一个台阶。很多业务团队从BIO改NIO第一个月都在跟粘包、半包、缓冲区扩容较劲。如果只是想把并发数撑上去又不想维持这么高的复杂度可以考虑在Java层面先引入Netty大多数NIO的底层细节已经被它包装好了。但我仍然建议所有做服务端的人哪怕不用Netty也至少手写一遍原生NIO服务端。只有手写过一遍你才能真正理解Netty里的EventLoop、ChannelHandler、ByteBuf这些概念到底解决了什么问题。5. 常见问题与排查技巧实录5.1 线上服务卡死应该从哪里开始查我之前在模拟项目X里遇到过一个“服务偶尔卡住几秒”的问题。一开始大家都怀疑数据库慢查询但排查后数据库那边毫无压力。后来我把线程dump下来发现大量线程卡在socketRead0这个本地方法上这就是BIO的典型阻塞现场。阻塞IO的线程栈信息往往很清晰直接指向具体端口和业务代码比较适合快速定位。如果看到大量线程都停在select或poll方法上则说明程序用的是NIO单线程正在等待事件。这种等待是正常的不一定是故障。真正需要警惕的是CPU占用极高同时线程栈里频繁出现select这多半是空轮询或事件风暴。排查IO问题有个基础顺序先top -H看哪个线程消耗CPU高再jstack拿到线程栈顺着栈里的Socket/Channel类名和行号找对应代码。千万不要在一开始就盯着GC日志很多时候GC压力是线程阻塞导致请求堆积后引发的间接结果。5.2 NIO空轮询导致CPU飙高怎么处理NIO的Selector.select()有一个众所周知的坑在某些内核版本下即使没有事件发生select()也可能立即返回0导致循环里的while(true)变成空转CPU占用直接打满。这种现象在JDK早期版本里出现过虽然高版本有所改善但高负载下依然可能复现。处理空轮询的通用办法是记录select()返回0的次数。如果连续多次返回0说明可能进入了空轮询状态不再继续依赖这个Selector而是重建一个Selector并把所有已经注册的Channel重新注册到新Selector上。Netty内部也做了类似处理它会统计连续空轮询的次数超过阈值就重建Selector避免CPU被白白消耗。我个人的实践是除了做空轮询计数还会给select()设置一个超时时间例如传一个1到10毫秒的超时参数。这样即使底层发生了空轮询线程至少每隔一小段时间就会被唤醒一次CPU空转的概率会低很多。当然这只能缓解不能根治真正要根治还是得在关键依赖上做好Selector重建机制。5.3 ByteBuffer使用不当造成的内存和GC隐患NIO里最常见的低级错误是每次处理数据都新建ByteBuffer.allocate()。这个方法在堆内分配如果并发上来短生命周期对象剧增GC会非常频繁。有人以为用allocateDirect()就好直接内存虽然能减少一次内核拷贝但它不受堆大小控制创建和释放成本更高如果频繁分配再释放很容易触发堆外内存溢出。我看到的不少线上OOM其实就是DirectByteBuffer大量堆积造成的。某个系统为了追求高性能每个请求都新建一个直接缓冲区结果堆正常程序却报OutOfMemoryError: Direct buffer memory。排查时用NMT或JMX查看direct内存占用就能看到明显的持续上涨。正确做法是复用Buffer。比如在事件循环里每个连接维护一个专用的ByteBuffer读写完成后clear()重新使用。如果你处理的协议消息长度差异很大可以在一开始分配一个中等大小的Buffer不够再扩容扩容后把旧数据拷进去。Buffer不是越大越好太大浪费内存太小频繁扩容影响性能。5.4 慢客户端拖垮整个服务的排查思路BIO场景下慢客户端是一个经典问题。早期通信框架里一个连接读数据时会同步等待如果客户端迟迟不读取服务端的响应服务端写缓冲区会被慢慢填满写操作变成阻塞进而占用线程。当这样的慢连接超过线程池数量服务端整个进程都会受到影响。排查慢客户端问题我一般先在操作系统层面看发送和接收队列netstat -anp或者ss -anp如果发现某个连接状态异常或发送队列特别大基本就能定位到慢客户端。再进一步看服务端日志里有没有某个连接长时间占用某条线程找到对应IP后可以在网关或接入层限制连接空闲时间。在NIO模型下慢客户端的影响要小很多因为一个线程不会为一个连接无限等待。但写数据时仍然可能出现问题如果客户端读得慢服务端写缓冲区会满OP_WRITE事件频繁触发导致处理线程一直处理同一个连接的写事件形成不公平的资源占用。这时候要设置每个连接可写字节数或者限制事件处理次数把机会让给其他连接。最后说一点我自己的体会。刚学IO模型时我也试图死记硬背BIO和NIO的区别但真正理解之后才发现所有的设计都是为了解决同一个问题不要让宝贵的线程资源浪费在等待上。BIO用线程换简单NIO用复杂度换并发没有绝对的好坏只有合不合适的业务场景。如果你现在还在为阻塞、连接数、线程池头疼可以先从手写一个BIO服务端开始观察它撑不住时的线程状态再切换成NIO重写一遍亲自感受两者在资源占用上的差异。这个对比做完你基本就掌握了服务端高并发设计的底层直觉。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
