跨机网络挂载场景下FileLock的工作机制及跨JVM锁同步问题

要理清这个问题，得从Spring Integration FileLocker的实现机制，以及CIFS/SMB协议的锁同步特性两方面拆解：

1. Spring Integration FileLocker的核心逻辑 #

Spring Integration默认提供的NioFileLocker，是依赖底层文件系统的独占锁机制实现的——它通过Java NIO的FileChannel.lock()方法请求文件独占锁，锁的行为完全由操作系统和挂载的文件系统决定。

另外还有一类基于标记文件的锁实现（比如自定义扩展的FileLocker），这类锁通过在共享目录下创建和目标文件关联的临时锁文件来标记“文件已被锁定”，本质靠共享目录的文件可见性实现锁同步。

2. CIFS挂载场景下的锁同步能力 #

当Linux通过CIFS挂载Windows共享目录时，文件锁的跨机器同步受以下因素限制：

• CIFS配置限制：默认CIFS挂载通常不启用强制锁（mandatory locking），且Linux的CIFS客户端对强制锁支持有限，大部分场景下，NIO请求的本地独占锁不会同步到Windows端的源文件。
• 跨平台锁语义差异：Windows与Linux的文件锁机制存在语义冲突，即便CIFS传递了锁请求，也可能因兼容性问题导致JVM-2无法识别。

结论 #

• 若使用默认的NioFileLocker：常规配置的CIFS挂载场景中，JVM-1添加的锁仅在本地Linux机器生效，无法同步到Windows源文件，JVM-2无法识别该锁。
• 若使用基于标记文件的锁实现：只要两台Linux机器具备共享目录的读写权限，JVM-2就能看到锁标记文件，从而识别文件已被锁定。

内容的提问来源于stack exchange，提问作者habjo