NIO支撑高并发的关键在于非阻塞I/O与Selector多路复用：单线程可轮询千级Channel，避免线程阻塞；需正确配置非阻塞模式、手动管理SelectionKey事件、精准控制ByteBuffer读写边界、区分适用场景——仅在连接数远超线程数时优势显著。
为什么NIO能撑起高并发服务器？关键在非阻塞 + Selector 多路复用
传统 InputStream.read() 一调用就卡住线程，直到数据来或超时；而 NIO 的 SocketChannel.read(buffer) 在没数据时立刻返回 0 或抛 IOException（取决于配置），线程不会空等。配合 Selector，一个线程就能轮询成百上千个 Channel 的就绪状态——这才是 Netty、Tomcat NIO 模式、ZooKeeper 底层能扛住万级连接的根本原因。
-
ServerSocketChannel.configureBlocking(false)必须在register()前调用，否则抛IllegalBlockingModeException -
selector.select()默认阻塞，但可传毫秒参数实现“最多等 100ms”，避免饿死其他任务 - 每个
SelectionKey需手动调用key.interestOps(...)更新关注事件，比如读完数据后想再监听写就绪，不重设就会漏事件
Buffer 的 flip/clear/rewind 不是仪式感，是真实的数据边界控制
IO 里 read(byte[]) 返回实际字节数，你直接处理数组前 n 个字节就行；NIO 的 ByteBuffer 却要自己管好“当前读到哪”“还能写多少”。flip() 不是魔法，它只是把 limit 设为当前 position、position 归零——相当于告诉缓冲区：“现在开始读，只读到刚才写入的位置”。忘了 flip()，get() 就会读到末尾全是 0；忘了 clear()，下一次 put() 可能覆盖未消费数据。
- 常见错误：
buffer.get()循环读取后没buffer.clear()，第二次read()写入失败（因position == limit） - 大文件传输慎用
allocate()，优先用allocateDirect()减少 JVM 堆压力，但注意 direct buffer 不受 GC 自动回收，需手动cleaner或依赖 finalize - 字符处理别硬套
ByteBuffer，CharsetEncoder/Decoder才是正确解码路径，否则中文乱码概率极高
FileChannel 和 FileInputStream.getChannel() 的坑：不是所有流都支持
FileInputStream.getChannel() 返回的 FileChannel 是阻塞的，且不支持 register(selector, ...) ——它压根不能进 Selector。真正能和 NIO 网络栈统一调度的，只有 SocketChannel、ServerSocketChannel、DatagramChannel 这三类。文件操作想用 NIO，得走 RandomAccessFile.getChannel() 或 Files.newByteChannel()，且注意 transferTo()/transferFrom() 在 Linux 下可触发 zero-copy，但 Windows 不支持。
-
FileChannel.map()映射大文件时，若 JVM 堆外内存不足，会抛OutOfMemoryError: Map failed，不是堆内存溢出 -
FileChannel.lock()是 JVM 进程级锁，跨 JVM 不生效；分布式场景必须换 ZooKeeper 或 Redis 实现 - 用
AsynchronousFileChannel（AIO）替代 NIO 文件操作？注意 JDK 8+ 才稳定，且 Windows 上底层仍是线程池模拟，并非真异步
什么时候该坚持用传统 IO？别为了“新”而换
如果你只是读写单个大文件（比如导出 500MB Excel）、做本地日志归档、或写个 CLI 工具解析配置——用 Files.readAllBytes() 或 BufferedReader 更直白，代码少一半，出错率更低。NIO 的优势只在“连接数远大于线程数”的场景才兑现，强行套用反而引入缓冲区管理、事件循环、半包粘包处理等复杂度。
立即学习“Java免费学习笔记（深入）”；
- Web 后端 API 接口，QPS
- 实时聊天室、IoT 设备长连接网关、高频行情推送服务：NIO（或 Netty 封装）是事实标准
- 混合场景（如 HTTP + WebSocket 共存）：别自己手写 Selector 主循环，直接上 Netty，它已帮你踩平了 epoll/kqueue 兼容性、空轮询、OP_WRITE 触发时机等所有坑
buffer.flip() 容易，维持整个连接生命周期中上百个 Buffer 的状态一致，才是真正的门槛。 
