Java语言定义的线程状态分析

    说到线程,一定要谈到线程状态,不同的状态说明线程正处于不同的工作机制下,不同的工作机制下某些动作可能对线程产生不同的影响。

    Java语言定义了6中状态,而同一时刻,线程有且仅有其中的一种状态。要获取Java线程的状态可以使用 java.lang.Thread类中定义的 getState()方法,获取当前线程的状态就可以使用Thread.currentThread().getState()来获取。该方法返回的类型是一个枚举类型,是Thread内部的一个枚举,全称为“java.lang.Thread.State”,这个枚举中定义的类型列表就是Java语言这个级别对应的线程状态列表,包含了NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED这些值。

 

以下是本文的目录大纲:

一、Java的几种线程状态说明

二、Java线程状态转换图

三、“VisualVM线程监控线程状态”与“Java线程状态”对应关系

 

若有不正之处请多多谅解,欢迎批评指正、互相讨论。

请尊重作者劳动成果,转载请标明原文链接:

http://www.cnblogs.com/trust-freedom/p/6606594.html

 

一、Java的几种线程状态说明

1、NEW(新建)

java.lang.Thread.State枚举中的NEW状态描述:

/**
 * Thread state for a thread which has not yet started.
 */
NEW

创建后尚未启动的线程处于这个状态。

意思是这个线程没有被start()启动,或者说还根本不是一个真正意义上的线程,从本质上讲这只是创建了一个Java外壳,还没有真正的线程来运行。

不代表调用了start(),状态就立即改变,中间还有一些步骤,如果在这个启动的过程中有另一个线程来获取它的状态,其实是不确定的,要看那些中间步骤是否已经完成了。

2、RUNNABLE(可运行)

java.lang.Thread.State枚举中的RUNNABLE状态描述:

/**
 * Thread state for a runnable thread.  A thread in the runnable
 * state is executing in the Java virtual machine but it may
 * be waiting for other resources from the operating system
 * such as processor.
 */
RUNNABLE

RUNNABLE状态包括了操作系统线程状态中的Running和Ready,也就是处于此状态的线程可能正在运行,也可能正在等待系统资源,如等待CPU为它分配时间片,如等待网络IO读取数据。

RUNNABLE状态也可以理解为存活着正在尝试征用CPU的线程(有可能这个瞬间并没有占用CPU,但是它可能正在发送指令等待系统调度)。由于在真正的系统中,并不是开启一个线程后,CPU就只为这一个线程服务,它必须使用许多调度算法来达到某种平衡,不过这个时候线程依然处于RUNNABLE状态。

3、BLOCKED(阻塞)

java.lang.Thread.State枚举中的BLOCKED状态描述:

/**
 * Thread state for a thread blocked waiting for a monitor lock.
 * A thread in the blocked state is waiting for a monitor lock
 * to enter a synchronized block/method or
 * reenter a synchronized block/method after calling
 * {@link Object#wait() Object.wait}.
 * 当一个线程要进入synchronized语句块/方法时,如果没有获取到锁,会变成BLOCKED
 * 或者在调用Object.wait()后,被notify()唤醒,再次进入synchronized语句块/方法时,如果没有获取到锁,会变成BLOCKED
 */
BLOCKED

BLOCKED称为阻塞状态,或者说线程已经被挂起,它“睡着”了,原因通常是它在等待一个“锁”,当尝试进入一个synchronized语句块/方法时,锁已经被其它线程占有,就会被阻塞,直到另一个线程走完临界区或发生了相应锁对象的wait()操作后,它才有机会去争夺进入临界区的权利

在Java代码中,需要考虑synchronized的粒度问题,否则一个线程长时间占用锁,其它争抢锁的线程会一直阻塞,直到拥有锁的线程释放锁

处于BLOCKED状态的线程,即使对其调用 thread.interrupt()也无法改变其阻塞状态,因为interrupt()方法只是设置线程的中断状态,即做一个标记,不能唤醒处于阻塞状态的线程

注意:ReentrantLock.lock()操作后进入的是WAITING状态,其内部调用的是LockSupport.park()方法

4、WAITING(无限期等待)

