Java并发之线程转储 java多线程状态

1、java线程转储

java的线程转储能够被定义为JVM中在某一个给定的时刻运行的全部线程的快照。一个线程转储可能包含一个单独的线程或者多个线程。在多线程环境中，好比J2EE应用服务器，将会有许多线程和线程组。每个线程都有它本身的调用堆栈，在一个给定时刻，表现为一个独立功能。线程转储将会提供JVM中全部线程的堆栈信息，对于特定的线程也会给出更多信息。

2、java虚拟机进程和java线程

java虚拟机，或者称为JVM，是一个操做系统级别的进程。java线程是JVM进程的子进程或者轻量级进程（Solar中的叫法）。

3、生成java线程转储

在java程序中有两种经常使用的方法可让咱们生成线程转储，这些方法对于linux或者Unix操做系统来讲是有效的，window状况稍有不一样。 

1. VisualVM 

咱们可使用VisualVM很容易的为任何java程序生成线程转储。只须要在运行的java进程上点右键，选择“Thread Dump”选项来生成。 

 

2.jstack

java提供了自带的工具jstack，经过这个工具咱们能够一样为java进程产生线程转储。经过两个步骤实现

2.1 用“ps -eaf | grep java”命令找到java进程的PID。 

2.2 用jstack PID 命令来生成线程转储到控制台，也能够用命令“jstack PID >> mydumps将输出保存到文件中mydumps中。 

3. Unix：kill -3 ，输出到了/proc//fd/1

4. Windows：CTRL+BREAK

4、java多线程状态

java多线程状态

线程的状态是一个重要的指标，它会显示在线程 Stacktrace的头一行结尾的地方。那么线程常见的有哪些状态呢？线程在什么样的状况下会进入这种状态呢？咱们能从中发现什么线索？ 

1.1 Runnable 
该状态表示线程具有全部运行条件，在运行队列中准备操做系统的调度，或者正在运行。 

1.2 Wait on condition 
该状态出如今线程等待某个条件的发生。具体是什么缘由，能够结合 stacktrace来分析。最多见的状况是线程在等待网络的读写，好比当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读以后，线程会从新激活，读取并处理数据。在 Java引入 NewIO以前，对于每一个网络链接，都有一个对应的线程来处理网络的读写操做，即便没有可读写的数据，线程仍然阻塞在读写操做上，这样有可能形成资源浪费，并且给操做系统的线程调度也带来压力。在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都获得提升。 

若是发现有大量的线程都在处在 Wait on condition，从线程 stack看， 正等待网络读写，这多是一个网络瓶颈的征兆。由于网络阻塞致使线程没法执行。一种状况是网络很是忙，几乎消耗了全部的带宽，仍然有大量数据等待网络读写；另外一种状况也多是网络空闲，但因为路由等问题，致使包没法正常的到达。因此要结合系统的一些性能观察工具来综合分析，好比 netstat统计单位时间的发送包的数目，若是很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，若是系统态的 CPU时间，相对于用户态的 CPU时间比例较高；若是程序运行在 Solaris 10平台上，能够用 dtrace工具看系统调用的状况，若是观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向因为网络带宽所限致使的网络瓶颈。 

另一种出现 Wait on condition的常见状况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。 

1.3 Waiting for monitor entry 和 in Object.wait() 
在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。 Monitor是 Java中用以实现线程之间的互斥与协做的主要手段，它能够当作是对象或者 Class的锁。每个对象都有，也仅有一个 monitor。下面这个图，描述了线程和 Monitor之间关系，以及线程的状态转换图： 
 

从图中能够看出，每一个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。 

先看 “Entry Set”里面的线程。咱们称被synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。对应的 code就像： 

synchronized(obj) { 
......... 
} 

这时有两种可能性： 

1）该 monitor不被其它线程拥有， Entry Set里面也没有其它等待线程。本线程即成为相应类或者对象的 Monitor的 Owner，执行临界区的代码 
2）该 monitor被其它线程拥有，本线程在 Entry Set队列中等待。 

在第一种状况下，线程将处于 “Runnable”的状态，而第二种状况下，线程 DUMP会显示处于 “waiting for monitor entry”。以下所示： 

"Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry [0xf927b000..0xf927bdb8] 
at testthread.WaitThread.run(WaitThread.java:39) 
- waiting to lock <0xef63bf08> (a java.lang.Object) 
- locked <0xef63beb8> (a java.util.ArrayList) 
at java.lang.Thread.run(Thread.java:595) 

临界区的设置，是为了保证其内部的代码执行的原子性和完整性。可是由于临界区在任什么时候间只容许线程串行经过，这 和咱们多线程的程序的初衷是相反的。 若是在多线程的程序中，大量使用 synchronized，或者不适当的使用了它，会形成大量线程在临界区的入口等待，形成系统的性能大幅降低。若是在线程 DUMP中发现了这个状况，应该审查源码，改进程序。 

如今咱们再来看如今线程为何会进入 “Wait Set”。当线程得到了 Monitor，进入了临界区以后，若是发现线程继续运行的条件没有知足，它则调用对象（通常就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ， “ Wait Set”队列中线程才获得机会去竞争，可是只有一个线程得到对象的 Monitor，恢复到运行态。在 “Wait Set”中的线程， DUMP中表现为： in Object.wait()，相似于： 

