本文深入探讨了在java `timertask`中使用`hashmap`进行文件监控时，`hashmap`在任务执行期间意外清空的问题。文章分析了导致此问题的两个主要原因：`hashmap`的非线程安全性以及对`keyset()`视图的错误操作。通过提供`concurrenthashmap`的使用示例和修正`keyset`操作的逻辑，本文旨在帮助开发者构建健壮的并发文件监控机制，并强调了并发编程中集合操作的注意事项。
在Java应用程序中，使用Timer和TimerTask实现定时任务是一种常见模式，例如用于周期性地监控文件系统变化。然而，当这类任务涉及共享数据结构，特别是像HashMap这样的非线程安全集合时，可能会遇到看似神秘的数据丢失问题。本文将以一个文件目录监控器DirWatcher为例，详细分析HashMap在TimerTask中出现异常清空的原因，并提供专业的解决方案。
问题场景描述
考虑一个DirWatcher类，它继承自TimerTask，旨在监控指定目录下的.json文件。在构造函数中，它会扫描初始文件并将文件路径及其最后修改时间存储在一个HashMap
原始DirWatcher的部分代码如下：
public abstract class DirWatcher extends TimerTask {
// 原始声明，非线程安全
public HashMap files = new HashMap<>();
private final File folder;
public DirWatcher(String path) {
this.folder = new File(path);
// ... 初始化并填充files HashMap ...
// 此时files HashMap包含数据
System.out.println("Constructor: " + files);
}
public final void run() {
// 此时files HashMap可能为空
System.out.println("Run method: " + files);
HashSet checkedFiles = new HashSet<>();
// ... 文件检查逻辑 ...
// 问题所在的代码块：删除已不存在的文件
Set ref = files.keySet(); // 获取的是一个视图
ref.removeAll(checkedFiles); // 直接修改了files HashMap
for (File deletedFile : ref) {
files.remove(deletedFile);
onUpdate(deletedFile, "delete");
}
}
// ... 其他方法 ...
} 在ConfigHandler中，DirWatcher被实例化并通过Timer调度：
立即学习“Java免费学习笔记（深入）”；
public class ConfigHandler {
public ConfigHandler(Instance instance) {
// ... 获取路径 ...
TimerTask configWatch = new DirWatcher(this.path) {
@Override
protected void onUpdate(File file, String action) {
// ... 处理文件更新 ...
}
};
Timer timer = new Timer();
timer.schedule(configWatch, new Date(), 5000); // 每5秒执行一次
}
}根本原因分析与解决方案
HashMap在run()方法中变为空，通常是由以下两个独立但可能同时发生的问题导致的：
1. 线程安全性问题：HashMap与TimerThread
java.util.Timer类在内部使用一个单独的线程（TimerThread）来执行其调度的TimerTask。这意味着DirWatcher实例的构造函数可能在主线程中执行，而run()方法则在TimerThread中执行。java.util.HashMap是一个非线程安全的集合，它不保证在多线程环境下的数据一致性。当多个线程同时访问和修改HashMap时，可能会导致数据丢失、不一致或ConcurrentModificationException。
尽管在示例中没有明确的多线程修改files的场景，但TimerThread对files的访问与主线程的初始化存在时间差。更重要的是，HashMap在非同步访问下的内部结构变化可能导致意想不到的行为。
解决方案：使用ConcurrentHashMap
为了确保在并发环境下的数据安全，应该使用线程安全的Map实现，例如java.util.concurrent.ConcurrentHashMap。ConcurrentHashMap提供了高效的并发访问和修改机制，而无需显式地进行同步。
代码修正：
import java.util.concurrent.ConcurrentHashMap;
// ...
public abstract class DirWatcher extends TimerTask {
// 将HashMap替换为ConcurrentHashMap
public ConcurrentHashMap files = new ConcurrentHashMap<>();
private final File folder;
// ... 构造函数和其他方法保持不变 ...
} 2. keySet()视图的错误操作
即使解决了线程安全性问题，HashMap仍然可能在某些情况下“清空”。这通常是由于对files.keySet()返回的集合进行了不当操作。HashMap.keySet()方法返回的是一个底层HashMap的键的视图。这意味着对这个视图集合的修改（例如add()、remove()、removeAll()等）会直接反映到原始的HashMap上。
在DirWatcher.run()方法中，用于检查已删除文件的逻辑如下：
Setref = files.keySet(); // 获取files的键的视图 ref.removeAll(checkedFiles); // 从视图中移除元素，这会同时从files HashMap中移除对应的键值对
如果checkedFiles集合包含了files中所有的键（例如，在某个时间点所有文件都存在且被检查到），那么ref.removeAll(checkedFiles)操作将从files中移除所有键，从而导致files变为空。接下来的循环for (File deletedFile : ref)将不再执行，因为ref此时也为空。
解决方案：操作keySet的副本
为了避免意外修改原始HashMap，在执行removeAll()等修改操作之前，应该创建keySet()返回集合的一个副本。
代码修正：
import java.util.HashSet;
import java.util.Set;
// ...
public final void run() {
// ...
HashSet checkedFiles = new HashSet<>();
// ... 文件检查逻辑，填充checkedFiles ...
// 创建files.keySet()的副本，而不是直接操作视图
Set ref = new HashSet<>(files.keySet());
ref.removeAll(checkedFiles); // 现在，这个操作只影响ref副本，不影响files
// 遍历ref中剩余的元素，这些是已被删除的文件
for (File deletedFile : ref) {
files.remove(deletedFile); // 从files中移除实际已删除的文件
onUpdate(deletedFile, "delete");
}
} 完整的DirWatcher修正版
结合上述两点修正，一个健壮的DirWatcher实现应该如下：
import java.io.File;
import java.util.Date;
import java.util.HashSet;
import java.util.Set;
import java.util.Timer;
import java.util.TimerTask;
import java.util.concurrent.ConcurrentHashMap; // 导入ConcurrentHashMap
public abstract class DirWatcher extends TimerTask {
// 使用ConcurrentHashMap确保线程安全
public ConcurrentHashMap files = new ConcurrentHashMap<>();
private final File folder;
public DirWatcher(String path) {
this.folder = new File(path);
System.out.println("Watching files on path: " + path);
// 获取初始文件
File[] startingFiles = this.folder.listFiles(file -> file.getName().endsWith(".json"));
if(startingFiles == null || startingFiles.length < 1) return;
for (File file : startingFiles) {
System.out.println("Starting: File is " + file.getName());
files.put(file, file.lastModified());
}
System.out.println("Constructor Init: " + files); // 确认构造函数中已填充
}
@Override
public final void run() {
System.out.println("Run method start: " + files); // 检查run方法开始时files的状态
HashSet checkedFiles = new HashSet<>(); // 用于检查已删除文件
// 检查目录中是否存在新文件或已修改文件
for(File f : getConfigFiles()) {
Long storedModified = files.get(f); // 查看当前是否追踪该文件
checkedFiles.add(f); // 标记为已检查
if(storedModified == null) { // 如果未追踪，则是新文件
files.put(f, f.lastModified());
onUpdate(f, "add");
}
else if(storedModified != f.lastModified()) { // 如果修改时间不同，则是更新文件
files.put(f, f.lastModified()); // 更新追踪信息
onUpdate(f, "modified");
}
}
// 检查已删除文件。
// 创建files.keySet()的副本，避免直接修改原始map
Set ref = new HashSet<>(files.keySet());
ref.removeAll(checkedFiles); // 从副本中移除所有当前目录中存在的文件
// 遍历副本中剩余的元素，这些是已删除的文件
for (File deletedFile : ref) {
files.remove(deletedFile); // 从追踪中移除
onUpdate(deletedFile, "delete");
}
System.out.println("Run method end: " + files); // 检查run方法结束时files的状态
}
public File[] getConfigFiles() {
return folder.listFiles(file -> file.getName().endsWith(".json"));
}
protected abstract void onUpdate(File file, String action);
} 替代方案：java.nio.file.WatchService
虽然TimerTask结合上述修正可以实现文件监控，但Java NIO.2 (java.nio.file) 提供了更强大、更高效的文件系统事件监听机制：WatchService。WatchService基于操作系统原生事件通知，而非轮询，因此资源消耗更低，响应更及时。
使用WatchService通常涉及：
- 创建一个WatchService实例。
- 将要监控的目录注册到WatchService，并指定感兴趣的事件类型（如ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY）。
- 在一个单独的线程中循环调用watchService.take()或poll()方法，以获取文件事件。
对于生产环境下的文件监控，强烈推荐使用WatchService。
总结与最佳实践
在Java中实现定时任务和文件监控时，务必注意以下几点：
- 线程安全：当数据结构在多个线程间共享或由TimerTask等在单独线程中执行的任务访问时，始终使用线程安全的集合（如ConcurrentHashMap、CopyOnWriteArrayList）或通过适当的同步机制保护非线程安全集合。
- 集合视图操作：理解keySet()、entrySet()、values()等方法返回的是底层集合的视图。对这些视图的修改会直接影响原始集合。如果需要进行修改操作而不影响原始集合，请先创建视图的副本。
- 选择合适的API：对于文件系统监控，java.nio.file.WatchService是比TimerTask轮询更优、更高效的解决方案。
- 日志记录：在关键代码路径中添加详细的日志输出，有助于在开发和调试阶段追踪数据状态和程序流程，快速定位问题。
通过遵循这些原则，开发者可以构建出更加健壮、高效且易于维护的并发应用程序。
