Java多线程(二十二)---LockSupport工具

移步java多线程系列文章

1.LockSupport综述

定义: LockSupport是一个线程阻塞工具类,可用于在线程内任意位置让线程阻塞和释放
作用: LockSupport通常不会被直接使用,更多是作为锁实现的基础工具类
实现: LockSupport底层依赖UnSafe实现,即park()和unpark()原语方法,通过"许可"替代状态
使用: park方法用于线程等待"许可",unpark方法用于为线程提供"许可"

由于"许可"的存在,当出现一个线程调用park方法,其他线程调用unpark方法时,会保持活跃

2.LockSupport的数据结构

2.1 类定义

public class LockSupport 

2.2 构造器

//私有构造器,不能被实例化 -- 实质就是个工作类,只能调用静态方法
private LockSupport() {} // Cannot be instantiated.

2.3 UnSafe

// Hotspot implementation via intrinsics API
private static final sun.misc.Unsafe UNSAFE;
//用于记录线程被谁阻塞的,用于线程监控和分析工具来定位原因,其表示parkBlocker在内存的偏移量
//之所以用偏移量是因为parkBlockerOffset被赋值时线程必须是阻塞的,阻塞时直接调方法无效只能走内存
private static final long parkBlockerOffset;
private static final long SEED;
private static final long PROBE;
private static final long SECONDARY;
static {
    try {
        UNSAFE = sun.misc.Unsafe.getUnsafe();
        Class<?> tk = Thread.class;
        //获取指定变量的内存偏移量
        parkBlockerOffset = UNSAFE.objectFieldOffset
            (tk.getDeclaredField("parkBlocker"));
        SEED = UNSAFE.objectFieldOffset
            (tk.getDeclaredField("threadLocalRandomSeed"));
        PROBE = UNSAFE.objectFieldOffset
            (tk.getDeclaredField("threadLocalRandomProbe"));
        SECONDARY = UNSAFE.objectFieldOffset
            (tk.getDeclaredField("threadLocalRandomSecondarySeed"));
    } catch (Exception ex) { throw new Error(ex); }

2.4 permit(许可)

LockSupport和每个使用它的线程都与一个permit关联,某种意义上可认为是Semaphore类,但区别于Semaphores,permit至多只有一个,并不能被累加(即重复调动unpark也不会累加,最多为1)
permit相当于一个开关(只有0和1两个值),默认为0,执行过程如下:
调用unpark方法,permit+1,即permit=1
调用park方法,permit被消费-1,即permit=0,同时park方法理解返回
再次调用park方法,线程会被阻塞(此时permit=0,线程无许可可用,直到permit=1之前都会被阻塞)

3 LockSupport重要方法

3.1 setBlocker方法

/**
 * Returns the blocker object supplied to the most recent
 * invocation of a park method that has not yet unblocked, or null
 * if not blocked.  The value returned is just a momentary
 * snapshot -- the thread may have since unblocked or blocked on a
 * different blocker object.
 *  返回提供给最近一次尚未解除阻塞的被park方法调用的blocker对象,如果该调用未阻塞,则返回null
 * @param t the thread
 * @return the blocker
 * @throws NullPointerException if argument is null
 * @since 1.6
 */
public static Object getBlocker(Thread t) {
    if (t == null)
        throw new NullPointerException();
    return UNSAFE.getObjectVolatile(t, parkBlockerOffset);
}
/**
  * This object is recorded while the thread is blocked to permit monitoring and diagnostic 
  * tools to identify the reasons that threads are blocked.
  * 此对象在线程受阻塞时被记录,以允许监视工具和诊断工具确定线程受阻塞的原因
  */
private static void setBlocker(Thread t, Object arg) {
    // Even though volatile, hotspot doesn't need a write barrier here.
    UNSAFE.putObject(t, parkBlockerOffset, arg);
}

测试一下设置blocker是否有区别

public static void main(String[] args) {
    new Thread(() -> LockSupport.park(),"sally").start();
    new Thread(() -> LockSupport.park(LockSupport.getBlocker(Thread.currentThread())),"kira").start();
    while (true);
}

通过线程Dump查看一下,可以很明显的看到阻塞的堆栈信息,但其实信息是差不多一样的


LockSupport不可重入.png

3.2 park方法

作用:该方法用于等待"许可",调用时可能发生以下两种情况:
当"许可"可用时,立即返回并且消费这个许可(将许可变成不可用)
当"许可"不可用时,当前线程可能被阻塞 java.lang.Thread.State : WAITING parking
使用: 由于park方法可能在任何时候"无理由"返回,因此通常会在循环中使用(在返回之前再次检查条件)
适用: park方法是"busy wait"(忙碌等待)的一种优化(即不需要在自旋上浪费太多时间),但它必须与unpark配对使用才更高效
注意: park方法的许可默认是被占用的,在unpark之前调用会获取不到许可而被阻塞

public static void park() {
    UNSAFE.park(false, 0L);
}
//纳秒级超时返回
public static void parkNanos(long nanos) {
    if (nanos > 0)
        UNSAFE.park(false, nanos);
}
//毫秒级限时等待
//注意这里的时间需要使用系统时间加上需要等待的时间
//LockSupport.parkUntil(System.currentTimeMillis() + 3000);
public static void parkUntil(long deadline) {
    UNSAFE.park(true, deadline);
}
//三种形式的 park 还各自支持一个 blocker 对象参数
//建议最好使用这些形式,而不是不带此参数的原始形式
//在锁实现中提供的作为 blocker 的普通参数是 this
public static void park(Object blocker) {
    Thread t = Thread.currentThread();
    setBlocker(t, blocker);
    UNSAFE.park(false, 0L);
    setBlocker(t, null);
}
public static void parkNanos(Object blocker, long nanos) {
    if (nanos > 0) {
        Thread t = Thread.currentThread();
        setBlocker(t, blocker);
        UNSAFE.park(false, nanos);
        setBlocker(t, null);
    }
}
public static void parkUntil(Object blocker, long deadline) {
    Thread t = Thread.currentThread();
    setBlocker(t, blocker);
    UNSAFE.park(true, deadline);
    setBlocker(t, null);
}

3.3 unpark方法

作用: 该方法用于提供"许可",会将还不可用的"许可"变成可用
注意: 由于park方法默认是许可占有并阻塞线程,因此调用park之前最好先调用unpark(当然因为park\unpark的顺序解耦性,所以前后执行顺序无所谓,只是代码上最好遵循 先释放再获取 的规则)

/**
  * 注意:必须指定一个线程(但无所谓该线程是否park),将尝试释放其可能拥有的许可
  */
public static void unpark(Thread thread) {
    if (thread != null)
        UNSAFE.unpark(thread);
}

4.LockSupport不可重入

不可重入: LockSupport不可重入,当一个线程多次调用park方法,线程将被第二个park方法阻塞

public static void main(String[] args) {
    LockSupport.unpark(Thread.currentThread());//我们直接用主线程
    System.out.println("执行unpark");
    LockSupport.park();
    System.out.println("执行第一次park");
    LockSupport.park();
    System.out.println("执行第二次park");
    while (true);
}
---------------------
//输出:
执行unpark
执行第一次park
//分析:通过打印结果可以发现第7行其实并没有被打印,根据下面的图片可以看到线程在第7行(对应图片的第16行)上阻塞

使用jstack命令查看一下线程状态,会发现线程是WAITING状态,即等待阻塞,而且还是被park方法阻塞

5.LockSupport与中断

*中断响应: LockSupport支持中断响应,线程调用park阻塞时仍能够响应中断请求,但不会抛出InterruptedException异常

public static void main(String[] args) {
    Thread thread = new Thread(() -> {
        long start = System.currentTimeMillis();
        while ((System.currentTimeMillis() - start) <= 1000);//空转1s
        System.out.println("空转1s结束");
        LockSupport.park();//等待"许可"
        System.out.println(Thread.currentThread().getName() + "是否被中断:" 
            + Thread.currentThread().isInterrupted());
    },"kira");
    thread.start();
    thread.interrupt();//中断线程
}
---------------------
//输出:
空转1s结束
kira是否被中断:true
//分析:通过先中断线程再park可以发现可获取中断响应,同时并没有抛出任何异常

6. suspend() vs wait() vs park()

6.1 suspend() vs wait()

suspend()不会释放锁,wait()会释放锁同时还支持超时处理

6.2 park() vs suspend()

LockSupport解决了suspend()不释放锁从而容易死锁的问题,比如resume()方法被阻塞时,即其他线程在调用resume()方法之前获取同步锁时被阻塞而导致resume()方法无法执行进而导致死锁

6.3 park() vs wait()

LockSupport不需要先获得某个对象的锁,也不会排除InterruptedException异常
unpark方法可以先于park方法调用,其没有方法调用的时序问题
wait/notify机制有个问题在于线程调用notify方法去唤醒其他线程时,需要保证需被唤醒线程必须被wait方法阻塞,否则被唤醒线程会永远处于WAITING状态,同时notify方法只能唤醒一个线程,当同时有多个线程在同一个对象上wait等待,就只能有一个线程可以被唤醒(不能指定)
park/unpark机制通过引入单个"许可"的概念实现对线程同步的解耦,线程间无须关心对方的状态,因为不需要一个变量专门用于存储状态

7.LockSupport官方标准用法

7.1 标准用法

//官方提供的标准用法
while (!canProceed()) { ... LockSupport.park(this); }}

