锁的状态
在Java早期版本中,synchronized属于重量级锁,效率低下,因为监视器锁(monitor)是依赖于底层的操作系统的Mutex Lock来实现的,需要调用操作系统相关接口。而操作系统实现线程之间的切换时需要从用户态转换到内核态,有可能给线程加锁消耗的时间比有用操作消耗的时间更多。
Java1.6后对synchronized 进行了很多的优化,有适应自旋、锁消除、锁粗化、轻量级锁及偏向锁等,效率有了本质上的提高。在之后推出的 Java1.7 与 1.8 中,均对该关键字的实现机理做了优化。引入了偏向锁和轻量级锁。都是在对象头中有标记位,不需要经过操作系统加锁。
| 锁 |
优点 |
缺点 |
适用场景 |
| 偏向锁 |
加锁和解锁不需要额外的消耗,和执行非同步方法比仅存在纳秒级的差距。 |
如果线程间存在锁竞争,会带来额外的锁撤销的消耗。 |
适用于只有一个线程访问同步块场景。 |
| 轻量级锁 |
竞争的线程不会阻塞,提高了程序的响应速度。 |
如果始终得不到锁竞争的线程使用自旋会消耗CPU。 |
追求响应时间。 同步块执行速度非常快。 |
| 重量级锁 |
线程竞争不使用自旋,不会消耗CPU。 |
线程阻塞,响应时间缓慢。 |
追求吞吐量。 同步块执行速度较长。 |

无锁
无锁没有对资源进行锁定,所有的线程都能访问并修改同一个资源,但同时只有一个线程能修改成功。
无锁的特点就是修改操作在循环内进行,

本文详细介绍了Java中synchronized的优化机制,包括无锁、偏向锁、轻量级锁和重量级锁四种状态,以及它们的加锁、解锁过程。在锁竞争不激烈的情况下,synchronized通过偏向锁和轻量级锁提高了性能,当锁竞争加剧时会升级为重量级锁。
最低0.47元/天 解锁文章
377

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



