synchronized是性能低效的。因为这是一个重量级操作，它对性能最大的影响是阻塞的是实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力。
相比之下使用Java提供的Lock对象，性能更高一些。
到了JDK1.6，发生了变化，对synchronize加入了很多优化措施，有自适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在JDK1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地，所以还是提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步。
ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法。
采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用Lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。
ReentrantLock里面有一个内部类Sync，Sync继承AQS（AbstractQueuedSynchronizer），添加锁和释放锁的大部分操作实际上都是在Sync中实现的。
它有公平锁FairSync和非公平锁NonfairSync两个子类。
ReentrantLock默认使用非公平锁，也可以通过构造器来显示的指定使用公平锁。
队列同步器 也是实现ReentrantLock的基础
AQS 有一个 state 标记位，值为1 时表示有线程占用，其他线程需要进入到同步队列等待，同步队列是一个双向链表。
当获得锁的线程需要等待某个条件时，会进入 condition 的等待队列，等待队列可以有多个。
当 condition 条件满足时，线程会从等待队列重新进入同步队列进行获取锁的竞争。
synchronized可以在synchronized方法或者是synchronized代码块执行完毕后自动释放锁，而Lock必须是用户手动释放锁，不然会出现死锁现象。
Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。
Lock可以提高多个线程进行读操作的效率。
synchronized是非公平锁，ReentrantLock可以控制是否是公平锁。
