一、摘要
由于硬件问题、系统资源紧缺或者程序本身的BUG,Java服务在线上不可避免地会出现一些“系统性”故障,比如:服务性能明显下降、部分(或所有)接口超时或卡死等。其中部分故障隐藏颇深,对运维和开发造成长期困扰。笔者根据自己的学习和实践,总结出一套行之有效的“逐步排除”的方法,来快速定位Java服务线上“系统性”故障。二、导言
Java语言是广泛使用的语言,它具有跨平台的特性和易学易用的特点,很多服务端应用都采用Java语言开发。由于软件系统本身以及运行环境的复杂性,Java的应用不可避免地会出现一些故障。尽管故障的表象通常比较明显(服务反应明显变慢、输出发生错误、发生崩溃等),但故障定位却并不一定容易。为什么呢?有如下原因: 1. 程序打印的日志越详细,越容易定位到BUG,但是可能有些时候程序中没有打印相关内容到日志,或者日志级别没有设置到相应级别 2. 程序可能只对很特殊的输入条件发生故障,但输入条件难以推断和复现 3. 通常自己编写的程序出现的问题会比较容易定位,但应用经常是由多人协作编写,故障定位人员可能并不熟悉其他人员编写的程序 4. 应用通常会依赖很多第三方库,第三方库中隐藏着的BUG可能是始料未及的 5. 多数的开发人员学习的都是“如何编写业务功能”的技术资料,但对于“如何编写高效、可靠的程序”、“如何定位程序故障”却知之甚少。所以一旦应用出现故障,他们并没有足够的技术背景知识来帮助他们完成故障定位。 尽管有些故障会很难定位,但笔者根据学习和实践总结出一套“逐步排除”的故障定位方法:通过操作系统和Java虚拟机提供的监控和诊断工具,获取到系统资源和目标服务(出现故障的Java服务)内部的状态,并依据服务程序的特点,识别出哪些现象是正常的,哪些现象是异常的。而后通过排除正常的现象,和跟踪异常现象,就可以达到故障定位的目标。 在正式介绍该方法之前,先申明一下这个方法使用的范围。三、本方法适用的范围
本方法主要适用于Linux系统中Java服务线上“系统性”故障的定位,比如:服务性能明显下降、部分(或所有)接口超时或卡死。其它操作系统或其它语言的服务,也可以参考本文的思路。 不适用本方法的情况:对于“功能性”故障,例如运算结果不对、逻辑分支走错等,不建议使用本方法。对待这些情况比较恰当的方法是在测试环境中重现,并使用Java虚拟机提供的“远程调试”功能进行动态跟踪调试。 前面说过,本方法基于“异常现象”的识别来定位故障。那系统中可能有哪些异常现象呢?四、有哪些异常现象
我们可以将异常现象分成两类:系统资源的异常现象、“目标服务”内部的异常现象。目标服务,指的是出现故障的Java服务。 1. 系统资源的异常现象 一个程序由于BUG或者配置不当,可能会占用过多的系统资源,导致系统资源匮乏。这时,系统中其它程序就会出现计算缓慢、超时、操作失败等“系统性”故障。常见的系统资源异常现象有:CPU占用过高、物理内存富余量极少、磁盘I/O占用过高、发生换入换出过多、网络链接数过多。可以通过top、iostat、vmstat、netstat工具获取到相应情况。 2. 目标服务内部的异常现象- Java堆满
Java堆是“Java虚拟机”从操作系统申请到的一大块内存,用于存放Java程序运行中创建的对象。当Java堆满或者较满的情况下,会触发“Java虚拟机”的“垃圾收集”操作,将所有“不可达对象”(即程序逻辑不能引用到的对象)清理掉。有时,由于程序逻辑或者Java堆参数设置的问题,会导致“可达对象”(即程序逻辑可以引用到的对象)占满了Java堆。这时,Java虚拟机就会无休止地做“垃圾回收”操作,使得整个Java程序会进入卡死状态。我们可以使用jstat工具查看Java堆的占用率。 - 日志中的异常
目标服务可能会在日志中记录一些异常信息,例如超时、操作失败等信息,其中可能含有系统故障的关键信息。 - 疑难杂症
死锁、死循环、数据结构异常(过大或者被破坏)、集中等待外部服务回应等现象。这些异常现象通常采用jstack工具可以获取到非常有用的线索。
五、故障定位的步骤
我们采用“从外到内,逐步排除”的方式来定位故障: 1. 先排除其它程序过度占用系统资源的问题 2. 然后排除“目标服务”本身占用系统资源过度的问题 3. 最后观察目标服务内部的情况,排除掉各种常见故障类型。 对于不能排除的方面,要根据该信息对应的“危险程度”来判断是应该“进一步深入”还是“暂时跳过”。例如“目标服务Java堆占用100%”这是一条危险程度较高的信息,建议立即“进一步深入”。而对于“在CPU核数为8的机器上,其它程序偶然占用CPU达200%”这种危险程度不是很高的信息,则建议“暂时跳过”。当然,有些具体情况还需要故障排查人员根据自己的经验做出判断。第一步:排除其它程序占用过量系统资源的情况
![outer](http://techblog.youdao.com/wp-content/uploads/2014/08/outer.png)
![cpu_idle](http://techblog.youdao.com/wp-content/uploads/2014/08/cpu_idle.png)
![free](http://techblog.youdao.com/wp-content/uploads/2014/08/free.png)
![vmstat](http://techblog.youdao.com/wp-content/uploads/2014/08/vmstat.png)
![iostat](http://techblog.youdao.com/wp-content/uploads/2014/08/iostat.png)
![df](http://techblog.youdao.com/wp-content/uploads/2014/08/df.png)
- 系统提供的调用栈的转储工具【pstack】,可以了解到程序中各个线程当前正在干什么,从而了解到什么逻辑占用了CPU、什么逻辑占用了磁盘等
- 系统提供的调用跟踪工具【strace】,可以侦测到程序中每个系统API调用的参数、返回值、调用时间等。从而确认程序与系统API交互是否正常等。
- 系统提供的调试器【gdb】,可以设置条件断点侦测某个系统函数调用的时候调用栈是什么样的。从而了解到什么逻辑不断在分配内存、什么逻辑不断在创建新连接等
第二步:排除目标服务占用了过量系统资源的情况
![self](http://techblog.youdao.com/wp-content/uploads/2014/08/self.png)
- 如果CPU使用分散到多个线程,而且每个线程占用都不算高(例如都<30%),则排除CPU占用过高的问题
- 如果CPU使用集中到一个或几个线程,而且很高(例如都>95%),则用【jstack pid > jstack.log】获取目标服务中线程调用栈的情况。top中看到的占用CPU较高的线程的PID转换成16进制(字母用小写),然后在jstack.log中找到对应线程,检查其逻辑:
- 假如对应线程是纯计算型任务(例如GC、正则匹配、数值计算等),则排除CPU占用过高的问题。当然如果这种线程占用CPU总量如果过多(例如占满了所有核),则需要对线程数量做控制(限制线程数 < CPU核数)。
- 假如对应线程不是纯计算型任务(例如只是向其他服务请求一些数据,然后简单组合一下返回给用户等),而该线程CPU占用过高(>95%),则可能发生了异常。例如:死循环、数据结构过大等问题,确定具体原因的方法见下文“第三步:目标进程内部观察”。
第三步:目标服务内部观察
![inside](http://techblog.youdao.com/wp-content/uploads/2014/08/inside.png)
- 检查jstack.log中是否有deadlock报出,如果没有则排除deadlock情况。
Found one Java-level deadlock: ============================= “Thread-0″: waiting to lock monitor 0x1884337c (object 0x046ac698, a java.lang.Object), which is held by “main” “main”: waiting to lock monitor 0x188426e4 (object 0x046ac6a0, a java.lang.Object), which is held by “Thread-0″ Java stack information for the threads listed above: =================================================== “Thread-0″: at LockProblem$T2.run(LockProblem.java:14) - waiting to lock <0x046ac698> (a java.lang.Object) - locked <0x046ac6a0> (a java.lang.Object) “main”: at LockProblem.main(LockProblem.java:25) - waiting to lock <0x046ac6a0> (a java.lang.Object) - locked <0x046ac698> (a java.lang.Object) Found 1 deadlock.如果发现deadlock则则根据jstack.log中的提示定位到对应代码逻辑。
- 用【POST http://www.xinitek.com/ajax/summaryJStack < jstack.log > jstack.log.summary】对jstack.log做合并处理,然后继续分析故障所在。
情况 | 嫌疑点 | 猜测原因 |
线程数量过多 | 某种线程数量过多 | 运行环境中“限制线程数量”的机制失效 |
多个线程在等待一把锁,但拿到锁的线程在做某个操作 | 拿到这把锁的线程在做网络connect操作 | 被connect的服务异常 |
拿到锁的线程在做数据结构遍历操作 | 该数据结构过大或被破坏 | |
某个耗时的操作被反复调用 | 某个应当被缓存的对象多次被创建 | 对象池的配置错误 |
等待外部服务的响应 | 很多线程都在等待外部服务的响应 | 该外部服务故障 |
很多线程都在等待FutureTask完成,而FutureTask在等待外部服务的响应 | 该外部服务故障 |
1000 threads at “Timer-0″ prio=6 tid=0x189e3800 nid=0x34e0 in Object.wait() [0x18c2f000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.util.TimerThread.mainLoop(Timer.java:552) - locked [***] (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:505)2. 多个线程在等待一把锁,但拿到锁的线程在做数据结构遍历操作
38 threads at “Thread-44″ prio=6 tid=0×18981800 nid=0x3a08 waiting for monitor entry [0x1a85f000] java.lang.Thread.State: BLOCKED (on object monitor) at SlowAction$Users.run(SlowAction.java:15) - waiting to lock [***] (a java.lang.Object)
1 threads at “Thread-3″ prio=6 tid=0x1894f400 nid=0×3954 runnable [0x18d1f000] java.lang.Thread.State: RUNNABLE at java.util.LinkedList.indexOf(LinkedList.java:603) at java.util.LinkedList.contains(LinkedList.java:315) at SlowAction$Users.run(SlowAction.java:18) - locked [***] (a java.lang.Object)3. 某个应当被缓存的对象多次被创建(数据库连接) 99 threads at “resin-tcp-connection-*:3231-321″ daemon prio=10 tid=0x000000004dc43800 nid=0x65f5 waiting for monitor entry [0x00000000507ff000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) - waiting to lock <0x00000000b26ee8a8> (a org.apache.commons.dbcp.PoolableConnectionFactory) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) … 1 threads at “resin-tcp-connection-*:3231-149″ daemon prio=10 tid=0x000000004d67e800 nid=0x66d7 runnable [0x000000005180f000] java.lang.Thread.State: RUNNABLE … at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:46) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) - locked <0x00000000b26ee8a8> (a org.apache.commons.dbcp.PoolableConnectionFactory) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) at … 4. 很多线程都在等待外部服务的响应 100 threads at
“Thread-0″ prio=6 tid=0x189cdc00 nid=0×2904 runnable [0x18d5f000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
…
at RequestingService$RPCThread.run(RequestingService.java:24)
5. 很多线程都在等待FutureTask完成,而FutureTask在等待外部服务的响应 100 threads at “Thread-0″ prio=6 tid=0×18861000 nid=0x38b0 waiting on condition [0x1951f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for [***] (a java.util.concurrent.FutureTask$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:248) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at IndirectWait$MyThread.run(IndirectWait.java:51) 100 threads at
“pool-1-thread-1″ prio=6 tid=0x188fc000 nid=0×2834 runnable [0x1d71f000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
…
at IndirectWait.request(IndirectWait.java:23)
at IndirectWait$MyThread$1.call(IndirectWait.java:46)
at IndirectWait$MyThread$1.call(IndirectWait.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
![all](http://techblog.youdao.com/wp-content/uploads/2014/08/all.png)