jdk1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。
每次设置锁，都需要操作系统的配合，需要操作系统在内核中维护一个Mutex（互斥量）的东西。这将带来线程阻塞，切换，消耗掉很大的性能。所以需要少用锁为好。
Account account = ...
synchronized(account){
...临界区的代码...
}
偏向锁
当此时此刻没有其他线程来进入临界区时，虚拟机可以不用跟操作系统协商互斥量，也就不用从用户态进入核心态，再从核心态返回用户态。而是去看了看account对象的所谓“对象头”，其中有个叫做Mark Word的东西，似乎是个什么数据结构， 里边有几个标识位，还有其他数据。
因为当前没有其他线程，于是虚拟机使用CAS操作把当前的线程ID记录到了这个Mark Word当中，修改了标识位，然后就可以执行代码了。
如果当此线程第二次进入临界区时，虚拟机只需要将比较线程ID即可，如果相等，直接进就好了。
这就是偏向锁，在没有别的线程竞争的时候，一直偏向当前线程，可以让此线程一直执行下去。
轻量级锁
当两个线程一块来竞争，进入临界区时，锁会升级成轻量级锁。要不然获得锁的线程一直执行，没有获得的锁一直进不去。
升级为轻量级锁后，虚拟机把锁对象account恢复成无锁状态，在两个线程的栈帧中各自分配了一个空间，叫做Lock Record， 把锁对象account的Mark Word在我们俩这里各自复制了一份，叫做Displaced Mark Word。
然后选择一个线程的Lock Record的地址使用CAS放到了Mark Word当中，并且把锁标志位改为00， 这其实就意味着已经获得了这个轻量级的锁了，可以继续进入临界区执行。
没有获得锁的线程，还是不阻塞，虚拟机让他自旋几次，等待一会儿。
等到获得锁的线程退出临界区，释放锁的时候，需要把这个Displaced markd word 使用CAS复制回去。接下来另一个线程就可以加锁了。
即使是出现了竞争，想获得锁的线程只要自旋几次，等待一会儿，锁就可能释放了。
很明显，如果没有竞争或者轻度的竞争，轻量级锁仅仅使用CAS操作和Lock record就避免了重量级互斥锁的开销，对JVM来说，确实是个好主意。
重量级锁
当想获取锁的线程，自旋太多次，还是没得到锁，就太浪费CPU了，升级为重量级锁！
这个重量级锁需要操作系统的帮忙，依赖操作系统底层的Mutex Lock。
这也是synchronized的原理：
虚拟机创建了一个monitor 对象， 把这个对象的地址更新到了Mark word当中。
Monitor record是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联（对象头的MarkWord中的LockWord指向monitor的起始地址），同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。
此时，没有获得锁的线程，只有进入阻塞状态。
设置了偏向锁和轻量级锁，就是为了避免阻塞，避免操作系统的介入， 这两种锁无非就是针对这两种情况：
偏向锁： 通常只有一个线程在临界区执行
轻量级锁： 可以有多个线程交替进入临界区，在竞争不激烈的时候，稍微自旋等待一下就能获得锁。
至于重量级锁，也是我最为期待的锁，那就是出现了激烈的竞争，去阻塞休息了。
参考：https://mp.weixin.qq.com/s/ohloH-32u6iJeSsU8cdjxA
锁优化
线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力。同时我们发现在许多应用上面，对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。
何谓自旋锁？
所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。怎么等待呢？执行一段无意义的循环即可（自旋）。
自旋等待不能替代阻塞，先不说对处理器数量的要求（多核，貌似现在没有单核的处理器了），虽然它可以避免线程切换带来的开销，但是它占用了处理器的时间。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好，反之，自旋的线程就会白白消耗掉处理的资源，它不会做任何有意义的工作，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。所以说，自旋等待的时间（自旋的次数）必须要有一个限度，如果自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。
自旋锁在JDK 1.4.2中引入，默认关闭，但是可以使用-XX:+UseSpinning开开启，在JDK1.6中默认开启。同时自旋的默认次数为10次，可以通过参数-XX:PreBlockSpin来调整；
如果通过参数-XX:preBlockSpin来调整自旋锁的自旋次数，会带来诸多不便。假如我将参数调整为10，但是系统很多线程都是等你刚刚退出的时候就释放了锁（假如你多自旋一两次就可以获取锁），你是不是很尴尬。于是JDK1.6引入自适应的自旋锁，让虚拟机会变得越来越聪明。
适应自旋锁
JDK 1.6引入了更加聪明的自旋锁，即自适应自旋锁。所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。它怎么做呢？线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。
有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。
锁消除
为了保证数据的完整性，我们在进行操作时需要对这部分操作进行同步控制，但是在有些情况下，JVM检测到不可能存在共享数据竞争，这是JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。
如果不存在竞争，为什么还需要加锁呢？所以锁消除可以节省毫无意义的请求锁的时间。变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是对于我们程序员来说这还不清楚么？我们会在明明知道不存在数据竞争的代码块前加上同步吗？但是有时候程序并不是我们所想的那样？我们虽然没有显示使用锁，但是我们在使用一些JDK的内置API时，如StringBuffer、Vector、HashTable等，这个时候会存在隐形的加锁操作。比如StringBuffer的append()方法，Vector的add()方法：
public void vectorTest(){
Vector<String> vector = new Vector<String>();
for(int i = 0 ; i < 10 ; i++){
vector.add(i + "");
}
System.out.println(vector);
}在运行这段代码时，JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外，所以JVM可以大胆地将vector内部的加锁操作消除。
锁粗化
我们知道在使用同步锁的时候，需要让同步块的作用范围尽可能小—仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能缩小，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。
在大多数的情况下，上述观点是正确的，LZ也一直坚持着这个观点。但是如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗话的概念。
锁粗话概念比较好理解，就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。如上面实例：vector每次add的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到for循环之外。
乐观锁和悲观锁的区别 （读取频繁使用乐观锁，写入频繁使用悲观锁）
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
本质上，数据库的乐观锁做法和悲观锁做法主要就是解决下面假设的场景，避免丢失更新问题：
一个比较清楚的场景
下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题：
假设当当网上用户下单买了本书，这时数据库中有条订单号为001的订单，其中有个status字段是’有效’,表示该订单是有效的；
后台管理人员查询到这条001的订单，并且看到状态是有效的
用户发现下单的时候下错了，于是撤销订单，假设运行这样一条SQL: update order_table set status = ‘取消’ where order_id = 001;
后台管理人员由于在b这步看到状态有效的，这时，虽然用户在c这步已经撤销了订单，可是管理人员并未刷新界面，看到的订单状态还是有效的，于是点击”发货”按钮，将该订单发到物流部门，同时运行类似如下SQL，将订单状态改成已发货:update order_table set status = ‘已发货’ where order_id = 001
观点1：只有冲突非常严重的系统才需要悲观锁；“所有悲观锁的做法都适合于状态被修改的概率比较高的情况，具体是否合适则需要根据实际情况判断。”，表达的也是这个意思，不过说法不够准确；的确，之所以用悲观锁就是因为两个用户更新同一条数据的概率高，也就是冲突比较严重的情况下，所以才用悲观锁。
观点2：最后提交前作一次select for update检查，然后再提交update也是一种乐观锁的做法，的确，这符合传统乐观锁的做法，就是到最后再去检查。但是wiki在解释悲观锁的做法的时候，’It is not appropriate for use in web application development.’， 现在已经很少有悲观锁的做法了，所以我自己将这种二次检查的做法也归为悲观锁的变种，因为这在所有乐观锁里面，做法和悲观锁是最接近的，都是先select for update，然后update
在实际应用中我们在更新数据的时候，更严谨的做法是带上更新前的“状态”，如
update order_table set status = ‘取消’ where order_id = 001 and status = ‘待支付’ and ..........;
update order_table set status = ‘已发货’ where order_id = 001 and status = ‘已支付’ and ..........;
然后在业务逻辑代码里判断更新的记录数，为0说明数据库已经被更新了，否则是正常的。