简单聊聊Synchronized和ReentrantLock锁.docxVIP

简约聊聊Synchronized和ReentrantLock锁 2021-08-01 前言 前些天偶然阅读到了一篇IBM博客，叙述Synchronized，ReentrantLock锁的区分以及相关的功能比较，读完发觉获益匪浅，本人之前对于这块学问了解的还挺浅的。所以本文就是对此的一个小结吧。这里笔者将次要争辩这么几个话题：Synchronized和ReentrantLock锁的区分，二者的功能比较，以及具体场景下的锁选择问题（其实也就是二者的优劣势比较了）。 Synchronized锁和ReentrantLock锁的异同 Synchronized关键字锁和ReentrantLock锁在多线程编程中格外常见，尤其是前者。那么这两者到底有什么区分呢？总结下来有下面几点： Synchronized锁会自带释放锁，无须用户本人执行释放锁操作，而ReentrantLock需要执行lock，unlock操作。 ReentrantLock支持更多锁原语操作，比如锁猎取，锁中缀等待等操作，这些比较高级的属性在Synchronized上是没有的。 在功能上，ReentrantLock锁在锁高竞争条件下会呈现出更好的功能，相较于Synchronized锁。 但是这两种锁也有部分属性是相同的，比如说默认都是非公正调度策略的。换句话说，就是同样多线程执行恳求锁操作，最终结果不会是FIFO挨次来获得锁的。其实在多并发竞争的条件下，公正策略未必是肯定必需的，为了保持这种挨次性，系统的开销还是存在的，所以Synchronized锁和默认的ReentrantLock都是unfair策略的。 Synchronized锁和ReentrantLock锁的适用场景 既然上节提到ReentrantLock在高竞争条件下拥有着更好的功能，而且它还支持了更多的高级属性，那么这是不是就意味着我们永久就使用ReentrantLock锁而完全不考虑Synchronized锁了呢？ 其实呢，话不能这么说。归根结底一句话：你真刚要用到哪个锁的属性时，那就去用哪种锁。比如说，你要使用到能支持锁中缀的操作，那么这时就用ReentrantLock锁。还有一点，也不是说ReentrantLock功能会比Synchronized好，就盲目的都使用ReentrantLock替换现有的Synchronized锁，只要你真正证明出在当前的场景下，Synchronized关键字锁存在锁竞争功能问题，然后再去换。但是大部分的一般情况下，Synchronized和ReentrantLock锁所呈现出的功能是相差无几的。 而且另外一方面，Synchronized锁也有着它自然?的优势，被更多的开发者所熟知和使用。而且用起来比较简约，便利，比如说它无需使用者执行释放锁操作，有的时候新手用户在使用类似ReentrantLock锁的时候，遗忘了执行unlock操作，导致最终程序消灭各种惊异的问题，而且还难以定位。总而言之，ReentrantLock是一种比较“高级”的锁，比较适合“高级”地去使用。