Java Scanner.findAll 怎样把匹配结果变成 Stream

如果你想把一段文本里所有符合正则的片段接入 Stream，Scanner.findAll(Pattern) 会直接返回一个有序的 Stream。最小写法是先准备 Pattern，再用 map(MatchResult::group) 提取匹配文本；但要把 Scanner 和流放在同一个生命周期里管理，因为终结操作完成后 Scanner 不能继续复用。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/Scanner.html

结论：把 Scanner.findAll 当成“从当前扫描位置产生有序匹配流”的 API，而不是按 delimiter 逐个取 token。小输入可以直接收集结果；大输入或可能持续到来的输入，要先评估阻塞、缓冲和资源关闭边界。

先分清 findAll 和按分隔符扫描

Scanner 常被用来按分隔符读取 token，但 findAll 的匹配独立于 delimiter。它按照给定的 Pattern 查找匹配项，返回顺序稳定的顺序流；真正开始扫描是在流的终结操作启动时，而不是调用 findAll 的那一刻。

这意味着下面三件事要同时记住：

• MatchResult 表示一次匹配，可以通过 group() 读取完整文本，也可以读取捕获组。
• 返回流是 sequential、ordered 的；不要在流执行期间再用同一个 Scanner 调用其它扫描方法。
• 流完成后 Scanner 处于不可继续依赖的状态，外部资源需要由 Scanner 或返回流负责关闭。

用 Pattern 调用 findAll 并提取匹配文本

下面的例子从文件中找出形如 ERR-数字 的标识，并把 MatchResult 映射成字符串。代码只展示 API 关系，不代表已经在某台机器上运行过。

import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.List;
import java.util.Scanner;
import java.util.regex.MatchResult;
import java.util.regex.Pattern;
import java.util.stream.Stream;

public class ErrorCodeReader {
    public static List readCodes(Path path) throws Exception {
        Pattern code = Pattern.compile("ERR-\\d+"); // 只匹配错误编号，不把分隔符当成规则

        try (Scanner scanner = new Scanner(path, StandardCharsets.UTF_8);
             Stream matches = scanner.findAll(code)) { // 流关闭时一并释放 Scanner
            return matches
                    .map(MatchResult::group) // 把匹配对象转换成完整文本
                    .toList(); // 终结操作启动实际扫描，并收集结果
        }
    }
}

这里的关键不是 toList() 本身，而是类型转换关系：Stream 先经过 map 变成 Stream，最后才收集为列表。若只需要捕获组，可以写成 map(match -> match.group(1))，前提是正则表达式确实定义了该组。

把 Scanner 和返回流绑定在同一个生命周期

Oracle API 对 findAll 的说明有一个容易忽略的边界：扫描从终结操作开始，流执行期间不要再调用 Scanner 的其它方法；执行完成后 Scanner 不能再作为可复用扫描器依赖。

因此推荐使用 try-with-resources。把 Scanner 和 Stream 都列为资源，能覆盖文件句柄、输入流和 Scanner 本身。若只把 Stream 交给下游，却让 Scanner 在外层长期存活，后续代码很容易误用同一个扫描状态。

static long countWords(Path path, Pattern word) throws Exception {
    try (Scanner scanner = new Scanner(path, StandardCharsets.UTF_8);
         Stream matches = scanner.findAll(word)) {
        return matches
                .peek(match -> {
                    // 只记录轻量指标，避免把每个匹配复制到额外集合
                })
                .count(); // 终结操作完成后，try-with-resources 负责关闭资源
    }
}

如果输入来自一个必须由调用方管理的 Reader，关闭 Scanner 也会影响底层资源，因此需要先约定“谁拥有关闭责任”。如果把返回流交给其它方法处理，也可以只把流放进 try-with-resources，但不要在流消费期间继续操作 Scanner。

用可复现指标判断是否适合大输入

findAll 会持续寻找下一个匹配项；对可能还没有结束的输入，它可能等待更多数据，也可能为了寻找匹配而缓冲不确定长度的内容。不要只用“代码能返回”判断是否适合生产数据，至少记录下面三项指标：

小文件、有限字符串和一次性离线处理通常适合这种写法。如果输入是长连接、管道或没有明确结束标志的 Reader，优先重新设计读取边界，或者使用能表达上限的解析方式；不要把 findAll 当作无限输入的背压机制。

常见问题：为什么看起来没有匹配或抛出异常

调用 findAll 后立刻读取结果，为什么还没有扫描？

因为它返回的是惰性流，实际扫描在终结操作启动时发生。把 findAll 返回值保存起来但没有 count、toList 或其它终结操作，不会得到最终匹配集合。

findAll 为什么不按 delimiter 切出的 token 工作？

该方法独立于 delimiter，查找的是 Pattern 在输入中的匹配。需要逐 token 读取时使用 hasNext、next 等 API；需要按正则找片段时使用 findAll。

流消费后还能再次调用 scanner.findAll 吗？

不建议。官方 API 将 Scanner 描述为执行完成后处于不可确定状态，调用方应把一次扫描封装在一个方法中；若需要第二种规则，重新创建 Scanner 或重新打开输入。

为什么大文件处理时程序像是卡住了？

可能是输入仍在等待更多内容，也可能是 Pattern 需要继续寻找匹配而导致缓冲增长。先用有限文件和明确计数验证规则，再测耗时与内存；不要在没有输入结束边界时把等待误判成 Stream API 失效。

小结

Scanner.findAll 的核心价值是把正则查找结果直接接入 Stream：用 Pattern 定义匹配，用 MatchResult 读取捕获内容，用终结操作触发扫描，再用 try-with-resources 关闭 Scanner 和流。真正需要留意的是它独立于 delimiter、依赖终结操作、不能在执行期间并发操作 Scanner，并且对长输入可能等待或缓冲。掌握这几个边界后，再决定是收集列表还是改用更明确的增量读取方案。