小心别落入正则回溯陷阱

1,029 阅读6分钟

写于2015年6月2日,可能已过时,请谨慎参考

原文

不知才哪儿看来的:

如果你有一个问题,你想到可以用正则来解决,那么你有两个问题了。

我觉得正则表达式实在是一种人难以理解的语言,比xml还要逆天。不过它真的很好用。正则表达式的坑在于,看到一个正则,我们很难直观地知道它要做什么;写了一个正则,我们也很难直观地想像机器是怎么处理的。因而常常出现想不到或者没想到的问题。今天我们谈谈一个严重影响性能的问题,我称之为回溯陷阱,或者叫灾难性回溯(Catastrophic Backtracking)。

回溯

对于正则而言,回溯并不是必需的,这跟具体的正则引擎有关。简单地说,正则引擎分为NFA和DFA。这东西难懂且无聊,我就挑重点说。DFA(确定型有穷自动机),从匹配文本入手,从左到右,每个字符不会匹配两次,它的时间复杂度是多项式的,所以通常情况下,它的速度更快,但支持的特性很少,不支持捕获组、各种引用等等;而 NFA(非确定型有穷自动机)则是从正则表达式入手,不断读入字符,尝试是否匹配当前正则,不匹配则吐出字符重新尝试,通常它的速度比较慢,最优时间复杂度为多项式的,最差情况为指数级的。但 NFA 支持更多的特性,因而绝大多数编程场景下(包括 js),我们面对的是 NFA。

NFA 匹配的过程就是吃入字符,尝试匹配,如果通过,再吃入尝试;如果不通过,就吐出,回到上一个状态,因为同一个字符串在正则中可能存在一种状态不同转化路径,这时正则引擎换一个转化状态进行尝试,如果通过,继续吃入字符,否则继续吐出字符,回到再上一个状态。这种尝试不成功就返回上一状态的过程,我们称为回溯。正则匹配的性能好坏,就看回溯的情况,回溯越多,性能越差。

为了说清楚这个问题,我们做一个实验,用 /a(acd|bsc|bcd)/ 这个正则来对 “abcd” 这个字符串进行匹配。

QQ20150601221148

截图上方是正则表达式,右侧是要匹配的文本,左侧是匹配的过程。

可以看到,匹配这4个字母花了8步,分别看看这8步都在干什么。

  • 第一步:从正则表达式第一个字符 a 开始,吃进 “abcd” 的第一个字符,也是 a,匹配成功!
  • 第二步:这时正则表达式遇到了分支,后面有三种匹配可能,分别是 acd、bsc、bcd。先选择第一个路径 acd,吃入 “abcd” 的第二个字符,是 b,匹配不成功。这时就需要进行一次回溯了(backtrack),把吃进来的最后一个字符 b 还回去,同时放弃第一个路径,选择第二个路径 bsc;
  • 第三步:第二个路径 bsc 中,第一个字符是 b,吃进 “abcd” 中的第二个字符,也是 b,匹配成功!
  • 第四步:第二个路径 bsc 中,下一个字符是 s,吃进 “abcd” 中的第三个字符是c,匹配失败,又要进行回溯了。把刚刚吃进的 c 和 b 还回去,回到第二步的状态,并选择第三个路径 bcd;
  • 第五步~第七步:依次匹配 bcd 和 “abcd” 中的剩余字符,均匹配成功。
  • 第八步:完成匹配。

从这个并不复杂的例子中,光 b 这个字母就匹配了三次,可见回溯在正则表达式中相当普遍。

量词嵌套

考虑这样一个正则 /(a*)*b/,用它来匹配 "aaaaaaaaaa"(10个 a 组成的字符串)。看起来不复杂呀,实验一下:

QQ20150601224618

哦,天哪,竟然花费了6143步才完成!如果再加上一个a呢,变成11个 a 组成的字符串会怎么样?

QQ20150601224802

变成12287步了,翻了一倍。事实就是这样,当出现以上这种量词嵌套时,如果遭遇最坏情况(最后一个字符才能确实匹配不成功),那么这时正则引擎陷入灾难性回溯,时间复杂度为指数级)。

如果你试着再嵌套一层,9个 a 组成的字符串就能突破100万步了……

其他情况

很多时候,并不是上面所述的那么极端的情况,更多的可能是对一个复杂的子句加量词,而这个子句中本身就含有量词;或者子句中有比较复杂的分组。这些情况实际应用中很可能会出现,虽然达不到夸张的指数级复杂度,但对性能依然是不小的挑战。

有一个例子我觉得比较有趣,对于性能优化这个问题,也有参考价值。什么例子呢?用正则表达式匹配一个数字是否为质数。呃……这有点跳跃,看似风马牛不相及,但还真能做到。我们就简单一点,不考虑1。首先,把数字转成字符串,是几就写几个1。比如5就转成5个1组成的字符串11111。用来匹配的正则是 /^(11+)\1+$/,如果匹配通过,则是合数;不通过说明是质数。这个原理并不复杂,我不多说了。同样还有一些用正则测试二元一次方程整数解的问题,原理也类似。

这个例子其实没什么用,因为好玩所以印象深刻。那对于我们有什么参考价值呢?就是别写这么费性能的正则!这个例子中,看起来没有量词嵌套等情况,但与其他问题类似的,这里对引用值加了量词,而这个引用词并不确定,回溯仍然会很多。所以我们除了要注意量词嵌套、复杂子表达式加量词或分组加量词这些情况外,还要注意引用加量词,这点是我没见别人提到过的。

一些解决手段

量词运算

对于量词嵌套的情况,一些简单的运算可以消除嵌套:

(a*)* <==> (a+)* <==> (a*)+ <==> a*
(a+)+ <==> a+

很简单,不多说。

占有优先量词(Possessive Quantifiers)

这个有点意思,可惜 javascript 还不支持,我说简单说说。用法很简单,在量词的后面再加上一个+。类似 /a++b/,那么这和 /a+b/ 有什么区别呢?占有优先量词并不保存回溯状态,换言之,前者不能回溯。如果匹配成功,没什么区别;如果最后 b 匹配不成功,那么前者不会进行回溯,而是直接匹配失败,后者会再进行回溯。

固化分组(或原子分组,Atomic Grouping)

这个更有意思,它控制一个这个字串整体不回溯。用法是这样的 /(?>abc)/。嗯,不幸的是 javascript 依然不支持。不过用其他语言的时候一定要对这个特性保持关注,本身它的兼容性要比占有优先量词要高(比如 c# 支持原子分组不支持占有优先量词),另外它完全可以模拟出占有优先量词的功能,用法也更灵活。

参考: