背景
在钻研规定引擎时，如果规定以文件的模式存储，那么就须要监听指定的目录或文件来感知规定是否变动，进而进行加载。当然，在其余业务场景下，比方想实现配置文件的动静加载、日志文件的监听、FTP文件变动监听等都会遇到相似的场景。
本文给大家提供三种解决方案，并剖析其中的利弊，倡议珍藏，以备不时之需。
计划一：定时工作 + File#lastModified
这个计划是最简略，最能间接想到的解决方案。通过定时工作，轮训查问文件的最初批改工夫，与上一次进行比照。如果发生变化，则阐明文件曾经批改，进行从新加载或对应的业务逻辑解决。
在上篇文章《JDK的一个Bug，监听文件变更要小心了》中曾经编写了具体的实例，并且也提出了其中的有余。
这里再把实例代码贴出来：
public class FileWatchDemo { /** * 上次更新工夫 */ public static long LAST_TIME = 0L; public static void main(String[] args) throws IOException { String fileName = "/Users/zzs/temp/1.txt"; // 创立文件，仅为实例，实际中由其余程序触发文件的变更 createFile(fileName); // 执行2次 for (int i = 0; i < 2; i++) { long timestamp = readLastModified(fileName); if (timestamp != LAST_TIME) { System.out.println("文件已被更新：" + timestamp); LAST_TIME = timestamp; // 从新加载，文件内容 } else { System.out.println("文件未更新"); } } } public static void createFile(String fileName) throws IOException { File file = new File(fileName); if (!file.exists()) { boolean result = file.createNewFile(); System.out.println("创立文件：" + result); } } public static long readLastModified(String fileName) { File file = new File(fileName); return file.lastModified(); }}对于文件低频变动的场景，这种计划实现简略，基本上能够满足需要。不过像上篇文章中提到的那样，须要留神Java 8和Java 9中File#lastModified的Bug问题。
但该计划如果用在文件目录的变动上，毛病就有些显著了，比方：操作频繁，效率都损耗在遍历、保留状态、比照状态上了，无奈充分利用OS的性能。
计划二：WatchService
在Java 7中新增了java.nio.file.WatchService，通过它能够实现文件变动的监听。WatchService是基于操作系统的文件系统监控器，能够监控零碎所有文件的变动，无需遍历、无需比拟，是一种基于信号收发的监控，效率高。
public class WatchServiceDemo { public static void main(String[] args) throws IOException { // 这里的监听必须是目录 Path path = Paths.get("/Users/zzs/temp/"); // 创立WatchService，它是对操作系统的文件监视器的封装，绝对之前，不须要遍历文件目录，效率要高很多 WatchService watcher = FileSystems.getDefault().newWatchService(); // 注册指定目录应用的监听器，监督目录下文件的变动； // PS：Path必须是目录，不能是文件； // StandardWatchEventKinds.ENTRY_MODIFY，示意监督文件的批改事件 path.register(watcher, StandardWatchEventKinds.ENTRY_MODIFY); // 创立一个线程，期待目录下的文件发生变化 try { while (true) { // 获取目录的变动: // take()是一个阻塞办法，会期待监视器收回的信号才返回。 // 还能够应用watcher.poll()办法，非阻塞办法，会立刻返回过后监视器中是否有信号。 // 返回后果WatchKey，是一个单例对象，与后面的register办法返回的实例是同一个； WatchKey key = watcher.take(); // 解决文件变动事件： // key.pollEvents()用于获取文件变动事件，只能获取一次，不能反复获取，相似队列的模式。 for (WatchEvent<?> event : key.pollEvents()) { // event.kind()：事件类型 if (event.kind() == StandardWatchEventKinds.OVERFLOW) { //事件可能lost or discarded continue; } // 返回触发事件的文件或目录的门路（相对路径） Path fileName = (Path) event.context(); System.out.println("文件更新: " + fileName); } // 每次调用WatchService的take()或poll()办法时须要通过本办法重置 if (!key.reset()) { break; } } } catch (Exception e) { e.printStackTrace(); } }}上述demo展现了WatchService的根本应用形式，注解局部也阐明了每个API的具体作用。
通过WatchService监听文件的类型也变得更加丰盛：
- ENTRY_CREATE 指标被创立
- ENTRY_DELETE 指标被删除
- ENTRY_MODIFY 指标被批改
- OVERFLOW 一个非凡的Event，示意Event被放弃或者失落
如果查看WatchService实现类（PollingWatchService）的源码，会发现，实质上就是开启了一个独立的线程来监控文件的变动：
PollingWatchService() { // TBD: Make the number of threads configurable scheduledExecutor = Executors .newSingleThreadScheduledExecutor(new ThreadFactory() { @Override public Thread newThread(Runnable r) { Thread t = new Thread(null, r, "FileSystemWatcher", 0, false); t.setDaemon(true); return t; }}); }也就是说，原本须要咱们手动实现的局部，也由WatchService外部帮咱们实现了。
如果你编写一个demo，进行验证时，会很显著的感觉到WatchService监控文件的变动并不是实时的，有时候要等几秒才监听到文件的变动。以实现类PollingWatchService为例，查看源码，能够看到如下代码：
void enable(Set<? extends Kind<?>> var1, long var2) { synchronized(this) { this.events = var1; Runnable var5 = new Runnable() { public void run() { PollingWatchKey.this.poll(); } }; this.poller = PollingWatchService.this.scheduledExecutor.scheduleAtFixedRate(var5, var2, var2, TimeUnit.SECONDS); } }也就是说监听器由依照固定工夫距离的调度器来管制的，而这个工夫距离在SensitivityWatchEventModifier类中定义：
public enum SensitivityWatchEventModifier implements Modifier { HIGH(2), MEDIUM(10), LOW(30); // ...}该类提供了3个级别的工夫距离，别离为2秒、10秒、30秒，默认值为10秒。这个工夫距离能够在path#register时进行传递：
path.register(watcher, new WatchEvent.Kind[]{StandardWatchEventKinds.ENTRY_MODIFY}, SensitivityWatchEventModifier.HIGH);绝对于计划一，实现起来简略，效率高。有余的中央也很显著，只能监听当前目录下的文件和目录，不能监督子目录，而且咱们也看到监听只能算是准实时的，而且监听工夫只能取API默认提供的三个值。
该API在Stack Overflow上也有人提出Java 7在Mac OS下有提早的问题，甚至波及到Windows和Linux零碎，笔者没有进行其余操作系统的验证，如果你遇到相似的问题，可参考对应的文章，寻求解决方案：https://blog.csdn.net/claram/... 。
计划三：Apache Commons-IO
计划一咱们本人来实现，计划二借助于JDK的API来实现，计划三便是借助于开源的框架来实现，这就是简直每个我的项目都会引入的commons-io类库。
引入相应依赖：
<dependency> <groupId>commons-io</groupId> <artifactId>commons-io</artifactId> <version>2.7</version></dependency>留神，不同的版本须要不同的JDK反对，2.7须要Java 8及以上版本。
commons-io对实现文件监听的实现位于org.apache.commons.io.monitor包下，根本应用流程如下：
- 自定义文件监听类并继承
FileAlterationListenerAdaptor实现对文件与目录的创立、批改、删除事件的解决； - 自定义文件监控类，通过指定目录创立一个观察者
FileAlterationObserver； - 向监视器增加文件系统观察器，并增加文件监听器；
- 调用并执行。
第一步：创立文件监听器。依据须要在不同的办法内实现对应的业务逻辑解决。
public class FileListener extends FileAlterationListenerAdaptor { @Override public void onStart(FileAlterationObserver observer) { super.onStart(observer); System.out.println("onStart"); } @Override public void onDirectoryCreate(File directory) { System.out.println("新建：" + directory.getAbsolutePath()); } @Override public void onDirectoryChange(File directory) { System.out.println("批改：" + directory.getAbsolutePath()); } @Override public void onDirectoryDelete(File directory) { System.out.println("删除：" + directory.getAbsolutePath()); } @Override public void onFileCreate(File file) { String compressedPath = file.getAbsolutePath(); System.out.println("新建：" + compressedPath); if (file.canRead()) { // TODO 读取或从新加载文件内容 System.out.println("文件变更，进行解决"); } } @Override public void onFileChange(File file) { String compressedPath = file.getAbsolutePath(); System.out.println("批改：" + compressedPath); } @Override public void onFileDelete(File file) { System.out.println("删除：" + file.getAbsolutePath()); } @Override public void onStop(FileAlterationObserver observer) { super.onStop(observer); System.out.println("onStop"); }}第二步：封装一个文件监控的工具类，外围就是创立一个观察者FileAlterationObserver，将文件门路Path和监听器FileAlterationListener进行封装，而后交给FileAlterationMonitor。
public class FileMonitor { private FileAlterationMonitor monitor; public FileMonitor(long interval) { monitor = new FileAlterationMonitor(interval); } /** * 给文件增加监听 * * @param path 文件门路 * @param listener 文件监听器 */ public void monitor(String path, FileAlterationListener listener) { FileAlterationObserver observer = new FileAlterationObserver(new File(path)); monitor.addObserver(observer); observer.addListener(listener); } public void stop() throws Exception { monitor.stop(); } public void start() throws Exception { monitor.start(); }}第三步：调用并执行：
public class FileRunner { public static void main(String[] args) throws Exception { FileMonitor fileMonitor = new FileMonitor(1000); fileMonitor.monitor("/Users/zzs/temp/", new FileListener()); fileMonitor.start(); }}执行程序，会发现每隔1秒输出一次日志。当文件产生变更时，也会打印出对应的日志：
onStart批改：/Users/zzs/temp/1.txtonStoponStartonStop当然，对应的监听工夫距离，能够通过在创立FileMonitor时进行批改。
该计划中监听器自身会启动一个线程定时解决。在每次运行时，都会先调用事件监听解决类的onStart办法，而后查看是否有变动，并调用对应事件的办法；比方，onChange文件内容扭转，查看完后，再调用onStop办法，开释以后线程占用的CPU资源，期待下次间隔时间到了被再次唤醒运行。
监听器是基于文件目录为本源的，也能够能够设置过滤器，来实现对应文件变动的监听。过滤器的设置可查看FileAlterationObserver的构造方法：
public FileAlterationObserver(String directoryName, FileFilter fileFilter, IOCase caseSensitivity) { this(new File(directoryName), fileFilter, caseSensitivity);}小结
至此，基于Java实现监听文件变动的三种计划便介绍结束。通过上述剖析及实例，大家曾经看到，并没有完满的解决方案，依据本人的业务状况及零碎的容忍度可抉择最适宜的计划。而且，在此基础上能够新增一些其余的辅助措施，来防止具体计划中的不足之处。
博主简介：《SpringBoot技术底细》技术图书作者，热爱钻研技术，写技术干货文章。
公众号：「程序新视界」，博主的公众号，欢送关注~
技术交换：请分割博主微信号：zhuan2quan