一個由正則表達式引起的血案

週末快到了，今天爲你們送上一篇頗有意思的小文章，具備提神醒腦之功效。做者是來自阿里巴巴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%的問題也獲得瞭解決。

所以，在本身寫正則表達式的時候，必定不能大意，在實現功能的狀況下，還要仔細考慮是否會帶來性能隱患。

關於正則表達式，你有哪些想要分享的特殊技能？歡迎在下面留言，一塊兒交流探討。

 

來源：【阿里技術】微信公衆號