怎么通过 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() 才更安全。
