【synchronized底层原理之3】JDK1.6对锁所做的优化

最新推荐文章于 2024-10-03 08:44:33 发布

weixin_34023863

最新推荐文章于 2024-10-03 08:44:33 发布

阅读量85

点赞数

文章标签：运维操作系统 python

原文链接：https://my.oschina.net/u/3866531/blog/2049938

版权

2019独角兽企业重金招聘Python工程师标准>>>

参考网页

https://www.cnblogs.com/dsj2016/p/5714921.html

https://www.zhihu.com/question/55075763

JDK1.6对synchronized锁所做的优化

优化包括自旋锁、锁粗化、锁消除（锁清除）、轻量级锁和偏向锁。

这些都是Java虚拟机层面的优化，对Java程序员是无感知的（Java程序员在程序层面是看不出什么的，但是JVM内部已对synchronized做了优化）。要说有感知的话，就是synchronized在多线程下的性能提高了（JDK1.6相比于JDK1.5），这些都得益于JVM层面锁的优化，就是上面所说的自旋锁、锁粗化、锁清除、偏向锁和轻量级锁。

自旋锁：本质上就是CPU空转等待一会儿获取锁的控制权，而不是马上进入阻塞状态

原理--互斥同步->产生阻塞->上下文切换->操作系统级别用户态和核心态的切换，而使用自旋不会产生阻塞，是个有益的补充

通常情况下，共享数据的锁定状态只持续很短的一段时间，为了这很短的一段时间进行上下文切换并不值得。

原理--CPU空转等待获取锁的控制权

自旋就是不停循环看是否能等到上个线程自己释放锁。这个问题是基于一个现实考量的：很多拿了锁的线程会很快释放锁。因为一般敏感的操作不会很多。当然这个是一个不能完全确定的情况，只能说总体上是一种优化。

举个例子就好比一个人要上厕所发现厕所里面有人，他可以：1，等一小会。2，跑去另外的地方上厕所。等一小会不一定能等到前一个人出来，不过如果跑去别的厕所的花费的时间肯定比等一小会结果前一个人出来了长。当然等完了结果那个人没出来还是要跑去别的地方上厕所这是最慢的。

优点--高效：不会引起上下文切换

缺点--自旋时间如果过长就会造成CPU资源的浪费

自适应自旋--根据以往经验设置合理的自旋次数、设计合理的自旋时间

自适应自旋可以根据以往自旋等待时间的经验，计算出一个较为合理的本次自旋等待时间。

比如第一次设置最多自旋10次，结果在自旋的过程中成功获得了锁，那么下一次就可以设置成最多自旋20次。道理是：一个锁如果能够在自旋的过程中被释放说明很有可能下一次也会发生这种事。那么就更要给这个锁某种“便利”方便其不阻塞得锁（毕竟快了很多）。同样如果多次尝试的结果是完全不能自旋等到其释放锁，那么就说明很有可能这个临界区里面的操作比较耗时间。就减小自旋的次数，因为其可能性太小了。

锁粗化--JVM扩大加锁的范围

若有一系列操作，反复地对同一把锁进行上锁和解锁操作，编译器会扩大这部分代码的同步块的边界，从而只使用一次上锁和解锁操作。

试想有一个循环，循环里面是一些敏感操作，有的人就在循环里面写上了synchronized关键字。这样确实没错不过效率也许会很低，因为其频繁地拿锁释放锁。要知道锁的取得（假如只考虑重量级MutexLock）是需要操作系统调用的，从用户态进入内核态，开销很大。于是针对这种情况也许虚拟机发现了之后会适当扩大加锁的范围（所以叫锁粗化）以避免频繁的拿锁释放锁的过程。