话说这天一大早，那个悲催的中年架构师大刘又被手机微信群给炸醒。部门的运维兄弟在公司微信群里说：

短信的生产环境服务器 CPU 占用率过高，疯狂报警。是不是你们昨天上线看门狗导致的？

大刘迷了巴登的想了想，没错，昨天确实给短信服务装上了看门狗。但是看门狗服务肯定不会有问题（架构师必备的蜜汁自信），而且上线之前各轮测试也都测过了，没见过这个想象啊。

难道是测试妹子没测试到位？难道线上短信应用自身出现了问题？

生产无小事，小事更不能忽视，主要是怕扣绩效奖金。大刘迅速打开电脑，打开 VPN ，远程登上短信生产服务器，开始大刘最拿手的 2W1H 三板斧诊断之旅。

接下来的诊断内容有点烧脑，节奏有点快，请大家坐稳扶好。

1. 病号是谁（WHO）？

大刘拿出控制台诊断仪器，输入 top 命令一探究竟。我勒个去，不看不知道一看吓一跳，PID 为 1878 的病号，CPU 占用居然 200% 多。

问题算是定位到了，但是 PID 为 1878 的病号到底是谁，难道真是昨天上线的看门狗？

虽然大刘久经职场，但是排查生产问题时，内心还是比较忐忑，毕竟这是生产环境。

说时迟那时快，只见大刘一个命令输入：

ps -ef | grep 1878

定睛一看，原来是放屁瞅别人，短信服务自己在作祟，和看门狗没关系，大刘心里一下子平缓了不少。

锅找到了主儿，其实这个时候大刘完全可以把这个问题甩给短信开发团队，但是大刘最喜欢做的不是甩锅，而是打破砂锅刨到底。

2. 病号哪里出了问题（WHERE）？

为什么 1878 号病人占用 CPU 会这么高呢？

只见黑乎乎的控制台诊断仪器上，大刘熟练的输入：

jstack -l  1878 >> 1878号病历.log

这样便得到一份 1878 号病人的病历详情单，一会儿用得上。

到底 1878 号病人的哪个部位出了问题呢？

话没说完，只见大刘又在控制台诊断仪器上，输入一个：

top -Hp 1878

白板黑字，把 1878 号病人的器官信息全部列了出来。

看到结果，甚是一惊，PID 代号为 8721 的器官占用 CPU 100% 多。

疑惑油然而生，这个 PID 代号为 8721 的器官是啥，是头、是眼睛、还是胳膊腿呢？这些器官展示的 PID 列都是昵称，都这么善于伪装，如何揭露它的真面目呢？

还好大刘有高招，借助照妖镜算法，熟练的输入：

printf "%x\n" 8721

果真使得代号为 8721 的器官，现了真身，真实身份居然是 2211 的呼吸道，怪不得病号一直气喘吁吁，上气不接下气。

到这一步还无法对症下药啊，还需要进一步确诊 2211 的呼吸道到底出了什么幺蛾子，导致 1878 号病人一直气喘吁吁，上气不接下气？

只见黑乎乎的控制台诊断仪器上，大刘再次飞一般的在输入：

grep 2211 -A20 1878号病历.log

诊断结果随之显示在诊断仪器上。

曾经背了很多锅的大刘，看到诊断结果心里乐了一下，一眼就看出是高并发情况下用了 HashMap 的问题（请大家们自行寻找谷歌、百度，就不在此深入展开啦），终于拨开云雾见青天。