/**
 * Thread state for a waiting thread.
 * A thread is in the waiting state due to calling one of the
 * following methods:
 * <ul>
 *   <li>{@link Object#wait() Object.wait} with no timeout</li>
 *   <li>{@link #join() Thread.join} with no timeout</li>
 *   <li>{@link LockSupport#park() LockSupport.park}</li>
 * </ul>
 *
 * <p>A thread in the waiting state is waiting for another thread to
 * perform a particular action.
 *
 * For example, a thread that has called <tt>Object.wait()</tt>
 * on an object is waiting for another thread to call
 * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
 * that object. A thread that has called <tt>Thread.join()</tt>
 * is waiting for a specified thread to terminate.
 */
WAITING

处于这种状态的线程不会被分配CPU执行时间,它们要等待显示的被其它线程唤醒。这种状态通常是指一个线程拥有对象锁后进入到相应的代码区域后,调用相应的“锁对象”的wait()方法操作后产生的一种结果。变相的实现还有LockSupport.park()、Thread.join()等,它们也是在等待另一个事件的发生,也就是描述了等待的意思。

以下方法会让线程陷入无限期等待状态:

(1)没有设置timeout参数的Object.wait()

(2)没有设置timeout参数的Thread.join()

(3)LockSupport.park()

注意:

LockSupport.park(Object blocker) 会挂起当前线程,参数blocker是用于设置当前线程的“volatile Object parkBlocker 成员变量”

parkBlocker 是用于记录线程是被谁阻塞的,可以通过LockSupport.getBlocker()获取到阻塞的对象,用于监控和分析线程用的。

 

“阻塞”与“等待”的区别:

(1)“阻塞”状态是等待着获取到一个排他锁,进入“阻塞”状态都是被动的,离开“阻塞”状态是因为其它线程释放了锁,不阻塞了;

(2)“等待”状态是在等待一段时间 或者 唤醒动作的发生,进入“等待”状态是主动的

如主动调用Object.wait(),如无法获取到ReentraantLock,主动调用LockSupport.park(),如主线程主动调用 subThread.join(),让主线程等待子线程执行完毕再执行

离开“等待”状态是因为其它线程发生了唤醒动作或者到达了等待时间

5、TIMED_WAITING(限期等待)

/**
 * Thread state for a waiting thread with a specified waiting time.
 * A thread is in the timed waiting state due to calling one of
 * the following methods with a specified positive waiting time:
 * <ul>
 *   <li>{@link #sleep Thread.sleep}</li>
 *   <li>{@link Object#wait(long) Object.wait} with timeout</li>
 *   <li>{@link #join(long) Thread.join} with timeout</li>
 *   <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>
 *   <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>
 * </ul>
 */
TIMED_WAITING

处于这种状态的线程也不会被分配CPU执行时间,不过无需等待被其它线程显示的唤醒,在一定时间之后它们会由系统自动的唤醒。

以下方法会让线程进入TIMED_WAITING限期等待状态:

(1)Thread.sleep()方法

(2)设置了timeout参数的Object.wait()方法

(3)设置了timeout参数的Thread.join()方法

(4)LockSupport.parkNanos()方法

(5)LockSupport.parkUntil()方法

6、TERMINATED(结束)

/**
 * Thread state for a terminated thread.
 * The thread has completed execution.
 */
TERMINATED

已终止线程的线程状态,线程已经结束执行。换句话说,run()方法走完了,线程就处于这种状态。其实这只是Java语言级别的一种状态,在操作系统内部可能已经注销了相应的线程,或者将它复用给其他需要使用线程的请求,而在Java语言级别只是通过Java代码看到的线程状态而已。

 

二、Java线程状态转换图

 

上图为个人了解的线程状态转换的各种情况,如有不到位的地方欢迎交流指教。

 

三、“VisualVM线程监控线程状态”与“Java线程状态”对应关系

通过VisualVM监控JVM时,可以通过“线程”标签页查看JVM的线程信息,VisualVM的线程状态如下:

通过dump thread stack,并与VisualVM监控信息中的线程名称对应,找到的VisualVM每种线程状态的线程堆栈如下:(请关注重点信息)

1、运行

"http-bio-8080-Acceptor-0" daemon prio=6 tid=0x000000000d7b4800 nid=0xa264 runnable [0x000000001197e000]
      java.lang.Thread.State: RUNNABLE
            at java.net.DualStackPlainSocketImpl.accept0(Native Method)
            at java.net.DualStackPlainSocketImpl.socketAccept(DualStackPlainSocketImpl.java:131)
            at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
            at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:199)
            - locked <0x00000000c2303850> (a java.net.SocksSocketImpl)
            at java.net.ServerSocket.implAccept(ServerSocket.java:530)
            at java.net.ServerSocket.accept(ServerSocket.java:498)
            at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
            at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:220)
            at java.lang.Thread.run(Thread.java:745)

