Java NIO FileChannel 怎样安全写入固定偏移

如果多个任务要把定长记录写进同一个文件，最稳妥的入口是 FileChannel.write(ByteBuffer src, long position)：把目标偏移作为参数传入，而不是先修改共享通道的当前位置。这样一次写入只围绕“缓冲区还剩多少字节”和“文件从哪个字节开始写”展开，适合分片文件、固定大小索引和预分配数据区。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/channels/FileChannel.html

固定偏移写入的关键不是把 position(long) 调得更勤，而是使用带偏移的写入重载、循环处理部分写入，并明确重叠区域是否需要互斥；需要崩溃后尽量保留数据时，再按业务重要性调用 force(false)。

• 位置语义：write(src, offset) 从指定字节开始写，不改变通道当前位置。
• 缓冲区语义：返回值是本次实际写入的字节数，不能默认一次耗尽整个缓冲区。
• 并发语义：不同且不重叠的区域可以独立写；同一区域必须由应用层或文件锁协调。
• 落盘语义：force(false) 请求把文件内容更新强制到存储设备，但不等于数据库事务提交。

为什么要使用带偏移的 write

FileChannel 有两种容易混淆的写法。相对写入 write(src) 使用通道当前的 position，并在写完后推进它；定位写入 write(src, offset) 直接使用传入的偏移，不修改通道的当前位置。多个线程共享一个通道时，前一种写法会让“谁先改变当前位置”成为额外的协调问题，后一种写法则把每次写入的目标显式放在调用参数里。

这里的 offset 是文件字节偏移，不是记录编号，也不是字符下标。若每条记录固定为 128 字节，第 10 条记录的起始偏移就是 10L * 128；编码后的字节数必须和你定义的记录布局一致，不能用字符串长度代替 UTF-8 字节长度。

先避开追加模式，再处理部分写入

打开文件时使用 WRITE，需要文件不存在时再加 CREATE；不要把 APPEND 混入固定偏移写入。Oracle API 明确说明，文件以追加模式打开时，定位写入的效果未定义。偏移还必须是非负数，否则 API 会抛出 IllegalArgumentException。

下面的辅助方法把任意字节数组写入指定位置。循环的意义是处理 ByteBuffer 仍有剩余内容的情况；每次返回正数后，缓冲区 position 会向前推进，下一次调用会继续写未完成的部分。示例没有把具体文件路径、业务记录或敏感数据写死，便于嵌入自己的固定记录格式。

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

public final class FixedOffsetWriter {
    private FixedOffsetWriter() {
        // 工具类不需要被实例化。
    }

    public static void writeAt(Path file, long offset, byte[] data) throws IOException {
        if (offset 

这个方法只保证把字节提交给通道，并不保证调用返回时已经完成崩溃持久化。它也没有覆盖多个调用之间的业务一致性：如果一条记录包含长度、正文和校验字段，仍需要由上层规定写入顺序和恢复策略。

固定偏移写入的范围和长度要先算清楚

如果文件是定长槽位，可以把“槽位编号到字节范围”的计算集中起来，避免调用方重复拼接偏移。以下示例假定每个槽位 128 字节，并用 UTF-8 填充；当内容超过槽位时直接失败，避免覆盖下一个槽位。填充字节的取值属于文件格式约定，读取端必须使用相同规则。

import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;

public static void writeSlot(Path file, long slot, String value) throws IOException {
    final int slotSize = 128;
    if (slot  slotSize) {
        throw new IllegalArgumentException("内容超过固定槽位");
    }

    ByteBuffer record = ByteBuffer.allocate(slotSize);
    // 固定长度记录用 0 填满尾部，读取端可按协议去除填充。
    record.put(encoded);
    while (record.hasRemaining()) {
        record.put((byte) 0);
    }
    FixedOffsetWriter.writeAt(file, Math.multiplyExact(slot, slotSize), record.array());
}

这里使用 Math.multiplyExact 是为了让槽位编号过大时显式失败，而不是静默溢出成错误的负偏移。生产文件格式还应明确字节序、版本号和校验方式；这些约束比“能否调用 write”更决定数据是否可恢复。

并发写入时，安全边界在哪里

定位写入解决的是共享当前位置问题，不会自动解决重叠写入。如果 writer A 写 0–127 字节、writer B 写 128–255 字节，两者的目标区域不重叠，通常只需要分别计算好范围；如果两者都写同一个槽位，后写入者可能覆盖前一个结果，调用带偏移重载并不会替你合并内容。

同一 JVM 内可以围绕槽位或文件对象加 synchronized，跨进程则应评估 FileChannel.lock / tryLock。锁的范围必须覆盖“读取旧内容、计算新内容、写回”的整个临界区；只锁住最后一次 write，仍可能让两个进程基于同一个旧值计算并互相覆盖。

还要留意打开选项和文件系统的边界：定位写入在 APPEND 模式下行为未定义，跨机器文件系统的锁语义也应以部署环境的文档和实测为准。不要把“线程安全地调用了 API”扩大解释成“整个文件格式具备事务性”。

什么时候需要 force(false)

force(false) 用于请求把文件内容更新强制写到承载文件的存储设备；传入 true 时还会要求元数据一并处理，可能带来额外 I/O。它适合日志索引、检查点或无法轻易重建的文件片段，但每次小写入都强制落盘会放大延迟，应由业务批量策略决定。

try (FileChannel channel = FileChannel.open(
        file, StandardOpenOption.CREATE, StandardOpenOption.WRITE)) {
    ByteBuffer source = ByteBuffer.wrap(data);
    long position = offset;
    while (source.hasRemaining()) {
        int written = channel.write(source, position);
        if (written == 0) {
            Thread.onSpinWait();
            continue;
        }
        position += written;
    }
    // 关键数据写完后请求内容落盘；远程文件系统不提供同等保证。
    channel.force(false);
}

Oracle 文档也提醒，非本地存储设备不提供同样的保证。因此需要更强一致性时，除了 force，还要设计临时文件、校验、版本指针或可重放日志；不能只靠一次 API 调用宣称“断电不丢”。

一张表记住定位写入的边界

常见问题

调用 position(offset) 再 write(src) 可以吗？

单线程、独占通道时可以工作，但它依赖共享当前位置；一旦其他调用也操作同一通道，定位写入重载更容易表达意图，也减少位置竞争。

偏移超过当前文件大小会怎样？

写入会让文件扩展到能容纳新字节，中间空洞的字节值由文件系统和实现语义决定，不能把它当成可靠的零填充协议。

FileChannel 定位写入是不是事务？

不是。它只描述一次通道写入；多字段一致性、重叠冲突、崩溃恢复和跨进程协调都需要额外设计。