Files.delete() 删除失败时不统一抛出特定子类异常，Windows 常抛 FileSystemException（含“used by another process”），Linux/macOS 多为 AccessDeniedException 或 IOException（含“busy”）；应组合判断异常类型与消息关键词，并辅以 Files.exists() 和 Files.isWritable() 验证。
Files.delete() 删除失败时抛出的 IOException 具体是什么类型
Java 的 Files.delete() 在文件被占用（如正被其他进程读写、在资源管理器中打开、或被 JVM 自身的 FileInputStream 持有句柄）时，**不统一抛出某个子类异常**，而是取决于底层操作系统返回的错误码。Windows 上最常见的是 java.nio.file.FileSystemException（继承自 IOException），错误消息里通常含 "The process cannot access the file because it is being used by another process"；Linux/macOS 则更可能抛 java.nio.file.AccessDeniedException 或原生 IOException，消息含 "Text file busy" 或 "Device or resource busy"。
所以不能依赖 instanceof IOException 做泛化处理，而应捕获 IOException 后检查具体类型和消息内容。
如何精准识别“文件被占用”并区别于其他删除失败原因
关键在于区分「占用」和「权限不足」「路径不存在」「只读」等场景。推荐组合判断：
- 先用
instanceof FileSystemException或instanceof AccessDeniedException快速过滤（Windows/Linux 常见） - 再检查异常消息是否包含典型关键词：
"used by another process"、"busy"、"in use"（注意大小写不敏感） - 避免仅靠消息字符串——某些 JVM 实现或本地化环境会翻译错误文本，所以建议同时结合
Files.isWritable(path)和Files.exists(path)辅助判断：若存在且可写，但删失败，大概率是占用
示例片段：
try {
Files.delete(path);
} catch (IOException e) {
boolean isOccupied = e instanceof FileSystemException
&& e.getMessage().toLowerCase().contains("used by another process");
if (isOccupied) {
// 处理占用逻辑
}
}
删除前主动检测文件是否被占用的可靠方法
Java 没有跨平台 API 能 100% 预判“是否被占用”，但可通过尝试获取独占锁来逼近判断：
- 对普通文件，用
FileChannel.lock()尝试加写锁（需先用RandomAccessFile打开）；加锁失败往往意味着被其他进程持有句柄 - 注意：该方法本身也可能抛
IOException（如文件只读），需兜底处理 - 不适用于目录（
lock()只支持文件），也不保证 100% 准确（某些占用方式绕过文件锁） - 更轻量的做法是：用
Files.deleteIfExists()替代delete()，它失败时不抛异常，可配合后续!Files.exists()判断是否真删掉了
实际项目中建议的容错删除策略
生产环境别指望一次就删掉，尤其 Windows 下临时文件、日志文件极易被占用。推荐分步重试：
- 首次调用
Files.delete()，捕获IOException - 若判定为占用，等待 50–200ms（用
Thread.sleep()），最多重试 3–5 次 - 每次重试前，用
Files.exists()确认文件还在；若已消失，说明已被其他线程/进程删掉，直接退出 - 重试仍失败后，记录带堆栈的 warn 日志，把异常交给上层决定是否跳过或告警——不要静默吞掉
IOException
真正难处理的不是“删不掉”，而是删不掉时要不要阻塞流程、要不要通知用户、要不要走降级路径（比如改名后延后清理）。这些必须根据业务语义定，API 层只负责暴露真实原因。
