asynchronousfilechannel并非真正零阻塞，而是基于线程池模拟的异步非阻塞i/o；它不阻塞调用线程但依赖jvm线程池执行实际i/o，高吞吐大文件场景下性能常不如优化的同步通道，适合响应式编程或与netty/reactor集成。
Java 中的文件异步通道（AsynchronousFileChannel）不是“真正零阻塞”的内核级 AIO，而是基于线程池模拟的异步非阻塞 I/O。它不挂起调用线程，但会把读写任务提交到后台线程池执行。适合响应式编程、避免主线程阻塞，或与 Netty/Reactor 集成，但大文件高吞吐场景下，往往不如优化过的同步通道（FileChannel + 直接缓冲区 + 分块 + 多线程）。
怎么打开和配置通道
必须显式指定读写权限，不能只传路径：
- 用
AsynchronousFileChannel.open(path, READ)或open(path, READ, WRITE)，不支持TRUNCATE_EXISTING等部分选项 - 推荐传入自定义线程池，避免挤占 JVM 默认池（默认大小为 CPU 核心数 + 1，且是守护线程）
- Windows 下若遇到重叠锁检查开销，可加启动参数：
-Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true（仅限可信环境）
缓冲区要用直接内存
普通堆内缓冲区（ByteBuffer.allocate()）会增加 GC 压力和内存拷贝，大文件操作必须用：
-
ByteBuffer.allocateDirect(4 * 1024 * 1024)（如 4MB），容量建议 4KB–64KB 页对齐；过大易触发堆外内存不足，过小则系统调用频繁 - 每次读完需手动
buffer.flip()取数据，处理完用buffer.clear()或compact()复用，避免丢数据 - 注意：
write()调用后，buffer 内容可能被复用，不能再修改
分块读写 + CompletionHandler 驱动流程
单次读写 GB 级文件极易 OOM，必须切块并链式回调：
- 按固定块（如 32MB）切分，用
channel.read(buf, position, attachment, handler)启动 -
onCompleted(Integer bytesRead, ...)中：若bytesRead == -1表示 EOF；否则buf.flip()处理数据，buf.clear()，更新 position，发起下一次 read -
onFailed()中必须释放 buffer（buf.clear()）、记录错误、中断后续流程 - 写入时控制并发数（如用
Semaphore限最多 3 个未完成 write），防内存溢出和系统资源耗尽
别踩这些常见坑
很多问题其实源于细节疏忽：
- 路径未校验：空值、非法字符、越界跳转（如
../）会导致NullPointerException或安全异常，务必前置检查 - 未显式关闭通道：
channel.close()必须在 finally 或 try-with-resources 中调用，否则句柄泄漏 - 在
CompletionHandler里做阻塞操作（如同步日志、数据库写入），会拖慢整个异步队列——应提交到独立业务线程池 - 误以为异步 = 不消耗资源：每个操作都占线程池名额，大量并发可能排队、延迟上升甚至 OOM
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
