Java 正则批量校验为什么会拖慢接口：Pattern 复用、Matcher 生命周期与基准核对

订单导入接口一次要检查几百个邮箱和手机号，慢点往往不在数据库，而是在循环里不断调用 Pattern.compile()。如果还把一个 Matcher 放进单例字段，性能问题会和线程安全问题一起出现。正确的边界是：正则规则编译一次，匹配器按一次文本或一次线程任务创建；是否值得优化，再用同一批输入做基准核对。

先把 Pattern 和 Matcher 的职责分开

Pattern 是编译后的正则规则，适合在初始化阶段准备好；Matcher 则绑定具体的字符序列和当前匹配状态。一次匹配完成后，匹配器内部已经记录了边界、捕获组和游标位置，它不是无状态工具。

因此，下面这种写法既重复做了规则解析，也让校验成本跟着批次长度线性放大：

boolean valid(String value) {
    return Pattern.compile("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$")
            .matcher(value)
            .matches();
}

它在功能上可能完全正确，但每次调用都要重新构造规则。批量接口里，几百次调用就会把这段固定成本放大。

最小改动：规则复用，匹配器就地创建

把正则声明为不可变的共享对象，再在方法内部创建 Matcher，即可同时解决重复编译和跨线程污染：

private static final Pattern EMAIL = Pattern.compile(
        "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$");

static boolean validEmail(String value) {
    return value != null && EMAIL.matcher(value).matches();
}

static long countValid(List values) {
    return values.stream().filter(RegexCheck::validEmail).count();
}

这里的关键不是把对象都做成静态字段，而是只共享不会随着匹配过程变化的 Pattern。EMAIL.matcher(value) 每次返回新的匹配器，调用方不需要清理，也不用给它加锁。

批量场景里，别把 Matcher 放进单例

下面的反例看起来省对象，实际上把请求状态放到了共享字段：

// 反例：多个请求会同时改写同一个 Matcher 的状态
private static final Matcher SHARED = EMAIL.matcher("");

static boolean unsafe(String value) {
    return SHARED.reset(value).matches();
}

Matcher.reset() 会改变当前匹配器的输入和游标。并发请求交错时，结果可能不稳定；即使暂时没有复现错误，也无法把它当成线程安全实现。局部变量、方法参数或每次调用新建的匹配器，才是清晰的生命周期。

用基准核对真正的收益

性能比较至少要固定三件事：输入条数、有效与无效数据的比例、线程模型。可以先写一个足够小的基准方法，用同一份不可变列表分别调用两种实现：

long start = System.nanoTime();
long result = countValid(samples);
long elapsed = System.nanoTime() - start;
System.out.printf("valid=%d, ns=%d%n", result, elapsed);

正式测量时建议交给 JMH，并设置预热与多轮采样。一次 System.nanoTime() 只能帮助排除明显错误，不能替代基准工具。重点看吞吐、P95 延迟和分配量，而不是只看某一次打印结果。

规则复杂时，优化边界不止是编译一次

如果正则包含大量回溯、嵌套量词或宽泛的 .*，复用 Pattern 只能去掉编译成本，无法消除匹配本身的风险。接口层还应限制单个字段长度，对异常长输入设置拒绝或降级策略，并用带有最坏路径的数据做回归。

另外，能用普通字符串判断解决的问题，不必强行用正则。例如固定前缀、分隔符数量这类校验，用 startsWith()、indexOf() 往往更直观。正则适合表达模式，不适合包揽所有字符串业务规则。

常见问题：复用正则时怎么判断边界

Pattern 真的可以在多线程中共享吗？

可以。Pattern 表示已编译规则，本身不保存某次匹配的游标；共享它不会把请求输入混在一起。

Matcher 每次都创建会不会更浪费？

短文本场景通常不必为此过早优化。匹配器创建成本应和重复编译、错误加锁的成本一起测量；先保证生命周期正确，再依据基准决定是否进一步调整。

为什么优化后接口仍然很慢？

可能是正则回溯、输入过长、批次过大，或数据库和网络才是主要耗时。先拆分 P95 时间，再看分配量和规则最坏路径，别把所有延迟都归因于 Pattern.compile()。

批量校验应该使用并行流吗？

不要把并行流当成默认加速开关。输入规模、正则复杂度和线程池竞争都会改变结果；先用串行版本得到稳定基线，再用固定线程数做对照。

结尾验收清单

• 共享的是 Pattern，不是带输入状态的 Matcher。
• 循环外编译规则，方法内创建匹配器。
• 固定输入规模和命中比例，至少预热后再比较。
• 对长输入和复杂回溯路径做单独回归。