java 异常监控系统_Java常见问题－排查线上服务故障手段(请先看本文)

一般排查线上问题常规的都是这几种手段：1、紧急处理；2、添加监控；3、异常处理；4、分析源代码那么一个一个说下去，怎么处理。在陆续分享一些java常见的排查方式

如NoSuchMethodException，应用没响应，调用另一应用超时， java.lang.OutOfMemoryError ，CPU us高，CPU sy高，CPU iowait高 ，Java进程退出等。

1、紧急处理

我做过的所有项目中，95%的故障都是在新代码上线后的12小时内发生的此时，根据情况判断是否应该立刻回滚新更改。

而另外5%的故障大部分是由于业务扩展导致的，这时候就需要进入其他的流程了。

在我们互联网圈子里面，技术业内也有一个普通的规律，线上的系统每半年都是需要重构一次的，否则无法对应业务量的增长。当然这也是说明那些增长比较快的企业。

对于因为业务量增长造成的故障，通常可以通过重启服务(服务容器如tomcat\jetty等)来紧急处理。

所这里总结下：如遇见紧急情况，第一个做的事情就是看看系统影响和系统变更的内容是否存在异常，如果处理不了异常立即联系pe回滚上一个版本。

2、添加监控

如果是因为业务扩展，研发添加的新代码上线，造成的故障，在系统回滚之后，研发在测试环境和预发环境，都是会有各种手段，来追查问题的；

如果是因为系统容量不足造成的故障，需要添加监控来作为追查问题的重要手段，监控一般用一个简单的脚本就可以搞定，比如http服务监控、jvm内存监控啊等等。

3、异常处理

首先要查看日志，看看有没有Exception。另外日志中常常有对接口调用，缓存使用的监控告警信息等。一个一个仔细认真的查看，都是有线索的。

之后查看目前gc的状况如何，使用JDK自带的工具就可以。命令jstat -gc -h 10 vmid 5000，每5秒打出一次。

一次是Permanent区分配过小，JVM内存溢出，内存造成的问题通过简单的重启服务就可以使得服务恢复，如果是old区增长的过快，就可能是内存泄露。

生了过多的Full GC，使得系统停止响应 也可以实用：jmap -histo vmid > jmap.log

，该命令会打出所有对象，包括占用的byte

数和实例个数

检查目前cpu占用情况，top -H，然后按“1”，会看到当前进程中每个线程所占CPU的比例

观察前几名，然后jstack -l vmid > jstack.log打出线程堆栈，看看是什么线程占用了CPU这是gc的处理的常用手段

4、分析源代码

分析源代码是最有技术含量的事情，也是比较耗时而且不见得有效果的事情，解决线上问题的最后一步，因为必须要做到“有的放矢”。带着问题去分析代码，会比较容易

性能问题其实通过20%代码的修改，就可以解决80%的性能问题

5、一些java常见问题线上排查

总结

线上问题遇见如果可以回滚，第一时间回滚在测试环境复现；如果不能回滚需要仔细检查线上日志看看是否存在异常，如果运行没有异常，就看看容器和jvm内存是否沾满，如果没有任何日志，可以通过重启缓解症状，如果好一会之后又挂，重启之后又好了，基本上都是内存占满了，容量过高需要添加机器解决问题。

只不过不管怎么样，遇见这些问题，还需要继续看的，想知道具体什么原因除了基础知识，还是要熟练才行。