一条昵称正则把 8 核打满：ReDoS 灾难性回溯的排查、改写与三道防线

作者程望舒 Trae · 17

ReDoS正则性能调优Java安全

结论先行

如果一次「正常流量压测全绿、合法输入 P99 只有几百纳秒」的校验接口，却在某天被几个恶意请求把整台机器 CPU 打满——第一嫌疑不是下游、不是 GC、不是连接池，而是那条你以为很普通的正则。我上个月在 UGC 服务上栽过：一个用户昵称校验正则，被一条 51 个字符的输入把 8 核机器的 CPU 从 12% 顶到 97%，QPS 从 4200 跌到 280。根因是 Java java.util.regex 的回溯引擎遇到了嵌套量词 + 可重叠字符类，走的是 2^n 级回溯。

一、现象：一次「昵称校验」把 8 核打满

背景：一个 UGC 内容服务的「创建/修改昵称」接口，JDK 17.0.8、8 核容器、Tomcat 线程池 max=200。校验用的正则是这样的（业务要求：字母数字可混用下划线/中划线，但不能以分隔符开头结尾、不能连续分隔符）：

// 危险写法：嵌套量词 + 可重叠
Pattern BAD = Pattern.compile("^([a-zA-Z0-9]+[_-]?)+[a-zA-Z0-9]*$");

正常昵称 wang_wu-2024 的 matches() 耗时，我用 JMH 测过，P99 约 350ns，压测 5000 QPS 全绿。

出事那天：同一接口收到 5 个并发请求，输入都是 a×50 + !（51 字符，! 不在字符类里，注定不匹配）。单条输入单线程 matches() 耗时 26.8s；把 a 换成 60 个，耗时 412s（约 7 分钟）。5 个并发恶意请求直接把 8 核里的 7.8 核吃满，CPU 12% → 97%，整服务 QPS 4200 → 280，P99 从 40ms 飙到 6.2s，后续合法请求全在排队。

定位靠 async-profiler 火焰图：99.1% 的时间落在 java.util.regex.Pattern$GroupHead.match 和 Pattern$LoopTail.match 两个方法里——一眼就能看出是回溯在空转，而不是业务逻辑。

二、根因：回溯引擎的「每个格子都有分叉」

打个比方：Java 的正则引擎像个走迷宫的人，每到一个分叉就「记住来路」，走不通就退回到上一个分叉重新选。问题在于，这条正则的迷宫是每个格子都有分叉。

([a-zA-Z0-9]+[_-]?)+ 对输入 aaaa...! 会怎样？内层 [a-zA-Z0-9]+ 能匹配 a/aa/aaa/aaaa，[_-]? 可选为空；外层 + 又能重复。于是 aaaa 这一段可以被划分成 (a)(a)(a)(a)、(aa)(aa)、(a)(aaa)……共 2^(n-1) 种划分方式。引擎对每一种划分都完整走一遍到末尾、撞上 !、再退回来换下一种——n 个 a 就要试约 2^n 条路径。50 个 a ≈ 5.6×10^14 次回溯，60 个 a ≈ 5.7×10^17，所以耗时不是线性涨，是指数级涨，26.8s → 412s 正是这个曲线。

关键点：^ $ 锚点不改变这一点。边界只是限定匹配范围，不会让回溯引擎变成线性时间。真正决定复杂度的是「有没有嵌套量词 + 量词之间是否可重叠」。

三、具体做法：改写法 + 换引擎 + 加超时（三道防线）

防线 1：消除嵌套量词与重叠（治本）。 把「可选分隔符挂在重复块里」改成「分隔符只出现在块与块之间」：

// 安全写法：量词不再嵌套，字符类不再重叠
Pattern GOOD = Pattern.compile("^[A-Za-z0-9]+(?:[-_][A-Za-z0-9]+)*$");

实测同一条 a×60 + ! 输入：BAD 正则 412s，GOOD 正则 0.4ms——因为它要么一次过、要么一次失败，没有可回溯的重叠路径。

防线 2：换线性时间引擎（兜底）。 用 RE2/J 替换 java.util.regex，它保证 O(n) 时间、彻底无回溯：

// 注意 import 的是 re2j，不是 java.util.regex
import com.google.re2j.Pattern;
import com.google.re2j.Matcher;
Pattern p = Pattern.compile("^[A-Za-z0-9]+(?:[-_][A-Za-z0-9]+)*$");

防线 3：前置长度限制 + 耗时熔断（保险丝）。 无论正则多安全，外部输入先卡长度，再把单次 match 包一层超时：

if (nick == null || nick.length() > 32) { return false; } // 先斩后奏
Future<Boolean> f = pool.submit(() -> p.matcher(nick).matches());
try {
    return f.get(50, TimeUnit.MILLISECONDS);   // 50ms 熔断，绝不拖死线程
} catch (TimeoutException e) {
    f.cancel(true);
    metrics.increment("regex.timeout");
    return false;
}

上线前的 fuzz 脚本（强烈建议跑一遍）：

for (int len = 20; len <= 80; len += 10) {
    String s = "a".repeat(len) + "!";
    long t0 = System.nanoTime();
    p.matcher(s).matches();
    System.out.printf("len=%d  %12.3f ms%n", len, (System.nanoTime()-t0)/1e6);
}

危险正则的输出会看到耗时随长度爆炸式上升；安全正则则基本是一条直线（<1ms）。

四、踩过的坑 & 反直觉之处

平均数的暴政：合法输入 P99 只有 350ns，压测全绿——但 ReDoS 是尾部攻击，正常流量永远触发不了，只有边界/恶意输入才炸。靠正常压测是发现不了的，必须专门喂「几乎全匹配但差一个字符」的输入。
加机器没用：瓶颈是算法复杂度 2^n，不是资源。加 10 台机器，60 个 a 还是要 7 分钟，70 个 a 就要 7 分钟 × 4 ≈ 半小时。扩容治不了 ReDoS。
锚点给的安全感是假的：^...$ 只限定范围，不消除回溯。
RE2 不支持 lookaround：换引擎后，(?=...)、(?<=...) 这类写法会直接编译报错，得用「两步校验」或改写。我们一条密码强度正则就栽在这，最后拆成两次 matches()。
Pattern 线程安全，Matcher 不是：Pattern 可以放心当单例，但 Matcher 有内部状态、不能跨线程共享，别图省事搞成全局单例。

五、结论与可复用清单

任何面向外部输入的校验正则，上线前先问一句：它会不会指数回溯？ 重点盯「嵌套量词」和「量词间可重叠的字符类」（如 ([a-z]+)+、([a-zA-Z0-9]+[_-]?)+）。
优先线性时间引擎：RE2/J、Go regexp、Rust regex；java.util.regex 只用于纯内部、输入可信的场景。
前置长度限制 + 单次 match 超时熔断，把最坏耗时从「分钟级」钉死在「几十 ms」。
上线前跑长度 fuzz（20→80 递增喂「几乎匹配」输入），看耗时是线性还是指数。
把单条 match 耗时打进 metrics，>10ms 告警——它能帮你在线上看到 ReDoS 的第一眼异常。

一句话收尾：正则的复杂度藏在「写法」里，不藏在「引擎配置」里；平均纳秒级不等于安全，能把输入喂到边界，才算安全。

2赞 0收藏 1评论 57浏览