Java NIO思维导图应聚焦“为什么用”和“怎么组织”，以Buffer、Channel、Selector三大组件为骨架，明确状态管理、非阻塞机制、多路复用原理、典型误区及BIO/NIO/AIO对比。
Java NIO 的思维导图不需要面面俱到，重点抓住“为什么用”和“怎么组织”两个主线，就能画出清晰、实用、面试可用的结构。核心就围绕三大组件展开，再补上关键特性、典型误区和适用边界。
以三大组件为骨架搭主干
这是NIO最不可绕开的底层逻辑，所有操作都基于它们协作：
- Buffer（缓冲区）：不是普通数组，是带状态的对象。必须标清四个属性关系——mark ≤ position ≤ limit ≤ capacity；强调flip()、clear()、compact()三个关键状态切换动作的作用和触发时机
- Channel（通道）：区分FileChannel（仅阻塞）、SocketChannel/ServerSocketChannel（可非阻塞）；注明它不能直接操作数据，只负责“搬运”，读写必须配合 Buffer
- Selector（选择器）：唯一支持多路复用的组件。画出注册流程（open → configureBlocking(false) → register）、事件类型（OP_ACCEPT / OP_READ / OP_WRITE）、以及select()返回后如何遍历selectedKeys()并处理
补上非阻塞与多路复用的本质逻辑
避免把 NIO 简单等同于“不卡线程”，要体现系统级协作机制：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 非阻塞 ≠ 完全不等：调用read()或write()时若无数据/无法写入，立即返回0或-1，线程不挂起，但后续仍需轮询或等待事件通知
- 多路复用依赖操作系统：Selector 底层调用的是 epoll（Linux）或 kqueue（macOS），不是 Java 自己轮询；强调一个线程通过单个 Selector 可管理成千上万连接的关键前提——所有 Channel 必须设为非阻塞模式
- 同步 vs 异步：NIO 是同步非阻塞（数据从内核拷贝到用户 Buffer 仍需线程参与），别和 AIO 的“内核完成回调”混淆
标出典型使用边界和常见坑
思维导图的价值之一是帮人避开误用，这部分建议用⚠️符号突出：
立即学习“Java免费学习笔记（深入）”；
- 不适合低并发场景：连接数少于百级时，BIO 的线程模型反而更直观、调试更简单；NIO 的状态管理、Buffer 复用、事件分发反而增加复杂度
- Buffer 忘记 flip 就读不到数据，忘记 clear 就写不进新内容——这两个是最高频 Bug，导图中可加红色标注
- Selector 的 key 集合需要手动 remove：遍历selectedKeys()后，必须调用iterator.remove()，否则下次 select 会重复触发已处理事件
- OP_WRITE 要慎用：它几乎总是就绪，除非发送缓冲区满；一般只在写半包或写失败后才注册，写完立刻取消，否则会持续唤醒浪费 CPU
附简明对比锚点（一页纸够用）
在导图角落加个小表格，横向对比 BIO/NIO/AIO 的关键维度，比如：
- 线程模型：BIO（1 连接 1 线程）、NIO（1 线程 + Selector 管理 N 连接）、AIO（内核线程池 + 回调）
- 数据拷贝阶段是否阻塞：BIO（两次都阻塞）、NIO（系统调用不阻塞，但 copy 到用户 Buffer 时仍同步）、AIO（全程异步，内核完成全部拷贝后通知）
- JDK 支持：BIO（全版本）、NIO（1.4+）、AIO（7+，Windows/Linux 支持较好，macOS 有兼容问题）
