内容简介:最近有点懒散,没什么比较有深度的产出。刚好想重新研读一下JUC线程池的源码实现,在此之前先深入了解一下Java中的线程实现,包括线程的生命周期、状态切换以及线程的上下文切换等等。编写本文的时候,使用的JDK版本是11。在对应
最近有点懒散,没什么比较有深度的产出。刚好想重新研读一下JUC线程池的源码实现,在此之前先深入了解一下 Java 中的线程实现,包括线程的生命周期、状态切换以及线程的上下文切换等等。编写本文的时候,使用的JDK版本是11。
Java线程的实现
在 JDK1.2之后 ,Java线程模型已经确定了基于操作系统原生线程模型实现。因此,目前或者今后的JDK版本中,操作系统支持怎么样的线程模型,在很大程度上决定了Java虚拟机的线程如何映射,这一点在不同的平台上没有办法达成一致,虚拟机规范中也未限定Java线程需要使用哪种线程模型来实现。线程模型只对线程的并发规模和操作成本产生影响,对于Java程序来说,这些差异是透明的。
对应 Oracle Sun JDK
或者说 Oracle Sun JVM
而言,它的Windows版本和 Linux 版本都是使用 一对一的线程模型 实现的(如下图所示)。
也就是一条Java线程就映射到一条轻量级进程( Light Weight Process )中,而一条轻量级线程又映射到一条内核线程( Kernel-Level Thread )。我们平时所说的线程,往往就是指轻量级进程(或者说我们平时新建的 java.lang.Thread
就是轻量级进程实例)。前面推算这个线程映射关系,可以知道,我们在应用程序中创建或者操作的 java.lang.Thread
实例最终会映射到系统的内核线程,如果我们恶意或者实验性无限创建 java.lang.Thread
实例,最终会影响系统的正常运行甚至导致系统崩溃(可以在Windows开发环境中做实验,确保内存足够的情况下使用死循环创建和运行 java.lang.Thread
实例)。
线程调度方式包括两种,协同式线程调度和抢占式线程调度。
线程调度方式 | 描述 | 劣势 | 优势 |
---|---|---|---|
协同式线程调度 | 线程的执行时间由线程本身控制,执行完毕后主动通知操作系统切换到另一个线程上 | 某个线程如果不让出CPU执行时间可能会导致整个系统崩溃 | 实现简单,没有线程同步的问题 |
抢占式线程调度 | 每个线程由操作系统来分配执行时间,线程的切换不由线程自身决定 | 实现相对复杂,操作系统需要控制线程同步和切换 | 不会出现一个线程阻塞导致系统崩溃的问题 |
Java线程最终会映射为系统内核原生线程,所以Java线程调度最终取决于系操作系统,而目前主流的操作系统内核线程调度基本都是使用抢占式线程调度。也就是可以死记硬背一下: Java线程是使用抢占式线程调度方式进行线程调度的 。
很多操作系统都提供线程优先级的概念,但是由于平台特性的问题,Java中的线程优先级和不同平台中系统线程优先级并不匹配,所以Java线程优先级可以仅仅理解为“ 建议优先级 ”,通俗来说就是 java.lang.Thread#setPriority(int newPriority)
并不一定生效, 有可能Java线程的优先级会被系统自行改变 。
Java线程的状态切换
Java线程的状态可以从 java.lang.Thread
的内部枚举类 java.lang.Thread$State
得知:
public enum State { NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED; }
这些状态的描述总结成图如下:
线程状态之间关系切换图如下:
下面通过API注释和一些简单的代码例子分析一下Java线程的状态含义和状态切换。
NEW状态
API注释:
/** * Thread state for a thread which has not yet started. * */ NEW,
线程实例尚未启动时候的线程状态。
一个刚创建而尚未启动(尚未调用 Thread#start()
方法)的Java线程实例的就是出于 NEW
状态。
public class ThreadState { public static void main(String[] args) throws Exception { Thread thread = new Thread(); System.out.println(thread.getState()); } } // 输出结果 NEW
RUNNABLE状态
API注释:
/** * 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,
可运行状态下线程的线程状态。可运行状态下的线程在Java虚拟机中执行,但它可能执行等待操作系统的其他资源,例如处理器。
当Java线程实例调用了 Thread#start()
之后,就会进入 RUNNABLE
状态。 RUNNABLE
状态可以认为包含两个子状态: READY
和 RUNNING
。
-
READY
:该状态的线程可以被线程调度器进行调度使之更变为RUNNING
状态。 -
RUNNING
:该状态表示线程正在运行,线程对象的run()
方法中的代码所对应的的指令正在被CPU执行。
当Java线程实例 Thread#yield()
方法被调用时或者由于线程调度器的调度,线程实例的状态有可能由 RUNNING
转变为 READY
,但是从线程状态 Thread#getState()
获取到的状态依然是 RUNNABLE
。例如:
public class ThreadState1 { public static void main(String[] args) throws Exception { Thread thread = new Thread(()-> { while (true){ Thread.yield(); } }); thread.start(); Thread.sleep(2000); System.out.println(thread.getState()); } } // 输出结果 RUNNABLE
WAITING状态
API注释:
/** * 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 {@code Object.wait()} * on an object is waiting for another thread to call * {@code Object.notify()} or {@code Object.notifyAll()} on * that object. A thread that has called {@code Thread.join()} * is waiting for a specified thread to terminate. */ WAITING,
等待中线程的状态。一个线程进入等待状态是由于调用了下面方法之一:
不带超时的Object#wait()
不带超时的Thread#join()
LockSupport.park()
一个处于等待状态的线程总是在等待另一个线程进行一些特殊的处理。
例如:一个线程调用了Object#wait(),那么它在等待另一个线程调用对象上的Object#notify()或者Object#notifyAll();一个线程调用了Thread#join(),那么它在等待另一个线程终结。
WAITING
是 无限期的等待状态 ,这种状态下的线程不会被分配CPU执行时间。当一个线程执行了某些方法之后就会进入无限期等待状态,直到被显式唤醒,被唤醒后,线程状态由 WAITING
更变为 RUNNABLE
然后继续执行。
RUNNABLE 转换为 WAITING 的方法(无限期等待) |
WAITING 转换为 RUNNABLE 的方法(唤醒) |
|
---|---|---|
Object#wait() |
`Object#notify() | Object#notifyAll()` |
Thread#join() |
- | |
LockSupport.part() |
LockSupport.unpart(thread) |
其中 Thread#join()
方法相对比较特殊,它会阻塞线程实例直到线程实例执行完毕,可以观察它的源码如下:
public final void join() throws InterruptedException { join(0); } public final synchronized void join(long millis)throws InterruptedException { long base = System.currentTimeMillis(); long now = 0; if (millis < 0) { throw new IllegalArgumentException("timeout value is negative"); } if (millis == 0) { while (isAlive()) { wait(0); } } else { while (isAlive()) { long delay = millis - now; if (delay <= 0) { break; } wait(delay); now = System.currentTimeMillis() - base; } } }
可见 Thread#join()
是在线程实例存活的时候总是调用 Object#wait()
方法,也就是必须在线程执行完毕 isAlive()
为false(意味着线程生命周期已经终结)的时候才会解除阻塞。
基于 WAITING
状态举个例子:
public class ThreadState3 { public static void main(String[] args) throws Exception { Thread thread = new Thread(()-> { LockSupport.park(); while (true){ Thread.yield(); } }); thread.start(); Thread.sleep(50); System.out.println(thread.getState()); LockSupport.unpark(thread); Thread.sleep(50); System.out.println(thread.getState()); } } // 输出结果 WAITING RUNNABLE
TIMED WAITING状态
API注释:
/** * 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,
定义了具体等待时间的等待中线程的状态。一个线程进入该状态是由于指定了具体的超时期限调用了下面方法之一:
Thread.sleep()
带超时的Object#wait()
带超时的Thread#join()
LockSupport.parkNanos()
LockSupport.parkUntil()
TIMED WAITING
就是 有限期等待状态 ,它和 WAITING
有点相似,这种状态下的线程不会被分配CPU执行时间,不过这种状态下的线程不需要被显式唤醒,只需要等待超时限期到达就会被VM唤醒,有点类似于现实生活中的闹钟。
RUNNABLE 转换为 TIMED WAITING 的方法(有限期等待) |
TIMED WAITING 转换为 RUNNABLE 的方法(超时解除等待) |
---|---|
Object#wait(timeout) |
- |
Thread#sleep(timeout) |
- |
Thread#join(timeout) |
- |
LockSupport.parkNanos(timeout) |
- |
LockSupport.parkUntil(timeout) |
- |
举个例子:
public class ThreadState4 { public static void main(String[] args) throws Exception { Thread thread = new Thread(()-> { try { Thread.sleep(1000); } catch (InterruptedException e) { //ignore } }); thread.start(); Thread.sleep(50); System.out.println(thread.getState()); Thread.sleep(1000); System.out.println(thread.getState()); } } // 输出结果 TIMED_WAITING TERMINATED
BLOCKED状态
API注释:
/** * 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}. */ BLOCKED,
此状态表示一个线程正在阻塞等待获取一个监视器锁。如果线程处于阻塞状态,说明线程等待进入同步代码块或者同步方法的监视器锁或者在调用了Object#wait()之后重入同步代码块或者同步方法。
BLOCKED
状态也就是阻塞状态,该状态下的线程不会被分配CPU执行时间。线程的状态为 BLOCKED
的时候有两种可能的情况:
A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method
- 线程正在等待一个监视器锁,只有获取监视器锁之后才能进入
synchronized
代码块或者synchronized
方法,在此等待获取锁的过程线程都处于阻塞状态。
reenter a synchronized block/method after calling Object#wait()
- 线程X步入
synchronized
代码块或者synchronized
方法后(此时已经释放监视器锁)调用Object#wait()
方法之后进行阻塞,当接收其他线程T调用该锁对象Object#notify()/notifyAll()
,但是线程T尚未退出它所在的synchronized
代码块或者synchronized
方法,那么线程X依然处于阻塞状态(注意API注释中的 reenter ,理解它场景2就豁然开朗)。
更加详细的描述可以参考笔者之前写过的一篇文章: 深入理解Object提供的阻塞和唤醒API 。
针对上面的场景1举个简单的例子:
public class ThreadState6 { private static final Object MONITOR = new Object(); public static void main(String[] args) throws Exception { Thread thread1 = new Thread(()-> { synchronized (MONITOR){ try { Thread.sleep(Integer.MAX_VALUE); } catch (InterruptedException e) { //ignore } } }); Thread thread2 = new Thread(()-> { synchronized (MONITOR){ System.out.println("thread2 got monitor lock..."); } }); thread1.start(); Thread.sleep(50); thread2.start(); Thread.sleep(50); System.out.println(thread2.getState()); } } // 输出结果 BLOCKED
针对上面的场景2举个简单的例子:
public class ThreadState7 { private static final Object MONITOR = new Object(); private static final DateTimeFormatter F = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); public static void main(String[] args) throws Exception { System.out.println(String.format("[%s]-begin...", F.format(LocalDateTime.now()))); Thread thread1 = new Thread(() -> { synchronized (MONITOR) { System.out.println(String.format("[%s]-thread1 got monitor lock...", F.format(LocalDateTime.now()))); try { Thread.sleep(1000); MONITOR.wait(); } catch (InterruptedException e) { //ignore } System.out.println(String.format("[%s]-thread1 exit waiting...", F.format(LocalDateTime.now()))); } }); Thread thread2 = new Thread(() -> { synchronized (MONITOR) { System.out.println(String.format("[%s]-thread2 got monitor lock...", F.format(LocalDateTime.now()))); try { MONITOR.notify(); Thread.sleep(2000); } catch (InterruptedException e) { //ignore } System.out.println(String.format("[%s]-thread2 releases monitor lock...", F.format(LocalDateTime.now()))); } }); thread1.start(); thread2.start(); // 这里故意让主线程sleep 1500毫秒从而让thread2调用了Object#notify()并且尚未退出同步代码块,确保thread1调用了Object#wait() Thread.sleep(1500); System.out.println(thread1.getState()); System.out.println(String.format("[%s]-end...", F.format(LocalDateTime.now()))); } } // 某个时刻的输出如下: [2019-06-20 00:30:22]-begin... [2019-06-20 00:30:22]-thread1 got monitor lock... [2019-06-20 00:30:23]-thread2 got monitor lock... BLOCKED [2019-06-20 00:30:23]-end... [2019-06-20 00:30:25]-thread2 releases monitor lock... [2019-06-20 00:30:25]-thread1 exit waiting...
场景2中:
- 线程2调用
Object#notify()
后睡眠2000毫秒再退出同步代码块,释放监视器锁。 - 线程1只睡眠了1000毫秒就调用了
Object#wait()
,此时它已经释放了监视器锁,所以线程2成功进入同步块,线程1处于API注释中所述的reenter a synchronized block/method
的状态。 - 主线程睡眠1500毫秒刚好可以命中线程1处于
reenter
状态并且打印其线程状态,刚好就是BLOCKED
状态。
这三点看起来有点绕,多看几次多思考一下应该就能理解。
TERMINATED状态
API注释:
/** * Thread state for a terminated thread. * The thread has completed execution. */ TERMINATED;
终结的线程对应的线程状态,此时线程已经执行完毕。
TERMINATED
状态表示线程已经终结。一个线程实例只能被启动一次,准确来说,只会调用一次 Thread#run()
方法, Thread#run()
方法执行结束之后,线程状态就会更变为 TERMINATED
,意味着线程的生命周期已经结束。
举个简单的例子:
public class ThreadState8 { public static void main(String[] args) throws Exception { Thread thread = new Thread(() -> { }); thread.start(); Thread.sleep(50); System.out.println(thread.getState()); } } // 输出结果 TERMINATED
上下文切换
多线程环境中,当一个线程的状态由 RUNNABLE
转换为非 RUNNABLE
( BLOCKED
、 WAITING
或者 TIMED_WAITING
)时,相应线程的上下文信息(也就是常说的 Context
,包括CPU的寄存器和程序计数器在某一时间点的内容等等)需要被保存,以便线程稍后恢复为 RUNNABLE
状态时能够在之前的执行进度的基础上继续执行。而一个线程的状态由非 RUNNABLE
状态进入 RUNNABLE
状态时可能涉及恢复之前保存的线程上下文信息并且在此基础上继续执行。这里的对 线程的上下文信息进行保存和恢复的过程 就称为上下文切换( Context Switch
)。
线程的上下文切换会带来额外的性能开销,这包括保存和恢复线程上下文信息的开销、对线程进行调度的CPU时间开销以及CPU缓存内容失效的开销(线程所执行的代码从CPU缓存中访问其所需要的变量值要比从主内存(RAM)中访问响应的变量值要快得多,但是 线程上下文切换会导致相关线程所访问的CPU缓存内容失效,一般是CPU的 L1 Cache
和 L2 Cache
,使得相关线程稍后被重新调度到运行时其不得不再次访问主内存中的变量以重新创建CPU缓存内容)。
在Linux系统中,可以通过 vmstat
命令来查看全局的上下文切换的次数,例如:
$ vmstat 1
对于Java程序的运行,在Linux系统中也可以通过 perf
命令进行监视,例如:
$ perf stat -e cpu-clock,task-clock,cs,cache-reference,cache-misses java YourJavaClass
参考资料中提到Windows系统下可以通过自带的工具 perfmon
(其实也就是任务管理器)来监视线程的上下文切换,实际上笔者并没有从任务管理器发现有任何办法查看上下文切换,通过搜索之后发现了一个工具: Process Explorer 。运行 Process Explorer
同时运行一个Java程序并且查看其状态:
因为打了断点,可以看到运行中的程序的上下文切换一共7000多次,当前一秒的上下文切换增量为26(因为笔者设置了 Process Explorer
每秒刷新一次数据)。
监控线程状态
如果项目在生产环境中运行,不可能频繁调用 Thread#getState()
方法去监测线程的状态变化。JDK本身提供了一些监控线程状态的工具,还有一些开源的轻量级 工具 如阿里的 Arthas ,这里简单介绍一下。
使用jvisualvm
jvisualvm
是JDK自带的堆、线程等待JVM指标监控工具,适合使用于开发和测试环境。它位于 JAVA_HOME/bin
目录之下。
其中 线程Dump
的按钮类似于下面要提到的 jstack
命令,用于导出所有线程的栈信息。
使用jstack
jstack
是JDK自带的命令行工具,功能是用于获取指定PID的Java进程的线程栈信息。例如本地运行的一个 IDEA
实例的 PID
是11376,那么只需要输入:
jstack 11376
另外,如果想要定位具体Java进程的 PID
,可以使用 jps
命令。
使用JMC
JMC
也就是 Java Mission Control
,它也是JDK自带的工具,提供的功能要比 jvisualvm
强大,包括MBean的处理、线程栈已经状态查看、飞行记录器等等。
小结
理解Java线程状态的切换和一些监控手段,更有利于日常开发多线程程序,对于生产环境出现问题,通过监控线程的栈信息能够快速定位到问题的根本原因(通常来说,目前比较主流的 MVC
应用都是通过一个线程处理一个单独的请求,当请求出现阻塞的时候,导出对应处理请求的线程基本可以定位到阻塞的精准位置,如果使用消息队列例如 RabbitMQ
,消费者线程出现阻塞也可以利用相似的思路解决)。
参考资料:
- Jdk11相关源码
- 《Java多线程编程实战指南》
- 《深入理解Java虚拟机-2nd》
(本文完 c-7-d e-a-20190623 最近业务迭代有点忙)
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Java 多线程(三)—— 线程的生命周期及方法
- Java并发 -- 线程生命周期
- Java线程生命周期深入理解
- java中线程池的生命周期
- Java线程生命周期这样理解挺简单的
- Java并发编程(01):线程的创建方式,状态周期管理
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
最高人民法院《关于行政诉讼证据若干问题的规定》释义与适用
李国光 / 人民法院出版社 / 2002-9 / 30.0
为进一步深入贯彻实施《中华人民共和国行政诉讼法》,最高人民法院发布了《关于行政诉讼证据若干问题的规定》。本书即是对《行政证据规定》作出的充分的阐释。《行政证据规定》是我国第一部关于行政诉讼证据问题系统的司法解释,对我国行政审判的发展和行政诉讼制度的完善必将产生重要而深远的影响。本书对这一《行政证据规定》进行阐述,是为了让广大读者更具体深入的了解这一重要的规定。 本书均将《最高人民法院......一起来看看 《最高人民法院《关于行政诉讼证据若干问题的规定》释义与适用》 这本书的介绍吧!