关于synchronized与lock的性能比较
https://blog.csdn.net/ganyao939543405/article/details/52486316?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
性能：在高并发的情况下都是在一个数量集的，较高和较低并发下，synchronized都比Lock来的快，基本是两倍的关系。
到底是使用synchronized还是使用lock！
我们写同步的时候，优先考虑synchronized，如果有特殊需要，再进一步优化，可以考虑使用lock。
synchronized的性能这么好，究竟是做了哪些优化
之前因为synchronized依赖硬件底层，显得非常重，性能方面比不上lock
后来1.6版本以来做了很多优化。
对synchronized的原理和优化方面可以参考
https://blog.csdn.net/shandian000/article/details/54927876/
synchronized的4中状态：无锁 偏向锁 轻量锁 重量锁的状态变化。 首先是无锁状态，如果只有A线程执行，则会变成偏向锁，单单偏向A线程。下次A线程再进来就能直接进来，不需要额外的cas操作。如果B线程进来，发现当前锁偏向A线程，就会通过cas竞争锁，竞争失败说明有多个线程竞争，就会再安全点的时候将锁升级为轻量级锁。如果轻量级锁还存在锁竞争失败的情况，就会升级为重量级锁，再竞争激烈的情况下，重量级锁会比轻量级锁更高的性能。因为轻量级锁不仅存在互斥的开销还存在cas的开销。
在竞争锁的时候，也做了一些优化，比如自旋锁/适应性自旋
在代码层面上，会做的优化有，锁消除（隐形加锁 StringBuffer）和锁粗化（for循环内部上锁变成外部上锁）。
synchronized跟ReentrantLock相比，有几点局限性：
加锁的时候不能设置超时。ReentrantLock有提供tryLock方法，可以设置超时时间，如果超过了这个时间并且没有获取到锁，就会放弃，而synchronized却没有这种功能
ReentrantLock可以使用多个Condition，而synchronized却只能有1个
不能中断一个试图获得锁的线程
ReentrantLock可以选择公平锁和非公平锁
ReentrantLock可以获得正在等待线程的个数，计数器等
