写点什么

Java 线程状态与状态间的切换

用户头像
Geek_571bdf
关注
发布于: 3 小时前

1. 在 Java 5 以后,线程状态被明确定义在其公共内部枚举类型 java.lang.Thread.State 中,分别是:

1.        NEW(初始化状态)

2.        RUNNABLE(可运行 / 运行状态)

3.        BLOCKED(阻塞状态)

4.        WAITING(无时限等待)

5.        TIMED_WAITING(有时限等待)

6.        TERMINATED(终止状态)

 

其中,Java 层面中的 BLOCKED、WAITING、TIMED_WAITING 对应到操作系统层面,都是休眠状态。也就是说,线程处于这三种状态之一,那么该线程就不会拥有 CPU 的使用权。

 

2. NEW 到 RUNNABLE

刚 new 出来的 Thread 对象、且未调用 start(),就处于 NEW 状态。此时还不会执行。当调用了 start()后,线程就从 NEW 状态转换到 RUNNABLE 状态

 

3. RUNNABLE 到 BLOCKED

只有一种场景会触发 RUNNABLE 到 BLOCKED 状态的转变,那就是线程等待 synchronized 隐式锁。

当线程获取 synchronized 隐式锁、并获取失败时,该线程状态就会从 RUNNABLE 转换成 BLOCKED,当持有锁的线程释放锁,且被阻塞线程获取锁后,该线程状态又从 BLOCKED 转换到 RUNNABLE。

 

那线程调用阻塞式 API 时,线程是否会进入到 BLOCKED 状态呢?

答案是,在操作系统层面,线程会进入到休眠状态;但在 JVM 层面,Java 线程的状态不会发生变化,仍然是 RUNNABLE。

 

事实上,JVM 并不关心操作系统调度相关的状态(JVM 把线程调度交给操作系统处理了)。因为在 JVM 看来,等待 CPU 使用权(操作系统层面处于可执行状态)与等待 I/O(操作系统层面处于休眠状态)没有区别,都是在等待某个资源(等待被调度与等待 IO 的反馈,都不会执行),所以都归入了 RUNNABLE 状态。

 

因此,我们平时所谓的 Java 在调用阻塞式 API 时,线程会阻塞,指的是操作系统线程的状态,并不是 Java 线程的状态。

 

4. RUNNABLE 到 WAITING

有三种场景会触发这样的转换:

1.        获得 synchronized 的线程,调用 Object 无参的 wait() 方法。

2.        调用无参的 join()。目标线程执行完,该线程又会回到 RUNNABLE 状态

3.        调用 LockSupport.park()。而调用 LockSupport.unpark(Thread thread) 可唤醒目标线程,目标线程的状态又会从 WAITING 状态转换到 RUNNABLE。

 

5. RUNNABLE 到 TIMED_WAITING

有五种场景会触发这种转换:TIMED_WAITING 和 WAITING 状态的区别,仅仅是触发条件多了超时参数。

1.        调用带超时参数的 Thread.sleep(long millis) 方法;

2.        获得 synchronized 隐式锁的线程,调用带超时参数的 Object.wait(long timeout) 方法;

3.        调用带超时参数的 Thread.join(long millis) 方法;

4.        调用带超时参数的 LockSupport.parkNanos(Object blocker, long deadline) 方法;

5.        调用带超时参数的 LockSupport.parkUntil(long deadline) 方法。

 

6. RUNNABLE 到 TERMINATED

1.        当线程执行完 run() 方法或执行 run()过程中抛出异常,线程都会进入到 TERMINATED 状态

 

不过有时候,我们想要主动强制终止 run() 方法的执行,比如 run()方法访问一个很慢的网络,我们不想等了,想终止它。怎么做呢?方法是,调用 interrupt()。

 

interrupt()和 stop()的区别是,stop() 会真的杀死线程,不给线程喘息的机会,如果线程持有 ReentrantLock 锁,被 stop() 的线程并不会自动调用 ReentrantLock 的 unlock() 去释放锁,这就太危险了。

 

而 interrupt() 仅仅是通知线程,线程有机会执行一些后续操作,同时也可以无视这个通知。InterruptedException 退出同步代码块会释放当前线程持有的锁,所以相比外部强制 stop 是安全的。

 

7. 那被 interrupt 的线程,是怎么收到通知的呢?

答:一种是异常,另一种是主动检测。

 

当线程处在 WAITING、TIMED_WAITING 状态时,如果有其它线程调用该线程的 interrupt()方法,那么会使该线程返回到 RUNNABLE 状态,同时触发 InterruptedException 异常。

这一点也可以从方法签名上看出。对于 WAITING、TIMED_WAITING 状态的触发条件,都是调用了诸如 wait()、join()、sleep() 这样的方法,从这些方法的方法签名上可以看到,当有其它线程调用其 interrupt()方法是,会抛出 InterruptedException 异常。

 

1.        当线程 A 处于 RUNNABLE 状态时,并且阻塞在 java.nio.channels.InterruptibleChannel 上时,如果其他线程调用线程 A 的 interrupt() 方法,线程 A 会触发 java.nio.channels.ClosedByInterruptException 这个异常;

2.        而阻塞在 java.nio.channels.Selector 上时,如果其他线程调用线程 A 的 interrupt() 方法,线程 A 的 java.nio.channels.Selector 会立即返回。

 

上述情况都属于被中断的线程通过异常的方式获得了通知。

 

另一种是主动检测,如果线程处于 RUNNABLE 状态,并且没有阻塞在某个 I/O 操作上,例如中断计算圆周率的线程 A,这时就得依赖线程 A 主动检测中断状态了。

 

如果其他线程调用线程 A 的 interrupt() 方法,那么线程 A 可以通过 isInterrupted() 方法,检测是不是自己被中断了。

用户头像

Geek_571bdf

关注

还未添加个人签名 2019.06.13 加入

还未添加个人简介

评论

发布
暂无评论
Java线程状态与状态间的切换