Java处理文件占用问题的核心是可控重试策略而非被动等待，需确保流彻底关闭、拆分I/O与文件操作、用Files.exists()和探路方法预检、采用指数退避重试（3–5次，100ms起）、捕获特定异常、配合FileLock协作及优先使用原子替换临时文件。
Java 中处理文件被其他进程短暂占用的问题，核心不是“等它释放”，而是用可控的重试策略避开瞬时冲突，同时避免空转或死等。
重试前先确认是真占用还是资源未释放
很多看似“被占用”的异常，其实是当前 JVM 自身没关好流。比如在 try-with-resources 块里调用 Files.delete()，但 BufferedReader 还没退出作用域——此时不是外部进程占着，而是你自己还拿着句柄。务必确保所有流（FileChannel、BufferedReader、FileOutputStream 等）已在 delete/move 操作前彻底关闭。
- 检查是否在 try 块内就执行了 delete()，应把 I/O 和文件系统操作拆开
- 用 Files.isReadable() / Files.isWritable() 快速探路，但注意这不能替代真实打开尝试
- Windows 下尤其敏感，哪怕只读打开也会加共享锁，影响后续写入
设计带超时和退避的重试逻辑
简单 while(true) + Thread.sleep() 容易卡死或耗尽 CPU。推荐固定次数 + 指数退避，让系统有喘息空间。
- 最多重试 3–5 次，首次等待 100ms，之后每次翻倍（100ms → 200ms → 400ms）
- 捕获明确异常：FileSystemException 或 IOException 中含 “being used”、“access denied” 等关键词
- 每次重试前用 Files.exists() 确认文件还在，避免删掉一半又重试出错
配合 FileLock 做协作式保护（非强制，但有用）
如果多个 Java 进程共用同一文件，且都能改代码，FileLock 可作为轻量级协作信号——不靠它拦住别人，而是靠它提醒“此刻有人正在操作”。
立即学习“Java免费学习笔记（深入）”；
- 用 tryLock() 尝试获取独占锁，成功再读写；失败就触发重试，不阻塞
- 锁范围尽量小：比如只锁数据区（72–end），头信息（0–63）用共享锁供并发读
- 务必在 finally 里 release()，否则锁残留会导致后续所有重试都失败
实在不行就换路径绕开
对写操作，优先采用“写新文件 → 原子替换”模式，从根本上规避占用问题。
- 生成临时文件（如 save.txt.tmp），完整写入并 flush
- 用 Files.move(temp, target, StandardCopyOption.REPLACE_EXISTING) 替换原文件
- move 在大多数文件系统上是原子的，比 delete + create 更可靠
