AsynchronousChannelGroup是Java NIO.2中统一调度与隔离异步I/O线程的核心载体，为异步通道提供线程资源边界和生命周期管理；它通过分组隔离、策略绑定（如withFixedThreadPool/withCachedThreadPool/withThreadPool）和生命周期联动，实现资源可见、行为可控、故障可界，并严格限定线程仅执行I/O事件处理与CompletionHandler派发，避免业务逻辑阻塞调度。
AsynchronousChannelGroup 是 Java NIO.2 中对异步 I/O 任务执行线程进行统一调度与隔离的核心载体。它不直接处理 I/O，而是为 AsynchronousFileChannel、AsynchronousSocketChannel 等异步通道提供线程资源边界和生命周期管理——关键在于“精细化控制”：不是简单配个线程池，而是通过分组隔离、策略绑定、生命周期联动，实现资源可见、行为可控、故障可界。
线程池绑定方式决定调度粒度
AsynchronousChannelGroup 提供三种主流创建方式，每种对应不同控制强度：
- withFixedThreadPool(int, ThreadFactory)：固定大小线程池，适合 IO 密集且负载可预估的场景（如批量日志归档）。线程数过少易堆积 CompletionHandler；过多则浪费调度开销。建议设为 CPU 核心数 × 1.5～3，配合自定义 ThreadFactory 设置线程名与守护属性。
- withCachedThreadPool(ExecutorService, int)：基于已有 ExecutorService 构建，initialSize 控制初始空闲线程数。适用于突发流量明显、但整体吞吐波动大的服务（如文件上传网关），线程可弹性伸缩，但需警惕无界队列导致 OOM。
- withThreadPool(ExecutorService)：最细粒度控制入口。传入的 ExecutorService 必须满足：支持直接移交（Direct Handoff）或无界队列；禁止调用者线程同步执行任务（即不能在 execute() 中直接 run()）。这是定制化调度的基础——例如可注入带有监控埋点的包装 Executor，或集成响应式线程上下文传播（如 MDC）。
线程职责严格限定为两类任务
绑定到 Group 的线程池并非通用工作线程池，其职责被 JVM 明确约束：
- 处理底层 I/O 事件（如 Linux epoll_wait 返回后的就绪通知解析）
- 派发 CompletionHandler 回调（即执行你写的 completed() 或 failed() 方法）
这意味着：业务逻辑不应在 CompletionHandler 中做耗时操作（如数据库写入、HTTP 调用），否则会阻塞整个 Group 的 I/O 调度线程。正确做法是将后续处理提交到独立业务线程池，或使用 CompletableFuture.supplyAsync() 拆离。
生命周期强耦合，避免外部干预
Group 与其线程池是“共生关系”：
- 调用 group.shutdown() 或 group.awaitTermination() 会触发关联 ExecutorService 的 orderly shutdown（先拒新任务，再等已提交任务完成）
- 若绕过 Group 直接调用 executor.shutdown()，行为未定义——可能造成 Channel 挂起、回调丢失、甚至 JVM 崩溃
- 默认系统级 Group 使用 daemon 线程，JVM 退出时不等待；显式创建的 Group 则默认使用 user 线程，需主动管理生命周期
异步文件 IO 的特殊考量
AsynchronousFileChannel 与其他通道不同：它不依赖操作系统真正的异步文件 I/O（Linux 下多数仍基于线程池模拟），因此 Group 的线程池实际承担了“伪异步”的核心负载：
- 读写请求最终由线程池中的线程调用本地文件系统 API（如 pread/pwrite），本质仍是同步阻塞调用
- 所以线程池大小需兼顾磁盘 IOPS 能力，而非仅看 CPU；SSD 场景可适度提高并发线程数，HDD 则宜保守（通常 ≤ 8）
- 避免多个 AsynchronousFileChannel 共享同一 Group 处理高吞吐随机读写——不同文件访问模式（顺序 vs 随机）会相互干扰，建议按访问特征分组（如日志组、索引组、缓存组）
控制不在数量多寡，而在边界清晰、职责分明、收放可控。用好 AsynchronousChannelGroup，就是为异步 I/O 找到它的专属调度室。
