码迷,mamicode.com
首页 > 编程语言 > 详细

线程转储分析

时间:2016-09-17 23:49:11      阅读:292      评论:0      收藏:0      [点我收藏+]

标签:

一、线程状态

 在具体分析线程转储数据之前,我们首先要明确线程的状态。java.lang.Thread.State枚举类中定义了如下几种类型:

  • NEW:线程创建尚未启动。
  • RUNNABLE:包括操作系统线程状态中的Ready和Running,可能在等待时间片或者正在执行。
  • BLOCKED:线程被阻塞。
  • WAITING:不会分配CPU执行时间,直到别的线程显式的唤醒,否则无限期等待。LockSupport.park(),没有设置Timeout参数的Object.wait()和Thread.join(),会导致此现象。
  • TIMED_WAITING:不会分配CPU执行时间,直到系统自动唤醒,不需要别的线程显示唤醒。Thread.sleep(),LockSupport.parkNanos(),LockSupport.parkUntil(),设置了超时时间的Object.wait()和Thread.join(),会让线程进入有限期等待。
  • TERMINATED:线程执行结束

  很多人分不清楚阻塞等待的区别,导致在分析线程转储时出现偏差。

  阻塞状态与等待状态的区别是:阻塞状态的线程是在等待一个排它锁,直到别的线程释放该排它锁,该线程获取到该锁才能退出阻塞状态;

  而等待状态的线程则是等待一段时间,由系统唤醒或者别的线程唤醒,该线程便退出等待状态。 

 线程状态转化见下图:

技术分享

  在任意一个时刻,线程只能处于其中的一种状态。

  上面的状态颗粒度比较大,stackoverflow上有个哥们将状态定义为如下11种。在我们强制dump出来的转储中,更多的是表现为如下状态中的一种。至于这11种状态的是否权威,不敢妄下定论。

  1. NEW: Just starting up, i.e., in process of being initialized.
  2. NEW_TRANS: Corresponding transition state (not used, included for completness).
  3. IN_NATIVE: Running in native code.
  4. IN_NATIVE_TRANS: Corresponding transition state.
  5. IN_VM: Running in VM.
  6. IN_VM_TRANS: Corresponding transition state.
  7. IN_JAVA: Running in Java or in stub code.
  8. IN_JAVA_TRANS: Corresponding transition state (not used, included for completness).
  9. BLOCKED: Blocked in vm.
  10. BLOCKED_TRANS: Corresponding transition state.
  11. UNINITIALIZED

  Java的线程转储指的是JVM中在某一个给定的时刻运行的所有线程的快照。一个线程转储可能包含一个单独的线程或者多个线程。在多线程环境中,如Java EE应用服务器,将会有许多线程和线程组。转储中的每一个线程都有一自己独立的逻辑,这些逻辑信息将会在堆栈信息中体现。

 线程转储可以通过如下的方式生成:

  1. Unix:kill -3 ,输出到了/proc//fd/1
  2. Windows:CTRL+BREAK
  3. jstack:jstack >> 输出文件

  在Linux上,大家可能都碰见过这样的问题:

技术分享

  就是用jstack 是拿不到thread dump的,必须加-F来强制dump。上面的问题是其实很简单,就是pid路径问题导致的,Google一下就清楚了。我想说的是,加-F dump出来的内容是不能用TDA分析的。如果不是真正的进程挂起,如果又想使用TDA进行分析的话,可以使用第一种方式进行dump。但有时候,的确必须要使用-F才能获得dump信息,比如程序挂起了。由于jstack -F/m就会使用到SA(The Serviceability Agent),我们平常不加-F/-m的时候默认走的是Instrumentationattach操作,知道这点非常重要。

二、转储说明

  线程转储生成好之后,我们便可以开始着手分析转储信息了,下面会给出几个例子逐一分析。

例子1

技术分享

  • http-bio-8080-exec-1-SendThread(192.168.161.36:2181):线程的名字
  • daemon:守护线程
  • prio=10:线程的优先级(默认是5)
  • tid:Java的线程Id(线程在当前虚拟机中的唯一标识)
  • nid:线程本地标识
  • runnable:线程的状态
  • [0x00007f79795ac000]:当前运行的线程在堆中的地址范围

  这个线程转储的剩余部分是调用堆栈,这个线程(http-bio-8080-exec-1-SendThread(192.168.161.36:2181))是操作系统守护线程,当前正在执行一个本地方法epollWait。该native线程正处于RUNNABLE的状态。

