大白话讲Java NIO

最新推荐文章于 2025-12-02 21:20:38 发布

原创最新推荐文章于 2025-12-02 21:20:38 发布 · 659 阅读

CC 4.0 BY-SA版权

文章标签：

11 篇文章

订阅专栏

如果把Java的I/O比作餐厅服务，BIO是“笨办法”（一对一盯桌），NIO是“聪明办法”（一个经理管所有桌）——核心就是用更少的人（线程）干更多的活（处理更多连接）。接下来用生活化的比喻+可视化图表，把NIO讲得明明白白。

场景	BIO（阻塞I/O）	NIO（非阻塞I/O）
餐厅对应角色	每个餐桌配1个专属服务员（线程）	1个大堂经理（Selector）+ 若干机动服务员（少量线程）
服务方式	服务员站在餐桌旁，直到客人点餐/结账才走（线程阻塞等待I/O）	经理在前台盯着所有餐桌，只有客人举手（I/O事件就绪）才派服务员过去（线程只处理有数据的连接）
效率	100桌需要100个服务员（线程膨胀，成本高）	100桌只需要1个经理+2-3个服务员（线程复用，成本低）
适用场景	客人少、点完就走（低并发、短连接）	客人多、边吃边加菜（高并发、长连接）

BIO的问题：哪怕客人只是占着桌不点餐，服务员也得一直等，100个桌就需要100个服务员，人多了（线程多了），老板（CPU）要花大量精力协调，效率极低。

NIO的核心：经理（Selector）只盯“谁有需求”，服务员（线程）只处理有需求的桌，没人举手时经理就等着，服务员也不闲着——用极少的人搞定大量桌子。

NIO的核心就是3个东西：Selector（大堂经理）、Channel（传菜通道）、Buffer（装菜的餐盘），三者配合才能实现“聪明服务”。

Buffer就像餐厅里的餐盘——菜（数据）不能直接拿手递，必须装在餐盘里传；客人点的菜（读数据）先放餐盘，服务员端走；要给客人上菜（写数据），也得先把菜装餐盘里。

餐盘有固定大小（比如只能装10道菜）→ Buffer有capacity（容量），创建后不能改；
装菜时从第一个空位开始装→ Buffer有position（当前装菜位置），装一个菜挪一格；
装到指定位置就不能装了→ Buffer有limit（装菜上限），默认等于容量；
装完菜要递给客人，得先把餐盘“转个向”→ Buffer的flip()方法（切换为“取菜模式”），把limit设为当前装菜位置，position归0，避免拿空位置。

Channel就像餐厅里的传菜通道——连接厨房（数据源）和餐桌（程序），而且是双向的（既能从厨房把菜传到餐桌，也能把餐桌的空盘子传回厨房）；而BIO的“流”是单向的（要么只传菜，要么只收盘子）。

Selector是餐厅的大堂经理——核心工作就是盯着所有传菜通道（Channel），只处理“有动静”的通道：

三、Selector底层模型

JVM给Selector做了一层“统一外壳”，底层会调用操作系统提供的“多路复用接口”，不同OS用不同的底层模型：

操作系统	Java NIO底层使用的模型	补充说明
Linux（2.6+）	epoll（默认最优选择）	高性能核心，NIO高并发的关键依赖
Linux（2.4及前）	poll（降级选择，无epoll支持）	老系统兼容，性能一般
Windows	IOCP（I/O Completion Port）	不是select/poll/epoll，是Windows的“多路复用神器”，效率和epoll相当
macOS/BSD	kqueue	类似epoll的高效事件通知模型
其他嵌入式系统	poll（若不支持epoll/kqueue）	兼容优先，性能有限