【爆出故障】
2019-03-04，下午16:37，我们的线上BUG群，有人爆出APP无法使用。我赶紧拿出手机，并第一时间叫了我们的测试负责人一起查看该问题。
【定位问题】
我马上登录线上服务器，使用“jps -ml”命令，查看支撑APP服务的Java进程是否挂了，发现进程还在
然后我使用“df -hl”查看服务器硬盘是否满了，发现使用了84%，那还不至于不能提供服务，不是服务器容量不够导致的问题（为什么我要查询服务器硬盘容量呢？是我们之前发生过一次因为服务器硬盘满了，导致无法创建数据库连接，进而导致APP无法请求Java应用。）
接着，我使用top命令查看进程的资源占用情况。top结果的第一条信息，就很明显的显示了，某个Java进程CPU使用了140%左右，而且一直维持在这个高位没有降低。看了这个进程ID，发现刚好是前面“jps -ml”查出来的支撑APP服务的Java服务。
定位到问题：支撑APP的Java进程cpu占用过高，导致无法正常提供服务。
【紧急处理】
- 由于是线上问题，且是致命的无法提供服务，所以我先用jstack命令，把当前的线程状态打印出来（这里我没做好，应该先用“ps -mp pid -o THREAD,tid,time”把占用资源最高的线程找出来，而且不能光打印当前的线程状态，最好是把这些分析问题的信息全部输出到文件，便于后续随时查看当时出问题的现场）
- 马上重启支撑APP服务的业务系统，观察重启是否成功
- 重启成功，我运行手机上的APP，并通知测试，确保正常之后，通知用户，业务恢复正常。
【总结反思】
把线上业务恢复正常之后，回头分析打算去分析这个问题。翻看dump出来的线程信息，发现里面信息不全，少了很多前面的日志，然后也没有特别能看出问题的内容。
理了一下思路，我意识到我这里做错了两步：
jstack dump出来的信息，不应该直接打印在终端，终端的容量有限，关闭之后就不能访问了。应该存放在硬盘的文件里面，那之后随时都可以查看，而且可以发送给其他人查看。
重启应用之前，应该要找出，具体是哪些线程占用了过高的资源（这里是CPU），这样我就可以在线程信息繁多的dump文件里面，找到对应的线程信息，和堆栈信息，这样我就可以定位到具体的代码了。
虽然这次没能很好的找到具体的问题，但是我总结出了排查的思路，接下去我就要关注线上该服务的资源占用情况了，能够在下次重现该问题的时候，解决掉这个问题。
