FileChannel高效读写取决于场景与方式：零拷贝（transferTo+RandomAccessFile）适合大文件本地复制；DirectBuffer循环读写适用于需加工或非零拷贝场景；MappedByteBuffer用于大文件随机访问；AsynchronousFileChannel适用于高并发多文件IO。
FileChannel 实现高效文件读写，关键不在“用了通道”，而在“用对场景+选对方式”。它不是万能加速器，不同操作路径性能差异极大，甚至可能比传统 Files.copy() 还慢——尤其是误用 FileInputStream.getChannel() 配合 transferTo 复制本地文件时。
优先走零拷贝：transferTo + RandomAccessFile 双向通道
这是大文件（几十MB 以上）本地复制的首选，真正绕过 JVM 堆内存、由内核直接搬运：
- 源和目标都必须用 RandomAccessFile 打开：“r”读源，“rw”写目标（不能用 FileInputStream 或 FileOutputStream）
- 确保源与目标在同一文件系统（同磁盘、同 ext4/xfs 分区），跨磁盘或 NFS 会退化为普通读写
- 调用
in.transferTo(0, in.size(), out)一行完成，无需缓冲区管理 - JDK 11+、Linux 内核 ≥ 4.5 且文件系统支持时，大概率触发
copy_file_range系统调用
需手动控制时：DirectBuffer + 规范状态流转
当要加进度回调、加密、压缩，或目标不满足零拷贝条件（如写入网络流、跨文件系统），就用 ByteBuffer 循环读写：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 缓冲区用
ByteBuffer.allocateDirect(64 * 1024)（64KB 是多数场景吞吐与内存占用的平衡点） - 每次 read() 后必须 flip()，否则 write() 读不到数据；write() 后检查返回值，用 while 循环确保全量写出
- 一轮结束用
clear()重置位置，不要用 compact()（除非保留未读完内容） - 避免用堆内 buffer（
allocate()），否则多一次 JVM 堆 → 直接内存拷贝
大文件随机访问：内存映射（MappedByteBuffer）
适合日志分析、数据库索引、视频帧提取等需频繁跳转读写的场景，而非顺序复制：
立即学习“Java免费学习笔记（深入）”；
- 调用
channel.map(MapMode.READ_ONLY, offset, size)直接将文件某段映射进虚拟内存 - 后续操作像访问数组一样读取
buffer.get(i)，无显式 I/O 调用 - 注意：映射区域过大可能引发 OOM 或影响 GC；修改后需调用
force()持久化（仅 WRITE/READ_WRITE 模式） - 不适用于小文件或只读一次的场景——映射开销反而得不偿失
高并发 IO 密集型：异步通道 AsynchronousFileChannel
当多个线程频繁读写不同文件（如 Web 服务静态资源分发），同步阻塞会拖垮吞吐：
- 用
AsynchronousFileChannel.open(path, READ, WRITE, CREATE)创建异步通道 - 调用
read(buffer, position, attachment, handler)发起非阻塞读，线程立即返回 - IO 完成后由回调 handler 处理结果，或用
Future<integer></integer>获取字节数 - 注意：它不支持 transferTo，也不适用于单个超大文件顺序写入——那是 FileChannel 的主场
