锁的优化
目录
锁的四种状态
- 从低到高，只能升级不能降级
- 无锁状态
- 偏向锁状态
- 轻量级锁状态
- 重量级锁状态
自旋锁和自适应自旋
理解
- 同步互斥的时候会造成线程阻塞，而挂起线程和恢复线程需要转入内核态中完成
- 有时候往往共享数据的锁定状态只会持续很短一段时间，那么如果此时将互斥的线程挂起，等待下一次获得锁再恢复线程，这样的话效率不高
- 那么可以不讲线程立即挂起，而是让他自旋（循环）等待获得锁（这就是自旋锁），那么这样可以避免在一段很短的等待时间挂起和恢复线程的开销
- 也就说，不立刻将线程挂起，稍微自旋等一下，这样的话或许可以减少线程挂起和恢复的开销
分析
- 虽然可以避免切换线程的开销，但是因为在自旋，这同样是消耗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/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。如果觉得还有帮助的话，可以点一下右下角的【推荐】，希望能够持续的为大家带来好的技术文章！想跟我一起进步么？那就【关注】我吧。