一，锁原理的前生今世
synchronized的出现
众所周知，JAVA中最简单的加锁方法是用关键字synchronized，我们可以使用这个关键字将一个方法变成线程安全的，也可以将一个代码块变成线程安全的，这样子我们不需要再担心多线程同时执行到这段代码会引发的并发问题。同时配合方法wait，notify和notifyall可以很好的实现多线程之间的协作，比如某个线程因为需要等待一些资源，于是调用wait方法将自己设置为waiting状态，其他线程释放或生产这个线程需要的资源的时候需要通知这个线程（notify）将其唤醒，或者通知所有等待当前资源的线程（notifyall）。
然而当功能完成之后我们似乎并不满足于此，于是我们开始考虑这么做的代价是什么，是否可以做的更好。
先说说这么做（使用synchronized）的代价是什么，当多个线程请求临界资源的时候只能有一个线程得到满足，那么其他的线程会做什么呢，他们会被阻塞，直到被通知（notify/notifyall）又有资源的时候才被唤醒进行再一次的锁争用，而后往复的是又只有一个线程能被得到满足，其他的线程继续进入阻塞状态，而这个时候可能会有不断的增加争用线程。性能损耗的关键点在于线程的阻塞操作是由操作系统来完成的，在Linux系统下是由pthread_mutex_lock函数来完成。线程被阻塞之后便进入了内核调度态，这个过程发生了操作系统将保存用户态的上下文进入内核态，这也就是常说的上下文切换，上下文切换代价大，在于操作系统需要将当前线程执行上下文内容（包括堆栈、寄存器等存储的内容）的保存以便之后线程切换回来时候再进行现场恢复。
上面可以看出使用synchronized的代价是什么了吧，当竞争激烈的时候会引起频繁的操作系统上下文切换，从而影响系统的性能。
自旋锁对synchronized的初步优化
自旋锁是对线程阻塞的一种优化，他的原理简单的说就是当线程争用锁失败的时候不立即进入阻塞状态，而是再等一会，因为对于执行时间短的代码这一会可能就会释放锁，而线程就不需要进行一次阻塞与唤醒。等待操作就是让线程多执行几个空指令，至于等待多久这跟具体的处理器实现有关，也有可能处理器根本不支持自旋锁，具体实现的时候我们可以设置一个临界值，当超过了这个临界值之后我们就不自旋了，就乖乖进入阻塞状态吧。这种优化对于执行时间短的代码是很有效的。synchronized使用自旋锁的时机是线程进入等待队列即阻塞的前一步。
轻量级锁原理
轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。
偏向锁有什么X用
偏向锁是java6提供的一种功能，主要是对无竞争条件下的对加锁代码执行的优化。目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。偏向锁会偏向于第一个获得它的线程（Mark Word中的偏向线程ID信息），如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。假设当前虚拟机启用了偏向锁（启用参数-XX:+UseBiasedLocking，JDK 1.6的默认值），当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为“01”，即偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如Locking、Unlocking及对Mark Word的Update等）。当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就如上面介绍的轻量级锁那样执行。偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，也就是说它并不一定总是对程序运行有利，如果程序中大多数的锁都总是被多个不同的线程访问，那偏向模式就是多余的。
JUC的Lock（可重入锁和读写锁）
Lock是JAVA5增加的内容，在JUC（java.util.concurrent.locks）包下面，作者是并发大师Doug Lea。JUC包提供了很多封装的锁，包括常用的ReentrantLock和ReadWriteLock。这些所其实都是依赖java.util.concurrent.AbstractQueuedSynchronizer(AQS)这个类来实现的，这个类有个简写的名字叫AQS，对这就是著名的AQS。
关于Lock，先说说线程获取Lock锁的时候会引起哪些事件呢。首先AQS是依赖一个被volatile修饰的int变量来标识当前锁的状态的，为0的时候代表当前锁不被任何线程拥有，当线程拿到这个锁的时候会通过CAS操作修改state的状态，那么对于争用失败的线程AQS会怎么办呢，AQS内部维护了一个等待队列，这个队列是纯JAVA实现的，其实现也是非常巧妙的，多线程在通过CAS来获取自己在队列中的位置，同时队列中的线程状态也是阻塞状态，遇到阻塞就头疼了，上面已经介绍过阻塞会带来的性能问题。在源码中我们可以看到的是AQS通过LockSupport（LockSupport底层依赖Unsafe）将线程阻塞，关于LockSupport其功能是用来代替wait和notity/notifyall的，更好的地方是LockSupport对park方法和unpark方法的调用没有先后的限制，而notify/notifyall必须在wait调用之后调用。尽管如此，这一切并没有阻止线程进入阻塞状态。
可重入锁原理
可重入锁就是当前持有该锁的线程能够多次获取该锁，无需等待。基于AQS实现，AQS是JDK1.5提供的一个基于FIFO等待队列实现的一个用于实现同步器的基础框架，这个基础框架的重要性可以这么说，JUC包里面几乎所有的有关锁、多线程并发以及线程同步器等重要组件的实现都是基于AQS这个框架。AQS的核心思想是基于volatile int state这样的一个属性同时配合Unsafe工具对其原子性的操作来实现对当前锁的状态进行修改。当state的值为0的时候，标识改Lock不被任何线程所占有。
作为AQS的核心实现的一部分，举个例子，我们假设目前有三个线程Thread1、Thread2、Thread3同时去竞争锁，如果结果是Thread1获取了锁，Thread2和Thread3进入了等待队列，AQS的等待队列基于一个双向链表实现的，HEAD节点不关联线程，后面两个节点分别关联Thread2和Thread3，他们将会按照先后顺序被串联在这个队列上。这个时候如果后面再有线程进来的话将会被当做队列的TAIL。当三个线程同时进来，他们会首先会通过CAS去修改state的状态，如果修改成功，那么竞争成功，因此这个时候三个线程只有一个CAS成功，其他两个线程失败，也就是tryAcquire返回false。接下来，addWaiter会把将当前线程关联的EXCLUSIVE类型的节点入队列如果队尾节点不为null，则说明队列中已经有线程在等待了，那么直接入队尾。如果Thread2和Thread3同时进入了enq，同时t==null，则进行CAS操作对队列进行初始化，这个时候只有一个线程能够成功，然后他们继续进入循环，第二次都进入了else代码块，这个时候又要进行CAS操作，将自己放在队尾，因此这个时候又是只有一个线程成功，我们假设是Thread2成功，哈哈，Thread2开心的返回了，Thread3失落的再进行下一次的循环，最终入队列成功，返回自己。当有多个线程，或者说很多很多的线程同时执行的时候，怎么能保证最终他们都能够乖乖的入队列而不会出现并发问题的呢？这也是这部分代码的经典之处，多线程竞争，热点、单点在队列尾部，多个线程都通过【CAS+死循环】这个free-lock黄金搭档来对队列进行修改，每次能够保证只有一个成功，如果失败下次重试，如果是N个线程，那么每个线程最多loop N次，最终都能够成功。上面只是addWaiter的实现部分，那么节点入队列之后会继续发生什么呢，如果Thread1死死的握住锁不放，那么Thread2和Thread3现在的状态就是挂起状态啦，而且HEAD，以及Thread的waitStatus都是SIGNAL，尽管他们在整个过程中曾经数次去尝试获取锁，但是都失败了，失败了不能死循环呀，所以就被挂起了。
锁释放-等待线程唤起首先，Thread1会修改AQS的state状态，加入之前是1，则变为0，注意这个时候对于非公平锁来说是个很好的插入机会，举个例子，如果锁是公平锁，这个时候来了Thread4，那么这个锁将会被Thread4抢去。
我们继续走常规路线来分析，当Thread1修改完状态了，判断队列是否为null，以及队头的waitStatus是否为0，如果waitStatus为0，说明队列无等待线程，按照我们的例子来说，队头的waitStatus为SIGNAL=-1，因此这个时候要通知队列的等待线程，可以来拿锁啦，这也是unparkSuccessor做的事情，unparkSuccessor主要做三件事情：
-
将队头的waitStatus设置为0.
-
通过从队列尾部向队列头部移动，找到最后一个waitStatus<=0的那个节点，也就是离队头最近的没有被cancelled的那个节点，队头这个时候指向这个节点。
-
将这个节点唤醒，其实这个时候Thread1已经出队列了。
还记得线程在哪里挂起的么，上面说过了，在acquireQueued里面，我没有贴代码，自己去看哦。这里我们也大概能理解AQS的这个队列为什么叫FIFO队列了，因此每次唤醒仅仅唤醒队头等待线程，让队头等待线程先出。当有多个线程去竞争同一个锁的时候，假设锁被某个线程占用，那么如果有成千上万个线程在等待锁，有一种做法是同时唤醒这成千上万个线程去去竞争锁，这个时候就发生了羊群效应，海量的竞争必然造成资源的剧增和浪费，因此终究只能有一个线程竞争成功，其他线程还是要老老实实的回去等待。AQS的FIFO的等待队列给解决在锁竞争方面的羊群效应问题提供了一个思路：保持一个FIFO队列，队列每个节点只关心其前一个节点的状态，线程唤醒也只唤醒队头等待线程。
无锁才是大BOSS
讲到无锁，必然是Disruptor并发框架，Disruptor底层依赖一个RingBuffer来进行线程之间的数据交换，无锁在于在并发条件下，多线程对RingBuffer的读和写不会涉及到锁，然而因为RingBuffer满或者RingBuffer中没有可消费内容引发的线程等待，那就要另当别论了。简单几句介绍下无锁原理，RingBuffer维护者可读和可写的指针，也叫游标，它指向生产者或消费者需要写或读的位置，而对于指针的更新是由CAS来完成的，这个过程中我们不需要加锁/解锁的过程。
Disruptor(无锁并发框架)
1.ring buffer是由一个大数组组成的。
2.所有ring buffer的“指针”（也称为序列或游标）是java long类型的（64位有符号数），指针采用往上计数自增的方式。（不用担心越界，即使每秒1,000,000条消息，也要消耗300,000年才可以用完）。
3.对ring buffer中的指针进行按ring buffer的size取模找出数组的下标来定位入口（类似于HashMap的entry）。为了提高性能，我们通常将ring buffer的size大小设置成实际使用的2倍。
这样我们可以通过位运算(bit-mask )的方式计算出数组的下标。
Ring buffer的基础结构
ring buffer维护两个指针，“next”和“cursor”。
在上面的图示里，是一个size为7的ring buffer，从0-2的坐标位置是填充了数据的。
“next”指针指向第一个未填充数据的区块。“cursor”指针指向最后一个填充了数据的区块。在一个空闲的ring bufer中，它们是彼此紧邻的，如上图所示。
填充数据（Claiming a slot，获取区块）
Disruptor API 提供了事务操作的支持。当从ring buffer获取到区块，先是往区块中写入数据，然后再进行提交的操作。
假设有一个线程负责将字母“D”写进ring buffer中。将会从ring buffer中获取一个区块（slot）,这个操作是一个基于CAS的“get-and-increment”操作，将“next”指针进行自增。这样，当前线程（我们可以叫做线程D）进行了get-and-increment操作后，
指向了位置4，然后返回3。这样，线程D就获得了位置3的操作权限。
接着，另一个线程E做类似以上的操作。
提交写入
以上，线程D和线程E都可以同时线程安全的往各自负责的区块（或位置，slots）写入数据。但是，我们可以讨论一下线程E先完成任务的场景…
线程E尝试提交写入数据。在一个繁忙的循环中有若干的CAS提交操作。线程E持有位置4，它将会做一个CAS的waiting操作，直到 “cursor”变成3，然后将“cursor”变成4。
再次强调，这是一个原子性的操作。因此，现在的ring buffer中，“cursor”现在是2，线程E将会进入长期等待并重试操作，直到 “cursor”变成3。
然后，线程D开始提交。线程E用CAS操作将“cursor”设置为3（线程E持有的区块位置）当且仅当“cursor”位置是2.“cursor”当前是2，所以CAS操作成功和提交也成功了。
这时候，“cursor”已经更新成3，然后所有和3相关的数据变成可读。
这是一个关键点。知道ring buffer填充了多少 – 即写了多少数据，那一个序列数写入最高等等，是游标的一些简单的功能。“next”指针是为了保证写入的事务特性。
最后的疑惑是线程E的写入可见，线程E一直重试，尝试将“cursor”从3更新成4，经过线程D操作后已经更新成3，那么下一次重试就可以成功了。
写入数据可见的先后顺序是由线程所抢占的位置的先后顺序决定的，而不是由它的提交先后决定的。但你可以想象这些线程从网络层中获取消息，这是和消息按照时间到达的先后顺序是没什么不同的，而两个线程竞争获取一个不同循序的位置。
总结：
在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。
ReenTrantLock独有的能力：
1. ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。
2. ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。
3. ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。
