前言
前些天偶然阅读到了一篇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是一种比较“高级”的锁，比较适合“高级”地去使用。
主要内容就是这么多了，想要阅读原文的同学可以点击下面的链接阅读英文原博客。
参考资料
[1].https://www.ibm.com/developerworks/java/library/j-jtp10264/index.html. More flexible, scalable locking in JDK 5.0