一、锁升级
JavaSE6为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”，所以JavaSe6中锁共有4种状态，级别从低到高依次是：无锁状态，偏向锁状态，轻量级锁状态，和重量级锁状态。锁的状态会随着锁竞争的激烈程度的升级而升级。锁可以升级，但不能降级，这种只能升级不能降级的策略，目的是为了提高获得锁和释放锁的效率。
Java SE1.6为了减少获得锁和释放锁所带来的性能消耗，引入了“偏向锁”和“轻量级锁”，所以在Java SE1.6里锁一共有四种状态，级别从低到高依次是：无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。
锁可升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。
补充：
(锁能否降级存在争议。这篇文章Java锁优化--JVM锁降级 中提到，R大说了锁是可以降级的。同时文章作者发现最新版的《深入理解Java虚拟机》中已经删掉了锁只能升级不能降级的相关文字)
1.锁偏向
HotSpot的作者研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。锁偏向的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。
偏向锁是JDK1.6提出的一种只是锁优化方式。其核心思想是：如果一个线程获得了锁，当其再次请求锁时，无需再做任何同步操作。这样就节省了大量锁申请的时间，从而提升了性能。
偏向锁的原理
假设虚拟机启用了偏向锁，当锁对象第一次被线程获取时，虚拟机将会把对象头中的标识位设为'01'，即偏向模式，同时使用CAS操作把获取到该锁的线程的ID记录在锁对象的Mark Word中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块，虚拟机就可以不再进行任何同步操作(例如Locking，Unlocking及对Mark Word的Update等)。
当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向(Revoke Bias)后恢复到未锁定(标志位为'01')或轻量级锁定(标识位为‘00’)的状态，后续的同步操作就如上面介绍的轻量级锁那样执行。锁偏向、轻量级锁的状态转化及对象Mark Word的关系如图。
2.轻量级锁
在之前的文章Java对象的创建、内存布局和访问定位 中介绍过对象头的Mark Word，它是实现轻量级锁和偏向锁的关键。
轻量级锁的加锁过程
在进入同步块的时候，如果同步对象没有被锁定(锁标识位为'01'状态)，虚拟机首先将在当前线程的栈帧中划分一个名为锁记录(Lock Record)的空间，用于存储锁对象目前的Mark Word的拷贝(官方把这份拷贝加了一个Displaced前缀，即Displayed Mark Word)，这时线程堆栈与对象头的状态如图13-3所示。
然后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位(Mark Word的最后2bit)将转变为'00'，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图13-4所示。
如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果只说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其它线程抢占了。如果有两条以上的线程征用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标识的状态值变为'10'，Mark Word中存储的就是指向重量级锁(互斥锁)的指针，后面等待锁的线程也要进入阻塞状态。
轻量级锁的解锁过程
解锁过程也是通过CAS操作来进行的，如果对象的Mark Word仍然指向着线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其它线程尝试过获取该锁，那就要在释放锁的同时，唤醒被挂起的线程。
需要注意的是：
轻量级锁提升程序同步性能的依据是"对于绝大部分的锁，在整个同步周期内都是不存在竞争的"，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。
3.锁膨胀(成为重量级锁)
当轻量级锁失败，虚拟机就会使用重量级锁。使用重量级锁时，对象的Mark Word中的末尾的2位会被设置为'10'。整个Mark Word表示指向monitor对象的指针。
在轻量级处理失败后，虚拟机会执行以下操作：
①废弃前面BasicLock备份的对象头信息。
②正式启动重量级锁。
启动过程分为两步：首先通过inflate()方法进行锁膨胀，其目的是获得对象的ObjectMonitor。然后使用enter()方法尝试进入该锁。
在enter()方法调用中，线程很可能在操作系统层面被挂起。如果是这样，线程间切换和调度的程度就比较高了。
二、JVM对锁的优化(JVM层优化)
从java6开始，JVM内部对内置锁的实现进行了一些优化，这些优化包括自旋、锁消除、锁粗化、偏向锁。这些优化仅在JVM的Server模式下起作用。
1.自旋锁
互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能带来了很大的压力； 同时，到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。
当前线程暂时无法获取锁，什么时候获取锁未知。于是系统或尝试去让当前线程做几个空循环（自旋的含义）；在经过几次循环后，如果获取锁，就直接进入到了临界区了。如果锁被占用的时间很短，自旋等待的效果就会非常好，反之，如果锁被占用的时间 很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有用的工作，反而会带来性能上的浪费
在JDK 1.6中引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定
2.锁粗化
如果一系列的连续操作都是对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。在这种情况下，虚拟机便会把所有的锁操作优化成对锁的一次请求，从而减少对锁的请求同步次数，这个操作叫做锁粗化。
public String concatString(String s1,String s2,String s3){ StringBuffer sb=new StringBuffer(); sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString(); }
3.锁消除
锁消除是指JIT编译器在运行时，将一些在代码上同步了但实际上不可能存在共享数据竞争的锁进行消除。
锁消除主要是根据逃逸分析技术来判定的，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其它线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无需进行了。
下面来看一个例子：
下面方法中，每个StringBuffer.append()方法都会进行同步，锁就是sb对象。JVM观察sb变量，会发现它的动态作用域被限制在concatString()方法内部，也就是说sb的所有引用永远都不会逃逸到concatString()方法之外，其它线程无法访问到它。因此，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。
public String concatString(String s1, String s2, String s3) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString(); }
变量是否逃逸，对于JVM来是说需要使用数据流分析来确定，但是对于程序员而言，怎么会在明知道不存在数据争用的场景下使用同步呢？实际上许多同步并不是程序员自己加入的。
下面看另外一个例子：
//一段看起来没有同步的代码 public String concatString(String s1, String s2, String s3) { return s1 + s2 + s3; }
我们知道String是一个不可变的类，对字符串的连接操作总是会生成新的String对象来进行，因此javac编译器会对String的连接做自动转化。在jdk1.5之前会转化为StringBuffer对象的连续append()操作，jdk1.5及之后版本会转为StringBuilder对象的连续append()操作。如果当前使用的jdk1.5，则这段代码就等价于前一个例子中的代码了。
对比记忆：
锁粗化和锁消除可以对比来看，都是举的StringBuffer.append的例子。
锁粗化是在多线程场景下，连续三次加锁-解锁操作可以优化为仅一次加锁-解锁操作。
锁消除是在单线程场景下，连续三次加锁-解锁操作可以优化为不进行加锁-解锁。
参考：java锁优化
三、应用中提升锁性能的建议(应用层优化)
1.减小锁持有时间
应该尽可能地减少对某个锁的占用时间，以减少线程互斥的可能。
2.减小锁的粒度
①锁分段
减小锁粒度也是一种削弱多线程锁竞争的有效手段。这种技术典型的使用场景就是ConcurrentHashMap类的实现，它的内部进一步细分若干个小的hashMap，称为段，默认情况下，一个ConcurrentHashMap被进一步细分为16个段，所以在高并发下锁竞争被分散在了16个段上。
②读写锁
读写锁ReadWriteLock可以提高系统的性能。在读多写少的场合，使用读写锁可以有效提升系统的并发能力。
③锁分离
将读写锁的思想进一步延伸，就是锁分离。读写锁根据读写操作功能上的不同，进行了有效的锁分离。
典型案例：java.util.concurrent.LinkedBlockingQueue 中的 take() 和 put()
总结
1.锁的升级流程？
如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。
2.java1.6对锁进行了哪些优化？