filelock 是建议性锁，非强制互斥，windows 下表现强于 linux；必须所有进程主动配合加锁才有效，不可用于分布式场景，且需显式 release() 并避免跨 jvm 复用。
FileLock 在 Windows 和 Linux 上行为不一致，别默认它能跨进程锁文件
Java 的 FileLock 不是“你调用就一定锁住”的硬锁，它本质是 advisory lock（建议性锁），依赖底层 OS 支持和进程是否配合。Windows 下 FileChannel.lock() 会真正阻塞其他进程的同区域访问；Linux 默认用 flock() 或 fcntl()，但若另一个程序完全不用锁机制（比如直接用 cat 写文件），FileLock 就形同虚设。
常见错误现象：FileLock 返回了非 null 对象，但另一 Java 进程或 Shell 脚本仍能同时写入同一文件，导致数据错乱。
- 必须确保所有访问该文件的程序都主动使用锁机制（哪怕只是检查
tryLock()是否成功） - Linux 下推荐搭配
FileChannel.open(..., StandardOpenOption.WRITE)显式打开写通道，避免只读打开后lock()失败却无提示 - 不要在
FileInputStream/FileOutputStream上直接调用getChannel().lock()—— 它们的 channel 默认不可写，lock()可能返回 null 或抛NonWritableChannelException
lock() 和 tryLock() 选哪个？看你是想等还是想立刻失败
lock() 会阻塞当前线程直到获得锁（或被中断），tryLock() 立即返回 FileLock 或 null。两者都不是“自动重试”，也都不保证锁的语义在 JVM 崩溃后依然有效。
使用场景：日志聚合服务需串行写入共享日志文件时，用 lock() 更稳妥；而命令行工具做快速状态检查（如“这个配置文件正被编辑吗？”），用 tryLock() 避免卡住用户。
立即学习“Java免费学习笔记（深入）”；
-
lock()调用前务必确保 channel 处于可读/可写状态，否则抛NonReadableChannelException或NonWritableChannelException -
tryLock()返回null≠ 错误，是正常流程分支，别把它当异常处理 - 带参数的
tryLock(long, long, boolean)支持超时和共享锁，但共享锁（shared=true）在 Windows 下不支持，调用直接抛IOException
FileLock 不能跨 JVM 生命周期，关掉进程前必须显式 release()
FileLock 是与 FileChannel 绑定的，channel 关闭、JVM 退出、甚至 GC 回收 channel 时，锁会被自动释放。但“自动释放”不是实时的——尤其在 JVM crash 或 kill -9 时，OS 层锁可能残留数秒，造成后续启动失败。
最容易踩的坑：在 finally 块里只 close() channel，没先 lock.release()；或者把 FileLock 存在静态变量里，以为能跨请求复用——它早随着上一个 channel 被回收了。
- 必须在业务逻辑结束、channel 关闭前调用
lock.release()，且要捕获IOException（比如锁已被其他进程释放） - 不要缓存
FileLock实例，每次操作都重新tryLock()或lock() - 测试时用
lsof -p <pid></pid>（Linux）或 Process Explorer（Windows）确认锁是否真实存在，别只信 return 值
用 FileLock 做分布式锁？别碰，它根本不是为这个设计的
FileLock 只作用于本地文件系统，NFS、SMB、Docker volume 等场景下行为未定义。很多团队踩过坑：容器内 Java 应用对挂载的 NFS 目录加锁，结果多个实例同时拿到 FileLock，因为 NFS 服务器根本不转发 flock 请求。
性能影响很小，但兼容性风险极大。一旦部署环境从单机切到容器或云盘，锁立即失效。
- 涉及多节点协作的场景，改用 Redis 的
SET key value NX PX或 ZooKeeper 临时节点 - 如果坚持用文件锁，只限于单机多进程协作，且文件路径必须是本地 ext4/xfs，避开网络文件系统
- CI/CD 流水线中跑集成测试时，记得在 Dockerfile 里用
mount -t tmpfs挂内存盘，避免 NFS 干扰
lock()，而是判断此刻到底需不需要锁、谁和谁之间要互斥、以及当锁失效时你的程序还能不能安全降级。 
