关于LockSupport
2015-11-15 21:01
183 查看
concurrent包的基础
Doug Lea 的神作concurrent包是基于AQS (AbstractQueuedSynchronizer)框架,AQS框架借助于两个类:Unsafe(提供CAS操作)和LockSupport(提供park/unpark操作)。因此,LockSupport可谓构建concurrent包的基础之一。理解concurrent包,就从这里开始。两个重点
操作对象归根结底,LockSupport调用的Unsafe中的native代码:
public native void unpark(Thread jthread); public native void park(boolean isAbsolute, long time);
两个函数声明清楚地说明了操作对象:park函数是将当前Thread阻塞,而unpark函数则是将另一个Thread唤醒。
与Object类的wait/notify机制相比,park/unpark有两个优点:1. 以thread为操作对象更符合阻塞线程的直观定义;2. 操作更精准,可以准确地唤醒某一个线程(notify随机唤醒一个线程,notifyAll唤醒所有等待的线程),增加了灵活性。
关于许可
在上面的文字中,我使用了阻塞和唤醒,是为了和wait/notify做对比。其实park/unpark的设计原理核心是“许可”。park是等待一个许可。unpark是为某线程提供一个许可。如果某线程A调用park,那么除非另外一个线程调用unpark(A)给A一个许可,否则线程A将阻塞在park操作上。
有一点比较难理解的,是unpark操作可以再park操作之前。也就是说,先提供许可。当某线程调用park时,已经有许可了,它就消费这个许可,然后可以继续运行。这其实是必须的。考虑最简单的生产者(Producer)消费者(Consumer)模型:Consumer需要消费一个资源,于是调用park操作等待;Producer则生产资源,然后调用unpark给予Consumer使用的许可。非常有可能的一种情况是,Producer先生产,这时候Consumer可能还没有构造好(比如线程还没启动,或者还没切换到该线程)。那么等Consumer准备好要消费时,显然这时候资源已经生产好了,可以直接用,那么park操作当然可以直接运行下去。如果没有这个语义,那将非常难以操作。
其它细节
理解了以上两点,我觉得应该把握了关键,其它细节就不是那么关键,也容易理解了,不作分析。
相关文章推荐
- Cookie的生命周期问题
- Android高仿微信图片选择功能的PhotoPicker
- 《软件需求模式》阅读笔记之三
- struts2学习笔记
- 人事档案管理系统介绍(二)
- python基础知识九
- wireshark1.99.2安装
- 求解时间复杂度
- 数字通信中的Rice和Nakagami特性研究
- 有序列表和无序列表
- Python小例子(求和)
- python基础知识八
- hadoop2.7.1单机和伪集群的搭建-0
- Odoo(OpenERP v8)数据模型(Dat 4000 a Model)
- 使用GDAL工具对OrbView-3数据进行正射校正
- UILabel根据内容设置宽度和高度
- python 命令行参数
- ios 滑动切换视图
- python基础知识七
- 工作中的一些好习惯