应放弃预检、改用原子操作+异常捕获来避免竞态；exists()与notExists()均为非原子查询，组合使用既矛盾又无效；正确做法是用createFile()、write(..., CREATE_NEW)等原子方法并捕获对应异常。
单纯用 files.exists() 判断再操作，无法避免竞态风险——两次调用之间文件状态可能被其他线程或进程改变。双重校验（exists() + notexists()）本身不能消除竞态，反而容易造成逻辑混乱；真正有效的做法是**放弃预检、改用原子操作+异常捕获**。
为什么 exists() + notExists() 不构成“双重保险”
这两个方法都是独立的非原子查询：
-
Files.exists(path)返回true只表示“此刻存在”，不代表下一毫秒仍存在 -
Files.notExists(path)返回true表示“此刻不存在”，同样不具持续性 - 把两者串起来写成
if (exists && notExists) {...}是自相矛盾的逻辑，永远不成立 - 即使写成
if (exists()) { ... } else if (notExists()) { ... }，中间仍有时间窗口，无法防止“刚判完存在，立刻被删”这类问题
真正能防竞态的替代方案
不依赖预判，而是让操作本身具备原子语义，并通过异常明确区分状态：
- 用
Files.createFile(path)尝试创建，捕获FileAlreadyExistsException—— 成功即新建，失败即已存在，无中间态 - 用
Files.write(path, data, CREATE_NEW)写入，同样只在文件全新时成功，否则抛FileAlreadyExistsException - 若需覆盖，直接用
Files.write(path, data, CREATE, TRUNCATE_EXISTING)，一次调用完成“存在则清空、不存在则创建” - 如必须预检（例如日志提示），仅作辅助，后续操作仍要按原子方式执行，不能跳过异常处理
何时可谨慎使用 exists() 配合业务逻辑
仅限低并发、非关键路径，且接受小概率误判的场景：
- 启动时加载配置文件，提示“配置不存在，将生成默认配置”——提示后仍用
createFile()创建 - 清理临时目录前快速扫描，发现就删，删失败也忽略——因清理本身不要求强一致性
- 注意：绝不可用于权限控制、计费判断、状态锁等需强一致性的环节
补充：跨进程竞态还需考虑文件系统特性
某些文件系统（如 NFS、某些容器卷）对原子操作的支持较弱，此时建议：
- 优先使用带唯一标识的临时文件名（如 UUID），再用
Files.move(..., ATOMIC_MOVE)替换目标 - 对关键路径加进程级互斥（如
FileLock），但要注意跨平台兼容性 - 避免依赖单次
exists()结果做决策，始终以操作结果为准
