CUP超高问题分析

1. 发现问题：服务信息报错，首先查看日志

日志显示从db连接池获取连接超时，可以初步判断有线程未正确释放连接池资源

2. 查看当前进程的数据库连接池情况

由于使用的是ORACLE数据库，使用命令查询连接池情况

jmap -histo:live 40317|grep oracle.jdbc.driver.T4CConnection

可以看到当前获取的连接数有151个，已经超过了服务的连接池上限

3. 查看CUP占用情况

首先使用top命令查询进程的CUP占用，从图中可以看到有很多线程的CUP占用接近100%

top -H -p 40317

4. 导出进程的线程信息

jstack 40317 > jstack.txt

把之前cup占有率100%的线程号转成16进制，在文件中搜索，发现很多线程都卡在了正则校验上

此时，我们查看代码，发现也只是一行平平无奇的正则校验

email.matches(cn.ztessc.utils.Constant.EMAIL_REGEX)

5. 导出dump信息进行分析

jmap -dump:format=b,file=public.dump 40317

利用jvisualvm分析，找到具体的线程

找到线程之后，找到用来匹配正则的变量

发现是这么一个玩意，原来是加密后的邮箱地址，这里没有进行解密，匹配了邮箱正则校验造成了死循环，具体为什么造成死循环，之后再分析。建议使用正则匹配不要过于复杂