Java文件过滤从入门到实战：FileFilter、FilenameFilter与NIO详解

先说明一下，这篇要讲的Filter是java.io.FileFilter，不是Web开发里那个拦截HTTP请求的Servlet Filter。这两者名字太像，搜索"Java Filter用法"的时候特别容易走错门。我之所以专门把文件过滤器拎出来写，是因为前两天刚帮一个同事排查了一段代码：他在一个日志目录里找.log文件，结果把目录对象本身也当成文件处理了，程序跑完生成了一堆脏数据。问题根源就是对FileFilter的用法理解得不完整。

这篇内容我会从FileFilter和FilenameFilter两个经典接口讲起，一直聊到JDK 7以后出现的DirectoryStream.Filter、PathMatcher，以及JDK 8后配合Stream API做递归过滤的写法。适合两类人看：一类是刚学Java、只知道listFiles()然后for循环判断的新手；另一类是工作两三年，想把手里的旧File操作换成NIO思路的开发者。

1. 最常用的入口：File.listFiles与FileFilter的搭配

1.1 FileFilter接口详解与最小实现

java.io.FileFilter是一个从JDK 1.2就存在的接口，结构极其简单，只有一个方法：

@FunctionalInterface public interface FileFilter { boolean accept(File pathname); }

accept方法返回true表示"保留这个文件"，返回false表示"丢弃这个文件"。所谓过滤，本质上就是把"要不要保留"这个判断逻辑从业务代码里抽出来，交给一个独立对象去决策。

先看一个最基础的实现，不用Lambda，用匿名内部类：

File dir = new File("/tmp/app-logs"); FileFilter logFilter = new FileFilter() { @Override public boolean accept(File pathname) { if (!pathname.isFile()) { return false; } return pathname.getName().endsWith(".log"); } }; File[] logFiles = dir.listFiles(logFilter);

这段代码做了两件事：第一，排除目录，只保留普通文件；第二，文件名必须以.log结尾。为什么先调用isFile()？因为目录也有可能叫xxx.log，如果不做这个判断，目录会被误当成文件处理，后续读取内容或统计大小时就会出现奇怪的现象。

FileFilter的参数是完整的File对象，这一点非常关键。你可以在accept里任意调用getName()、length()、lastModified()、isHidden()这些方法，组合出任意复杂条件。这也是我推荐优先使用FileFilter而不是FilenameFilter的原因之一，后面会详细对比。

1.2 listFiles的重载与返回值陷阱

File类的listFiles有好几个重载版本，很多新人看到这里就晕。我整理成一张表：

严格来说，常见的是前三个。这几种方法都有一个极其相似的"坑"：返回的数组可能是null，而不是空数组。当一个File对象不是目录，或者发生I/O错误时，listFiles返回null。一旦写成下面这种代码：

