实现文件内容覆盖的实时检测，本质上要解决两个问题：第一是快速感知文件发生了变化，第二是确认这种变化是内容覆盖而不是简单的时间戳或权限调整。Apache Commons IO 的 monitor 包在这方面提供了一个很务实的方案，它不依赖操作系统底层的事件通知，而是用固定间隔扫描目录并比较文件元数据快照。这个机制虽然存在轮询延迟，但胜在跨平台稳定、代码量少，适合中小规模目录和已有 Commons IO 依赖的项目。

基于元数据的监听机制

FileAlterationObserver 是 Apache Commons IO 里负责目录观察的核心类。它会在内存中维护一个 FileEntry 快照，记录每个文件的名称、长度和最后修改时间。每次调用 checkAndNotify 方法时，观察者重新遍历目录，生成新的 FileEntry 列表，然后与旧快照逐项比较。如果某个文件的长度或最后修改时间发生变化，就会触发 onFileChange 回调；如果文件消失则触发 onFileDelete，新文件出现则触发 onFileCreate。

这种基于元数据的比较有一个明显的好处：它不需要深入了解操作系统的事件模型。无论是 Windows、Linux 还是 macOS，只要 Java 能列出目录并读取文件属性，监听逻辑就能工作。FileAlterationMonitor 则是定时触发观察者的调度器，构造时传入轮询间隔和观察者实例即可。下面的示例建立一个每 1000 毫秒扫描一次目录的监听器，先打印所有变化事件。

import org.apache.commons.io.monitor.FileAlterationListenerAdaptor;
import org.apache.commons.io.monitor.FileAlterationMonitor;
import org.apache.commons.io.monitor.FileAlterationObserver;
import java.io.File;
public class MetaChangeMonitor {
    public static void main(String[] args) throws Exception {
        File directory = new File("C:\\data\\watch");
        FileAlterationObserver observer = new FileAlterationObserver(directory);
        observer.addListener(new FileAlterationListenerAdaptor() {
            @Override
            public void onFileChange(File file) {
                System.out.println("检测到文件元数据变化: " + file.getAbsolutePath());
            }
        });
        FileAlterationMonitor monitor = new FileAlterationMonitor(1000, observer);
        monitor.start();
        Thread.sleep(60000);
        monitor.stop();
    }
}

不过要小心，onFileChange 触发并不等于文件内容真的被覆盖。因为 FileEntry 比较的是文件长度和最后修改时间，如果文件被重写后长度恰好相同，并且写入工具保留了原始时间戳，或者文件系统时间精度较粗，就可能出现漏报。反过来，有些操作只修改了元数据但没有重写内容，也会触发事件。因此，若想确认文件内容确实被覆盖，还需要在回调里增加内容摘要比对。

增加内容摘要比对

内容摘要比对的核心思路是：第一次看到某个文件时记录它的指纹，后续每次收到 onFileChange 回调时重新计算指纹，并与上一次记录的值比较。如果指纹不同，说明文件字节序列发生了变化，可以认定为内容覆盖。Apache Commons IO 提供了 FileUtils.checksumCRC32 方法，它利用 CRC32 算法对文件内容生成 32 位校验值，速度很快，适合实时检测场景。如果对碰撞风险有更高要求，也可以换成 MD5 或 SHA-256，但代价是计算时间会增加。

这里要注意一个细节：在回调里读取文件时，文件可能正在被另一个线程或进程写入。如果恰好读到半写状态，计算出的摘要既不是旧内容也不是最终新内容，下一次扫描还会再触发一次变化。处理这个问题的常见策略有两种：一种是监听方捕获 IOException 后稍后重试；另一种是从写入方入手，让写入过程先写临时文件，写完后再原子替换目标文件。多数生产环境会优先推荐后者，因为它可以从根本上减少读取到中间状态的概率。

import org.apache.commons.io.FileUtils;
import java.io.File;
import java.io.IOException;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
public class ContentFingerprintHandler {
    private final Map<String, Long> lastCrc = new ConcurrentHashMap<>();
    public void onFileChange(File file) {
        try {
            long crc = FileUtils.checksumCRC32(file);
            String key = file.getCanonicalPath();
            Long old = lastCrc.put(key, crc);
            if (old != null && old.longValue() != crc) {
                System.out.println("确认文件内容已被覆盖: " + key + " 旧CRC=" + old + " 新CRC=" + crc);
            } else if (old == null) {
                System.out.println("首次记录文件指纹: " + key + " CRC=" + crc);
            }
        } catch (IOException e) {
            System.err.println("文件读取失败，可能正在写入: " + file.getAbsolutePath() + " 原因: " + e.getMessage());
        }
    }
}

上面的代码使用 ConcurrentHashMap 保存每个文件的 CRC32 指纹。put 方法会返回旧值，如果旧值存在且不同于新值，就输出覆盖确认信息。如果文件第一次出现，只记录指纹而不报覆盖，避免初始扫描时大量误报。使用 canonicalPath 作为 key 可以消除软链接和大小写路径造成的重复判断。