Locked ownable synchronizers:
        - None

2、休眠

"Druid-ConnectionPool-Destory-293325558" daemon prio=6 tid=0x000000000d7ad000 nid=0x9c94 waiting on condition [0x000000000bf0f000]
      java.lang.Thread.State: TIMED_WAITING (sleeping)
           at java.lang.Thread.sleep(Native Method)
            at com.alibaba.druid.pool.DruidDataSource$DestroyConnectionThread.run(DruidDataSource.java:1685)

Locked ownable synchronizers:
        - None

3、等待

"Finalizer" daemon prio=8 tid=0x0000000009349000 nid=0xa470 in Object.wait() [0x000000000a82f000]
      java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x00000000c22a0108> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)

      - locked <0x00000000c22a0108> (a java.lang.ref.ReferenceQueue.Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
            at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

   Locked ownable synchronizers:
        - None

 

"JMX server connection timeout 45" daemon prio=6 tid=0x000000000e846000 nid=0xab10 in Object.wait() [0x00000000137df000]
      java.lang.Thread.State: TIMED_WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
           - waiting on <0x00000000c55da3f0> (a [I)
            at com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
            - locked <0x00000000c55da3f0> (a [I)
            at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
         - None

4、驻留

"http-bio-8080-exec-2" daemon prio=6 tid=0x000000000d7b8000 nid=0x9264 waiting on condition [0x000000000ee4e000]
      java.lang.Thread.State: WAITING (parking)
            at sun.misc.Unsafe.park(Native Method)
           - parking to wait for  <0x00000000c5629bc8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject)
            at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
            at java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
            at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
            at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
            at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
            at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
            at java.util.concurrent.ThreadPoolExecutor.Worker.run(ThreadPoolExecutor.java:615)
            at org.apache.tomcat.util.threads.TaskThread.WrappingRunnable.run(TaskThread.java:61)
            at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
        - None


"pool-9-thread-1" prio=6 tid=0x000000000d7b2000 nid=0xd5fc waiting on condition [0x000000001187e000]
       java.lang.Thread.State: TIMED_WAITING (parking)
             at sun.misc.Unsafe.park(Native Method)
             - parking to wait for  <0x00000000c563b9e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject)
             at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
             at java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
             at java.util.concurrent.ScheduledThreadPoolExecutor.DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
             at java.util.concurrent.ScheduledThreadPoolExecutor.DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
             at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
             at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
             at java.util.concurrent.ThreadPoolExecutor.Worker.run(ThreadPoolExecutor.java:615)
             at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
       - None

5、监视

"Thread-1" prio=6 tid=0x000000000a8a1800 nid=0xfdb4 waiting for monitor entry [0x000000000b4de000]
      java.lang.Thread.State: BLOCKED (on object monitor)
            at com.jy.modules.test.Test2$T.run(Test2.java:58)
           - waiting to lock <0x00000000eab757e0> (a java.lang.Object)

Locked ownable synchronizers:
      - None

 

“VisualVM线程监控线程状态”与“Java线程状态”对应关系总结:

可以看出,VisualVM的线程状态将“WAITING”和“TIMED_WAITING”两个状态根据行程状态的原因做了细化(其实java的thread stack dump上已经细化了)

如造成“TIMED_WAITING”状态的原因可能是 :

Thread.sleep()  --  休眠

Object.wait(timeout)  --  等待

LockSupport.parkUntil(deadline)  --  驻留

 

参考资料:

《深入理解Java虚拟机》

《Java特种兵》5.1 基础介绍

原文链接:
作者:Trust_FreeDom - 博客园
博客主页:http://www.cnblogs.com/trust-freedom/
欢迎转载,但请保留作者和本文链接,谢谢!
欢迎在下面的评论区与我交流。
如果觉得写的不错,请点击下面的“推荐”按钮,让我更有动力写出更好的文章。
posted @ 2017-03-25 18:08  Trust_FreeDom  阅读(16101)  评论(1编辑  收藏  举报