Java实现isFileClosed校验：兼顾未创建不抛错与准确检测文件占用

• 现有实现的本质问题是用同一个“打开失败”的结果覆盖了两类完全无关的异常场景：
  • 第一类是目标文件本身不存在、路径无访问权限、路径指向目录等情况，打开时会触发FileNotFoundException，这类场景和“文件被其他进程占用”没有任何关系
  • 第二类是目标文件真实存在，但被其他进程以独占读写模式锁定，Linux环境下打开时会触发IOException（对应系统错误EBUSY，即资源忙），这类才是真正需要识别的“文件被占用未关闭”场景
• 之前“单独捕获FileNotFoundException就会导致检测失效”的判断是常见的认知误区：文件被独占占用触发的异常根本不属于FileNotFoundException的子类，只要按异常类型做分类捕获，完全不会干扰占用状态的识别，更不会让检测逻辑失效。之前调整后失效，基本都是因为异常捕获顺序写反了——先抓了父类的Exception或IOException，把本该分类处理的FileNotFoundException提前拦截了。

明确三类核心场景的判定规则：

1. 成功获取文件通道：说明无进程占用，判定为文件已关闭
2. 捕获到FileNotFoundException：说明打开失败的原因是文件不存在/路径不合法，不属于占用场景，按需求直接判定为无占用，不会抛非预期异常
3. 捕获到其他IOException：说明文件存在但被独占锁定，判定为文件未关闭，符合占用状态的识别要求

调整后的代码示例：

private boolean isFileClosed(File file) {
    boolean closed = true;
    FileChannel channel = null;
    try {
        // 以读写模式打开通道，被其他进程独占时会直接触发IO异常
        channel = new RandomAccessFile(file, "rw").getChannel();
    } catch (FileNotFoundException ex) {
        // 文件不存在类异常，直接判定为无占用
        closed = true;
    } catch (IOException ex) {
        // 资源被占用类异常，判定为未关闭
        closed = false;
    } finally {
        if (channel != null) {
            try {
                channel.close();
            } catch (IOException ex) {
                // 通道关闭失败可记录日志，不影响核心判定结果
            }
        }
    }
    return closed;
}

• 异常捕获顺序必须严格遵守“子类在前、父类在后”的规则：必须先捕获范围更小的FileNotFoundException，再捕获范围更大的IOException，反过来写会导致FileNotFoundException被上层catch块提前拦截，达不到分类判定的效果
• 这套逻辑跨平台兼容性良好：Windows环境下文件被独占占用时，同样会抛IOException而非FileNotFoundException，分类判定逻辑无需额外修改
• 捕获FileNotFoundException时不要主动创建空文件：这个操作会改动目标路径的文件状态，可能对上层业务的文件创建逻辑造成意外干扰
• 该检测逻辑仅能识别“独占读写模式的占用”，无法识别仅以共享读模式打开的文件，如果业务需要覆盖这类场景，需要结合系统层的进程文件扫描结果做二次校验

内容的提问来源于stack exchange，提问作者gus