Java NIO FileChannel position 并发读写如何避免覆盖

Java NIO 的 FileChannel 可以安全地被多个线程使用，但这不等于“先调用 position(offset)，再调用 write(buffer)”就是安全的。两次调用共享同一个当前游标，线程切换后，后一次 position 可能改写前一次准备好的位置，最终出现数据覆盖。

不要在多线程间共享同一个FileChannel实例的全局position属性，每次执行read/write操作时都显式传入独立的pos偏移参数，给不同线程分配文件内互不重叠的读写区间，配合独享的分片文件锁，就能完全避免并发场景下的内容覆盖问题。

为什么 position 加 write 容易把数据写到同一段

position(long) 修改的是通道的当前文件位置，而无位置参数的 write(ByteBuffer) 会从这个位置开始写，并在写入后推进它。假设线程 A 刚把 position 设为 0，线程 B 随后把 position 设为 4096，A 再执行 write，A 的数据就可能从 4096 开始。这里的关键不是 FileChannel 是否允许并发使用，而是应用把“选择位置”和“执行写入”拆成了依赖共享状态的复合动作。

并发分段写入应把 offset 直接交给 API

FileChannel 提供了带绝对位置的重载：write(ByteBuffer src, long position)。它从指定字节位置写入，不修改该通道的当前 position。只要任务提前拿到互不重叠的区间，例如 A 使用 [0, 4096)、B 使用 [4096, 8192)，线程就不需要先争夺共享游标。

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

static void writeBlock(FileChannel channel, long offset, byte[] bytes) throws IOException {
    // offset 是任务独占的文件区间起点，不通过 position(long) 修改共享游标。
    ByteBuffer buffer = ByteBuffer.wrap(bytes);
    while (buffer.hasRemaining()) {
        // 显式位置写入不会改变 channel 的 current position。
        int written = channel.write(buffer, offset);
        if (written == 0) {
            // 阻塞 FileChannel 通常会继续推进；零写入时让出调度，避免忙等。
            Thread.yield();
            continue;
        }
        offset += written;
    }
}

循环不能假设一次 write 就消费完整缓冲区。每次返回的字节数都要推进本任务自己的 offset；遇到异常时，调用方还应记录任务对应的区间，避免重试时把新数据写进旧区间。

显式位置不代表重叠写入自动合并

两个任务即使都调用了带 position 的方法，只要它们写入的字节范围重叠，后写入的数据仍可能覆盖先写入的数据。应在任务分配阶段保存 offset 和 length，用半开区间判断是否重叠，并把“谁拥有这段区间”作为业务状态保存下来。

如果一次业务更新需要“读取旧内容、修改字段、再写回同一段”，显式位置也不够，因为整个读改写仍是复合操作。此时在同一 JVM 内使用 ReentrantLock 或按区间分片的锁；如果多个进程协作，再评估 FileChannel.lock(position, size, shared)。

几个容易忽略的边界

第一，FileChannel 的线程安全只说明通道能被并发线程使用，涉及通道 position 或文件大小的操作仍受内部串行化规则影响，不能替应用决定业务顺序。第二，FileLock 是面向文件区域的进程协作机制，官方文档明确提示它不适合控制同一 JVM 内多个线程；线程之间仍要使用 Java 锁。第三，写入位置超过当前文件大小是合法的，但中间空洞字节内容不应被业务当作有效数据。最后，文件通道关闭、任务取消和重试都应进入同一份区间状态记录。

常见问题

只给每个线程创建一个 ByteBuffer 就够了吗？

不够。独立缓冲区只能避免缓冲区对象互相改写，不能解决共享 position 或文件区间重叠。

write(buffer, offset) 会自动扩展文件吗？

写入超出当前文件末尾时，文件会扩展；但跳过区域的字节值没有业务保证，读取前应先写满或建立长度元数据。

什么时候应该改用 AsynchronousFileChannel？

当任务模型确实需要异步完成回调、独立的每次读写位置和专门的线程池时再考虑。它改变的是异步调度方式，不会替你解决区间分配和重叠写入。

复查这类问题时，先搜索代码中所有无位置参数的 read、write 和 position 调用，再对照任务区间表。能把 offset 的所有权、长度和锁范围写清楚，通常比单纯增加 synchronized 更容易长期维护。