nio高性能网络并发核心是分层协作：bossgroup仅accept连接（1–2线程），workergroup处理io（cpu×2线程），耗时业务须移交独立线程池，禁用阻塞操作与大对象分配。
NIO 结合线程池实现高性能网络并发，核心不是“用更多线程”，而是分层协作：用少量 Reactor 线程做事件分发，把耗时业务逻辑交给独立线程池处理，避免阻塞 IO 轮询。
主从 Reactor 分层设计
这是 Netty 默认采用、也是生产环境最稳妥的结构：
- BossGroup（主线程组）：只负责 accept 新连接，1–2 个线程足够。例如 32 核机器也只需设为 2；多了反而增加上下文切换开销，且 accept 本身不耗 CPU
- WorkerGroup（从线程组）：绑定已建立的 Channel，专责非阻塞读写、编解码和事件触发。建议设为 CPU 核数 × 2（如 16 核配 32 线程），兼顾吞吐与调度效率
- 每个 Channel 固定绑定一个 Worker 线程，保证 IO 操作无锁、无竞争，也不需要同步
业务逻辑必须移交独立线程池
数据库查询、HTTP 远程调用、JSON 解析、复杂计算等操作，绝不能在 Worker 线程中执行——否则整个事件循环会被拖慢，吞吐骤降。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 显式移交方式：
ctx.executor().submit(() -> { /* 业务代码 */ })，或使用自定义EventExecutorGroup - 推荐线程池配置：
ThreadPoolExecutor+SynchronousQueue（不缓存任务） +CallerRunsPolicy（过载时由调用线程自己执行，形成天然背压） - 典型参数示例：
corePoolSize=50、maxPoolSize=200、keepAliveTime=60s，并与 HikariCP 最大连接数对齐，防止 DB 成瓶颈
Selector 与 Buffer 的底层协同优化
性能上限取决于 JVM 与操作系统配合是否到位：
- 确保运行在 Linux 2.6+，JVM 自动启用
epoll（可用java -XX:+PrintNIOEpoll验证），避免退化到低效的select或poll - 禁用干扰项如
sun.nio.ch.disableSystemWideOverlappingFileLockCheck，防止意外降级 - 优先使用
PooledByteBufAllocator复用堆外内存（DirectBuffer），减少 GC 压力和内存拷贝；大文件传输可结合FileChannel.transferTo()实现零拷贝
关键避坑提醒
几个容易忽略但影响巨大的细节：
- 不要在
channelRead()中直接调用阻塞 API（如JDBC Statement.execute()），哪怕只是查一条记录 - 避免在 Worker 线程中创建大对象或频繁分配临时 Buffer，会加剧 GC 压力，间接卡住事件循环
- Selector 的
selectedKeys()集合必须手动remove()已处理的 key，否则重复触发导致逻辑错乱 - 客户端连接突发激增时，BossGroup 若被阻塞（如 DNS 解析未异步），会导致 accept 队列积压，应确保初始化阶段不带同步 IO
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
