一个由正则表达式引起的血案

周末快到了，今天为你们送上一篇颇有意思的小文章，具备提神醒脑之功效。做者是来自阿里巴巴LAZADA产品技术部的申徒童鞋。

1. 血案由来

近期我在为Lazada卖家中心作一个自助注册的项目，其中的shop name校验规则较为复杂，要求：
1. 英文字母大小写
2. 数字
3. 越南文
4. 一些特殊字符，如“&”，“-”，“_”等
看到这个要求的时候，天然而然地想到了正则表达式。因而就有了下面的表达式（写的比较龊）：

^([A-Za-z0-9._()&'\- ]|[aAàÀảẢãÃáÁạẠăĂằẰẳẲẵẴắẮặẶâÂầẦẩẨẫẪấẤậẬbBcCdDđĐeEèÈẻẺẽẼéÉẹẸêÊềỀểỂễỄếẾệỆfFgGhHiIìÌỉỈĩĨíÍịỊjJkKlLmMnNoOòÒỏỎõÕóÓọỌôÔồỒổỔỗỖốỐộỘơƠờỜởỞỡỠớỚợỢpPqQrRsStTuUùÙủỦũŨúÚụỤưƯừỪửỬữỮứỨựỰvVwWxXyYỳỲỷỶỹỸýÝỵỴzZ])+$ 

在测试环境，这个表达式从功能上符合业务方的要求，就被发布到了马来西亚的线上环境。结果上线以后，发现线上机器时有发生CPU飙到100%的状况，致使整个站点响应异常缓慢。经过dump线程trace，才发现线程所有卡在了这个正则表达式的校验上：

一开始难以置信，一个正则表达式的匹配过程怎么可能引起CPU飚高呢？抱着怀疑的态度去查了资料才发现小小的正则表达式里面居然大有文章，平时写起来都是浅尝辄止，只要可以知足功能需求，就认为达到目的了，彻底忽略了它可能带来的性能隐患。

引起此次血案的就是所谓的正则“回溯陷阱（Catastrophic Backtracking）”。下面详细介绍下这个问题，以免重蹈覆辙。

 

2. 正则表达式引擎

提及回溯陷阱，要先从正则表达式的引擎提及。正则引擎主要能够分为基本不一样的两大类：一种是DFA（肯定型有穷自动机），另外一种是NFA（不肯定型有穷自动机）。简单来说，NFA 对应的是正则表达式主导的匹配，而 DFA 对应的是文本主导的匹配。

DFA从匹配文本入手，从左到右，每一个字符不会匹配两次，它的时间复杂度是多项式的，因此一般状况下，它的速度更快，但支持的特性不多，不支持捕获组、各类引用等等；而NFA则是从正则表达式入手，不断读入字符，尝试是否匹配当前正则，不匹配则吐出字符从新尝试，一般它的速度比较慢，最优时间复杂度为多项式的，最差状况为指数级的。但NFA支持更多的特性，于是绝大多数编程场景下（包括java，js），咱们面对的是NFA。如下面的表达式和文本为例，

text ＝ ‘after tonight’ regex ＝ ‘to(nite|nighta|night)’ 

在NFA匹配时候，是根据正则表达式来匹配文本的，从t开始匹配a，失败，继续，直到文本里面的第一个t，接着比较o和e，失败，正则回退到 t，继续，直到文本里面的第二个t，而后 o和文本里面的o也匹配，继续，正则表达式后面有三个可选条件，依次匹配，第一个失败，接着2、三，直到匹配。

而在DFA匹配时候，采用的是用文原本匹配正则表达式的方式，从a开始匹配t，直到第一个t跟正则的t匹配，但e跟o匹配失败，继续，直到文本里面的第二个 t 匹配正则的t，接着o与o匹配，n的时候发现正则里面有三个可选匹配，开始并行匹配，直到文本中的g使得第一个可选条件不匹配，继续，直到最后匹配。

能够看到，DFA匹配过程当中文本中的字符每个只比较了一次，没有吐出的操做，应该是快于NFA的。另外，无论正则表达式怎么写，对于DFA而言，文本的匹配过程是一致的，都是对文本的字符依次从左到右进行匹配，因此，DFA在匹配过程当中是跟正则表达式无关的，而 NFA 对于不一样但效果相同的正则表达式，匹配过程是彻底不一样的。

3. 回溯

说完了引擎，咱们再来看看到底什么是回溯。对于下面这个表达式，相信你们很清楚它的意图，

ab{1,3}c 

也就是说中间的b须要匹配1~3次。那么对于文本“abbbc”，按照第1部分NFA引擎的匹配规则，实际上是没有发生回溯的，在表达式中的a匹配完成以后，b刚好和文本中的3个b完整匹配，以后是c发生匹配，一鼓作气。若是咱们把文本换成“abc”呢？无非就是少了一个字母b，却发生了所谓的回溯。匹配过程以下图所示（橙色为匹配，黄色为不匹配），

1~2步应该都好理解，可是为何在第3步开始，虽然已经文本中已经有一个b匹配了b{1,3}，后面还会拉着字母c跟b{1,3}作比较呢？这个就是咱们下面将要提到的正则的贪婪特性，也就是说b{1,3}会竭尽所能的匹配最多的字符。在这个地方咱们先知道它一直要匹配到撞上南墙为止。 在这种状况下，第3步发生不匹配以后，整个匹配流程并无走完，而是像栈同样，将字符c吐出来，而后去用正则表达式中的c去和文本中的c进行匹配。这样就发生了一次回溯。

4. 贪婪、懒惰与独占

咱们再来看一下究竟什么是贪婪模式。

下面的几个特殊字符相信你们都知道它们的用法：

i. ?: 告诉引擎匹配前导字符0次或一次。事实上是表示前导字符是可选的。
ii. +: 告诉引擎匹配前导字符1次或屡次。
iii. *: 告诉引擎匹配前导字符0次或屡次。
iv. {min, max}: 告诉引擎匹配前导字符min次到max次。min和max都是非负整数。若是有逗号而max被省略了，则表示max没有限制；若是逗号和max都被省略了，则表示重复min次。

默认状况下，这个几个特殊字符都是贪婪的，也就是说，它会根据前导字符去匹配尽量多的内容。这也就解释了为何在第3部分的例子中，第3步之后的事情会发生了。

在以上字符后加上一个问号（？）则能够开启懒惰模式，在该模式下，正则引擎尽量少的重复匹配字符，匹配成功以后它会继续匹配剩余的字符串。在上例中，若是将正则换为

ab{1,3}?c 

则匹配过程变成了下面这样（橙色为匹配，黄色为不匹配），

因而可知，在非贪婪模式下，第2步正则中的b{1,3}?与文本b匹配以后，接着去用c与文本中的c进行匹配，而未发生回溯。

若是在以上四种表达式后加上一个加号（+），则会开启独占模式。同贪婪模式同样，独占模式同样会匹配最长。不过在独占模式下，正则表达式尽量长地去匹配字符串，一旦匹配不成功就会结束匹配而不会回溯。咱们如下面的表达式为例，

ab{1,3}+bc 

若是咱们用文本"abbc"去匹配上面的表达式，匹配的过程以下图所示（橙色为匹配，黄色为不匹配），

能够发现，在第2和第3步，b{1,3}+会将文本中的2个字母b都匹配上，结果文本中只剩下一个字母c。那么在第4步时，正则中的b和文本中的c进行匹配，当没法匹配时，并不进行回溯，这时候整个文本就没法和正则表达式发生匹配。若是将正则表达式中的加号（+）去掉，那么这个文本总体就是匹配的了。

把以上三种模式的表达式列出以下，

 

贪婪	懒惰	独占
X?	X??	X?+
X*	X*?	X*+
X+	X+?	X++
X{n}	X{n}?	X{n}+
X{n,}	X{n,}?	X{n,}+
X{n,m}	X{n,m}?	X{n,m}+

5. 总结

如今再回过头看看文章开头的那个很长的正则表达式，其实简化以后，就是一个形如

^[容许字符集]+ 

的表达式。该字符集大小约为250，而+号表示至少出现一次。按照上面说到的NFA引擎贪婪模式，在用户输入一个过长字符串进行匹配时，一旦发生回溯，计算量将是巨大的。后来采用了独占模式，CPU 100%的问题也获得了解决。

所以，在本身写正则表达式的时候，必定不能大意，在实现功能的状况下，还要仔细考虑是否会带来性能隐患。

关于正则表达式，你有哪些想要分享的特殊技能？欢迎在下面留言，一块儿交流探讨。

 

来源：【阿里技术】微信公众号