还需要注意，FileUtils.checksumCRC32 内部会打开文件输入流并按缓冲块读取文件，对于几百 MB 的大文件来说，每次变化都全量计算仍然会有可感知的开销。如果监控目录里大文件很少，这种开销可以接受；如果大文件频繁变化，可以考虑先通过文件长度快速过滤，长度没变再进入哈希比对。但正如前面所说，长度相同仍可能内容覆盖，所以长度过滤只能作为第一层优化，不能替代内容指纹。

完整示例与轮询间隔选择

把上面两部分组合起来，就能得到一个可运行的覆盖检测器。下面的类封装了观察者、监听器和摘要缓存，对外提供 start 和 stop 方法。当目录下的文件被覆盖时，控制台会输出旧 CRC 和新 CRC，并提示文件被重写。这个实现可以直接嵌入到配置热加载、日志文件监控、数据同步检查等业务场景中。

import org.apache.commons.io.FileUtils;
import org.apache.commons.io.monitor.FileAlterationListenerAdaptor;
import org.apache.commons.io.monitor.FileAlterationMonitor;
import org.apache.commons.io.monitor.FileAlterationObserver;
import java.io.File;
import java.io.IOException;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
public class OverwriteDetector {
    private final Map<String, Long> lastCrc = new ConcurrentHashMap<>();
    private FileAlterationMonitor monitor;
    public void start(File directory, long intervalMs) throws Exception {
        FileAlterationObserver observer = new FileAlterationObserver(directory);
        observer.addListener(new FileAlterationListenerAdaptor() {
            @Override
            public void onFileChange(File file) {
                handleChange(file);
            }
        });
        monitor = new FileAlterationMonitor(intervalMs, observer);
        monitor.start();
        System.out.println("覆盖检测已启动，目录: " + directory.getAbsolutePath());
    }
    private void handleChange(File file) {
        try {
            long crc = FileUtils.checksumCRC32(file);
            String key = file.getCanonicalPath();
            Long old = lastCrc.put(key, crc);
            if (old != null && old.longValue() != crc) {
                System.out.println("文件内容已被覆盖: " + key + " 旧CRC=" + old + " 新CRC=" + crc);
            } else if (old == null) {
                System.out.println("首次记录文件指纹: " + key + " CRC=" + crc);
            }
        } catch (IOException e) {
            System.err.println("文件读取失败，可能正在写入: " + file.getAbsolutePath() + " 原因: " + e.getMessage());
        }
    }
    public void stop() throws Exception {
        if (monitor != null) {
            monitor.stop();
            System.out.println("覆盖检测已停止。");
        }
    }
    public static void main(String[] args) throws Exception {
        OverwriteDetector detector = new OverwriteDetector();
        detector.start(new File("C:\\data\\watch"), 800);
        Thread.sleep(120000);
        detector.stop();
    }
}

轮询间隔直接决定实时性。设置为 500 毫秒，程序能更快发现覆盖，但目录文件很多时 CPU 和 IO 压力会上升。设置为 2000 毫秒，开销明显下降，但覆盖发生后可能要等将近两秒才会收到事件。实际项目中，如果覆盖动作来自后台任务或定期同步，1 秒左右通常是性价比较高的选择。可以先压测一下目标目录的扫描耗时，再把间隔设置成扫描耗时的两到三倍。

与 Java NIO WatchService 的对比

Java 7 引入了 WatchService，它基于操作系统的事件通知来监测文件变化，实时性通常比轮询更好。但它也有自己的问题，例如在部分平台上事件可能丢失或重复，递归监听目录时需要手动注册每个子目录，而且事件中只包含文件名和事件类型，不直接提供文件属性。相比之下，Apache Commons IO 的 FileAlterationMonitor 虽然依赖轮询，但实现简单、行为可预期，并且能直接拿到 File 对象，方便做后续内容校验。

如果已经确定只有少量关键文件需要监控，使用 WatchService 配合 Commons IO 的 FileUtils 做内容摘要也是一个高效组合。先用 WatchService 收到触发信号，再调用 FileUtils.checksumCRC32 确认内容是否真的覆盖，可以减少不必要的哈希计算。如果监控对象是一整个目录下的所有文件，且目录规模不大，直接使用 FileAlterationMonitor 会让代码更加集中和易维护。

综合来看，Apache Commons IO 提供的目录监控组件并不是操作系统级事件监听的替代品，而是一种更偏工程化的折中方案。它把元数据扫描和事件回调封装得很干净，加上内容摘要比对后，可以满足大多数文件覆盖检测需求。只要控制好轮询间隔和文件数量，这套方案在配置热加载、数据文件同步、日志变化监控等场景里都能稳定工作。