Files.copy无原子性，REPLACE_EXISTING仅控制覆盖异常，COPY_ATTRIBUTES降低并发安全；真正原子操作需用Files.move配合临时文件实现。
Files.copy 本身不提供原子性选项，REPLACE_EXISTING 不是原子操作，它只是允许覆盖已存在目标文件；而 COPY_ATTRIBUTES 是属性同步行为，与原子性无关。真正影响并发安全的是底层实现路径——只有同文件系统内、使用 Path → Path 的直接复制，且未启用 COPY_ATTRIBUTES 时，才可能触发操作系统级的原子重命名（rename），这是唯一接近“原子性”的保障。
REPLACE_EXISTING 的真实作用：覆盖开关，不是原子承诺
这个选项仅控制“是否抛出 FileAlreadyExistsException”，不改变复制过程的分步本质：
- 默认行为：目标存在 → 直接抛异常，中断操作
- 加上 REPLACE_EXISTING：跳过存在性检查，继续执行复制逻辑（先写内容，再设属性，最后可能 rename）
- 但它无法防止“写入中途被其他进程读取脏数据”，也不保证“整个操作不可分割”——比如复制大文件时，目标文件会经历“空文件→部分写入→完整写入”过程
COPY_ATTRIBUTES 会削弱并发安全性
显式添加 COPY_ATTRIBUTES 可能引入额外风险：
- 触发多次系统调用（stat + chmod + utimes 等），延长操作窗口
- 在某些文件系统上，设置权限或时间戳失败会导致复制中断，留下不一致状态
- 若源文件在复制中被修改，COPY_ATTRIBUTES 可能将过期或冲突的元数据写入目标
- 跨用户或容器环境，chmod 可能因权限不足静默失败或抛 SecurityException
真正提升并发安全的实践方式
想让 Files.copy 在多线程/多进程场景下更可靠，关键不在选项组合，而在流程设计：
- 优先使用临时文件名复制，完成后用 Files.move(..., REPLACE_EXISTING) 原子替换——move 同卷时是 rename，具备 OS 级原子性
- 避免在共享目录中直接覆盖活跃文件；改用带时间戳或 PID 的临时名，由下游按需链接或切换
- 对高敏感文件，加文件锁（FileChannel.lock()）或外部协调（如 ZooKeeper 临时节点）控制写入权
- 不要依赖 COPY_ATTRIBUTES 保持“完全一致”——修改时间、访问时间等本就难以精确同步，应以内容哈希为准
把 REPLACE_EXISTING 当作必要开关，把 COPY_ATTRIBUTES 当作可选但需审慎启用的增强项，把原子性寄托在 move + rename 而非 copy 上，才是实际工程中的稳健做法。
