synchronized 是java中常见的保证多线程访问共享资源时的安全的一个关键字。很多人在讲到synchronized 时都说synchronized 是一把重量级的锁，那么synchronized 真的很重么？
synchronized 在jdk 1.6以前(不包括1.6)的确是一把很重的锁，每次使用锁的时候都是直接向操作系统请求的，所以效率低，且占资源，但是在jdk1.6以后，jvm对synchronized 进行了优化，加入了锁升级的功能，使得synchronized 在一些情况下并不是一把重量级的锁，而是一个很轻的一把锁。
本文就来探讨一下，jdk对synchronized 优化，包括锁升级、锁粗化、锁消除。
一、锁升级
锁升级其实是指，随着多线程并发加锁的程度提高而相应的对锁的状态的升级，可以分为：偏向锁、轻量级锁、自旋锁、重量级锁；
偏向锁
偏向锁不是一把锁，而是代表了当前synchronized 锁状态。偏向锁是一把很轻的锁，当只有一个来线程加锁的时候，此时synchronized 锁就会变成偏向锁，偏向锁代表这个锁偏向这个线程，就是说当这个线程再次来加锁的时候，不需要再向操作系统申请资源，而是很快就能获取到锁，减少了申请锁的开销。
为什么需要偏向锁。因为在大多数情况下，多线程竞争同一把锁的情况是很少的，那么在没有多线程并发竞争的情况下，其实没必要再去向系统申请重量级锁了，我就用目前这把偏向锁就够了，因为申请重量级会耗费比较大的资源。
轻量级锁
当随着更多线程来加锁的时候，偏向锁就会无法满足使用的条件了，因为偏向锁认为加锁的线程只有一个。
那么多线程加锁有可能会出现这种情况。当会有两个及以上的线程来加锁，但是没有出现同时来竞争锁的情况，也就是说虽然有多个线程来加锁，可能会出现A线程加完锁之后释放了锁，此时B来加锁，发现并没有线程持有锁，也就说没有线程跟B来竞争，也就相当于多线程来交替加锁的情况。
当出现这种情况的时候，偏向锁就会升级为轻量级锁。轻量级锁就是指虽然可能会出现多线程来加锁的情况，但是并不存在锁竞争的情况，并不会存在锁冲突。
自旋锁
上面说到随着加锁的线程变多，出现了多线程交替加锁的情况，偏向锁会升级为轻量级锁，但是随着并发加锁的线程越来越多，出现了多个线程同时来加锁的情况，也就不是交替加锁，那么此时轻量级锁已经不适合使用了，但是jvm为了防止锁直接升级为重量级锁（因为挂起线程和恢复线程的操作都需要转入到内核态中完成，这些操作给系统的并发性能带来很大的压力），加入了线程自旋的机制。所谓的自旋就是虽然加锁失败了，但是有可能出现其他线程很快就释放锁的情况，那么就尝试不断的自旋来尝试加锁，而不是直接将锁升级为重量级锁。
自旋锁的好处就是用来减少操作系统的压力。
重量级锁
但是随着加锁的线程不断增多，自旋了一定的时间或者次数也没有成功加锁，那么锁就会升级为重量级锁，因为自旋会消耗cpu，一直这么自旋也不是很好的选择，所以就会升级为重量级锁。升级为重量级锁之后，所有来加锁的线程加锁失败之后，就会加入等待的队列中，等待别的线程释放锁之后再进行锁的竞争。
通过以上的分析，我们也看出了，synchronized 在最开始的时候并不是上来就是一把重量级的锁，而是随着多线程并发竞争锁的激烈程度的提高来不断的升级，慢慢变成重量级锁，在整个升级的过程会经历偏向锁、轻量级锁、自旋锁、重量级锁的过程。
二、锁消除
先来看一段代
java;gutter:true;
public class SynchronizedDemo {</p>
<pre><code>public static void main(String[] args) {
Object monitor = new Object();
synchronized (monitor){
System.out.println("加锁成功....");
}
}
</code></pre>
<p>}</p>
<pre><code>
通过上面代码我们可以看出，synchronized 的锁对象其实是方法的一个局部变量，那么对于这种情况，不会出现多线程竞争同一把Object 对象锁的情况，那么在运行的时候就会忽略这个synchronized 加锁的过程。
说的官方一点就是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。
## 三、锁粗化
;gutter:true;
public class SynchronizedDemo {
private static final Object MONITOR = new Object();
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
synchronized (MONITOR) {
System.out.println("加锁成功….");
}
}
}
}
通过这段代码的分析，可以看出，循环内部每次都对同一个对象进行加锁和解锁，对于这种一串零碎的操作都对同一个对象加锁情况，虚拟机将会把加锁同步的范围扩展 （粗化）到整个操作序列的外部。以上述代码为例，也就是扩展到把for循环这个操作加锁，这样只需要加锁一次就可以了。
总结
所以，通过本篇文章可以看出，jdk对synchronized 其实进行了一系列的优化来尽可能减少加锁时对于性能的消耗，包括锁升级、锁消除、锁粗化。希望通过本篇文章可以让你对synchronized 底层又有一个全新的认识。
如果觉得这篇文章对你有所帮助，还请帮忙点赞、在看、转发一下，码字不易，非常感谢！
如果觉得这篇文章对你有所帮助，还请帮忙点赞、在看、转发给更多的人，码字不易，非常感谢！
往期热门文章推荐
- 有关循环依赖和三级缓存的这些问题，你都会么？（面试常问）
- Redis分布式锁实现Redisson 15问
- 万字+28张图带你探秘小而美的规则引擎框架LiteFlow
- 面渣逆袭：Spring三十五问，四万字+五十图详解！建议收藏！
- 7000字+24张图带你彻底弄懂线程池
- 【SpringCloud原理】OpenFeign原来是这么基于Ribbon来实现负载均衡的
- 【SpringCloud原理】Ribbon核心组件以及运行原理源码剖析
- 【SpringCloud原理】OpenFeign之FeignClient动态代理生成原理
- 一文带你看懂Java中的Lock锁底层AQS到底是如何实现的
扫码或者搜索关注公众号 三友的java日记 ，及时干货不错过，公众号致力于通过画图加上通俗易懂的语言讲解技术，让技术更加容易学习。
Original: https://www.cnblogs.com/zzyang/p/16336060.html
Author: 三友的java日记
Title: synchronized真的很重么？
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/621752/
转载文章受原作者版权保护。转载请注明原作者出处！