Lock对象是在java5中加的实现同步的效果，Lock主要是在jdk的层面来实现同步，synchronized是Java的关键字，是java的内置属性，主要在jvm层面上来对临界资源的同步互斥访问。
一. synchronized 的局限性 与 Lock 的优点
如果一个代码块被synchronized关键字修饰，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待直至占有锁的线程释放锁。事实上，占有锁的线程释放锁一般会是以下三种情况之一：
- 占有锁的线程执行完了该代码块，然后释放对锁的占有；
- 占有锁线程执行发生异常，此时JVM会让线程自动释放锁；
- 占有锁线程进入 WAITING 状态从而释放锁，例如在该线程中调用wait()方法等。
synchronized 是Java语言的内置特性，可以轻松实现对临界资源的同步互斥访问。那么，为什么还会出现Lock呢？
Case 1 ：ReenTrantLock可以实现等待可中断，一种是直接中断lock.lockInterruptibly(),它的原理也还是检查Interrupted标志，检测到了会处理，一般是去catch块里面去处理，另一种就是设置最大等待时间tryLock(long time, TimeUnit unit)
在使用synchronized关键字的情形下，假如占有锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，那么其他线程就只能一直等待，别无他法。这会极大影响程序执行效率。因此，就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间 (解决方案：tryLock(long time, TimeUnit unit)) 或者 能够响应中断 (解决方案：lockInterruptibly())，在线程的执行过程中，如果出现中断，则释放锁），这种情况可以通过 Lock 解决。
Case 2 ：ReentrantReadWriteLock实现多个线程同时读操作。
我们知道，当多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作也会发生冲突现象，但是读操作和读操作不会发生冲突现象。但是如果采用synchronized关键字实现同步的话，就会导致一个问题，即当多个线程都只是进行读操作时，也只有一个线程在可以进行读操作，其他线程只能等待锁的释放而无法进行读操作。因此，需要一种机制来使得当多个线程都只是进行读操作时，线程之间不会发生冲突。同样地，Lock也可以解决这种情况 (解决方案：ReentrantReadWriteLock) 。
Case 3 ：
我们可以通过Lock得知线程有没有成功获取到锁 (解决方案：ReentrantLock) ，但这个是synchronized无法办到的。
Case 4：ReentrantLock可以指定是公平锁还是非公平锁。
Case 5：ReentrantLock可以通过Condition对象来实现选择性通知，一个lock锁绑定多个条件。
上面提到的情形，我们都可以通过Lock来解决，但 synchronized 关键字却无能为力。事实上，Lock 是 java.util.concurrent.locks包 下的接口，Lock 实现提供了比 synchronized 关键字 更广泛的锁操作，它能以更优雅的方式处理线程同步问题。也就是说，Lock提供了比synchronized更多的功能。但是要注意以下几点：
1）synchronized是Java的关键字，因此是Java的内置特性，是基于JVM层面实现的。而Lock是一个Java接口，是基于JDK层面实现的，通过这个接口可以实现同步访问；
2）采用synchronized方式不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而 Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致死锁现象
Lock：
通过查看Lock的源码可知，Lock 是一个接口： public interface Lock { void lock(); void lockInterruptibly() throws InterruptedException; // 可以响应中断，和lock（）的功能类似，但是通过这个方法获得锁时，如果这个线程正在等待获取锁，也就是这个线程如果处于阻塞状态，
那么这个这个线程是可以被中断的。例如，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。
当一个线程已经获取锁时，它是不能够被interrupt中断的。
boolean tryLock(); // 在调用时锁定未被另外一个线程占有，就获取这个锁定 boolean tryLock(long time, TimeUnit unit) throws InterruptedException; // 可以响应中断，在调用时，在给定等待时间内锁定未被另外一个线程占有，就获取这个锁定 void unlock(); Condition newCondition(); }
ReentrantReadWriteLock：
ReentrantReadWriteLock允许多个读线程同时访问，但不允许写线程和读线程、写线程和写线程同时访问。相对于排他锁，提高了并发性。在实际应用中，大部分情况下对共享数据（如缓存）的访问都是读操作远多于写操作，这时ReentrantReadWriteLock能够提供比排他锁更好的并发性和吞吐量。
ReentrantReadWriteLock支持以下功能：
1）支持公平和非公平的获取锁的方式；
2）支持可重入。读线程在获取了读锁后还可以获取读锁；写线程在获取了写锁之后既可以再次获取写锁又可以获取读锁；
3）还允许从写入锁降级为读取锁，其实现方式是：先获取写入锁，然后获取读取锁，最后释放写入锁。但是，从读取锁升级到写入锁是不允许的；
4）读取锁和写入锁都支持锁获取期间的中断；
5）Condition支持。仅写入锁提供了一个 Conditon 实现；读取锁不支持 Conditon ，readLock().newCondition() 会抛出 UnsupportedOperationException。
Lock和synchronized的选择：
总的来说，Lock和synchronized有以下几点不同：
- (1) Lock是一个接口，是JDK层面的实现；而synchronized是Java中的关键字，是Java的内置特性，是JVM层面的实现；
- (2) synchronized 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
- (3) Lock 可以让等待锁的线程响应中断，而使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
- (4) 通过Lock可以知道有没有成功获取锁，而synchronized却无法办到；
- (5) Lock可以提高多个线程进行读操作的效率。
在性能上来说，如果竞争资源不激烈，两者的性能是差不多的。而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。
可重入锁的概念：
当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是，这就会造成死锁，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。而由于synchronized和Lock都具备可重入性，所以不会发生上述现象。
class MyClass { public synchronized void method1() { method2(); } public synchronized void method2() {} }
公平锁和非公平锁：
在AQS里面的时候我们理解过这个概念，公平锁一般是按请求锁的顺序来获取锁的，就是唤醒head后面的第一个waitstatus为0或者-1的节点的线程（源码里面有一个判断这个节点的前置节点是不是head节点）。非公平锁就是一种抢占机制（队列里面的任何一个节点都可以去），随机获得锁的。而对于ReentrantLock 和 ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。
我发现很多的文章说非公平锁就是每个线程获取锁的几率都是相同的，其实研究源码发现好像并不是这样的，一旦进入了队列，这些节点还是按顺序的，非公平锁只是在线程最开始获取锁的时候但不会去管队列里面情况，直接去和队列里面head后面的第一个节点一起尝试获取同步状态，成功就成功，失败了你就得进队列了，而公平锁就是在线程一开始尝试获取锁的时候就会判断队列里面有没有在排队的，有的话，你就得乖乖进队。（这一段不知道我的理解有没有问题）
为什么他们默认是非公平锁呢？
非公平锁性能高于公平锁性：
在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟。
假设线程A持有一个锁，并且线程B请求这个锁。由于锁被A持有，因此B将被挂起。当A释放锁时，B将被唤醒，因此B会再次尝试获取这个锁。与此同时，如果线程C也请求这个锁，那么C很可能会在B被完全唤醒之前获得、使用以及释放这个锁。这样就是一种双赢的局面：B获得锁的时刻并没有推迟，C更早的获得了锁，并且吞吐量也提高了。
当持有锁的时间相对较长或者请求锁的平均时间间隔较长，应该使用公平锁（因为你这个时候你插队也没用啊，插队带来的吞吐量提升不明显）。
我们通过分析ReentrantLock源码来分析公平锁与非公平锁
公平锁：主要是多了hasQueuedPredecessors这样一个函数，去判断当前队列中有没有在等待的节点，有的话你乖乖进队列，别想着想在队列前面去获取同步状态
protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { //如果同步状态被释放了 if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { //进入这里面表示直接获取同步状态了，都不用进队列了 setExclusiveOwnerThread(current); return true; } } else if (current == getExclusiveOwnerThread()) { //这里是可重入锁的功能 int nextc = c + acquires; if (nextc < 0) throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; }
非公平锁：会发现没有hasQueuedPredecessors这个函数了，就是他可以无视队列率先拿到同步资源
final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; }
最后， 在ReentrantLock类中定义了很多方法，举几个例子：
- isFair() //判断锁是否是公平锁
- isLocked() //判断锁是否被任何线程获取了
- hasWaiters(Condition condition) //是否有线程正在等待与锁定有关的condition条件
- isHeldByCurrentThread() //判断锁是否被当前线程获取了
- hasQueuedThreads() //判断是否有线程在等待该锁
- hasQueuedThread(Thread thread) //判断指定线程是否在等待该锁
- getHoldCount() //查询当前线程占有lock锁的次数，也就是调用lock()方法的次数
- getQueueLength() // 获取正在等待此锁的线程数
- getWaitQueueLength(Condition condition) // 获取正在等待此锁相关条件condition的线程数在ReentrantReadWriteLock中也有类似的方法，同样也可以设置为公平锁和非公平锁。不过要记住，ReentrantReadWriteLock并未实现Lock接口，它实现的是ReadWriteLock接口。