LockSupport:不用担心线程被永久阻塞

本文介绍了LockSupport工具类在多线程中的应用,对比了wait/notify、suspend/resume方法,强调了LockSupport.park()和unpark()方法的安全性。即使unpark()在park()之前调用,线程也不会被永久阻塞,这是因为LockSupport使用许可机制,通过Unsafe类的park()和unpark()实现线程的阻塞和唤醒,确保线程活性竞争的正确性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

让线程“等待”的方法有很多,例如wait()和notify(),不过这两个方法是对对象做操作,它们不在Thread类中。如果一个对象object o调用wait()方法,那么它就会进入object的等待队列中,直到notify()方法被调用后,从这个等待队列中随机选择唤醒一个线程,这种选择是随机的,是不公平的。

还有suspend()和resume()方法,不过既然是被标注为废弃方法,就很少用了,因为suspend()方法挂起线程后,不会释放任何资源,此时如果有其他线程想去访问它占用的锁时,也会被牵连一起等待。如果resume()方法意外地被执行在suspend()之前,那么被挂起的线程就起不来了,一直处于挂起状态。还有一点很重要的是,书上说“对于被suspend()挂起的线程,它的线程状态依然是Runnable,这会严重影响系统对线程当前状态的判断。“这么多问题,怪不得被标注为废弃方法。

有一种安全的方法,就是用阻塞工具类LockSupport,在线程执行时的任意地方都可以调用它,使用LockSupport.park()方法让线程阻塞,然后在想唤醒线程的地方调用LockSupport.unpakr()方法。为什么说它是安全的呢?假设LockSupport.unpark()方法意外地在LockSupport.park()方法前被调用了,被阻塞的线程仍然可以被唤醒,是的,来看看代码:

我们定义线程执行后睡眠,然后在执行LockSupport.park()来阻塞线程,做的事情很简单。然后main函数中,实例化两个线程T1,T2。T1先执行后接着立刻调用LockSupport.unpark()方法,模拟unpark()方法意外地发生在了park()方法前,T2也一样。执行结果你会发现,两个线程始终能够完成所有任务,不会因为方法的调用顺序出现意外而导致线程被永久阻塞。

这样看来很不错,但是想知道它是怎么做到的,代码一条一条按顺序执行?难道是有序性的问题,程序执行时出现了指令重排?以前刚开始看多线程时,就了解到指令重排的问题,指令是否发生重排,如何重排,都是不可预知的。不过,指令重排有一个基本前提,就是保证串行语义的一致性,也就是保证不会使逻辑语义发生问题,否则代码就无法保证一直正常工作了,所以,在串行执行的代码程序中,不用担心指令重排的问题。在多线程环境下,就不能保障指令重排出现问题了。

排除了指令重排问题,至于为什么LockSupport.unpark()方法意外地被调用在了LockSupport.park()方法后,线程还能从阻塞状态被唤醒?首先我去翻了文档:

原来,LockSupport类使用了类似于信号量的东西,文档里称为许可,LockSupport类为每一个线程使用它的线程都与一个许可关联起来,调用park()方法时,如果这个许可是可用的,那么就把许可设置为不可用,线程进入阻塞。当调用unpark()方法后,如果许可不可用,则将其设置为可用,此时线程被唤醒。文档中有一句说到,每个使用LockSupport类的线程都与一个许可关联(注意许可只有一个,这与信号量不同),还有特别重要的一句“调用park()方法的线程和另一个试图将其unpark()的线程之间的竞争将保持活性”,这才是park()和unpark()方法调用顺序不当也不会出错的原因。

      可是文档只是告诉我它们之间的活性竞争特点所以不会引起unpark()被调用在park()前而造成的线程永久阻塞问题,并没有告诉我们它们是如何做到的。这里我们再把重点放在那个“许可”上,我在网上翻了一些LockSupport的源码解读,下面两个我觉得挺不错:

https://www.cnblogs.com/leesf456/p/5347293.html

https://blog.youkuaiyun.com/chengzhang1989/article/details/79669045

两个一起看,大概就是,LockSupport类引入了sun.misc.Unsafe类中的park()和unpark()方法,park()方法中的Parker类有一个链表成员_counter就是文档中所说的“许可”,调用park()方法,如果许可_counter的值大于0(表示许可可用),就把它设置为0,并且调用Linux线程下的pthread_cond_timedwait一直等待。而unpark()方法,如果许可_counter等于0,也就是不可用,就设置为1,然后直接返回,否则就一直等待许可的改变,这样来实现park()和unpark()方法之间的活性竞争。

