jp-regex-hot — 循环中编译正则表达式
主张
在每次调用时编译一个 Pattern 仍然会比重用 static final Pattern 分配大约 2.4×。在 JDK 27 上，1024 行时间对比则相反（~0.76×，每次编译更快）。行数=64 时，时间约为 1.07×。
如何测量
- 利用:
J26 Regexocility.java ' /scripts/run jmh.sh J26 Regexocility ' - 工作:将 " 线条 " 字符串与固定的regex匹配;JMH 1.37 avgt +
-prof gc ' ;XX:+ 使用对象头 ' - ** 之前:** `编译小组 '
- ** 之后:**
静态终极 模式 - Raw:`研究/成果/J26-Regexicul.jsonl'
运行时（本证据文件）
| Field | Value |
|---|---|
| 时间 | 2026-10-23 亚洲/上海 |
| JDK | 27 (27+35) |
| JVM 参数 | -XX:+UseCompactObjectHeaders |
在 compileEachCall[lines=1024] 之前 | 128040.677 ns/次操作, 827392.817 B/次操作 |
在 staticFinalPattern[lines=1024] 之后 | 167595.045 ns/次操作, 344065.068 B/次操作 |
| 前/后比率 | ~0.76× 时间（每次编译更快），~2.40× B/op |
| 行数=64（相同的 JSONL） | ~1.07× 时间，~2.40× B/操作 |
与 lint 的对应
默认严重性 关闭（运行时使用 --enable）；实际运行时间仅略高于约 1.3×，不像 jp-string-concat-hot 那样出现明显的时间急剧上升。证据文件存在，因此该声明可以审计；保持为自愿审查提示，直到更热的工作负载显示出更大的时间陡坡。
在一台空闲的16核主机（Temurin 21.0.13，负载 0.96）上进行的后续方向检查不能替代此 JSONL。对1024行拆分进行200次重复，预热5次，中位数为9：每次编译 33.023 毫秒，静态模式 19.738 毫秒，大约1.67×，样本紧密。在该 JDK 上，静态模式略快。JDK 27 的时间对保持记录状态，而大约2.4×的分配差距是规则保持的原因。
限制
- 动态模式（用户提供的正则表达式）不能是静态-最终的 —— 预期有抑制。
- 当模式已经编译时，匹配成本占主导；一次编译获胜会减少缩减。
- 不要发明比 J26 记录更大的比例。