AsynchronousFileChannel基于Proactor模式实现真正的异步I/O，调用read/write后立即返回，内核完成I/O后通知JVM私有线程执行CompletionHandler，Java线程无需阻塞或轮询。
AsynchronousFileChannel 本身是 Java NIO.2 提供的 Proactor 模式实现，它不依赖线程轮询或回调线程池模拟异步，而是直接绑定操作系统级异步 I/O（如 Linux 的 io_uring 或 Windows 的 IOCP），因此能实现真正的异步文件读写——调用发起后立即返回，I/O 完成由内核通知，应用线程无需阻塞、也无需主动轮询。
理解 Proactor 模式在 AsynchronousFileChannel 中的体现
Proactor 的核心是“完成即通知”，而非“就绪即通知”（Reactor）。AsynchronousFileChannel 的 read/write 方法签名返回 Future<Integer> 或接受 CompletionHandler<Integer, ?>，这背后不是封装了线程池提交任务，而是向底层异步 I/O 子系统注册操作。当内核完成磁盘读写并触发完成事件时，JVM 通过私有线程（DefaultThreadPool 中的 daemon 线程）调用你的 handler —— 这个线程只负责分发完成事件，不参与实际 I/O 执行。
- 调用
channel.read(buffer, position, attachment, handler)后，方法立刻返回，buffer 仍为空 - 真正读取发生在内核，Java 线程此时可做其他事
- completed() 方法
正确使用 CompletionHandler 避免常见陷阱
CompletionHandler 是 Proactor 的关键接口，但容易误用：handler 实例不应被复用（尤其 buffer 引用需隔离），且 completed() 中不能阻塞或执行耗时操作，否则会拖慢整个完成线程池。
- 每次 read/write 都应创建新的 handler，或确保 buffer 和 attachment 不被多个操作共享
- completed() 中只做轻量处理（如解析数据头、触发下一个异步操作），重逻辑交给业务线程池
- 务必实现 failed() 方法——磁盘满、权限不足、文件被删等都会触发它，忽略会导致静默失败
与 Future 方式对比：何时选哪种
AsynchronousFileChannel 同时支持 Future 和 CompletionHandler 两种 API。Future 更适合简单串行场景（如启动一个异步读，然后 await）；CompletionHandler 才是 Proactor 的典型用法，适合高吞吐流水线（如边读边解密边写入另一文件）。
- Future 方式本质是同步等待：
future.get()会阻塞当前线程，失去异步意义 - CompletionHandler 是纯异步链式驱动：上一读完成 → 触发下一写 → 再触发下一读，全程无阻塞
- 生产环境推荐 CompletionHandler，尤其是服务端处理大量小文件或流式日志场景
必须注意的平台与配置细节
真异步依赖 OS 支持。Linux 上 JDK 17+ 默认启用 io_uring（需 kernel ≥ 5.10），旧版本或未启用时会回退到线程池模拟；Windows 始终使用 IOCP。可通过 JVM 参数确认：
-
-Djdk.io.enableIOUring=true显式启用 io_uring（JDK 17+） - 用
strace -e trace=io_uring_enter,io_submit观察是否调用 io_uring 相关 syscall - AsynchronousFileChannel 必须用
StandardOpenOption.ASYNC打开（仅 Linux 有效，Windows 忽略）
不复杂但容易忽略：真异步不是靠 Java 代码写得“像异步”就成立，而是看内核是否真正接管了 I/O 执行。AsynchronousFileChannel 提供了标准入口，但需配合 OS 能力、正确 API 用法和非阻塞设计，才能释放 Proactor 的全部价值。