7.2 FIFOMutex

/**
  * Here is a sketch of a first-in-first-out non-reentrant lock class:
  * 官方提供了一个FIFO先进先出的非重入锁实现Demo
  */
class FIFOMutex {
    private final AtomicBoolean locked = new AtomicBoolean(false);//锁标记
    private final Queue<Thread> waiters
      = new ConcurrentLinkedQueue<Thread>();//无界线程安全队列,存放等待线程
    public void lock() {
        boolean wasInterrupted = false;//标记中断
        Thread current = Thread.currentThread();
        waiters.add(current);//添加当前线程到队尾(FIFO)
        // Block while not first in queue or cannot acquire lock
        //阻塞条件:当前线程非队列首元素(FIFO) or 没有获得锁
        while (waiters.peek() != current ||
            !locked.compareAndSet(false, true)) {
            LockSupport.park(this);
            //补充一点:调用interrupted方法会将线程真正的中断状态清除,连续调用会返回false
            //这里的作用主要用于在park调用时线程阻塞过程中忽略中断带来的其他影响
            if (Thread.interrupted()) // ignore interrupts while waiting
                wasInterrupted = true;//当前线程若被中断,需要重新标记中断状态
        }
        //当能够获取锁后,将首元素移除(FIFO),立即返回
        waiters.remove();
        if (wasInterrupted)          // reassert interrupt status on exit
            current.interrupt();//若线程被标记为中断,需要重新声明为中断状态
    }
    public void unlock() {
      locked.set(false);//解锁
      LockSupport.unpark(waiters.peek());//解除队列首元素的阻塞,FIFO
    }
}

