内容简介:讲正题之前,先说一下 ReentrantLock 和 synchronized 这对冤家,我们经常会拿这两个锁作比较,其中一个是显式锁,实现于 Lock 接口;而另外一个是隐式锁,更加的原生。如果我们从性能上来比较的话,在 JDK 1.6 以前,多线程环境下的 synchronized 性能明显差于 ReentrantLock;但在 JDK 1.6 及其之后的版本中,两者的性能已经基本持平,而且我们通常优先考虑使用 synchronized 进行同步。究其原因,就是“锁优化”。其实自旋锁在 JDK 1.4.
讲正题之前,先说一下 ReentrantLock 和 synchronized 这对冤家,我们经常会拿这两个锁作比较,其中一个是显式锁,实现于 Lock 接口;而另外一个是隐式锁,更加的原生。
如果我们从性能上来比较的话,在 JDK 1.6 以前,多线程环境下的 synchronized 性能明显差于 ReentrantLock;但在 JDK 1.6 及其之后的版本中,两者的性能已经基本持平,而且我们通常优先考虑使用 synchronized 进行同步。究其原因,就是“锁优化”。
二. 自旋锁
其实自旋锁在 JDK 1.4.2 中已经引入,不过当时的默认状态为关闭;在 JDK 1.6 中改为默认开启。
1. 产生的原因
在互斥同步中,阻塞对性能的影响是最大的,挂起线程和恢复线程两个操作(即线程的切换)给了并发性能很大的压力。
但是很多时候,共享资源处于锁定状态的时间其实非常短,为了那么短的时间而去对线程反复地挂起与恢复明显十分不值得。因此我们可以利用自旋锁避免这两个操作。
2. 原理
当一个线程在请求一个被持有的锁时,让这个线程执行一个空循环(自旋),此时并不会放弃处理器的执行,如果锁很快就被释放,那么就避免了对这个线程的挂起与恢复操作。
3. 利弊得失
自旋本身避免了线程切换带来的开销,但也占用了处理器的时间。如果锁被占用的时间很短,那自旋锁的效果自然很好;但如果时间很长,那么这个自旋的线程就白白消耗了处理器的资源,反而适得其反,浪费了性能。
因此,自旋等待的时间是有限度的,一旦超过了自旋的限度次数,那么就会使用传统的方法进行阻塞,即挂起该线程。
4. 自适应自旋
JDK 1.6 中对自旋锁进行了改进,引入了自适应自旋锁,使得自旋的时间不再固定。简单来说,就是随着程序的运行和性能的监控,JVM 会对锁的情况进行预测,从而给出适合的自旋时间,更加 “智能”。
三. 锁消除
JVM 会对于一些代码上要求同步,但被检测到不可能存在共享数据竞争的锁进行消除。
例子:
public void add(String str1, String str2) { StringBuffer sb = new StringBuffer(); sb.append(str1).append(str2); } 复制代码
众所周知,StringBuffer 的 append 方法是同步方法,但是在这个 add 方法中,StringBuffer 不会存在共享资源竞争的情况,因为其他线程并不会访问到它。这就符合了 “代码上要求同步,但不可能存在共享数据竞争” 的条件。因此虽然这里有锁,但是可以安全地清除掉,避免了锁的获取释放带来的性能消耗。
四. 锁粗化
通常情况下,我们编写代码时,都尽可能地将同步块的作用范围缩小,使得锁的持有时间尽可能地缩短,提高细粒度,增加并发度,降低锁的竞争。
但是有些情况下,如果一系列连续的操作中我们不断地加锁解锁,比如在循环之中,那么也会造成不必要的性能损耗。
比如:
public void add(String str1, String str2, String str3) { StringBuffer sb = new StringBuffer(); sb.append(str1); sb.append(str2); sb.append(str3); } 复制代码
同样是 StringBuffer ,JVM 检测到有一连串操作都对同一个对象(sb)加锁时,就会把锁进行粗化处理,扩展同步范围,这样从一个 append() 到最后一个,只需要加一次锁就可以了。
五. 偏向锁
1. 产生的原因
大多数情况下,锁不仅不存在多线程竞争状态,而且通常由同一个线程多次获得,因此,我们有必要减少同一个线程多次获得同一个锁的性能消耗。
2. 原理
当锁对象第一次被线程获取的时候,虚拟机在对象的对象头中标志为偏向模式,同时使用 CAS 操作把获取到这个锁的线程的 ID 记录在对象头的 Mark Word 数据中。(这部分不了解的读者可以去学习一下 JVM 的“对象内存布局”)
只要 CAS 操作获取成功,该锁对象便 “偏向” 了这个线程,只要不出现第二个线程,这个锁对象的对象头就会一直记录着该线程的 id。
这时,获得偏向锁的线程以后每次进入这个锁的时候都不再需要进行同步操作,一路畅通。
那如果出现了第二个线程会发生什么呢?我们继续往下看。
六. 轻量级锁
当偏向锁失效后,便会升级为轻量锁
1. 原理
当一个线程企图持有一个锁的时候,倘若这个锁已经是偏向状态,那么这个时候会将偏向状态解除,然后在竞争这个锁的线程的栈帧中建立一个锁记录的空间(Lock Record),并把锁对象的 Mark Word 拷贝到里面来,记作 Displaced Mark Word。
然后,JVM 再使用 CAS 操作将锁对象的 Mark Word 更新为指向其中一个线程的 Lock Record 的指针,当这个操作成功,这个线程也就持有了该轻量锁。
当然,轻量锁的持有和释放,都需要 CAS 操作进行。释放锁的时候,只需要把栈帧里的 Displaced markd word 使用 CAS 复制回去即可。如果 CAS 操作获取锁失败,JVM 会首先检查一下锁对象的 Mark Word 是否指向当前线程,是则可以直接通行,否则先自旋一下吧。
2. 适应情况
这个锁适应的是没有竞争或是只有轻度竞争的情况,若是发送了轻度的竞争,只需要进行几次自旋即可。
但是一旦发生长时间的竞争,轻量级锁就会升级为重量级锁,这时候就变成了传统的通过阻塞来进行同步,并使用 monitor 对象来管理锁的持有和释放的方式(不要忘了 monitorenter 和 monitorexit 这两个指令)。
以上所述就是小编给大家介绍的《说一说 JVM 对锁的优化》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Implementing Responsive Design
Tim Kadlec / New Riders / 2012-7-31 / GBP 27.99
New devices and platforms emerge daily. Browsers iterate at a remarkable pace. Faced with this volatile landscape we can either struggle for control or we can embrace the inherent flexibility of the w......一起来看看 《Implementing Responsive Design》 这本书的介绍吧!