Java FileLock是建议性锁，需所有进程主动配合才生效；必须通过FileChannel.lock()加锁，绕过通道的操作会使锁失效；应按字段分区加锁提升并发，关键更新禁用tryLock()；跨语言或容器环境锁不可靠，应优先使用Redis等外部协调机制。
Java 的 FileLock 本身不自动防止并发冲突，它只在所有进程都主动配合加锁的前提下起作用——本质是建议性锁（advisory lock），不是操作系统强制拦截的锁。真正防冲突的关键，是你统一的读写路径和对锁的严格遵守。
必须走 FileChannel.lock() 这一条路
绕过通道的操作会让锁完全失效：
- 用
Files.write()、FileWriter、PrintWriter或 shell 命令（如echo > file）直接写文件，锁形同虚设 - 必须用
RandomAccessFile("file", "rw")或FileOutputStream.getChannel()获取可读写通道 - 写入前调用
channel.lock(0, Long.MAX_VALUE, false)（全文件独占）或指定范围加锁 - 所有修改必须在锁持有期间完成，写完立即
channel.force(true)刷盘，再释放
按字段分区加锁，减少阻塞
如果文件含多个逻辑部分（比如校验头 + 版本号 + 主数据），可分段加锁提升并发度：
- 校验头（0–63 字节）：用
tryLock(0, 64, true)允许多进程并发读 - 版本号（64–71 字节）：用
lock(64, 8, false)独占更新 - 主数据区（72 字节起）：单独加锁写入，不影响元数据操作
- 注意：同一字节区间不能同时存在 shared 和 exclusive 锁，否则后者失败
别用 tryLock() 做关键更新
tryLock() 非阻塞，返回 null 只表示“此刻没抢到”，不说明谁占着、多久释放：
立即学习“Java免费学习笔记（深入）”；
- 反复轮询空转 CPU；对方崩溃未释放锁，就会一直卡住
- 业务可能误判为“无冲突”而降级写入，导致数据不一致
- 关键配置更新推荐用阻塞式
lock()，配合超时控制（如Future.get(3, TimeUnit.SECONDS)） - 若必须用
tryLock()，应加带重试上限的循环（例如最多 3 次，间隔 100ms）
跨语言或容器环境要格外小心
Linux/macOS 默认是建议性锁，Windows 是强制锁但仅对同句柄 I/O 生效：
- Python 脚本没调用
flock()，照样能覆盖写 Java 加了锁的文件 - Docker 容器中 overlay2、NFS/CIFS 卷基本不支持可靠文件锁
- K8s 多实例共享配置目录时，优先考虑 Redis（
SET key val NX EX 30）等外部协调机制 - 不要依赖
FileLock.isValid()判断业务状态，它只反映锁是否被显式释放
