线上异常排查总结

一般来说，一个已经投入运营的大型项目出现问题的可能最多如下几种情况：

异常的CPU使用率

业务相关

业务高峰或上下游业务方异常的高QPS

定时任务大量的任务并发

消息、请求堆积后恢复时的瞬时流量引起

持久化任务引起

未经优化的代码

HASH冲突大量的KEY的hashcode相同，导致单链表过长

锁竞争，代码上下文复杂度低，导致大量线程停留在上锁代码处竞争锁

集合频繁扩容，用map或collection通信时，多次扩容容器

GC增高

空间分配不合理或代码不合理导致的频繁gc

代码不合理或虚拟机配置不合理导致的大量对象直接创建在老年代中(PretenureSizeThreshold)

java1.6中，大量使用代理引起的perm空间不足

load增高

线程使用不当导致产生大量线程，大量线程处于WAITING或TIMED_WAITING竞争资源，从而load增高

容器使用不当导致的线程不安全，引起循环链表等，线程陷入死循环，频繁竞争CPU资源

st增高

超卖或宿主机的问题或宿主机下的其他虚拟机竞争了资源

对于CPU异常的排查：
第一步：就是找出业务关联，由业务引起的异常可以将复的同步任务改造为异步任务，限流，扩容等方式优化

第二步：定位异常线程，使用top -Hp来确定线程号(此处十进制)，再使用kill -3 或 jstat 确认线程(此处十六进制，注意转换)，根据线程数量、线程名称、线程状态、上下文确定问题点

第三步 : 定位异常的GC，使用jmap -heap、jstat -gcpermcapation 等命令确认问题，频繁的fullgc或长时间的fullgc都是异常的问题点

第四步：定位代码异常，可用jmap导出堆栈判断数据结构排查容器使用情况。

异常的内存使用

业务或配置导致

业务模型的设计不合理，大量的长生命周期的对象

虚拟机配置不合理引起的空间不足

阻塞io的使用又未使用超时

内存泄露

逻辑混乱、bug等问题导致的大量对象

性能不足引起的等待处理队列持续增长

静态空间异常

类加载器使用不当导致的大量的classloader和随之加载的class

堆外内存的分配不均

使用了nio但是了解不深导致的产生堆外内存

不正确的对unsafe使用或者开源项目中的bug产生的堆外内存脱离管理

对于内存异常的排查：
第一步：检查内存状态，使用jmap -heap 等命令查看内存使用，调优参数

第二部：检查实例统计，使用jmap命令查看活跃实例

第三步：dump出内存，直接分析

异常的IO使用

待整理….

其他异常情况

日志无输出

一般日志包冲突引起，可根据我的另一篇博客定位问题

类冲突

使用IDE定位class存在的jar包，使用maventree排查不兼容的版本依赖，如果两个以来使用了不兼容的版本，可以根据需要自己打包特殊版本

timeout

数据库的timeout或spring的事物机制，根据情况解决

待整理