微服务压测因本地文件锁导致停机，本质是多实例并发访问共享路径下的日志、缓存或临时文件且缺乏跨进程互斥控制；表现为日志写入失败、临时文件覆盖、配置热更新中断等，实为锁竞争引发的串行阻塞或静默失败。
微服务在大规模压测时因本地文件锁导致写停机，本质是多个服务实例并发访问同一共享路径下的日志、缓存或临时文件，而未做跨进程互斥控制。这类故障常表现为：日志写入失败、临时文件覆盖、配置热更新中断、甚至服务启动卡死——表面看是“磁盘忙”或“权限拒绝”，实则是锁竞争引发的串行阻塞或静默失败。
识别是否为本地文件锁问题
先确认故障是否真由文件锁触发，而非磁盘满、inode耗尽或NAS挂载异常：
- 查看错误日志中是否含 “Permission denied”、“Text file busy”、“Device or resource busy”、“Invalid argument”（常见于NFS/POSIX锁失效） 等关键词
- 用 lsof + grep 文件路径 检查是否有多个Java进程同时 open 同一文件（尤其是 .log、.tmp、.pid 类）
- 在压测期间执行 strace -p <pid> -e trace=open,openat,flock,fcntl，观察是否存在 flock 返回 -1 或 fcntl 阻塞超时
- 对比单实例压测 vs 多实例压测：若仅多实例时复现，且故障点集中在共用目录（如 /var/log/app/、/tmp/app/），基本可锁定
禁用共享路径下的本地文件锁依赖
最根本的解法是让各服务实例“物理隔离”文件操作，消除锁争抢前提：
- 将日志路径按实例动态化：例如用 spring.application.name}-${server.port}-${PID} 构造唯一 logpath，避免所有实例写入同一文件
- 禁用共享临时目录：不使用 /tmp 或 /var/tmp 存放运行时文件；改用 /data/app/${service_name}/${instance_id}/tmp 这类独占路径
- 移除对本地锁文件（如 .lock、.pid）的强依赖：用 ZooKeeper 临时节点或 Redis SETNX 替代进程级文件锁做主从选举或启动互斥
- 若必须共享配置文件，改用只读挂载（如 NFS ro mount），写操作全部走配置中心（Apollo/Nacos）下发
用原子操作+重试替代直接写
当无法完全规避共享路径（如某些中间件强制要求写固定路径），需用更健壮的写模式绕过锁冲突：
- 写日志/临时文件时，始终采用 先写 ${file}.tmp → 再 rename 到 ${file}。rename 在大多数文件系统上是原子的，且不依赖文件锁
- 对必须加锁的场景（如计数器文件），用 flock(fd, LOCK_EX | LOCK_NB) 非阻塞尝试，失败则 sleep + retry（建议最多 3 次，每次递增 50ms）
- 避免在锁内执行网络调用、数据库查询等长耗时操作——锁持有时间越长，冲突概率指数上升
- Java 应用中慎用
FileChannel.lock()，它在 NFS 上不可靠；优先用java.nio.channels.FileLock配合 try-with-resources 自动释放
压测专项配置加固
大规模压测本身会放大一切并发缺陷，需针对性收紧文件操作边界：
- 关闭非必要日志级别：压测期间将 INFO 日志降为 WARN，减少磁盘 I/O 和锁竞争频次
- 禁用同步刷盘：Logback 中设置
<appender ... async="true">，或 Log4j2 使用 AsyncLogger - 限制单服务实例最大文件句柄数：
ulimit -n 65535，并检查应用是否泄漏 fd（用 lsof -p PID | wc -l 对比） - 若使用容器部署，为每个实例挂载独立 EmptyDir 或 hostPath 卷，彻底隔离存储层
不复杂但容易忽略：很多团队花大力气排查网络或 GC，却没意识到那个被 20 个服务实例反复争夺的 /tmp/app.pid，才是压测中途集体卡住的真正开关。
