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

週末快到了，今天爲你們送上一篇頗有意思的小文章，具備提神醒腦之功效。做者是來自阿里巴巴 LAZADA 產品技術部的申徒童鞋。

血案由來

近期我在爲 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）」。下面詳細介紹下這個問題，以免重蹈覆轍。

正則表達式引擎

提及回溯陷阱，要先從正則表達式的引擎提及。正則引擎主要能夠分爲基本不一樣的兩大類：一種是 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 對於不一樣但效果相同的正則表達式，匹配過程是徹底不一樣的。

回溯

說完了引擎，咱們再來看看到底什麼是回溯。對於下面這個表達式，相信你們很清楚它的意圖。

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進行匹配。這樣就發生了一次回溯。

貪婪、懶惰與獨佔

咱們再來看一下究竟什麼是貪婪模式。

下面的幾個特殊字符相信你們都知道它們的用法：

• ?: 告訴引擎匹配前導字符 0 次或一次。事實上是表示前導字符是可選的。
• +: 告訴引擎匹配前導字符 1 次或屢次。
• *: 告訴引擎匹配前導字符 0 次或屢次。
• {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}+

總結

如今再回過頭看看文章開頭的那個很長的正則表達式，其實簡化以後，就是一個形如 ^[容許字符集]+ 的表達式。該字符集大小約爲 250，而 + 號表示至少出現一次。按照上面說到的 NFA 引擎貪婪模式，在用戶輸入一個過長字符串進行匹配時，一旦發生回溯，計算量將是巨大的。後來採用了獨佔模式，CPU 100% 的問題也獲得瞭解決。

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

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

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