文章目录
线程的生命周期
线程的所有状态在java.lang.Thread
中的State
枚举中有定义,如:
public enum State
{
NEW, 线程创建之后,但是还没有启动(没有调用start()方法)。这时候它的状态就是NEW
RUNNABLE, 表示当前线程正在运行中或者等待CPU分配资源。Java线程的`RUNNABLE`状态其实是包括了传统操作系统线程的`ready和running`两个状态的。
WAITING, 等待状态,等待其他线程唤醒自己。
BLOCKED, 阻塞状态,已经醒了,但是CPU被其他线程占用。等待其他线程释放锁
TIMED_WAITING, 有等待时间的waiting
TERMINATED; 线程中止的状态,这个线程已经完整地执行了它的任务
}
有资源有执行权:运行态
有资源无执行权:就绪态
无资源无执行权:阻塞态(会一直请求资源)
主动释放资源和执行权,不设置超时时间,需要被唤醒:等待态
主动释放资源和执行权,设置超时时间,能自动唤醒:超时等待态
线程状态的转换
10种简述
详述其中三种
BLOCKED与RUNNABLE状态的转换
我们在上面说到:处于BLOCKED状态的线程是因为在等待锁的释放。假如这里有两个线程a和b,a线程提前获得了锁并且暂未释放锁,此时b就处于BLOCKED状态。我们先来看一个例子:
@Test
public void blockedTest() {
Thread a = new Thread(new Runnable() {
@Override
public void run() {
testMethod();
}
}, "a");
Thread b = new Thread(new Runnable() {
@Override
public void run() {
testMethod();
}
}, "b");
a.start();
b.start();
System.out.println(a.getName() + ":" + a.getState()); // 输出?
System.out.println(b.getName() + ":" + b.getState()); // 输出?
}
// 同步方法争夺锁
private synchronized void testMethod() {
try {
Thread.sleep(2000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
初看之下,大家可能会觉得线程a会先调用同步方法,同步方法内又调用了Thread.sleep()方法,必然会输出TIMED_WAITING
,而线程b因为等待线程a释放锁所以必然会输出BLOCKED
。
其实不然,有两点需要值得大家注意,一是在测试方法blockedTest()内还有一个main线程,二是启动线程后执行run方法还是需要消耗一定时间的。
测试方法的main线程只保证了a,b两个线程调用start()方法(转化为RUNNABLE状态),如果CPU执行效率高一点,还没等两个线程真正开始争夺锁,就已经打印此时两个线程的状态(RUNNABLE)了。
当然,如果CPU执行效率低一点,其中某个线程也是可能打印出BLOCKED状态的(此时两个线程已经开始争夺锁了)。
这时你可能又会问了,要是我想要打印出BLOCKED状态我该怎么处理呢?BLOCKED状态的产生需要两个线程争夺锁才行。那我们处理下测试方法里的main线程就可以了,让它“休息一会儿”,调用一下Thread.sleep()方法。
这里需要注意的是main线程休息的时间,要保证在线程争夺锁的时间内,不要等到前一个线程锁都释放了你再去争夺锁,此时还是得不到BLOCKED状态的。
我们把上面的测试方法blockedTest()改动一下:
public void blockedTest() throws InterruptedException {
······
a.start();
Thread.sleep(1000L); // 需要注意这里main线程休眠了1000毫秒,而testMethod()里休眠了2000毫秒
b.start();
System.out.println(a.getName() + ":" + a.getState()); // 输出?
System.out.println(b.getName() + ":" + b.getState()); // 输出?
}
在这个例子中两个线程的状态转换如下
- a的状态转换过程:RUNNABLE(a.start()) ->
TIMED_WATING(Thread.sleep())->RUNABLE(sleep()时间到)->BLOCKED(未抢到锁) ->
TERMINATED - b的状态转换过程:RUNNABLE(b.start()) -> BLOCKED(未抢到锁)
->TERMINATED
斜体表示可能出现的状态, 大家可以在自己的电脑上多试几次看看输出。同样,这里的输出也可能有多钟结果。
WAITING状态与RUNNABLE状态的转换
执行Object.wait()和Thread.join() :RUNNABLE-》WAITING
我们再把上面的例子线程启动那里改变一下:
public void blockedTest() {
······
a.start();
a.join();
b.start();
System.out.println(a.getName() + “:” + a.getState()); // 输出 TERMINATED
System.out.println(b.getName() + “:” + b.getState());
}
要是没有调用join方法,main线程不管a线程是否执行完毕都会继续往下走。
a线程启动之后马上调用了join方法,这里main线程就会等到a线程执行完毕,所以这里a线程打印的状态固定是TERMINATED。
至于b线程的状态,有可能打印RUNNABLE(尚未进入同步方法),也有可能打印TIMED_WAITING(进入了同步方法)。
TIMED_WAITING与RUNNABLE状态转换
TIMED_WAITING与WAITING状态类似,只是TIMED_WAITING状态等待的时间是指定的。
Thread.sleep(long)
使当前线程睡眠指定时间。需要注意这里的“睡眠”只是暂时使线程停止执行,并不会释放锁。时间到后,线程会重新进入RUNNABLE状态。
Object.wait(long)
wait(long)方法使线程进入TIMED_WAITING状态。这里的wait(long)方法与无参方法wait()相同的地方是,都可以通过其他线程调用notify()或notifyAll()方法来唤醒。
不同的地方是,有参方法wait(long)就算其他线程不来唤醒它,经过指定时间long之后它会自动唤醒,拥有去争夺锁的资格。
Thread.join(long)
join(long)使当前线程执行指定时间,并且使线程进入TIMED_WAITING状态。
我们再来改一改刚才的示例:
public void blockedTest() {
······
a.start();
a.join(1000L);
b.start();
System.out.println(a.getName() + ":" + a.getState()); // 输出 TIEMD_WAITING
System.out.println(b.getName() + ":" + b.getState());
}
这里调用a.join(1000L),因为是指定了具体a线程执行的时间的,并且执行时间是小于a线程sleep的时间,所以a线程状态输出TIMED_WAITING。
b线程状态仍然不固定(RUNNABLE或BLOCKED)。
blocked vs waiting
BLOCKED和WAITING都是属于线程的阻塞等待状态。
BLOCKED状态是指线程在等待监视器锁的时候的阻塞状态。也就是在多个线程去竞争Synchronized同步锁的时候,没有竞争到锁资源的线程,会被阻塞等待。
WAITING状态表示线程的等待状态,在这种状态下,线程需要等待某个线程的特定操作才会被唤醒。
比如Object.notify方法可以唤醒Object.wait()方法阻塞的线程
LockSupport.unpark()可以唤醒LockSupport.park()方法阻塞的线程。
在我看来,BLOCKED和WAITING两个状态最大的区别有两个:
-
BLOCKED是锁竞争失败后被动触发的状态,WAITING是人为的主动触发的状态
-
BLCKED的唤醒时自动触发的,而WAITING状态是必须要通过特定的方法来主动唤醒
详解start()
反复调用同一个线程的start()方法是否可行? NO
假如一个线程执行完毕(此时处于TERMINATED
状态),再次调用这个线程的start()方法是否可行?NO
要分析这两个问题,我们先来看看start()的源码:
public synchronized void start() {
if (threadStatus != 0)
throw new IllegalThreadStateException();
group.add(this);
boolean started = false;
try {
start0();
started = true;
} finally {
try {
if (!started) {
group.threadStartFailed(this);
}
} catch (Throwable ignore) {
}
}
}
我们可以看到,在start()内部,这里有一个threadStatus的变量。如果它不等于0,调用start()是会直接抛出异常的。
我们接着往下看,有一个native的start0()方法。这个方法里并没有对threadStatus的处理。到了这里我们仿佛就拿这个threadStatus没辙了,我们通过debug的方式再看一下:
@Test
public void testStartMethod() {
Thread thread = new Thread(() -> {});
thread.start(); // 第一次调用
thread.start(); // 第二次调用
}
我是在start()方法内部的最开始打的断点,叙述下在我这里打断点看到的结果:
第一次调用时threadStatus的值是0。
第二次调用时threadStatus的值不为0。
查看当前线程状态的源码:
// Thread.getState方法源码:
public State getState() {
// get current thread state
return sun.misc.VM.toThreadState(threadStatus);
}
// sun.misc.VM 源码:
public static State toThreadState(int var0) {
if ((var0 & 4) != 0) {
return State.RUNNABLE;
} else if ((var0 & 1024) != 0) {
return State.BLOCKED;
} else if ((var0 & 16) != 0) {
return State.WAITING;
} else if ((var0 & 32) != 0) {
return State.TIMED_WAITING;
} else if ((var0 & 2) != 0) {
return State.TERMINATED;
} else {
return (var0 & 1) == 0 ? State.NEW : State.RUNNABLE;
}
}
所以,我们结合上面的源码可以得到引申的两个问题的结果:
两个问题的答案都是不可行,在调用一次start()之后,threadStatus的值会改变(threadStatus !=0),此时再次调用start()方法会抛出IllegalThreadStateException异常。