8.LockSupport vs Object

这里主要是对比 LockSuppor.park/unpark() 与 object.wait/notify() 的区别:
面向对象不同:前者能够主动指定Thread;后者必须被动执行且不能准确指定,具有随机性
监视器是否必须:前者由于只需要"许可",因此无需监视器;后者能使用的前提是必须获取监视器,即wait/notify()必须出现在synchronized作用范围内
实现机制不同:前者使用的是"许可",后者使用的监视器,两者无交集,互相不会影响

  • 当需要阻塞或唤醒一个线程的时候,都会使用LockSupport工具类来完成相应工作。
  • LockSupport定义了一组的公共静态方法,这些方法提供了最基本的线程阻塞和唤醒功能,而LockSupport也成为构建同步组件的基础工具。
  • LockSupport定义了一组以park开头的方法用来阻塞当前线程,以及unpark(Thread thread)方法来唤醒一个被阻塞的线程。
  • 在Java 6中,LockSupport增加了park(Object blocker)、parkNanos(Object blocker,long nanos)和parkUntil(Object blocker,long deadline)3个方法,用于实现阻塞当前线程的功能,其中参数blocker是用来标识当前线程在等待的对象(以下称为阻塞对象),该对象主要用于问题排查和系统监控。
qq_pic_merged_1535466045884.jpg

参考

《java并发编程的艺术》
并发番@LockSupport一文通(1.8版)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,214评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,307评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,543评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,221评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,224评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,007评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,313评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,956评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,441评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,925评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,018评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,685评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,234评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,240评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,464评论 1 261
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,467评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,762评论 2 345

推荐阅读更多精彩内容