技术的锅太多，到底该不该你背？
一大早就被微信群炸醒，开发短信服务的猿妹子，在公司微信群里说：
短信的生产环境服务器， CPU 占用率过高，疯狂报警，应该是你们昨天上线看门狗导致的（看门狗：守护短信服务的监控应用，后续有机会再进行分享）。
没错，昨天确实给短信服务装上了看门狗。但是看门狗服务肯定不会有问题（作为程序猿们，潜意识都坚信自己写的代码永无 Bug），主要因为测试环境都没有此现象。
难道是测试妹子没测试到位？难道线上短信应用自身出现了问题？
生产无小事，小事更不能忽视。迅速打开电脑，打开 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 " 8721 ，果真使得代号为 8721 的器官，现了真身，真实身份居然是 2211 的呼吸道，怪不得病号一直气喘吁吁，上气不接下气。
到这一步还无法对症下药啊，还需要进一步确诊 2211 的呼吸道到底出了什么幺蛾子，导致 1878 号病人一直气喘吁吁，上气不接下气？
只见黑乎乎的控制台诊断仪器上，猿外再次飞一般的在输入 grep 2211 -A20 1878号病历.log，诊断结果随之显示在诊断仪器上。
看到诊断结果心里乐了一下，一眼就看出是高并发情况下用了 HashMap 的问题（请猿友们自行寻找谷哥、度娘，就不在此深入展开啦），终于拨开云雾见青天。
3. 如何对症下药（ HOW ）？
1、病号是谁？（WHO）
- 第一步：采用 top 命令，找出 CPU 占用最高的问题 PID ；
- 第二步：通过 ps -ef | grep PID 查看问题PID对应的真实身份。
2、病号哪里出了问题？（WHERE）
- 第一步：采用 jstack -l PID >> pid.log //获取某个进程中运行的所有线程；
- 第二步：采用 top -Hp PID 拿到占用 CPU 最高的线程 PID ;
- 第三步：采用 printf "%x " PID 根据线程 PID 的拿到线程真实身份 TID ;
- 第四步：采用 grep TID -A20 pid.log 根据 TID 去临时文件中匹配，确定是哪出了问题。
3、捉得病根、便可拿出医药箱，对症下药啦。（HOW）
作为运维，工作中难免会遇到不少类似这样的问题，面对问题，你如果像无头苍蝇一样乱撞，撞得头破血流依然不知道缘由，在背锅即将成为现实时，那就不妨试试的 2W1H 三板斧的诊断方式，说不定会帮你快速定位、解决线上问题，毕竟快速的解决生产问题会把损失降到最低。