FileLock是操作系统级建议性锁，仅当所有进程统一通过FileChannel加锁并严格遵循“先锁后操作、finally释放”流程时才有效；绕过锁直接写文件即失效，且在NFS、overlay2等环境不可靠。
Java 中多进程读写同一文件时，真正的冲突不是“锁冲突”，而是数据覆盖或读到脏数据。FileLock 本身不制造冲突，它只是暴露协作是否到位——所有进程都按规则加锁、操作、释放，才能避免问题；只要有一个绕过锁，就全盘失效。
必须统一走 FileChannel + lock 流程
不能用 FileOutputStream.write() 或 RandomAccessFile.write() 直接写，哪怕加了 synchronized 也没用。跨进程同步只能靠操作系统级的 FileLock，而它只对通过 FileChannel 调用 lock() / tryLock() 的操作生效。
- 打开文件必须用 RandomAccessFile("file", "rw") 或 FileOutputStream.getChannel()，确保 channel 可读可写
- 所有读写操作必须在 FileLock 获取成功后、release() 前 完成，不能先 unlock 再 write
- 务必在 finally 块中 release()，并捕获 IOException（比如锁已被其他进程释放）
区分共享锁与独占锁，按区域划分职责
多个进程同时读配置头、各自写不同字段，是常见场景。靠“全文件锁”会严重串行化，应按字节偏移切分区域，再匹配锁类型：
- 校验字段（0–63 字节）：用 tryLock(0, 64, true) —— 多进程可并发读
- 版本号（64–71 字节）：用 tryLock(64, 8, false) —— 更新时独占，阻塞其他对该段的任何锁请求
- 主数据区（72 开始）：用 tryLock(72, Long.MAX_VALUE, false) —— 写入业务数据，互斥但不影响头信息读取
注意：同一区域不能混用 shared=true 和 shared=false，否则后者永远拿不到锁。
立即学习“Java免费学习笔记（深入）”；
规避底层限制：别在 NFS、overlay2 或 rootless 容器里硬扛
FileLock 在某些环境根本不可靠，不是代码写得不对，而是系统不支持：
- df -T /path/to/file 查看挂载类型：显示 nfs、cifs、overlay —— 区域锁大概率退化为全文件锁，甚至完全失效
- Docker 默认禁用 CAP_SYS_ADMIN，而部分文件系统锁实现依赖它；加 --cap-add=SYS_ADMIN 也不一定解决 overlay2 的限制
- 替代方案更务实：用 Redis 的 SET key val NX EX 30 做分布式争抢，或改用 SQLite（自带 WAL 和进程级写锁）
加锁失败不是异常，而是协作信号
tryLock() 返回 null 不代表程序出错，只说明此刻有其他进程正持有冲突锁。不要立即重试或抛 RuntimeException，应结合业务判断：
- 是关键更新（如扣减库存）？可设置有限次重试 + 指数退避
- 是日志追加？可暂存本地缓冲，稍后重试；或降级为异步落盘+补偿机制
- 是配置热加载？可先读旧值继续运行，后台轮询等待锁空闲
强行阻塞调用 lock() 容易拖慢整个流程，尤其在高并发或不稳定存储上。
