锁原理与优化
synchronized的弊端
众所周知，JAVA中最简单的加锁方法是用关键字synchronized，我们可以使用这个关键字将一个方法变成线程安全的，也可以将一个代码块变成线程安全的，这样子我们不需要再担心多线程同时执行到这段代码会引发的并发问题。同时配合方法wait，notify和notifyall可以很好的实现多线程之间的协作，比如某个线程因为需要等待一些资源，于是调用wait方法将自己设置为waiting状态，其他线程释放或生产这个线程需要的资源的时候需要通知这个线程（notify）将其唤醒，或者通知所有等待当前资源的线程（notifyall）。
然而当功能完成之后我们似乎并不满足于此，于是我们开始考虑这么做的代价是什么，是否可以做的更好。
先说说这么做（使用synchronized）的代价是什么，当多个线程请求临界资源的时候只能有一个线程得到满足，那么其他的线程会做什么呢，他们会被阻塞，直到被通知（notify/notifyall）又有资源的时候才被唤醒进行再一次的锁争用，而后往复的是又只有一个线程能被得到满足，其他的线程继续进入阻塞状态，而这个时候可能会有不断的增加争用线程。性能损耗的关键点在于线程的阻塞操作是由操作系统来完成的，线程被阻塞之后便进入了内核调度态，这个过程发生了操作系统将保存用户态的上下文进入内核态，这也就是常说的上下文切换，上下文切换代价大，在于操作系统需要将当前线程执行上下文内容（包括堆栈、寄存器等存储的内容）的保存以便之后线程切换回来时候再进行现场恢复。
上面可以看出使用synchronized的代价是什么了吧，当竞争激烈的时候会引起频繁的操作系统上下文切换，从而影响系统的性能。
synchronized原理
要了解synchronized原理和运作过程，必须从 Hotspot虚拟机的对象(对象头部分)的内存布局开始介绍。 Hotspot虚拟机的对象头( Object Header)分为两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码( Hash Code)、GC分代年龄( Generational GC Age)等，这部分数据的长度在32位和64位的虚拟机中分别为32bit和64bit，官方称它为“ Mark Word"，另外一部分用于存储指向方法区对象类型数据的指针，如果是数组对象的话，还会有一个额外的部分用于存储数组长度。对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如，在32位的 Hotspot虚拟机中对象未被锁定的状态下， Mark Word的32bit空间中的25bit用于存储对象哈希码( Hashcode),4bit用于存储对分代年龄，2bit用于存储锁标志位，1bit固定为0不同状态下的对象的存储内容是不同的。如图
轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增加的，稍后我们会简要分析，这里主要分析未锁定到重量级锁定的过程，也就是代码进入synchronized 前和进入后的状态分析，由图知该锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）
ObjectMonitor() {
_header = NULL;
_count = 0; //记录个数
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL; //处于wait状态的线程，会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; //处于等待锁block状态的线程，会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象)，_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSe t集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。如下图所示
由此看来，monitor对象存在于每个Java对象的对象头中(存储的指针的指向)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因。
对于同步代码块：
同步语句块的实现使用的是monitorenter 和 monitorexit 指令，其中monitorenter指令指向同步代码块的开始位置，monitorexit指令则指明同步代码块的结束位置，当执monitorenter指令时，当前线程将试图获取 objectref(即对象锁) 所对应的 monitor 的持有权，当 objectref 的 monitor 的进入计数器为 0，那线程可以成功取得 monitor，并将计数器值设置为 1，取锁成功。如果当前线程已经拥有 objectref 的 monitor 的持有权，那它可以重入这个 monitor (关于重入性稍后会分析)，重入时计数器的值也会加 1。倘若其他线程已经拥objectref 的 monitor 的所有权，那当前线程将被阻塞，直到正在执行线程执行完毕，即monitorexit指令被执行，执行线程将释放 monitor(锁)并设置计数器值为0 ，其他线程将有机会持monitor 。值得注意的是编译器将会确保无论方法通过何种方式完成，方法中调用过的每条 monitorenter 指令都有执行其对应 monitorexit 指令，而无论这个方法是正常结束还是异常结束。为了保证在方法异常完成时 monitorenter 和 monitorexit 指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异常处理器声明可处理所有的异常，它的目的就是用来执行 monitorexit 指令。从字节码中也可以看出多了一个monitorexit指令，它就是异常结束时被执行的释放monitor 的指令。
对于同步方法：
方法级的同步是隐式，即无需通过字节码指令来控制的，它实现在方法调用和返回操作之中。JVM可以从方法常量池中的方法表结构(method_info Structure) 中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。当方法调用时，调用指令将会 检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先持有monitor（虚拟机规范中用的是管程一词）， 然后再执行方法，最后再方法完成(无论是正常完成还是非正常完成)时释放monitor。在方法执行期间，执行线程持有了monitor，其他任何线程都无法再获得同一个monitor。如果一个同步方法执行期间抛 出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的monitor将在异常抛到同步方法之外时自动释放。
synchronized修饰的方法并没有monitorenter指令和monitorexit指令，取得代之的确实是ACC_SYNCHRONIZED标识，该标识指明了该方法是一个同步方法，JVM通过该ACC_SYNCHRONIZED访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。
这便是synchronized锁在同步代码块和同步方法上实现的基本原理。
自旋锁对synchronized的初步优化
自旋锁是对线程阻塞的一种优化，他的原理简单的说就是当线程争用锁失败的时候不立即进入阻塞状态，而是再等一会，因为对于执行时间短的代码这一会可能就会释放锁，而线程就不需要进行一次阻塞与唤醒。等待操作就是让线程多执行几个空指令，至于等待多久这跟具体的处理器实现有关，也有可能处理器根本不支持自旋锁，具体实现的时候我们可以设置一个临界值，默认是10，当超过了这个临界值之后我们就不自旋了，就乖乖进入阻塞状态吧。这种优化对于执行时间短的代码是很有效的。synchronized使用自旋锁的时机是线程进入等待队列即阻塞的前一步。
锁消除与锁粗化对synchronized的优化
锁消除
是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的目的主要是判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把他们当作栈数据对待，同步加锁就无需进行，典型的例子是StringBuffer 的拼接例子，如果该对象在方法中new的话，sb对象就不会逃逸到方法以外，这样对于SB对象来说，他的内部实现是加锁的，那么这个锁就毫无意义了，所以就会被安全的消除了。
锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小，只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗如连续的 append方法就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展(粗化)到整个操作序列的外部，就是扩展到第一个 append操作之前直至最后一个 append0操作之后，这样只需要加锁一次就可以了。
轻量级锁对synchronized的优化
轻量级锁是JDK1.6之中加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就称为“重量级”锁。首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
在代码进入同步块的时候，如果此同步对象没有被锁定(锁标志位为“01”状态)，虚拟机首先将在当前线程的栈帧中建立一个名为锁记录( Lock Record)的空间，用于存储锁对象目前的Mark Word的拷贝(官方把这份拷贝加了一个 Displaced前缀，即 Displaced Mark Word)，这时候线程堆栈与对象头的状态如图13-3所示然后，虚拟机将使用CAS操作尝试将对象的 Mark Word更新为指向 Lock Record的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象 Mark Word的锁标志位( Mark Word的最后2bit)将转变为“00”，即表示此又对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图13-4所示
如果这个更新操作失败了，虚拟机首先会检查对象的 Mark Word是否指向当前线程的栈帧，如果只说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程抢占了，如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态值变为“10°， Mark Word中存储的就是指向重量级锁(互斥量)的指针，后面等待锁的线程也要进入阻塞状态
轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。
偏向锁对synchronized的优化
偏向锁是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）性质的优化，也就是说它并不一定总是对程序运行有利，如果程序中大多数的锁都总是被多个不同的线程访问，那偏向模式就是多余的。
无锁才是大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，那么下一次重试就可以成功了。
写入数据可见的先后顺序是由线程所抢占的位置的先后顺序决定的，而不是由它的提交先后决定的。但你可以想象这些线程从网络层中获取消息，这是和消息按照时间到达的先后顺序是没什么不同的，而两个线程竞争获取一个不同循序的位置。