LockSupport是用来创建锁和其他同步类的基本线程阻塞原语。
LockSupport中的park()和unpark()的作用分别是阻塞线程和解除阻塞线程。
LockSupport类使用了一种名为Permit(许可)的概念来做到阻塞和唤醒线程的功能,每个线程都有一个许可(permit),permit只有两个值1和零,默认是零。
三种让线程等待和唤醒的方法:
- 使用
Object中的wait()方法让线程等待, 使用Object中的notify()方法唤醒线程,结合synchronized - 使用
JUC包中Condition的await()方法让线程等待,使用signal()方法唤醒线程,结合ReentrantLock LockSupport类可以阻塞当前线程以及唤醒指定被阻塞的线程
传统的synchronized和Lock实现等待唤醒通知的约束:
- 线程先要获得并持有锁,必须在锁块(
synchronized或lock)中 - 必须要先等待后唤醒,线程才能够被唤醒
LockSupport.park()/park(Object blocker):

阻塞当前线程/阻塞传入的具体线程。
permit默认是0,所以一开始调用park()方法,当前线程就会阻塞,直到别的线程将当前线程的permit设置为1时,park方法会被唤醒,然后会将permit再次设置为0并返回。
LockSupport.unpark(Thread thread):

唤醒处于阻断状态的指定线程。
调用unpark(thread)方法后,就会将thread线程的许可permit设置成1(注意多次调用unpark方法,不会累加,permit值还是1)会自动唤醒thread线程,即之前阻塞中的LockSupport.park()方法会立即返回。
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
System.out.println(Thread.currentThread().getName() + "\t park...");
LockSupport.park();
System.out.println(Thread.currentThread().getName() + "\t 被唤醒");
}, "Thread-1");
t1.start();
try {
TimeUnit.SECONDS.sleep(2L);
} catch (Exception e) {
}
System.out.println(Thread.currentThread().getName() + "\t 通知 t1");
LockSupport.unpark(t1);
}
总结:
LockSupport是一个线程阻塞工具类,所有的方法都是静态方法,可以让线程在任意位置阻塞,阻塞之后也有对应的唤醒方法。归根结底,LockSupport调用的Unsafe中的native代码。
LockSupport提供park()和unpark()方法实现阻塞线程和解除线程阻塞的过程。
LockSupport和每个使用它的线程都有一个许可(permit)关联。permit相当于1,0的开关,默认是0,
调用一次unpark就加1变成1,
调用一次park会消费permit,也就是将1变成0,同时park立即返回。
如再次调用park会变成阻塞(因为permit为零了会阻塞在这里,一直到permit变为1),这时调用unpark会把permit置为1。
每个线程都有一个相关的permit, permit最多只有一个,重复调用unpark也不会积累凭证。
形象的理解:
线程阻塞需要消耗凭证(permit),这个凭证最多只有1个。
当调用park方法时:
- 如果有凭证,则会直接消耗掉这个凭证然后正常退出;
- 如果无凭证,就必须阻塞等待凭证可用;
- 而unpark则相反,它会增加一个凭证,但凭证最多只能有1个,累加无效。
为什么可以先唤醒线程后阻塞线程?
因为unpark获得了一个凭证,之后再调用park方法,就可以名正言顺的凭证消费,故不会阻塞。
为什么唤醒两次后阻塞两次,但最终结果还会阻塞线程?
因为凭证的数量最多为1,连续调用两次unpark和调用一次unpark效果一样,只会增加一个凭证;
而调用两次park却需要消费两个凭证,证不够,不能放行。
1372

被折叠的 条评论
为什么被折叠?



