Java AIO中CompletionHandler回调由AsynchronousChannelGroup私有线程池直接同步执行，非ForkJoinPool等通用线程池；默认为ThreadPoolExecutor（核心线程数=CPU核数、最大无界），仅用于回调派发，需轻量、线程安全且避免阻塞。
Java AIO 中的 CompletionHandler 回调**不是由你常用的 ForkJoinPool 或 Executors 创建的通用线程池调度的**，而是由每个 AsynchronousChannelGroup 自带的私有线程池负责执行。这个线程池是 JDK 封装 OS 异步能力（如 Linux 的 epoll + 独立轮询线程、Windows 的 IOCP）后，在 JVM 内部管理的一套专用机制。
回调执行线程来自 AsynchronousChannelGroup 的私有线程池
每次调用 channel.read()、write() 或 connect() 并传入 CompletionHandler 后：
- 操作注册到操作系统级异步设施（如 io_uring、IOCP），JVM 不主动轮询
- OS 完成 I/O 后触发事件通知，JVM 的 I/O 事件处理线程从队列中取出结果
- 该线程**直接同步调用**你的
completed()或failed()方法——不经过Executor.submit()，也不走 Future 链路 - 这个线程就来自当前
AsynchronousChannelGroup所绑定的线程池
默认线程池配置与可控性
如果你没显式指定 AsynchronousChannelGroup，JDK 使用默认组，其底层线程池是：
-
ThreadPoolExecutor实例，核心线程数 =Runtime.getRuntime().availableProcessors() - 最大线程数为
Integer.MAX_VALUE（即无界），空闲线程 60 秒后回收 - 该池只用于分发
CompletionHandler回调，不复用给其他任务 - 可通过
AsynchronousChannelGroup.withThreadPool(Executors.newFixedThreadPool(4))替换为自定义线程池
为什么不能当成普通线程池任务来理解？
关键区别在于调度模型：
立即学习“Java免费学习笔记（深入）”；
- 它不是“你提交一个 Runnable，线程池 later 执行”，而是“OS 通知一到，线程池里某个空闲线程立刻拉起回调方法”
- 回调执行不可控：无法指定哪个线程、无法保证顺序、无法加 @Scheduled 或依赖线程局部变量
- 若在
completed()里做耗时操作（如写 DB、序列化大对象），会阻塞该线程，拖慢整个组的回调吞吐 - 推荐做法：在回调内快速提取数据，再把重逻辑提交到你自己的业务线程池（如
Executors.newVirtualThreadPerTaskExecutor()）
attachment 和 buffer 的线程安全要点
由于回调可能在任意线程执行，需特别注意上下文对象的安全性：
-
attachment是你传入的任意对象，但必须是线程安全的，或仅被当前回调单次使用（例如 new 一个 RequestContext） -
ByteBuffer在回调中不能直接复用——读完要flip()，处理完要compact()或clear()；多个并发回调共用同一个 buffer 会出错 - 不要在回调里修改共享集合（如 static List）、未加锁的 Map，除非你明确做了同步或用了 ConcurrentXXX
