jdk1.5以后，并发包中新增了lock接口，
它相对于synchronized，多了以下三个主要特性：尝试非阻塞地获取锁（尝试获取锁成功则持有）、能被中断地获取锁（锁的进程能响应中断）、超时获取锁（指定时间截止之前获取锁）。
我们看看它接口中定义的api:
获取锁
可中断地获取锁
尝试非阻塞地获取锁，能够获取则返回true，否则false
超时获取锁，三种返回情况：1、当前线程在超时时间内获得了锁。2、当前线程在超时时间内被中断。3、超时时间内没获得锁
释放锁
获取等待通知组件，该组件和当前的锁绑定，当前线程只有获得了锁，才能调用该组件的wait（）方法，而调用后，当前线程将释放锁。
java中lock的实现是ReentrantLock
观测其源码，我们可以发现，lock接口的所有实现方法均是通过一个AbstractQueuedSynchronizer（同步器）的对象实现的
队列同步器是用来构建锁或者其他同步组件的基础框架，使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作。
他有三个方法改变状态
getState()：获取当前同步状态
setState()：设置当前同步状态
compareAndSetState(): 使用CAS设置当前状态，保证原子性
同步器中的队列使用了一个双向队列来管理同步状态
每个队列元素都有三种状态： cancelled:1 等待的线程超时或者被中断，将取消等待变成该状态（已取消）
signal: -1 下一个节点处于等待状态，当前节点若是释放了同步状态或者被取消了，将通知后继节点得以运行
condition: -2 节点在等待队列中，等待在condition上，其他线程对condition调用了signal()方法后，该节点将从等待队列中转移到同步队列中，加入到对同步状态的获取中。
propagate: -3 传播共享式同步状态
initial: 0 初始状态
主要对象：
node prev:前驱节点
node next:后继节点
node nextWaiter: 等待队列中的后继节点。
Thread thread: 获取同步状态的线程
同步器中存储着头节点head跟尾节点tail。
源码中实现lock的方法，是调用了同步器中的acquire(int arg)（独占式同步状态）方法
该方法尝试独占获取同步状态，成功则返回，否则进入同步队列等待
通过死循环来保证节点的正确添加（CAS）
节点进入同步队列后，进入一个自旋的过程，当获得同步状态则调用release从自旋退出，并唤醒头节点的后继节点
独占式同步状态总结： 获取同步状态失败的线程会进入到同步器队列中进行自旋，移除队列的条件是前驱节点为头节点且成功获取了同步状态，在释放同步状态时候，同步器会调用tryRelease()方法释放同步状态并且唤醒后继节点。
共享式同步状态：主要用在读写操作上，多线程可以同时读，但是写锁会排他。
同步器中的acquireShared（）方法就是以共享式地获取同步状态
我们可以看到在ReentrantReadWriteLock中的读锁ReadLock中的lock()方法
调用了同步器中的共享式获取同步状态，而写锁writeLock中则调用了独占式方法
重入锁：支持线程对资源的重复加锁，reentrantLock中先判断当前线程是否为获取锁的线程，是则成功获取，锁获取成功时候计数器加1，释放时候减1，当获取n次并释放n次时候，计数器为0则表示当前锁已经释放，源码方法为nonfairTrAcquire()非公平锁Nonfairsync
公平锁的源码 FairSync
两者的比较就是判断条件多了hasQueuedPredecessors()方法，就是加入了同步队列中当前节点是否有前驱节点的判断，如果方法返回true 则表示有线程更早请求获取锁，因此要等待前驱线程获取并释放锁之后才能获取。
为什么会有公平锁跟非公平锁呢：
其实非公平锁（默认）系统线程开销更低，公平锁按照队列fifo的原则，进行了大量的线程切换，而非公平锁，大部分是同一个线程又获取到了锁，进行了少量的线程切换，从而提升了性能。