和Synchronized相比，可重入锁ReentrantLock的实现原理有什么不同？
锁的实现原理基本是为了达到一个目的：让所有的线程都能看见某种标记。
Synchronized是在对象头中设置标记实现这一目的，是一种JVM原生锁的实现.
ReentrantLock和其他所有的基于lock接口实现的类，都是通过一个volitile修饰的int型变量，并保证每个线程都能拥有对该int的可见性和原子修改。其本质是基于AQS框架实现的。
什么是AQS框架？
AQS（AbstractQueueSynchronizer类）是一个用来构建锁和同步器的框架，各种Lock包中的锁，甚至早起的FutureTask，都是基于AQS构建的。
1.AQS在背部定义了一个volatile int state变量，表示同步状态：当线程调用Lock方法时，如果state=0,说明没有任何线程占用共享资源锁，可以获得锁并将状态state改为1,；如果state=1，说明有线程正在使用共享变量，其他线程必须加入同步队列并等待。
/**
* The synchronization state.
*/
private volatile int state;
2.AQS通过Node内部类构成一个双向链表结构的同步队列，来完成线程获取锁的排队工作，当有线程获取锁失败后，就会被添加到队列末尾。
/**
* Wait queue node class.
*
* The wait queue is a variant of a "CLH" (Craig, Landin, and
* Hagersten) lock queue. CLH locks are normally used for
* spinlocks. We instead use them for blocking synchronizers, but
* use the same basic tactic of holding some of the control
* information about a thread in the predecessor of its node. A
* "status" field in each node keeps track of whether a thread
* should block. A node is signalled when its predecessor
* releases. Each node of the queue otherwise serves as a
* specific-notification-style monitor holding a single waiting
* thread. The status field does NOT control whether threads are
* granted locks etc though. A thread may try to acquire if it is
* first in the queue. But being first does not guarantee success;
* it only gives the right to contend. So the currently released
* contender thread may need to rewait.
*
*
To enqueue into a CLH lock, you atomically splice it in as new
* tail. To dequeue, you just set the head field.
*
* +------+ prev +-----+ +-----+
* head | | <---- | | <---- | | tail
* +------+ +-----+ +-----+
*
*
* Insertion into a CLH queue requires only a single atomic
* operation on "tail", so there is a simple atomic point of
* demarcation from unqueued to queued. Similarly, dequeuing
* involves only updating the "head". However, it takes a bit
* more work for nodes to determine who their successors are,
* in part to deal with possible cancellation due to timeouts
* and interrupts.
*
*
The "prev" links (not used in original CLH locks), are mainly
* needed to handle cancellation. If a node is cancelled, its
* successor is (normally) relinked to a non-cancelled
* predecessor. For explanation of similar mechanics in the case
* of spin locks, see the papers by Scott and Scherer at
* http://www.cs.rochester.edu/u/scott/synchronization/
*
*
We also use "next" links to implement blocking mechanics.
* The thread id for each node is kept in its own node, so a
* predecessor signals the next node to wake up by traversing
* next link to determine which thread it is. Determination of
* successor must avoid races with newly queued nodes to set
* the "next" fields of their predecessors. This is solved
* when necessary by checking backwards from the atomically
* updated "tail" when a node's successor appears to be null.
* (Or, said differently, the next-links are an optimization
* so that we don't usually need a backward scan.)
*
*
Cancellation introduces some conservatism to the basic
* algorithms. Since we must poll for cancellation of other
* nodes, we can miss noticing whether a cancelled node is
* ahead or behind us. This is dealt with by always unparking
* successors upon cancellation, allowing them to stabilize on
* a new predecessor, unless we can identify an uncancelled
* predecessor who will carry this responsibility.
*
*
CLH queues need a dummy header node to get started. But
* we don't create them on construction, because it would be wasted
* effort if there is never contention. Instead, the node
* is constructed and head and tail pointers are set upon first
* contention.
*
*
Threads waiting on Conditions use the same nodes, but
* use an additional link. Conditions only need to link nodes
* in simple (non-concurrent) linked queues because they are
* only accessed when exclusively held. Upon await, a node is
* inserted into a condition queue. Upon signal, the node is
* transferred to the main queue. A special value of status
* field is used to mark which queue a node is on.
*
*
Thanks go to Dave Dice, Mark Moir, Victor Luchangco, Bill
* Scherer and Michael Scott, along with members of JSR-166
* expert group, for helpful ideas, discussions, and critiques
* on the design of this class.
*/
static final class Node {
……
}
- Node类是对要访问同步代码线程的封装，包含线程本身及其状态waitStatus(有五种取值：是否被阻塞，是否等待唤醒，是否已经被取消等)，每个Node节点关联其prev节点和next节点，方便线程释放锁后幻想下一个等待的线程，是一个FIFO的过程。
/**
* Status field, taking on only the values:
* SIGNAL: The successor of this node is (or will soon be)
* blocked (via park), so the current node must
* unpark its successor when it releases or
* cancels. To avoid races, acquire methods must
* first indicate they need a signal,
* then retry the atomic acquire, and then,
* on failure, block.
* CANCELLED: This node is cancelled due to timeout or interrupt.
* Nodes never leave this state. In particular,
* a thread with cancelled node never again blocks.
* CONDITION: This node is currently on a condition queue.
* It will not be used as a sync queue node
* until transferred, at which time the status
* will be set to 0. (Use of this value here has
* nothing to do with the other uses of the
* field, but simplifies mechanics.)
* PROPAGATE: A releaseShared should be propagated to other
* nodes. This is set (for head node only) in
* doReleaseShared to ensure propagation
* continues, even if other operations have
* since intervened.
* 0: None of the above
*
* The values are arranged numerically to simplify use.
* Non-negative values mean that a node doesn't need to
* signal. So, most code doesn't need to check for particular
* values, just for sign.
*
* The field is initialized to 0 for normal sync nodes, and
* CONDITION for condition nodes. It is modified using CAS
* (or when possible, unconditional volatile writes).
*/
volatile int waitStatus;
- Node类有两个常量，SHARED和EXCLUSIVE，分别代表共享模式和独占模式。所谓共享模式就是一个锁熏晕多个线程同事操作（信号量Semaphore就是AQS的共享模式实现的），独占模式是同一个时间段只能有一个线程对共享资源进项操作，多余的线程需要排队等待（如ReentranLock）。
/** Marker to indicate a node is waiting in shared mode */
static final Node SHARED = new Node();
/** Marker to indicate a node is waiting in exclusive mode */
static final Node EXCLUSIVE = null;
3.AQS通过内部类ConditionObject构建等待队列(可有多个）,当Condition调用wait()后，线程将会加入等待队列中，Condition调用signal()后，线程会从等待队列中转移到同步队列中进行锁竞争。
4.AQS和Condition各自维护不同的队列，在使用Lock和Condition的时候，其实就是两个队列在互相移动。
Synchronized和ReentrantLock的异同
ReentrantLock是Lock的实现类，是一个互斥的同步锁。
从功能角度讲：ReentrantLock比synchronized更精细，可以实现synchronized实现不了的功能：
- 等待可中断：当长期持有锁的线程不释放锁时，正在等待的线程可以选择放弃等待，对处理执行时间非常长的同步块很有用。
- 带超时的获取锁尝试：在指定时间范围内获取锁，如果到了时间仍无法获取就返回。
- 可以判断是否有线程在等待获取锁。
- 可以响应中断请求：与synchronized不同，当获取到锁的线程被中断时，能够响应中断，中断异常会被抛出，同时锁会被释放。
- 可以实现公平锁
从释放锁的角度讲：synchronized在JVM层面实现的，不但可以通过监控工具监测synchronized的锁定，代码异常时会自动释放锁；Lock加锁后必须手动释放锁。
从性能角度讲：java6改进synchronized后，在竞争不激烈的情况下，synchronized性能高于ReentrantLock;高竞争情况下，synchronized性能会下降几十倍，ReentrantLock性能会维持。