"Thread-1" prio=10 tid=0x08223250 nid=0xa in Object.wait() [0xef47a000..0xef47aa38] 
at java.lang.Object.wait(Native Method) 
- waiting on <0xef63beb8> (a java.util.ArrayList) 
at java.lang.Object.wait(Object.java:474) 
at testthread.MyWaitThread.run(MyWaitThread.java:40) 
- locked <0xef63beb8> (a java.util.ArrayList) 
at java.lang.Thread.run(Thread.java:595) 

仔细观察上面的 DUMP信息，你会发现它有如下两行： 

- locked <0xef63beb8> (a java.util.ArrayList) 
- waiting on <0xef63beb8> (a java.util.ArrayList) 

这里须要解释一下，为何先 lock了这个对象，而后又 waiting on同一个对象呢？让咱们看看这个线程对应的代码： 

synchronized(obj) { 
               ......... 
               obj.wait(); 
               ......... 
        } 

线程的执行中，先用 synchronized 得到了这个对象的 Monitor（对应于 locked <0xef63beb8> ）。当执行到 obj.wait(), 线程即放弃了 Monitor的全部权，进入 “wait set”队列（对应于 waiting on <0xef63beb8> ）。 

每每在你的程序中，会出现多个相似的线程，他们都有类似的 DUMP信息。这也多是正常的。好比，在程序中，有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是 lock以及 waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被 Notify，固然只有一个线程得到了 lock，继续执行，而其它线程继续等待。

5、分析一个Java线程

为了能够理解/分析线程转储，首先要理解线程转储的各个部分。让咱们先拿一个简单的线程堆栈为例，而且去了解他的每一个部分。

"ExecuteThread: '1' " daemon prio=5 tid=0x628330 nid=0xf runnable [0xe4881000..0xe48819e0]
at com.vantive.vanjavi.VanJavi.VanCreateForm(Native Method)
at com.vantive.vanjavi.VanMain.open(VanMain.java:53)
at jsp_servlet._so.__newServiceOrder.printSOSection( __newServiceOrder.java:3547)
at jsp_servlet._so.__newServiceOrder._jspService (__newServiceOrder.java:5652)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet (WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute (ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute (ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

In the above Thread Dump, the interesting part to is the first line. The rest of the stuff is nothing more than a general stack trace. Lets analyze the first line here

Execute Thread : 1 说明了线程的名字

daemon 代表这个线程是一个守护线程

prio=5 线程的优先级 (默认是5)

tid Java的线程Id (这个线程在当前虚拟机中的惟一标识).

nid 线程本地标识. 也就是Solaris中的LWP，线程在操做系统中的标识

runnable 线程的状态 (参考上面的)

[x..y] 当前运行的线程在堆中的地址范围

这个线程转储的剩余部分是调用堆栈。在这个例子中，这个线程（Execute Thread 1）是操做系统守护线程，当前正在执行一个本地方法vanCreateForm()。

6、使用线程转储

在这部分，我将描述几个用例来讲明线程转储是很是有用的。

1.高CPU占用率

①诊断

应用程序看起来几乎让CPU的占用率达到了100%，可是系统吞吐量却明显降低。开始于高负载的CPU性能不好。

②线程转储

经过全部的线程转储，能够看到一个或多个线程在同一个操做中罢工了。

③解决办法

• 为一个特定的调用流程（好比说网页上的form提交），在流程完成以前，生成一系列的线程转储（大约5~7个）
• 查找线程转储中的“runnable”线程。若是每个线程看起来运行良好（每个线程调用的方法都不相同），这些线程就是正在处理事务中，并且有可能并非此次事件的罪魁祸首。若是经过全部的线程转储，发现线程正在执行同一个方法（一样的行号），几乎就能够肯定这就是罪魁祸首了。那就能够查看代码，来作代码级别的分析了。你确定也能从代码中找到解决问题的灵感。

2.低CPU负载率和很长的响应时间

①诊断

这一般在一个高I/O限制的系统处于高负载的时候发生。CPU的占用率很低，只有几个线程在消耗CPU的时间片。然而应用的响应时间却很长。

②线程转储

一部分或者所有运行线程看起来就像是在一个I/O操做中罢工了，好比文件读/写或者数据库的操做。

③解决办法

了解你系统中的I/O操做。使用缓存以减小应用与数据库之间的交互。

3.应用/服务宕机

①诊断

一个应用或者一个运行这个应用的服务JVM宕机（变得中止响应）

②线程转储

• 在得到的全部线程转储中，能够看到全部的运行线程都在同一个操做中罢工了。服务器没有可用的线程，由于没有一个线程可以完成他本身的操做。
• 或许有不少线程在等待一个锁。当一个运行的线程持有一个对象锁不释放，而其余的线程刚好在等待这个对象锁的时候就会发生。

③解决办法

• 检查死锁，一般简单状况下（线程A在等待线程B，同时B也在等待A），JVM一般会检测到死锁。可是，你须要了解在这个时刻锁的状态，以确认这时候是否涉及到一个复杂的死锁了。
• 复查同步方法/代码块，尽量的将不须要同步的代码移出同步区，以减小同步区的大小。
• 这种问题还有一个可能，就是访问一个远程的资源/组件的响应超时设置的太长。在访问远程对象时设置一个合理的超时时间，这样就可以在远程系统失去响应时抛出一个能够捕获的异常。
• 若是全部的线程在等待一个资源（好比EJB/DB链接），考虑增长这些资源的对象池大小。