怎么通过 FileLock 锁定文件区域防止多进程冲突

怎么通过 FileLock 锁定文件区域防止多进程冲突

FileLock.lock(long, long, boolean) 怎么指定字节范围加锁

想锁定文件的特定一段，比如只锁日志头部的1KB，或者跳过元数据区域，就必须使用 lock(long position, long size, boolean shared) 这个方法，而不是那个无参的 lock()。参数的含义很直观：position 是起始偏移量（从0开始计数），size 是要锁定的字节长度，而 shared 则决定了锁的类型——设为 true 是共享锁，允许多个进程并发读；设为 false 则是独占锁，这是写操作所必需的。

这里有个常见的坑是关于 size 参数的传递。比如，你想锁定文件的最后1024个字节，可能会写成 lock(fileSize - 1024, 1024, false)。但如果 fileSize 是动态变化的，计算这个值的时间和实际加锁的时间点不一致，就可能导致锁定的区域发生偏移。更稳妥的做法是，先通过 channel.size() 获取文件的当前长度，然后在同一个 try 代码块内完成锁定和写入操作，避免中间被其他进程截胡。

另外，有个特性值得注意：position + size 这个范围是允许超过文件当前长度的。这意味着操作系统支持锁定一个“未来才会写入”的区域，这个特性对于预分配日志块、分片写入这类场景来说，就非常实用了。

为什么 tryLock(0, 1024, true) 和 tryLock(0, 1024, false) 会互斥

共享锁和独占锁在操作系统底层是严格区分的。当调用 tryLock(0, 1024, true) 时，意思是“我只想读取前1024字节”，这种情况下，多个进程可以同时成功获取这把锁。但是，一旦有任何一个进程调用了 tryLock(0, 1024, false)（哪怕它只打算写入1个字节），那么其他所有针对同一区域的锁请求——无论 shared 参数是 true 还是 false——都会失败或者进入阻塞状态。

这就决定了你不能混用锁类型。举个例子，进程A正持有一把共享锁在读取配置头，此时进程B却试图对同一区域加独占锁来写入版本号，那么B的请求肯定会失败。所以，在设计时就需要明确各个区域的职责：用不同的偏移量和长度把“只读的元数据区”和“可写的内容区”隔离开，避免交叉锁定。

这里有几个实操建议：

• 用固定的偏移量来划分区域。比如，规定0到511字节存放校验头，512字节之后存放正文。读取头部就用 tryLock(0, 512, true)，写入正文则用 tryLock(512, Long.MAX_VALUE, false)。
• 不要对同一个起始位置（position）同时尝试申请共享锁和独占锁。这不仅仅是锁竞争的问题，本质上是访问协议的冲突。
• 当 tryLock() 返回 null 时，先别急着盲目重试。最好确认一下，是不是自己或者其他进程正持有冲突类型的锁。

FileLock 区域锁在容器或 NFS 上为什么经常失效

问题的根源在于底层的文件系统可能不支持 POSIX 规范中的 fcntl 区域锁语义。像 Linux 的 ext4 文件系统是支持的，但很多常见环境，比如 Docker 默认的 overlay2 存储驱动、NFSv3、或者 CIFS 卷，大多只实现了全文件锁（flock），会直接忽略你传入的 position 和 size 参数。结果就是，你以为调用的 lock(100, 512, false) 是锁定特定区域，实际上它可能把整个文件都给锁了。

怎么验证呢？可以运行 df -T /path/to/file 命令查看文件系统类型。或者在容器里，通过 strace -e trace=fcntl,flock ls /dev/null 2>&1 | grep -i lock 这样的命令，观察系统是否真的调用了带偏移量的 fcntl(F_SETLK) 函数。

如果部署环境不确定（比如在 Kubernetes 中使用共享的 PVC），那么最好不要依赖区域锁。可以考虑改用全文件锁，再配合应用层逻辑进行分区；或者，干脆切换到分布式协调方案，比如用 Redis 的 SET key val NX EX 30 命令来控制写入权限。

release() 必须在 finally 块里显式调用，且要处理 IOException

FileLock.release() 这个方法不会自动调用。JVM不会管它，垃圾回收器（GC）也不会清理它，甚至进程崩溃后，这把锁也不会自动释放（除非操作系统回收了相关的文件描述符）。忘记调用 release() 的后果很直接：其他进程会在 lock() 或 tryLock() 上永远卡住，直到你手动杀掉持有锁的那个 JVM 进程。

所以，正确的写法必须包含 finally 块和异常捕获：

FileLock lock = null;
try {
    lock = channel.lock(1024, 2048, false);
    if (lock == null) throw new IllegalStateException("Failed to acquire region lock");
    // ... write to region
} finally {
    if (lock != null && lock.isValid()) {
        try {
            lock.release();
        } catch (IOException e) {
            // log but don't throw — release() 失败通常意味着锁已失效或通道关闭
        }
    }
}

还有一个容易被忽略的细节：lock.isValid() 返回 false 并不总是代表“锁已经被释放了”。它也可能是因为通道被关闭，或者 JVM 被 kill -9 强制终止而提前失效了。因此，判断条件里同时加上 lock != null && lock.isValid() 才更安全。