java的filelock是操作系统级建议性锁，无法强制阻止其他进程访问文件，其“独占”效果依赖所有参与者主动遵守；必须通过长期存活的filechannel获取并显式管理，跨进程需统一绝对路径与锁策略，生产环境推荐分布式协调服务替代。
Java中通过FileChannel获取的FileLock是操作系统级别的 advisory lock（建议性锁），**不能强制阻止其他进程访问文件**，仅在所有参与者都主动检查并遵守该锁时才有效。因此，“独占锁”的安全性高度依赖使用规范，而非Java本身保证。
必须使用FileChannel关联真实文件且保持通道打开
FileLock绑定于FileChannel实例，且仅在通道未关闭时有效。若用Files.newByteChannel()或RandomAccessFile.getChannel()打开，需确保：
- 通道由同一JVM内长期存活的对象持有（如单例管理器），避免被GC或提前
close() - 不要用
Files.lock()等便捷方法——它们内部创建临时通道，锁在方法返回后即失效 - Windows下对已映射（
MappedByteBuffer）的文件加锁可能失败，应避免混合使用
加锁必须基于阻塞I/O且显式处理失败
FileChannel.lock()默认阻塞，但更安全的做法是用tryLock()并严格判断返回值：
-
null表示锁不可用（其他进程已持有），不可忽略或重试无限制 - 返回非
null锁对象后，须验证其有效性：lock.isValid()，并在业务完成后调用lock.release() - 不推荐用
lock(0, Long.MAX_VALUE, true)锁整个文件——部分OS不支持，且易引发跨平台问题；应按实际读写范围精确锁定
跨进程协作需统一锁策略与路径语义
多个Java进程（或混用C/Python等）要互斥，必须约定一致的行为：
- 所有进程使用**完全相同的绝对文件路径**（符号链接、相对路径、不同挂载点会导致锁隔离）
- 统一采用
FileChannel.lock(start, size, shared=false)申请排他锁（shared=true为共享锁，不满足“独占”需求） - Linux/macOS上锁基于inode，Windows基于文件路径——若文件被移动/重命名，锁行为不一致，应避免运行时改名
- 进程异常退出时锁自动释放，但应用层应添加超时机制（如加锁等待≤30秒）防止死等
替代方案更可靠：优先考虑外部协调服务
纯文件锁在分布式或多语言环境中脆弱。生产环境建议：
- 单机多进程：用
java.nio.file.Files.createLink()创建硬链接+原子rename模拟锁（需同文件系统） - 跨机器或复杂场景：改用ZooKeeper、etcd、Redis（带NX+EX的SET）等分布式锁服务
- 若必须用文件锁，配合
FileLock.isShared()日志校验，失败时明确报错而非静默降级
不复杂但容易忽略：FileLock不是同步原语，它只是操作系统提供的一把“门牌”，开门关门全靠自觉。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
