基于文件的锁 vs 内存锁：Lucene采用文件锁的优势及相关疑问

一、文件锁相对于内存锁的核心优势 #

除了你提到的系统崩溃后的锁持久性，文件锁还有以下关键优势：

• 跨进程同步能力：内存锁（如Java的ReentrantLock）仅能约束同一进程内的线程，而文件锁是文件系统级别的，可实现不同进程（甚至不同JVM实例）对共享索引目录的访问控制，这对Lucene这类可能被多进程读写的引擎至关重要。
• 天然的全局可见性：所有访问同一索引目录的进程都能通过文件锁状态感知当前的读写权限，无需额外的共享内存或通信机制来同步锁状态。
• 自动释放机制：锁与进程的文件句柄绑定，无论进程是正常退出还是崩溃，操作系统都会在进程终止后自动释放文件锁，避免内存锁可能出现的“锁泄漏”（如进程崩溃未释放内存锁，需额外清理逻辑）。

二、采用文件锁的其他典型实现 #

• Elasticsearch/Solr：二者均基于Lucene构建，直接继承了文件锁机制，用于集群中多个节点对同一索引分片的读写互斥控制。
• SQLite：通过文件锁实现多进程环境下的数据库并发访问，不同锁级别（共享锁、排他锁）对应读、写操作的权限控制。
• Git：在执行pack、gc等涉及仓库数据修改的操作时，会创建.lock文件防止多个Git进程同时修改仓库数据。

三、文件锁的典型使用流程（以Lucene为例） #

1. 锁获取：写操作发起前，尝试创建并获取write.lock文件的排他锁；读操作则尝试获取共享锁，允许多个读进程同时持有。
2. 锁校验：每次读写操作前都会检查锁的状态，确保当前进程拥有合法的访问权限。
3. 锁释放：正常操作完成后，关闭锁文件句柄释放锁；若进程异常终止，操作系统会自动回收文件句柄并释放锁。

四、判断持有文件锁的进程/线程 #

文件锁的持有信息依赖操作系统提供的工具，不同系统的操作方式如下：

• Linux/macOS：使用lsof命令，例如执行lsof /path/to/index/write.lock，输出中的PID列即为持有锁的进程ID；若要查看该进程内的具体线程，可执行ps -T -p <PID>。
• Windows：使用Sysinternals工具集中的handle.exe，执行handle.exe C:\path\to\index\write.lock，结果会显示持有锁的进程ID及线程信息。

五、参考资料 #

• Lucene官方文档：《Lucene Index Locking》章节（详细描述了索引锁的设计逻辑、锁类型及异常处理）
• SQLite官方文档：《File Locking And Concurrency In SQLite Version 3》
• Git官方文档：《Git Internals - Maintenance and Data Recovery》中关于仓库锁机制的内容

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