核心是用好nio多路复用能力，避开bio线程爆炸问题：单线程通过selector管理成千上万连接，事件驱动处理op_accept、op_read、op_write；需设通道为非阻塞、正确使用bytebuffer、及时清理selectionkey，并优先选用netty等成熟框架封装细节。
核心是用好 NIO 的多路复用能力，避开 BIO 的线程爆炸问题，再结合成熟框架封装细节，避免重复造轮子。
用 Selector 实现单线程高并发
NIO 的本质优势在于一个线程能同时管理成千上万个连接。关键不是写多少代码，而是理解事件驱动的流转逻辑：注册 OP_ACCEPT → 接收新连接并设为非阻塞 → 注册 OP_READ → 数据就绪后读取 → 处理完再注册 OP_WRITE（如需响应）。注意每次 read 后要 flip() 才能正确读取缓冲区，write 后要检查是否写完，没写完得保留 OP_WRITE 直到完成。
- ServerSocketChannel 和 SocketChannel 必须 configureBlocking(false)
- Selector.select() 是阻塞调用，但只等有事件发生，不空转耗 CPU
- 处理 selectedKeys 后必须调用 key.remove() 或 iter.remove()，否则下次还会被选中
善用 DirectBuffer 和缓冲区池
堆外内存（DirectByteBuffer）能绕过 JVM 堆，配合底层零拷贝机制（如 transferTo/transferFrom），减少用户态与内核态之间的数据复制。但 DirectBuffer 不受 GC 管理，需手动清理或依赖 Cleaner，容易引发内存泄漏。高频短连接场景建议搭配缓冲区对象池（如 Netty 的 PooledByteBufAllocator），避免频繁分配释放。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- ByteBuffer.allocate() → 堆内缓冲区，适合小数据、生命周期短
- ByteBuffer.allocateDirect() → 堆外缓冲区，适合大吞吐、长连接、需零拷贝场景
- 避免在循环中反复 new ByteBuffer，尤其不要在 OP_READ 处理里每次都 allocate
选用成熟的 NIO 框架而非裸写 NIO
原生 NIO API 底层灵活但易出错：粘包/半包要自己拆解、连接超时要自己计时、异常关闭要手动清理资源、线程模型要自己编排。Netty 是目前最主流的选择，它内置 Reactor 线程模型（Boss/Worker）、内存池、编解码器、心跳、SSL 封装、背压支持，且经过海量生产验证。若项目轻量，可考虑 Undertow（嵌入式、高性能 HTTP 容器）或 MINA（较老但结构清晰）。
- Netty 默认使用 EpollEventLoopGroup（Linux）或 NioEventLoopGroup（跨平台），自动适配最优多路复用机制
- 用 ChannelHandler 分层处理：解码 → 业务逻辑 → 编码，职责清晰，便于复用和测试
- 避免在 ChannelHandler 中执行耗时操作（如 DB 查询、HTTP 调用），应交由业务线程池处理
配套调优不可少
再好的 IO 模型也依赖系统与 JVM 协同。Linux 下需调大 somaxconn（全连接队列）、net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog（半连接队列）；JVM 建议开启 -XX:+UseG1GC，并适当增大堆外内存限制（-XX:MaxDirectMemorySize）；连接层面启用 TCP_NODELAY 关闭 Nagle 算法，降低小包延迟；对长连接务必加心跳保活，防止中间设备断连不通知。
- SocketChannel 配置：channel.config().setOption(StandardSocketOptions.TCP_NODELAY, true)
- 连接空闲检测：IdleStateHandler 可触发 READ/WRITE/ALL_IDLE 事件，方便主动关闭僵尸连接
- 监控指标：关注 EventLoop 的 taskQueue size、Channel 的 pending write bytes、buffer pool 的 hit rate
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