例子2

技术分享

  该转储表示守护线程http-bio-8080-exec-1会一直等待,直到ThreadPoolExecutor上有需要执行的任务分配给该线程执行(LockSupport.unpark),它才能从LockSupport.park中解脱出来。

 例子3

技术分享

  线程RMI Scheduler不会分配CPU执行时间,直到系统自动唤醒,不需要别的线程显示唤醒。它由于调用了LockSupport.parkNanos()进入了有限期等待。

三、案例分析

1、CPU负载高

  Java进程CPU占用率居高不下,导致系统吞吐率下降,这种问题对很多初级码农来说简直就是梦魇。如果想快速的定位CPU高的原因,线程转储绝对是第一选择。CPU过高一般原因分为CPU密集型和死循环,这两种情况我们分开来分析。

死循环分析非常简单,步骤如下:

  1. 在CPU占用率高的时候,通过top -H或者ps H -eo user,pid,ppid,tid,time,%cpu,cmd –sort=%cpu将CPU占用率高的线程的tid给找出来,并即时线程转储。
  2. 将上面的找到的tid进行转化为16进制,然后在线程转储中查找对应的线程号,都会找到对应的nid标示。
  3. 定位之后,通过转储中的精确的行号,可以定位到代码中相应的位置,便可以迅速确定原因。

  死循环一般是逻辑错误导致的,我们在代码中应该慎用自旋。在一些带有状态机逻辑的代码中,加入次数限制,防止程序跑飞。

  CPU密集型分析跟死循环不一样,因为你通过查看线程的CPU使用率,你会发现每个线程都不是很高,但是多个加起来之后就不容乐观。这类问题,步骤如下:

  1. 在CPU占用率高的时候,通过top -H或者ps H -eo user,pid,ppid,tid,time,%cpu,cmd –sort=%cpu将CPU占用率高的前10个线程的tid给找出来,并即时线程转储。
  2. 将上面的找到的tid进行转化为16进制,然后在线程转储中查找对应的线程号,将能够找到的部分标记出来。
  3. 然后在标记出来的线程转储中寻找共性。如果通过所有的线程转储,发现线程正在执行同一个方法(同样的行号),几乎就可以确定这就是罪魁祸首了。那就可以查看代码,来做代码级别的分析了,问题便迎刃而解了。

  CPU密集型,一般原因是算法效率低导致的。例如,正则表达式写的差,该用Map或者Set结构的却用了List来遍历。

   线程占用CPU的类型可以分为如下两种:

    us:用户空间占用CPU百分比

    sy:内核空间占用CPU百分比

  在linux下可以通过top命令查看详细,示例如下:

技术分享

 CPU us高的原因主要是执行线程不需要任何挂起动作,且一直执行,导致CPU没有机会去调度执行其他的线程,我们上面分析的都属于这类情况。

 CPU sy高的原因主要是线程的运行状态要经常切换,对于这种情况,常见的一种优化方法是减少线程数。

2、响应慢(低负载)

 相应时间长,一般出现在高负载的机器上。如果在CPU的占用率很低,只有几个线程在消耗CPU的时间片,然而应用的响应时间却很长,我们首先要想到的是IO操作出现问题,至于到底是网络IO还是本地IO,我们就可以通过线程转储来定位。定位到位置之后,可以使用缓存或者减少IO操作来提升系统响应速度。

3、应用/服务宕机

  当一个应用活着却不能完成任何响应的时候,表明该服务已经宕机。

  此时分析线程转储,会发现大量的线程在同一个操作中罢工了,没有任何一个线程能够完成自己的操作,从而导致该JVM再没有可用的线程。很多时候都是由于死锁导致的,当一个线程持有一个对象锁而不释放,而别的线程都在等待该锁的时候便会发生死锁现象。幸运的是JVM通常会检测死锁,通过工具分析转储能够更快的定位到原因。如果想避免复杂的死锁,我们需要尽可能减小同步块的大小,并且在进行资源的访问时设置合理的超时时间,避免死等现象。

线程转储分析

标签:

原文地址:http://www.cnblogs.com/moonandstar08/p/5879968.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!