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。
DougLea并发包解析
本文探讨了DougLea的concurrent包中的lock机制,在Java 1.5及1.6版本中相较于JVM级别的synchronized锁表现出更高的性能与更好的伸缩性。文章通过解析《The java.util.concurrent Synchronizer Framework》一书的第三章《DESIGN AND IMPLEMENTATION》,深入剖析了Synchronizer框架的设计理念与实现细节。
349

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



