谈一谈 JVM 对锁的优化
JDK 1.6 对并发性进行了很大的改进,这也是为了使线程之间更好更高效地共享数据,处理竞争问题,实现线程安全。因而从 JDK 1.6 开始,实现了很多锁的优化技术。
一. 从 ReentrantLock 和 synchronized 看锁的优化
讲正题之前,先说一下 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 这两个指令)。
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 谈一谈 JVM 对锁的优化