<think>好的,我现在需要帮用户深入理解Java中LockSupport的底层实现原理和源码解析。首先,我应该回顾一下用户提供的引用内容,确保准确引用相关信息。用户提到了引用[1]和引用[2],其中引用[2]详细说明了LockSupport类是基于Unsafe类实现的,特别是park和unpark两个本地方法。 首先,我需要解释LockSupport的基本作用,它是用来阻塞和唤醒线程的工具类,属于Java并发包的一部分。接着,需要深入到Unsafe类,因为LockSupport的核心方法park和unpark实际上调用了Unsafe的本地方法。这部分需要详细说明Unsafe类的作用,以及它在Java中的重要性,尽管它通常不推荐直接使用,但并发工具类如LockSupport确实依赖它。 然后,应该解析park和unpark的具体实现机制。根据引用[2],park方法用于阻塞当前线程,而unpark方法用于唤醒指定线程。这里需要说明这两个方法如何与操作系统的线程调度交互,比如在Linux系统下可能使用pthread库的mutex和condition变量来实现阻塞和唤醒。需要指出park方法如何通过许可证(permit)的机制来避免线程挂起的问题,许可证是一个二进制信号量,unpark会发放许可证,park会消耗许可证,这样即使unpark先调用,park也不会阻塞。 接下来,需要分析LockSupport的源码结构,展示其如何封装Unsafe的方法。例如,LockSupport中的park()方法内部调用Unsafe的park()方法,并处理可能的参数。这部分需要引用具体的代码片段,说明参数的作用,比如isAbsolute和time参数如何控制阻塞时间。 然后,讨论许可证机制的具体实现细节,强调其不可重入的特性,以及许可证的单一性。这里可以对比synchronized和LockSupport的区别,突出LockSupport的灵活性和性能优势,比如能够更精确地控制线程阻塞和唤醒,避免死锁等问题。 还需要考虑LockSupport在实际应用中的使用场景和注意事项,比如在高级同步工具中的应用,如AQS(AbstractQueuedSynchronizer),以及正确使用park和unpark的顺序,避免导致线程永久挂起的情况。同时,可以提到调试和监控线程状态时的注意事项,因为使用LockSupport线程在JVM中的状态显示为“WAITING”或“TIMED_WAITING”。 最后,总结LockSupport的设计哲学,如何通过简单的API提供强大的并发控制能力,并强调其在Java并发框架中的基础地位。确保整个回答结构清晰,逐步深入,从基本概念到底层实现,再到实际应用,帮助用户全面理解LockSupport的机制。 在整理过程中,需要检查是否有遗漏的关键点,比如许可证的二进制特性、与操作系统交互的具体方式、源码中的关键代码示例等。同时,确保引用标记正确,用户提供的引用[1]和引用[2]需要正确对应到相关内容,避免混淆。此外,生成的相关问题需要围绕LockSupport的实现原理、应用场景、与其他并发工具的比较等方面,帮助用户进一步探索该主题。</think>### Java LockSupport底层实现机制及源码解析 #### 1. **核心依赖:Unsafe类** LockSupport的底层实现完全依赖`sun.misc.Unsafe`类。`Unsafe`提供两个核心本地方法: - `public native void park(boolean isAbsolute, long time)`:阻塞当前线程,支持超时控制。 - `isAbsolute=true`时,`time`为绝对时间(毫秒); - `isAbsolute=false`时,`time`为相对等待时间(纳秒)。 - `public native void unpark(Thread thread)`:唤醒指定线程。 **源码片段**: ```java // LockSupport类核心代码 public static void park() { UNSAFE.park(false, 0L); // 无限期阻塞 } public static void unpark(Thread thread) { if (thread != null) UNSAFE.unpark(thread); } ``` 这两个方法直接调用`Unsafe`的本地实现[^2]。 --- #### 2. **许可证机制(Permit)** LockSupport通过**二进制信号量(Permit)** 实现线程阻塞与唤醒: - **Permit初始值为0**,调用`unpark()`会将Permit设为1(即使多次调用,值仍为1)。 - **`park()`尝试消耗Permit**: - 若Permit=1,立即返回且Permit重置为0; - 若Permit=0,线程阻塞,直到被唤醒或超时。 **特性**: - **不可累加性**:连续调用`unpark()`不会累积Permit。 - **线程关联性**:Permit与线程绑定,精准控制唤醒目标。 --- #### 3. **操作系统级实现** 在Linux系统下,`park()`和`unpark()`通过**POSIX线程库(pthread)** 实现: - `pthread_mutex_t` + `pthread_cond_t`:构成条件变量,用于线程挂起和唤醒。 - `futex`系统调用:优化短时间阻塞,减少用户态与内核态切换。 **示例流程**: 1. 线程A调用`park()` → 检查Permit为0 → 进入等待队列。 2. 线程B调用`unpark(A)` → Permit置1 → 触发条件变量唤醒线程A。 3. 线程A恢复执行,Permit重置为0。 --- #### 4. **与synchronized的对比** | 特性 | LockSupport | synchronized | |--------------------|------------------------------|--------------------------| | **锁粒度** | 线程级精准控制 | 对象监视器(粗粒度) | | **死锁风险** | 无(单线程操作) | 需注意锁顺序 | | **唤醒灵活性** | 可指定唤醒线程 | 随机唤醒(notify) | | **性能开销** | 更低(直接操作线程状态) | 较高(涉及锁竞争) | --- #### 5. **应用场景与注意事项** - **适用场景**: - 实现自定义锁(如AQS中的`AbstractQueuedSynchronizer`)。 - 高并发任务调度中精准控制线程状态。 - **注意事项**: - **避免连续park**:调用`unpark()`直接多次`park()`会导致线程永久阻塞。 - **线程状态监控**:使用`jstack`时,LockSupport阻塞线程状态为`WAITING (parking)`。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值