前几天线上一个项目监控信息突然报告异常，上到机器上后查看相关资源的使用情况，发现 CPU 利用率将近 100%。通过 Java 自带的线程 Dump 工具，我们导出了出问题的堆栈信息。

我们可以看到所有的堆栈都指向了一个名为 validateUrl 的方法，这样的报错信息在堆栈中一共超过 100 处。通过排查代码，我们知道这个方法的主要功能是校验 URL 是否合法。

很奇怪，一个正则表达式怎么会导致 CPU 利用率居高不下。为了弄清楚复现问题，我们将其中的关键代码摘抄出来，做了个简单的单元测试。

public static void main(String[] args) { String badRegex = "^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~\\\\/])+$"; String bugUrl = "http:///dddp-web/pdf/download?request=6e7JGxxxxx4ILd-kExxxxxxxqJ4-CHLmqVnenXC692m74H38sdfdsazxcUmfcOH2fAfY1Vw__%5EDadIfJgiEf"; if (bugUrl.matches(badRegex)) { System.out.println("match!!"); } else { System.out.println("no match!!"); }}

运行上面的程序，立刻就会打印出match!!。

但这是不够的，如果以后还有其他 URL 包含了乱七八糟的字符呢，我们难不成还再修改一遍。肯定不现实嘛！

其实在正则表达式中有这么三种模式：贪婪模式、懒惰模式、独占模式。

在关于数量的匹配中，有 + ? * {min,max} 四种两次，如果只是单独使用，那么它们就是贪婪模式。

如果在他们之后加多一个 ? 符号，那么原先的贪婪模式就会变成懒惰模式，即尽可能少地匹配。但是懒惰模式还是会发生回溯现象的。例如下面这个例子：

text="abbc"regex="ab{1,3}?c"

正则表达式的第一个操作符 a 与 字符串第一个字符 a 匹配，匹配成功。于是正则表达式的第二个操作符 b{1,3}? 和 字符串第二个字符 b 匹配，匹配成功。因为最小匹配原则，所以拿正则表达式第三个操作符 c 与字符串第三个字符 b 匹配，发现不匹配。于是回溯回去，拿正则表达式第二个操作符 b{1,3}? 和字符串第三个字符 b 匹配，匹配成功。于是再拿正则表达式第三个操作符 c 与字符串第四个字符 c 匹配，匹配成功。于是结束。

如果在他们之后加多一个 + 符号，那么原先的贪婪模式就会变成独占模式，即尽可能多地匹配，但是不回溯。

于是乎，如果要彻底解决问题，就要在保证功能的同时确保不发生回溯。我将上面校验 URL 的正则表达式的第二部分后面加多了个 + 号，即变成这样：

^([hH][tT]{2}[pP]:\/\/|[hH][tT]{2}[pP][sS]:\/\/)(([A-Za-z0-9-~]+).)++ --->>> （这里加了个+号）([A-Za-z0-9-~_%\\\/])+$

这样之后，运行原有的程序就没有问题了。

最后推荐一个网站，这个网站可以检查你写的正则表达式和对应的字符串匹配时会不会有问题。

Online regex tester and debugger: PHP, PCRE, Python, Golang and JavaScript

例如我本文中存在问题的那个 URL 使用该网站检查后会提示：catastrophic backgracking（灾难性回溯）。

当你点击左下角的「regex debugger」时，它会告诉你一共经过多少步检查完毕，并且会将所有步骤都列出来，并标明发生回溯的位置。

本文中的这个正则表达式在进行了 11 万步尝试之后，自动停止了。这说明这个正则表达式确实存在问题，需要改进。

但是当我用我们修改过的正则表达式进行测试，即下面这个正则表达式。

^([hH][tT]{2}[pP]:\/\/|[hH][tT]{2}[pP][sS]:\/\/)(([A-Za-z0-9-~]+).)++([A-Za-z0-9-~\\\/])+$

工具提示只用了 58 步就完成了检查。

总结

以上所述是小编给大家介绍的藏在正则表达式里的陷阱，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对网站的支持！