JDK1.8中synchronized与ReentrantLock如何选择？

在JDK1.8里，synchronized和ReentrantLock在性能方面基本不存在差异。自JDK1.6之后，synchronized就进行了锁升级优化，性能较之前有了很大提升。那在实际运用时该如何抉择？毕竟二者都能用于线程同步操作。这可以从使用和特性这两个方面来分析。从使用方式来看，若使用ReentrantLock，就得先声明ReentrantLock变量，而且要手动调用lock和unlock方法，还得妥善处理异常情况，要保证unlock能成功执行，不然可能致使所有线程都无法获取锁。而对于synchronized而言，使用起来就简单多了，想要对什么加锁，直接加锁就行，不需要我们操心锁的添加与释放，这些都由JVM底层来完成。所以，二者在使用上的区别就在于ReentrantLock用起来更麻烦，synchronized使用起来比较便捷。再来说灵活性。灵活性与便捷程度恰恰相反，synchronized虽然使用方便，但不够灵活，因为我们无法控制具体的锁粒度；而使用ReentrantLock就能够控制锁粒度，可以在代码层面控制锁的粒度以及加锁和解锁，灵活性更强。此外，在ReentrantLock里，等待锁的线程能够响应中断，然而synchronized中的等待线程无法响应中断，只会一直等待。并且ReentrantLock还支持公平锁和非公平锁、可重入锁，synchronized却只支持非公平锁。所以在高并发的使用场景下，显然ReentrantLock功能更多，也更灵活。而且既然是高并发场景，大部分人对ReentrantLock的使用和理解都比较到位，所以这种情况下建议使用ReentrantLock。如果对synchronized的锁升级流程感兴趣，可以查看这篇文章；如果对ReentrantLock的底层原理感兴趣，可以查看另一篇文章。