正则表达式应预编译复用，因Pattern.compile()涉及词法/语法分析、AST构建、优化及NFA生成等CPU密集操作；高频调用会导致微秒级开销累积成性能瓶颈。
因为 Pattern.compile() 每次调用都会解析正则字符串、构建语法树、生成状态机（NFA/DFA），这个过程涉及大量字符串分析和对象创建，属于 CPU 密集型操作，不适合在高频路径中反复执行。
正则编译到底做了什么
调用 Pattern.compile("a+b*") 时，JDK 实际完成以下步骤：
- 词法分析：将字符串切分为原子（如
a、+、b、*） - 语法分析：构建抽象语法树（AST），识别量词、分组、边界等结构
- 模式优化：合并连续字符、简化嵌套量词、预判常见匹配失败路径
- 状态机构建：生成用于实际匹配的 NFA（非确定有限自动机），部分场景会尝试转为 DFA
- 缓存关键元数据：如是否需要区分大小写、是否含捕获组、最小/最大匹配长度等
为什么不能每次都 compile
每次编译都重复上述流程，尤其当正则较复杂（如含多层嵌套、前瞻断言、Unicode 类）时，耗时可能达微秒级甚至更高。在循环或高并发请求中频繁调用，容易成为性能瓶颈。
- 一个含 3 个捕获组、2 个正向先行断言的正则，单次编译约消耗 5–15 μs（HotSpot JDK 17，典型配置）
- 若每秒处理 10 万次匹配请求，仅编译开销就占 CPU 时间 0.5–1.5 ms，积少成多
- Pattern 对象本身是线程安全且不可变的，完全可复用
怎么正确使用预编译
把 Pattern 实例作为静态常量或单例缓存，避免重复编译：
立即学习“Java免费学习笔记（深入）”；
public class RegexUtils {
// ✅ 推荐：静态 final 编译一次，全局复用
private static final Pattern EMAIL_PATTERN = Pattern.compile("^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$");
public static boolean isValidEmail(String email) {
return EMAIL_PATTERN.matcher(email).matches();
}
}
- 对动态生成的正则（如用户输入的搜索关键词），可加 LRU 缓存（例如用
ConcurrentHashMap+ 弱引用或定时淘汰） - 避免在方法体内直接写
Pattern.compile(...).matcher(...).find()—— 这是最常见的反模式 - 注意：
String.replaceAll()、String.split()等便捷方法内部也会调用compile，高频场景应改用预编译的Pattern+Matcher
JVM 层面的额外优化细节
JDK 并未对 Pattern.compile() 做全局字符串级缓存（比如相同正则串只编译一次），但有两点隐式优化：
- 正则字符串字面量会被 JVM 常量池复用，减少 String 对象分配
- HotSpot 的 JIT 编译器会对热点
Pattern匹配逻辑做内联与特化，但编译阶段仍无法跳过 - JDK 19+ 引入了
Pattern.compile(..., Pattern.CANON_EQ)等新标志，部分场景可减少运行时归一化开销，但不改变编译成本
基本上就这些。预编译不是“最佳实践建议”，而是正则使用的底层前提——它不复杂，但容易被忽略。
