底层实现_再来聊聊synchronized的底层实现

jdk早期的时候，这个synchronized的底层实现是重量级的，重量级到这个synchronized都是要去找操作系统去申请锁的地步，这就会造成synchronized效率非常低。

java后来越来越开始处理高并发的时候，很多程序员都不满意，说这个synchronized用的太重了，我没办法，就要开发新的框架，不用你原生的了。

后来的改进才有了锁升级的概念。关于这个锁升级，我写过一篇文章《没错，我就是厕所所长！(一)》和《没错，我就是厕所所长！(二)》，大家可以去看一下，专门以小说的形式降了这个锁升级到底是怎么一个概念。

是这样的，原来呢都要去找操作系统，要找内核去申请这把锁，到后期做了对synchronized的一些改进，他的效率就比原来要改变不少。

当我们使用synchronized的时候，Hotspot的实现是这样的：上来后第一个去访问某把锁的线程，比如sync(Object)，来了之后现在这个Object的头上面markword记录这个线程。(如果只有第一个线程访问的时候，实际上是没有给这个Object加锁的，在内部实现的时候，只是记录这个线程的ID(偏向锁))。

偏向锁如果有线程争用的话，就升级为自旋锁。概念就是(有一个哥们在蹲马桶，另外来了一个哥们，他就在旁边等着，他不会跑到cpu的就绪队列里，而就在这等着占用cpu，用一个while的循环在这转圈儿玩，很多圈之后不行的话就再一次升级)。

自旋锁转圈十次之后，升级为重量级锁，重量级锁就是去操作系统那里去申请资源。

需要注意的是并不是CAS的效率就一定比系统锁要高，这个要区分实际情况：

执行时间短(加锁代码)，线程数少，用自旋锁

执行时间长，线程数多，用系统锁

关于效率方面的内容，如果暂时不理解，我后面再找时间给大家分享一下CAS锁。

如有收获请划至底部

点击“在看”支持，谢谢！

关注马士兵

每天分享技术干货

点赞是最大的支持