java nio在微服务中实现轻量级通信，核心是以非阻塞i/o替代bio的“一连接一线程”模式，通过channel+buffer+selector构建高并发低开销网络交互能力，但不提供服务发现等高级功能，仅作为底层通信骨架。
Java NIO 在微服务中实现轻量级通信，核心是用非阻塞 I/O 替代传统 BIO 的“一连接一线程”模式，避免线程资源爆炸，同时通过 Channel + Buffer + Selector 构建低开销、高并发的网络交互能力。它不直接提供服务发现、负载均衡或序列化等微服务必需能力，但可作为底层通信骨架，支撑自研或轻量框架的高效数据传输。
用 NIO 构建基础通信通道
NIO 的 SocketChannel 和 ServerSocketChannel 是微服务间点对点通信的底层载体。服务提供方启动非阻塞 ServerSocketChannel，注册到 Selector 监听 OP_ACCEPT；调用方用非阻塞 SocketChannel 发起连接并注册 OP_READ/OP_WRITE。所有读写都经 ByteBuffer 中转，无需为每个连接分配独立线程，单个 EventLoop 线程就能管理成百上千连接。
- ServerSocketChannel 必须调用 configureBlocking(false) 才能注册到 Selector
- 每次 read() 前需确保 buffer 处于写模式（clear 或 compact），read() 后调用 flip() 切换读模式
- write() 可能未一次性写完，需检查返回值并循环处理，或注册 OP_WRITE 事件等待可写
集成简单协议与编解码逻辑
微服务通信需要结构化数据交换，NIO 本身不定义协议，但可在 Channel 上叠加轻量协议层。例如采用固定头（4 字节长度）+ JSON 或 Protobuf 消息体的二进制格式：
- 读取时先解析 header 获取 body 长度，再累计读满对应字节数才触发完整消息解码
- 写入前先将业务对象序列化为 byte[]，写入 buffer 前先 putInt(长度)，再 put(内容)
- 避免在 Selector 线程中做耗时反序列化，应将完整 byte[] 提交到业务线程池处理
结合 Reactor 模式组织事件流
纯 NIO API 较底层，推荐按 Reactor 单线程模型组织：一个 Selector 线程负责 accept、read、write 事件分发，不同事件绑定不同 Handler。例如：
- OP_ACCEPT 事件由 Acceptor 处理，建立连接后注册 OP_READ 到同一 Selector
- OP_READ 事件由 DecodeHandler 接收，解析出完整消息后投递到业务线程池
- OP_WRITE 事件由 EncodeHandler 触发，仅在有响应待发且 channel 可写时执行 flush
这种职责分离让通信逻辑清晰、无锁、低延迟，适合内部服务间低开销 RPC 场景。
注意资源与异常边界
NIO 轻量不等于无管理。实际部署中必须显式控制生命周期：
- 每个 SocketChannel 关闭时，要 cancel 对应 SelectionKey，并关闭 channel
- ByteBuffer 尽量复用（如使用 ThreadLocal 或对象池），避免频繁创建堆外内存
- 捕获 ClosedChannelException、IOException 等，及时清理 key 和 channel，防止 Selector 泄漏
- 超时机制需自行实现（如记录 lastReadTime，空闲连接定期 close）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
