Java单应用实例最佳实现方式及方案选型疑问

没有什么玄乎的设计考量，全是工程落地踩坑踩出来的选择：

• 文件锁的跨环境兼容性在服务端场景下根本不可靠
  Java的FileLock是直接映射操作系统原生的文件锁能力，不是JVM自己实现的统一逻辑，不同平台、不同文件系统的行为差异极大：Windows下默认是强制锁，被锁定的文件其他进程连读取权限都没有；Linux下不同内核版本、不同发行版对建议锁、强制锁的支持不一致，尤其是现在服务端普遍运行在容器、分布式存储环境中，NFS、overlayfs这类文件系统经常出现锁状态异常——要么进程已经退出锁没被正常释放，要么两个进程同时拿到锁，这类问题排查成本极高，线上出一次就是严重故障。
• 标记文件能提供文件锁不具备的运维价值
  服务端用的标记文件从来不是空文件，比如Play Framework的RUNNING_PID文件里直接写入当前进程的PID。运维人员做优雅停机、配置热重载、进程存活巡检的时候，直接读这个文件就能拿到进程号，不用再通过ps、jps遍历进程匹配启动参数找目标应用，能省非常多运维侧的工作量。文件锁本身承载不了这类附加信息，也没有额外的元数据可以存这类内容。
• “异常退出残留文件”的缺陷，在服务端场景下完全可以被抹平
  你觉得残留文件需要手动删除很麻烦，这其实是桌面客户端场景的痛点——普通用户根本不知道应用的标记文件存在哪个目录，出了问题完全不知道怎么清理。但服务端部署全是标准化流程：启动脚本在拉起应用前就会先检查旧的标记文件，读取里面的PID去系统进程表查询对应进程是否真的存活，如果进程已经不存在，直接删掉旧标记文件再正常启动；如果进程确实在运行，就提示已有实例运行后退出。整个流程全是脚本自动完成，根本不需要人工介入，所谓的方案劣势在标准化运维体系里根本不算问题。
• 标记文件的实现逻辑更简单，可靠性更高
  用文件锁实现单实例的话，你需要一直持有打开的RandomAccessFile流引用不能关闭，一旦流被意外回收、关闭，持有的文件锁会自动释放，单实例约束直接失效，代码里要额外处理流的生命周期，多写不少容易出bug的逻辑。而标记文件方案就是启动时检查、写入PID，注册个JVM关闭钩子在正常退出时删掉文件，逻辑简单到几乎不可能写错，长期运行的稳定性比文件锁高得多。

关于你提到的选型规律，确实和场景强相关，但核心影响因素不是性能：

桌面客户端类应用适合选文件锁，是因为客户端跑在用户个人设备上，没有配套运维脚本处理残留文件，普通用户也没有能力手动清理，文件锁在进程异常退出后自动释放的特性刚好匹配这个场景，而且桌面端基本都是跑在物理机本地文件系统上，文件锁的兼容性坑比较少。
服务端应用适合选无锁标记文件，是因为服务端有标准化的部署运维流程，可以低成本解决残留文件的问题，同时标记文件能提供运维需要的PID信息，再加上容器、虚拟化环境下文件锁兼容性太差，自然就成了框架的默认选择。

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