File notDir = new File("/tmp/some-file.txt"); File[] files = notDir.listFiles(f -> true); for (File file : files) { // 这里会空指针 System.out.println(file); }

运行时直接报NullPointerException。最稳妥的写法是：

File[] files = dir.listFiles(filter); if (files == null) { // 说明dir不是目录，或者发生了I/O错误 return; }

如果目录是空的，listFiles返回的是一个长度为0的数组，并不会返回null。这两者区别一定记牢。我建议在工具方法里统一做这个空判断，避免每次调用都重复写一遍。

1.3 从匿名内部类到Lambda

FileFilter是函数式接口，所以JDK 8之后写起来非常简洁。上面那段匿名内部类可以缩成一行：

File[] logFiles = dir.listFiles( pathname -> pathname.isFile() && pathname.getName().endsWith(".log") );

如果过滤逻辑比较复杂，不要硬写在Lambda里，把它抽成一个独立方法，再用方法引用：

public boolean isDailyLog(File file) { return file.isFile() && file.getName().startsWith("app-") && file.getName().endsWith(".log"); } File[] result = dir.listFiles(this::isDailyLog);

方法引用的好处是过滤逻辑可以单独写单元测试，比在Lambda里堆条件更容易维护。我在实际项目里几乎不写那种超过五六个条件的Lambda，目测能看懂，但一个星期后再看就想骂人。

2. FilenameFilter：名字背后藏着另一个参数

2.1 双参数签名带来的便利

FilenameFilter也是一个古老的接口，同样只有一个方法：

@FunctionalInterface public interface FilenameFilter { boolean accept(File dir, String name); }

注意第二个参数name是文件名，不含路径。如果你需要路径，第一个参数dir就是当前父目录的File对象。典型用法：

File[] txtFiles = dir.listFiles((d, name) -> name.toLowerCase().endsWith(".txt"));

因为过滤的只是文件名，不需要构造完整的File对象，所以在这类纯名称过滤场景下会比FileFilter更轻量。

有个小细节值得留意：dir参数不是字符串，而是File对象。如果你需要在过滤规则里拼完整路径，可以这样：

File[] recentFiles = dir.listFiles((d, name) -> { File full = new File(d, name); return full.isFile() && full.lastModified() > someTime; });

但既然都要拼File对象了，直接用FileFilter更简单，没必要绕一圈。

2.2 为什么很多老项目只喜欢拼路径

我在旧代码里经常看到一种写法：FilenameFilter里拿到name之后，自己拼一个new File(d, name)去做判断。出现这种写法的原因在于历史API设计不均衡——FilenameFilter的参数给的是父目录和文件名，而不是一个完整对象，所以想判断文件大小、修改时间，就必须自己拼。

对于这类代码，我一般会建议改成FileFilter，因为FileFilter的入参就是完整的File，可以直接调用各种方法，代码语义也更清楚。但FilenameFilter并没有完全被淘汰，如果你只是判断扩展名，不想为了每次调用都生成一个File对象，它确实省事。

2.3 两者的选择建议

我用一张表总结一下选择思路：

个人经验：新写的代码，80%都用FileFilter。只有当过滤条件真的只和文件名有关，并且你特别在意那一点点对象创建开销时，才考虑FilenameFilter。这不是性能洁癖的问题，而是代码统一性问题——一个项目里同时存在两种filter，后来维护的人每次都要猜你当时为什么这么选。

3. 组装一个可复用的文件过滤器类

3.1 过滤规则拆解：扩展名、目录、大小、时间

实际业务里很难只用一个条件过滤文件。最常见的组合是：只要普通文件、只要指定扩展名、排除隐藏文件、文件大小不小于某个值、最后修改时间在某个区间。

我不建议每次用到的时候都现场写Lambda，而是把公共规则封装成工具类。下面是我经常使用的一种结构，你可以直接抄：

public final class FileFilters { private FileFilters() { } public static FileFilter regularFileOnly() { return File::isFile; } public static FileFilter directoriesOnly() { return File::isDirectory; } public static FileFilter notHidden() { return file -> !file.isHidden(); } public static FileFilter extension(String... extensions) { return file -> { if (!file.isFile()) { return false; } String lowerName = file.getName().toLowerCase(); for (String ext : extensions) { if (lowerName.endsWith("." + ext.toLowerCase())) { return true; } } return false; }; } public static FileFilter sizeAtLeast(long minBytes) { return file -> file.isFile() && file.length() >= minBytes; } public static FileFilter modifiedBetween(long startMillis, long endMillis) { return file -> { long m = file.lastModified(); if (m == 0L) { return false; } return m >= startMillis && m <= endMillis; }; } }

这些静态方法返回的都是FileFilter，可以独立使用，也可以通过简单的&&组合出更复杂的过滤条件。我额外强调一点：lastModified()在发生I/O错误时会返回0L，所以modifiedBetween里专门做了排除，这个细节很容易被忽略。

3.2 用Predicate 替代FileFilter的进阶思路

如果过滤条件需要动态组合，用FileFilter其实不太方便，因为它没有and、or这些默认方法。好在FileFilter的签名和Predicate<File>的签名本质一样，我们可以借助Predicate来组合：

Predicate<File> isLog = f -> f.isFile() && f.getName().endsWith(".log"); Predicate<File> isRecent = f -> f.lastModified() > cutoffTime; File[] files = dir.listFiles(isLog.and(isRecent)::test);

这里最费解的是isLog.and(isRecent)::test这个写法。它的原理是：isLog.and(isRecent)返回一个新的Predicate<File>，然后通过方法引用::test把它转成符合FileFilter签名的逻辑，可以安全地传给listFiles。

如果不喜欢这种写法，也可以自己封装一个组合方法：

public static FileFilter and(FileFilter first, FileFilter second) { return file -> first.accept(file) && second.accept(file); }

两种方式都行。我更倾向于后者，因为对于不熟悉Predicate的同事来说，and方法的可读性明显更高。

3.3 实战示例：清理临时文件脚本

用一个真实感比较强的例子把这些规则串起来。场景：程序运行目录下有个temp文件夹，里面既有业务缓存文件，也有日志文件。现在要清理3天前产生的.log和.tmp文件。

如果你是老派写法：

File tempDir = new File("temp"); long cutoff = System.currentTimeMillis() - TimeUnit.DAYS.toMillis(3); File[] candidates = tempDir.listFiles( FileFilters.regularFileOnly() .and(FileFilters.extension("log", "tmp")) // 注意：这里用了自定义的and方法 .and(FileFilters.modifiedBetween(0, cutoff)) ); if (candidates == null) { return; } for (File file : candidates) { System.out.println("准备删除: " + file.getAbsolutePath()); boolean deleted = file.delete(); if (!deleted) { System.err.println("删除失败: " + file); } }

我故意加了个注意事项：FileFilter没有默认的and方法，所以上面的and需要自己定义。另一个重点是，清理操作最好先打印再删除，至少留个日志，否则误删了文件想找回来就麻烦了。

这段代码可以工作，但它存在一个隐含问题：它只清理当前目录，不递归子目录。如果temp下面还有二级目录，这些文件不会被处理。这时就要考虑NIO的递归遍历方案，下一章专门说。

4. NIO世界里的过滤器：DirectoryStream与PathMatcher

4.1 DirectoryStream.Filter的签名与try-with-resources

JDK 7开始，java.nio.file包提供了DirectoryStream，它是对目录内容的流式迭代接口。和File[]不同，它不是一次性把整个目录列表组装成数组，而是按需迭代，这在处理超大目录时优势明显。

Files.newDirectoryStream有两个常用重载，其中一个接受DirectoryStream.Filter：

DirectoryStream.Filter<Path> filter = entry -> { if (!Files.isRegularFile(entry)) { return false; } String name = entry.getFileName().toString(); return name.endsWith(".log"); }; Path dir = Paths.get("/tmp/app-logs"); try (DirectoryStream<Path> stream = Files.newDirectoryStream(dir, filter)) { for (Path path : stream) { System.out.println(path.getFileName()); } } catch (IOException e) { e.printStackTrace(); }

这里有个必须养成的习惯：DirectoryStream实现了AutoCloseable，所以一定要用try-with-resources，否则文件描述符会一直不释放，运行久了就会报"too many open files"。很多从File[]时代转过来的开发者容易漏掉这个close，这是NIO下的头号坑。

4.2 PathMatcher的glob与regex模式

如果你只是需要按文件名模式过滤，NIO还直接支持glob语法。Files.newDirectoryStream(dir, "*.log")就能列出当前目录下所有.log文件：

try (DirectoryStream<Path> stream = Files.newDirectoryStream(dir, "*.log")) { for (Path path : stream) { System.out.println(path); } }

这里的*.log不是简单的字符串匹配，而是通过PathMatcher解释的glob模式。你也可以显式创建PathMatcher，便于复用：

PathMatcher matcher = FileSystems.getDefault().getPathMatcher("glob:**/*.log"); try (Stream<Path> stream = Files.walk(dir)) { stream.filter(Files::isRegularFile) .filter(matcher::matches) .forEach(System.out::println); }

glob:**/*.log里的**表示可以跨目录匹配，它会匹配dir下的所有子目录中的.log文件。如果只写*.log，匹配的是单级路径，对完整路径/tmp/app-logs/a/b.log就不会生效。我早期在这里栽过跟头，以为*.log能递归匹配，结果漏了一堆文件。

PathMatcher还支持正则模式，把前缀从glob:换成regex:即可：

PathMatcher matcher = FileSystems.getDefault().getPathMatcher("regex:.*\\.log");

说实话，在实际项目里glob已经覆盖了90%的需求，正则用得不多。正则的好处是表达能力强，坏处是写错了很难排查，所以我一般只在确实需要复杂模式时才用。

4.3 Files.walk和Files.find怎么选

回到清理临时文件的场景，如果需要递归处理整个目录树，我优先考虑Files.walk或Files.find。两者都返回Stream<Path>，并且必须放在try-with-resources里。

Files.walk更偏重"遍历路径"，你拿到路径后再自行判断属性；Files.find则在遍历的同时把BasicFileAttributes传进过滤器，省去重复访问文件系统获取元数据的开销。一个典型的Files.find过滤条件如下：

long cutoff = System.currentTimeMillis() - TimeUnit.DAYS.toMillis(3); try (Stream<Path> stream = Files.find( root, Integer.MAX_VALUE, (path, attrs) -> attrs.isRegularFile() && path.getFileName().toString().endsWith(".log") && attrs.lastModifiedTime().toMillis() < cutoff )) { stream.forEach(path -> System.out.println("候选文件: " + path)); }

Files.find的第三个参数是一个BiPredicate<Path, BasicFileAttributes>，你可以在同一个判断里同时使用路径和属性，代码非常紧凑。如果还想跟随符号链接，可以额外传入FileVisitOption.FOLLOW_LINKS，但要注意链接死循环风险，使用前必须确认目录结构可控。

什么时候用walk，什么时候用find？我的判断标准是：如果过滤条件只涉及文件名，用walk就够了，代码更直观；如果过滤条件涉及文件大小、最后修改时间、是否是普通文件这类属性，用find，因为它把属性查询内建到遍历过程中，效率更好。

5. 过滤器实战中容易踩的坑

5.1 返回null不等于空数组

虽然前面提过一次，但这个坑太经典，值得单独展开。listFiles返回null的场合非常隐蔽，尤其是在参数是由外部传入的路径时。比如一个配置项里写的路径是/data/report，但运维部署的时候目录没建出来，等到程序一跑，new File("/data/report").listFiles(filter)直接返回null，接着for循环空指针。

为了防止这种问题，我一般会写一个防御性工具方法：

public static File[] listFilesSafely(File dir, FileFilter filter) { if (dir == null || !dir.isDirectory()) { return new File[0]; } File[] files = dir.listFiles(filter); return files == null ? new File[0] : files; }

调用方永远拿到一个非空数组，后续逻辑就不需要到处判断。这是用牺牲了一点精确性换取整体代码简洁的做法，适合业务场景。如果你需要区分"目录不存在"和"目录为空"这两种状态，那就要保留null判断，不要一刀切。

5.2 隐藏文件与符号链接

Windows和Linux对隐藏文件的定义不一样。Linux下以.开头的文件是隐藏文件，Windows下则依赖文件的隐藏属性。File.isHidden()在跨平台场景下行为不同，测试时要注意运行环境。

另一个容易忽略的是符号链接。在NIO的Files.isRegularFile()里，默认行为是跟随符号链接判断最终目标类型。如果某个链接指向目录，Files.isRegularFile()会返回false，这通常没问题。但反过来，如果你用Files.isDirectory()去过滤，可能会因为跟随链接而进入意想不到的目录树。

更隐蔽的是性能问题：过滤器中大量调用Files.isRegularFile()或Files.isDirectory()，每个方法调用都可能触发一次stat系统调用。在几万文件量的目录下，这种额外开销会变得非常明显。所以我倾向于在过滤条件允许的情况下，先用文件名过滤，把命中的范围缩小，再对少数候选文件做属性判断。

5.3 性能问题：一次性列出还是流式遍历

使用旧版File[]和过滤器时，listFiles会一次性构造出目录下所有File对象。假设目录里有50万个文件，即使最终只保留3个，JVM也要先创建50万个对象。这个内存峰值在低配置服务器上可能直接把应用压垮。

DirectoryStream的优势是按需迭代，配合过滤条件可以尽早拒绝不匹配项，内存压力小很多。但它也不是银弹：如果你在迭代每个条目时都执行昂贵的操作，例如Files.readAttributes或者解压文件头，整体耗时依然会很高。

我建议按照这个顺序思考：

• 只列当前目录，文件量不大，用File.listFiles(FileFilter)，简单直接。
• 目录文件量大，或需要流式处理，用DirectoryStream。
• 需要递归处理整个目录树，用Files.walk。
• 需要递归并且过滤条件依赖文件属性，用Files.find。

5.4 过滤器内异常处理方式

FileFilter.accept声明里没有throws IOException，所以在实现里遇到受检异常会非常别扭。如果你需要读取文件头来判断文件类型，只能在accept内部捕获异常，并决定返回true还是false。

DirectoryStream.Filter则不同，它的accept声明了throws IOException，异常可以继续向上抛。这意味着遍历如果中途遇到异常，整个for循环会中断。你需要做出取舍：是记录日志然后跳过异常文件，还是让遍历立即停止。

我的个人经验是：过滤器里不应该做"读文件内容"这类重操作。过滤阶段只做轻量判断，例如文件名、扩展名、大小、时间。如果需要读文件内容做判断，不如先过滤出一个较小的候选集合，再在业务层面对每个文件做二次判断，这样职责更清晰，也方便分别打日志。

6. 从"过滤"到"决策"：把过滤结果交给下游

6.1 先过滤再排序

过滤之后最常见的需求是排序。无论用File[]还是Stream<Path>，都建议先过滤再排序，这样排序的数据量会小很多。File[]可以这样排：

Arrays.sort(files, Comparator.comparingLong(File::lastModified) .reversed() .thenComparing(File::getName));

Comparator.comparingLong(File::lastModified)按最后修改时间升序，reversed()变成最新的在前，thenComparing(File::getName)保证时间相同的文件按文件名字典序排列，避免排序不稳定导致的结果随机。

在Stream风格里则更直观：

try (Stream<Path> stream = Files.walk(root)) { List<Path> files = stream .filter(Files::isRegularFile) .filter(matcher::matches) .sorted(Comparator.comparingLong(path -> path.toFile().lastModified()).reversed()) .collect(Collectors.toList()); }

这里我有一个提醒：Path.toFile()会创建一个File对象。如果你在遍历几万个路径时反复调用toFile()，会产生大量临时对象。如果确实需要获取修改时间，Files.getLastModifiedTime(path)会更合适，但要注意它抛出IOException，需要在Lambda里处理。

6.2 统计、汇总与批处理

过滤后的结果不仅用于删除，还常用于统计。比如统计日志总大小：

File[] files = safeListFiles(logDir, regularFileOnly()); long total = Arrays.stream(files) .mapToLong(File::length) .sum();

再比如找出最大的文件：

Optional<File> largest = Arrays.stream(files) .max(Comparator.comparingLong(File::length));

批处理时尤其注意：不要在一个还在迭代的DirectoryStream里删除文件。更安全的方法是把命中的路径先收集到List，关闭流之后再做删除或移动：

List<Path> toDelete; try (Stream<Path> stream = Files.find(root, Integer.MAX_VALUE, (p, attrs) -> attrs.isRegularFile())) { toDelete = stream .filter(p -> p.getFileName().toString().endsWith(".log")) .collect(Collectors.toList()); } for (Path path : toDelete) { Files.deleteIfExists(path); }

这样做的好处是，删除操作不会影响正在进行的目录遍历状态，也方便在删除前统一打印一份清单，便于审计。

6.3 我的个人经验与建议

这么多年代码写下来，我对Java文件过滤器的总体感受是：旧API虽然笨重，但胜在简单；NIO虽然更现代，但用起来需要多考虑资源释放和异常处理。对于新项目，我的默认选择已经是Path+Stream，但时不时需要维护老项目，FileFilter依然是不可或缺的基本功。

最后分享一个实用小技巧：如果你的过滤规则会在多处复用，务必把它们沉淀成工具类，并且给方法起一个"看到名字就知道规则"的名称。比如expiredLogFilesOnly(3, TimeUnit.DAYS)就比一堆Lambda条件拼在一起清晰得多。代码是要给别人看的，也是要给三个月后的自己看的，过滤器这种小细节，恰恰能体现一个开发者的工程习惯。