Doug Lea大神的concurrent包的lock,无论是在1.5还是1.6上(开或是不开自旋锁选项),都比jvm级别的synchronized高效和伸缩性更强,功能更丰富。对此很是好奇,语法上的实现是如何打败jvm级别上的实现?从Doug Lea的《The java.util.concurrent Synchronizer Framework》开始,感兴趣的筒子们可下来拜读一下。
这个系列主要是《Framework》第三章《DESIGN AND IMPLEMENTATION》的读书笔记或是简单翻译,如果时间充足第四章《USAGE》也会做些笔记。后继会把Synchronizer Framework的一些关键代码实现分析一下。
不是关键的部分的描述,不会字字计较,有些e文还真是不知怎么用中文表达。
Synchronizer的基本思想是很简单的。
一个acquire的操作如下:
while (synchronization state does not allow acquire) {
enqueue current thread if not already queued;
possibly block current thread;
}
一个release操作如下:
update synchronization state;
if (state may permit a blocked thread to acquire)
unblock one or more queued threads;
为了支持以上的操作,需要以下的三个基础组件的协调
- Atomically managing synchronization state
- Blocking and unblocking threads
- Maintaining queues
创建一个拥有三个各自独立的基础组件的framework是允许的。但是这可能不高效和不合适。例如:queue nodes的信息一定要和unblocking的需要相一致;公开的方法特征也依赖于synchronization state.
synchronizer framework里,一个中心的设计思想是为这三个基础组件各自选择一个具体的实现(concrete implementation),但是在它们的用法上允许存在一个大范围的选择。它故意的限制了适用的范围,但提供足够高的效率的支持。事实上不存在任何理由不使用这个framework,而选择白手起家,从头开发一个synchronizer。