Java Pattern 怎样避免正则编译开销

同一正则反复处理输入时，把 Pattern.compile 移出每次调用的路径，让多个请求共享编译后的 Pattern，而每次匹配创建自己的 Matcher。只做一次匹配时没有必要强行建立缓存；规则来自配置时，优先由配置对象持有，而不是把所有用户输入永久放进全局 Map。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/regex/Pattern.html。Pattern 是不可变且可供并发使用的对象，Matcher 则不能被多个线程随意共享。以下是原创工程写法，未提供实测加速倍数。

先确认重复编译是否发生在热路径

先沿业务入口寻找循环或请求处理方法中的 compile，以及重复调用的 Pattern.matches。后者把编译和匹配合在一次便利调用中，不适合表达“长期复用这条规则”的意图。问题信号是同样的规则在高频调用中持续编译，而不是代码里出现了正则就一定有性能问题。

记录规则的来源、是否固定、编译选项以及复用范围。先把这四项写清，才能决定是类级常量、对象字段还是有限配置集合。不要仅因接口慢，就预设编译是主要耗时。

固定规则移到共享 Pattern

import java.util.regex.Pattern;

public final class RouteCode {
    // 固定业务规则由类持有，避免每次检查重新编译
    private static final Pattern CODE = Pattern.compile("[A-Z]{2}-[0-9]{4}");

    private RouteCode() {}

    public static boolean accepts(String input) {
        // 空值策略显式定义；每次调用创建独立 Matcher
        return input != null && CODE.matcher(input).matches();
    }
}

这个例子只接受两个大写英文字母、连字符和四位数字组成的完整输入。调用 accepts 时复用 CODE，输入和匹配状态留在本次调用中。小型固定规则无需引入复杂缓存框架。

动态规则按配置对象持有

动态规则不一定需要全局缓存。例如导入任务在创建时取得一条规则，随后处理许多行，可以让任务配置对象持有一次编译结果。相同配置对象的多次调用即可复用，不必额外发明缓存键。

import java.util.Objects;
import java.util.regex.Pattern;

public final class RowRule {
    private final Pattern compiled;

    public RowRule(String regex, int flags) {
        // 在配置构建时编译，语法错误交由配置加载层报告
        this.compiled = Pattern.compile(
            Objects.requireNonNull(regex, "regex"), flags);
    }

    public boolean accepts(String row) {
        // 不把 Matcher 保存为共享字段
        return row != null && compiled.matcher(row).matches();
    }
}

配置更新时先构建新 RowRule，成功后再通过已有的线程安全配置发布机制替换引用，保留旧配置用于回退。不要在每一行处理时重新构建 RowRule。该设计把复用期限交给业务配置生命周期，旧对象没有使用者后也不需要永久留在映射表里。

确实需要跨配置查找时，应把正则文本和 flags 都纳入标识，并预先规定容量与失效策略。仅使用并发 Map 不等于缓存有容量限制；规则种类不断增加时，要把缓存保留成本算进去。这是设计建议，不是本文额外实现的缓存组件。

并发请求各自创建 Matcher

并发调用 RouteCode.accepts 或同一个 RowRule.accepts 时，各次调用各自使用 matcher(input) 的返回对象。不要为了减少一个对象创建，就把 Matcher 提升为 static 字段，也不要在没有明确同步约束的情况下让多个请求对同一个 Matcher 做 reset。

共享 Pattern 和共享 Matcher 是两种不同改动。前者复用规则，后者把输入及匹配状态混到共享资源中，已经超出消除重复编译的目标。本文因此选择简单的局部 Matcher，不引入线程本地对象池。

保留回退路径与观察指标

发布改动时，把正则文本、flags、完整匹配还是子串查找、空值策略分别列入变更记录。优化只移动编译位置，不顺手改规则或把 matches 换成 find，才能把行为变化与性能变化分开判断。

上线后由团队按原有观察方式比较相同负载下的请求耗时、CPU 和分配情况；配置型方案还应观察配置构建失败率及规则对象数量。本文没有执行这些比较，也不宣称收益已经成立。如果行为出现偏差，回退代码或恢复上一份配置对象，避免通过吞掉规则错误来维持表面成功。

正则只使用一次，还值得缓存吗？通常应先看复用次数和持有成本，不必为了形式建立全局状态。预编译后能保证固定速度吗？不能，减少重复编译不代表匹配本身没有成本。出现并发结果串用该先查什么？先确认 Matcher 是否被保存到共享字段，以及输入对象是否在调用期间被外部修改。

参考：Oracle Pattern API：编译复用与并发约束。