前言
实际我们在开发过程中，遇到最多的问题就是代码bug导致数据异常这种情况，这种情况一般都可以静态的查看代码去进行定位。但是问题产生不是我们能预料到的，预料到了的缺陷那可能是放弃治疗了，所以这里我分享一个真实的非静态定位bug的过程--一个服务器宕机让测试头皮发麻的问题。
案件重现
场景1
头天晚上提测完，第二天正是放松警惕的时候，老实说测试告诉我服务器宕机的时候我是懵逼的，怎么我们自测的好好的，到他们那服务器就挂了呢。
Step1：
看了一下服务器环境，内存使用量已经超标了，然后我们提出让测试对测试服务器的内存进行扩容。
step2：
结果没有测试几天，服务器又宕机了，测试过程也真是坎坷，宕机的还是他们的主测环境，然后我熟练的连上了他们的环境，一看是IO的问题，IO都占用100%了，这服务器能正常就有鬼了。这个时候最粗暴的方法就是加硬盘，横向拓宽服务器的IO处理能力。但是服务器已经装好了，如果要把装好的服务卸载装到新的硬盘里面，那么原先的数据就丢了，不是良好的解决方案。
然后我们打开了服务器上tomcat的JMX看一下到底是哪个服务在过量打印日志信息。通过VisualVM这个工具，我们看到有个线程内存分配很频繁，每次申请的空间也较大，然后找到对应的开发人员让其做一下修改。然后继续定位，发现http请求的线程都黄了，都处于等待状态，正好符合页面请求无响应的现象。
然后我们只是更彻底的了解了问题，但定位的思路又回到了原点，所以这个时候就去看服务器上哪些服务占用IO过高了，在服务器上，有两个应用占用IO很高，一个是对象存储的，还有一个是用于存储日志信息的数据库。对象存储的IO占用高也不能算异常，毕竟要读取图片什么的，但是数据库的IO占用那么高就有点异常了。
这个时候问题很清晰了，是日志服务在抽取日志信息到数据库的过程中占用了服务器绝大部分IO，导致其他服务器请求数据库得不到响应。然后我们关掉了部分日志记录，服务器又回到正常状态。
场景2
step3：
好景不长，服务器又宕机了，这次IO和内存以及CPU都很正常，凡是可以监控到的指标都没有出现异常情况。然后组件日志里面满屏都是http请求超时的异常。
幸亏这次提测的时候测试已经提前打开了JMX，我们可以更快的连上服务器。当我看到大量http请求都处于黄色状态的时候。我百思不得其解，因为我们的服务本身不是具有大量并发http请求的服务，我怀疑有服务没有及时释放IO，后来看了代码，发现基本上所有的代码都是使用的restTemplate，IO是自动释放的，超时时间也有设置，理论上不会出现阻塞。
这个时候问题又回到了大量http请求阻塞了，既然我们的服务不会有这么多请求，却又出现了这么多并发请求，那肯定有个地方触发了。我们只要找到它就行。
我机制的同事，在我另外一台闲置的虚拟机上，把数据库关了，然后打开web页面去操作了一会（打开F12），发现有个带有刷新功能的页面会触发不少查询，点击次数的增加，它的并发查询数还会增加。
后来通过交流发现是前端设置了点击那个tab页会启动一个定时器，然后我们多次点击这个tab也之后，定时器就会越来越多，然后就成为了本次宕机的罪魁祸首。
定位思路改进点
（1）上面的定位过程中有一个绕圈圈的过程，其中一次服务器宕机我们看到IO异常之后，应该直接去找那个占用IO的服务，从它出发逆向推问题，而不是南辕北辙的去看tomcat里面的服务有没有异常，因为开发JMX需要重启tomcat，耗时较长。
（2）在场景1中，我们忽略了一个很严重的问题，虽然我们关闭了日志服务，但是打开JMX的时候，我们重启了服务，有些问题在重启的过程中暂时得到了解决。让我们以为问题已经被彻底解决。
（3）第三次定位问题的过程中，从一开始我就发现了是http请求阻塞的情况，但却无从下手。实际上我们可以通过日志中的调用链去查看请求的源头，然后就不需要这种碰巧式的定位问题法了。
（4）数据库连接状态查看，select * from pg_stat_activity，可以找到是哪些sql导致数据库阻塞。
