jdk中锁的实现原理

系统管理员 2022-04-25 10:14 181阅读 0赞

[【死磕Java并发】—–深入分析synchronized的实现原理][Java_synchronized]

详细说明了Java对象天生能作为锁的原理，JDK内置各种锁的实现机制，Synchronized的实现原理及JDK对其所做的优化

当多个线程需要访问某个公共资源的时候，我们知道需要通过加锁来保证资源的访问不会出问题。java提供了两种方式来加锁，

**一种是关键字：synchronized，一种是concurrent包下的lock锁。**

synchronized是java底层支持的，而concurrent包则是jdk实现。

记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronized是这么的神奇而又强大，那个时候我们赋予它一个名字“同步”，也成为了我们解决多线程情况的百试不爽的良药。但是，随着我们学习的进行我们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以至于我们认为它不是那么的高效而慢慢摒弃它。

诚然，随着Javs SE 1.6对synchronized进行的各种优化后，synchronized并不会显得那么重了。

**synchronized关键字并非一开始就该对象加上重量级锁，也是从偏向锁，轻量级锁，再到重量级锁的过程。**  
这个过程也告诉我们，假如我们一开始就知道某个同步代码块的竞争很激烈、很慢的话，那么我们一开始就应该使用重量级锁了，从而省掉一些锁转换的开销。  
来自 [https://blog.csdn.net/qq\_38462278/article/details/81976428][https_blog.csdn.net_qq_38462278_article_details_81976428]

历史回顾：在JDK1.6以前的版本，synchronized实现的内置锁都比较重（这也是诸多同学们理解的版本）。JVM中monitorenter和monitorexit字节码依赖于底层的操作系统的Mutex Lock来实现的，但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的。然而在现实中的大部分情况下，同步方法是运行在单线程环境（无锁竞争环境）如果每次都调用Mutex Lock那么将严重的影响程序的性能。

来自 [https://www.cnblogs.com/jebysun/p/10048494.html][https_www.cnblogs.com_jebysun_p_10048494.html]

[Java_synchronized]: http://cmsblogs.com/?p=2071
[https_blog.csdn.net_qq_38462278_article_details_81976428]: https://blog.csdn.net/qq_38462278/article/details/81976428
[https_www.cnblogs.com_jebysun_p_10048494.html]: https://www.cnblogs.com/jebysun/p/10048494.html