jvm系列 (三) ---锁的优化

锁的优化

目录

• jvm系列（一）：jvm内存区域与溢出
• jvm系列（二）：垃圾收集器与内存分配策略
• jvm系列（三）：锁的优化
• 我的博客目录

锁的四种状态

• 从低到高，只能升级不能降级
• 无锁状态
• 偏向锁状态
• 轻量级锁状态
• 重量级锁状态

自旋锁和自适应自旋

理解

• 同步互斥的时候会造成线程阻塞，而挂起线程和恢复线程需要转入内核态中完成
• 有时候往往共享数据的锁定状态只会持续很短一段时间，那么如果此时将互斥的线程挂起，等待下一次获得锁再恢复线程，这样的话效率不高
• 那么可以不讲线程立即挂起，而是让他自旋（循环）等待获得锁（这就是自旋锁），那么这样可以避免在一段很短的等待时间挂起和恢复线程的开销
• 也就说，不立刻将线程挂起，稍微自旋等一下，这样的话或许可以减少线程挂起和恢复的开销

分析

• 虽然可以避免切换线程的开销，但是因为在自旋，这同样是消耗cpu
• 倘若锁被占用的时间很短，那么这短时间的自旋比起切换线程来说是值得的
• 但是倘若锁被占用的时间很长，那么自旋会消耗cpu资源，却没有做有用的事

锁消除

理解

• 虚拟机即使编译器在运行的时候，同步代码被检测不存在共享数据竞争，那么锁会被消除。也就是说如果数据不会被其他线程访问到，那么我们没必要加锁

锁粗化

理解

• 我们加锁的时候会尽量减小锁的粒度，减少竞争
• 而如果我们对同一个对象反复加锁和解锁，会造成性能损耗。
• 所以不如把锁的粒度加大

使用

StringBuffer sb=new StringBuffer();
sb.append(s1);
sb.append(s2);
...
sb.sppend(sn);

• 我们知道StringBuffer的append方法是加锁的，而这里的锁就是sb对象，如果我们执行每一个append方法都加锁解锁，显然这样性能是不高的，所以当虚拟机检测到一系列操作都是对同一个对象加锁，他会将同步的范围扩大，比如这里扩大到s1-sn，那么这样的话就只需加一次锁

MarkWord与线程之间的操作过程

• java对象头中的Mark Word默认存储对象的Hashcode、分代年龄和锁标志位
• 进入同步代码块的时候，当前线程的栈帧会建立一个名为锁记录的空间，用于存储锁对象MarkWord的拷贝

偏向锁

理解

• 锁会偏向于第一个获得他的线程，如果后面锁没有被其他线程获取，那么持有偏向锁的线程永远不需要再进行同步

使用

• 锁对象第一次被线程获取的时候，对象头的标志位会设为偏向模式，同时通过CAS操作把这个线程的ID记录在MarkWord中
• 如果CAS操作成功，持有偏向锁的线程以后每一进入这个锁的同步块时，不需要进行同步操作
• 当另一个线程尝试获取这个锁，偏向锁结束

轻量级锁

理解

• 传统的重量级锁需要使用系统互斥量来实现，而轻量级锁的意图是在没有多线程竞争的情况下，减少重量级锁的系统互斥量产生的性能消耗

使用

• 虚拟机使用CAS操作尝试将MarkWord更新为指向LockRecord的指针，如果更新成功表示线程就拥有该对象的锁
• 如果失败，会检查MarkWord是否指向当前线程的栈帧，如果是表示当前线程已经拥有这个锁，如果不是说明这个锁被其他线程抢占，此时膨胀为重量级锁

轻量级锁和偏向锁

• 重量级锁需要使用操作系统的互斥量（常常使用一个整型量，0表示解锁，而其他所有的值则表示加锁。通过互斥量使同一资源同时只允许一个访问者对其进行访问）来实现
• 轻量级锁依据大部分的锁在同步周期内不存在竞争，使用CAS操作避免使用互斥量的开销
• 偏向锁的则是在无竞争的情况下，连CAS操作都不做

我觉得分享是一种精神，分享是我的乐趣所在，不是说我觉得我讲得一定是对的，我讲得可能很多是不对的，但是我希望我讲的东西是我人生的体验和思考，是给很多人反思，也许给你一秒钟、半秒钟，哪怕说一句话有点道理，引发自己内心的感触，这就是我最大的价值。（这是我喜欢的一句话，也是我写博客的初衷）

作者：jiajun 出处： http://www.cnblogs.com/-new/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。如果觉得还有帮助的话，可以点一下右下角的【推荐】，希望能够持续的为大家带来好的技术文章！想跟我一起进步么？那就【关注】我吧。