Java Pattern 怎样避免 Matcher 被重复创建

如果一段 Java 代码在循环里反复处理文本，最容易出现的写法是每次都调用 pattern.matcher(text)。这并不意味着必须把 Matcher 做成全局共享对象：更稳妥的做法是让 Pattern 长期复用，让 Matcher 按调用边界复用。一次性请求保持局部创建；同一线程的顺序批处理使用 reset(CharSequence)；并发任务则为每个线程保留自己的 Matcher。

官方资料：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/regex/Pattern.html

Pattern 负责保存编译后的规则，Matcher 负责一次具体输入的可变匹配状态。真正需要避免的是重复编译 Pattern，以及在不合适的边界上共享 Matcher；不是无条件地把所有 Matcher 都改成缓存。

先分清 Pattern 和 Matcher 的职责

Pattern.compile 得到的是可复用的正则规则对象，适合放在不可变字段中。调用 pattern.matcher(input) 会得到一个 Matcher，它不仅关联 Pattern，还会保存当前输入、最近一次匹配位置、捕获组和追加替换位置等状态。

所以优化的第一步不是马上上 ThreadLocal，而是把两个成本和两个生命周期拆开：规则通常可以跨调用共享；匹配状态必须由一次调用、一个顺序批次或一个线程独占。

import java.util.regex.Matcher;
import java.util.regex.Pattern;

public final class AccountCode {
    // 正则规则不携带某一次输入的匹配位置，可以作为不可变共享对象。
    private static final Pattern CODE = Pattern.compile("[A-Z]{2}-\\d{6}");

    public static boolean isValid(String value) {
        // 一次性调用由当前方法独占 Matcher，边界最清楚，也不会跨请求保留输入。
        Matcher matcher = CODE.matcher(value);
        return matcher.matches();
    }
}

这个最小写法并不“低级”。如果每个输入只匹配一次，局部 Matcher 的可读性和隔离性通常比缓存更重要。只有当分析确认 Matcher 创建本身处在高频热点，才值得继续比较复用方案。

三种持有方式怎么选

可以把常见方案压缩成三个选择。局部 Matcher 适合一次性调用；循环复用适合同一线程连续处理一批输入；ThreadLocal 适合长期存在的线程与高频、顺序的匹配任务。三者的区别不是“谁最快”，而是谁拥有匹配状态。

一个常见误区是把 Pattern 和 Matcher 一起做成静态字段。这样虽然表面上没有重复创建，但并发调用可能同时修改同一个 Matcher 的输入和当前位置，最终表现为偶发的匹配错误，而不是稳定的性能收益。

顺序批处理用 reset 复用 Matcher

在同一个线程中连续校验一批字符串时，可以先创建一次 Matcher，然后用 reset(CharSequence) 换入下一条输入。每次调用匹配方法前，Matcher 都只属于当前循环，不会被另一个任务插入使用。

import java.util.List;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public final class BatchValidator {
    private static final Pattern CODE = Pattern.compile("[A-Z]{2}-\\d{6}");

    public static long countValid(List values) {
        // 空字符串只是初始化输入；真正的输入会在循环中通过 reset 替换。
        Matcher matcher = CODE.matcher("");
        long valid = 0;
        for (String value : values) {
            // 当前线程顺序独占 matcher，reset 会丢弃上一条输入的匹配状态。
            if (matcher.reset(value).matches()) {
                valid++;
            }
        }
        return valid;
    }
}

这里的收益边界要说清楚：复用的是 Matcher 对象，不代表正则匹配算法的复杂度改变，也不代表每一种输入都能测出稳定差异。批次很小或匹配本身很重时，代码简化可能比对象复用更值得保留。

并发时按线程隔离，而不是共享一个字段

如果确实存在长期运行的高频线程，并且基准数据表明 Matcher 创建成为可见热点，可以让每个线程拿到自己的 Matcher。ThreadLocal 的关键不是“缓存更快”，而是把可变状态的所有权限制在当前线程。

import java.util.regex.Matcher;
import java.util.regex.Pattern;

public final class ThreadLocalValidator {
    private static final Pattern CODE = Pattern.compile("[A-Z]{2}-\\d{6}");
    private static final ThreadLocal MATCHER =
            ThreadLocal.withInitial(() -> CODE.matcher(""));

    public static boolean isValid(String value) {
        // 每个线程取得自己的 Matcher，不能把它传给其他线程使用。
        Matcher matcher = MATCHER.get().reset(value);
        return matcher.matches();
    }

    public static void clearWorkerState() {
        // 线程池任务结束或线程即将长期闲置时，主动释放线程绑定的引用。
        MATCHER.remove();
    }
}

ThreadLocal 不是默认答案。线程池会复用工作线程，如果最后一次匹配输入很大，Matcher 可能继续持有这条输入的引用；长生命周期线程尤其要考虑何时调用 remove()。此外，业务调用若会嵌套、异步切换线程或需要保存多个独立匹配结果，局部 Matcher 往往更容易维护。

用四个问题做最终选择

落地前可以依次问四个问题：这段正则是否在循环中高频调用？调用是否严格顺序执行？同一个 Matcher 是否可能被两个线程看到？输入对象是否可能很大且需要尽快释放？只要后三个问题有一个回答不理想，就不应为了少一次创建而扩大缓存范围。

最后再强调一次：先复用 Pattern，再根据实际热点决定是否复用 Matcher。没有分配分析或基准数据时，局部 Matcher 是更容易证明正确的默认选择。

相关问题

Pattern 本身可以被多个线程共享吗？

可以。Pattern 表示编译后的规则，适合做不可变共享字段；不要因此推导出 Matcher 也可以被多个线程共享。

调用 reset 后还需要重新创建 Matcher 吗？

同一个线程顺序处理下一条输入时通常不需要，直接调用 reset(CharSequence) 即可。若调用之间存在并发、嵌套或需要保留旧匹配状态，则应创建独立 Matcher。