前言
JDK1.6版本花费了大量精力去实现各种锁优化，如适应性自旋，锁消除，锁粗化，轻量级锁，偏向锁等，这些技术都是为了在线程期间更高效的共享数据，以及解决竞争问题。
叙述
锁的分类
自旋锁
自选锁其实就是在拿锁时发现已经有线程拿了锁，自己如果去拿会阻塞自己，这个时候会选择进行一次忙循环尝试。也就是不停循环看是否能等到上个线程自己释放锁。这个问题是基于一个现实考量的：很多拿了锁的线程会很快释放锁。因为一般敏感的操作不会很多。当然这个是一个不能完全确定的情况，只能说总体上是一种优化。
举个例子就好比一个人要上厕所发现厕所里面有人，他可以：1，等一小会。2，跑去另外的地方上厕所。等一小会不一定能等到前一个人出来，不过如果跑去别的厕所的花费的时间肯定比等一小会结果前一个人出来了长。当然等完了结果那个人没出来还是要跑去别的地方上厕所这是最慢的。
然后是基于这种做法的一个优化：自适应自旋锁。也就是说，第一次设置最多自旋10次，结果在自旋的过程中成功获得了锁，那么下一次就可以设置成最多自旋20次。道理是：一个锁如果能够在自旋的过程中被释放说明很有可能下一次也会发生这种事。那么就更要给这个锁某种“便利”方便其不阻塞得锁（毕竟快了很多）。同样如果多次尝试的结果是完全不能自旋等到其释放锁，那么就说明很有可能这个临界区里面的操作比较耗时间。就减小自旋的次数，因为其可能性太小了。
偏向锁
首先JVM要设置为可用偏向锁。然后当一个进程访问同步块并且获得锁的时候，会在对象头和栈帧的锁记录里面储存取得偏向锁的线程ID。
下一次有线程尝试获取锁的时候，首先检查这个对象头的MarkWord是不是储存着这个线程的ID。如果是，那么直接进去而不需要任何别的操作。如果不是，那么分为两种情况。1，对象的偏向锁标志位为0（当前不是偏向锁），说明发生了竞争，已经膨胀为轻量级锁，这时使用CAS操作尝试获得锁（这个操作具体是轻量级锁的获得锁的过程下面讲）。2，偏向锁标志位为1，说明还是偏向锁不过请求的线程不是原来那个了。这时只需要使用CAS尝试把对象头偏向锁从原来那个线程指向目前求锁的线程。这种情况举个例子就是老王准备退休了，他儿子接替他来拿钥匙，于是仓库管理员认识了他儿子，他儿子每次来也不用登记注册了。
这个CAS失败了呢？首先必须明确这个CAS为什么会失败，也就是说发生了竞争，有别的线程和它抢锁并且抢赢了，那么这个情况下，它就会要求撤销偏向锁（因为发生了竞争）。接着它首先暂停拥有偏向锁的线程，检查这个线程是否是个活动线程，如果不是，那么好，你拿了锁但是没在干事，锁还记录着你，那么直接把对象头设置为无锁状态重新来过。如果还是活动线程，先遍历栈帧里面的锁记录，让这个偏向锁变为无锁状态，然后恢复线程。
偏向锁的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。在无竞争的情况下把整个同步都消除掉，能提高带有同步但无竞争的程序性能。但如果大多数锁总是被不同的线程访问，则偏向模式则是多余的。当有另外一个线程去尝试获取这个锁时，偏向模式就结束，根据锁对象是否处于被锁定的状态，撤销偏向后回复到未锁定（01）或轻量级锁定（00）。
轻量级锁
JVM在当前线程的栈帧中创建用于储存锁记录的空间（LockRecord），然后把MarkWord放进去，同时生成一个叫Owner的指针指向那个加锁的对象，同时用CAS尝试把对象头的MarkWord替换成一个指向锁记录的指针。成功了就拿到了锁。那么失败了呢？失败了的说法比较多。
轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量。在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。提升性能的依据是“对于绝大部分额情况下，在整个同步周期内都是不存在竞争的”，但有竞争的情况下，轻量级锁会比传统的重量级锁更慢。如果有两条以上的线程争用同一个锁，轻量级锁就不再有效，会膨胀成重量级锁（10）。
锁的优化
锁粗化
试想有一个循环，循环里面是一些敏感操作，有的人就在循环里面写上了synchronized关键字。这样确实没错不过效率也许会很低，因为其频繁地拿锁释放锁。要知道锁的取得（假如只考虑重量级MutexLock）是需要操作系统调用的，从用户态进入内核态，开销很大。于是针对这种情况也许虚拟机发现了之后会适当扩大加锁的范围（所以叫锁粗化）以避免频繁的拿锁释放锁的过程。
锁消除
通过逃逸分析发现其实根本就没有别的线程产生竞争的可能（别的线程没有临界量的引用），而“自作多情”地给自己加上了锁。有可能虚拟机会直接去掉这个锁。
锁分离
- 对锁功能进行分类
- 读写锁的实现：ReadWriteLock，读锁和读锁不互斥，读锁和写锁，写锁和写锁互斥。
- 阻塞链表队列的实现：LinkedBlockingQueue，put和take操作互不影响，不需要锁住整个链表，只需要take和put持有不同的锁即可。
减小锁粒度
- 大对象拆成小对象，降低锁竞争
- 提供偏向锁、轻量级锁成功率
- HashMap的同步实现：
- Collections.synchronizedMap(Map m)获得一个同步的hasnMap，其中get和put方法都被synchronized，每次只能被一个线程访问，效率低。
- ConcurrentHashMap通过减小锁粒度优化：
将HashMap底层的数组分段，分层若干个Segment，每次put、get操作只锁定一个Segment数组段，因此允许多线程同时访问ConcurrentHashMap，提供系统效率。
减少锁持有时间
只同步需要同步的代码块
减少锁持有时间
乐观认为不存在多线程竞争，首先尝试无竞争状态实现代码，如果执行时发现有竞争，退而求其次通知线程重试。
小结
感谢您的阅读~~