转载请注明原文地址：http://www.cnblogs.com/ygj0930/p/6561264.html
锁的优化策略
编码过程中可采取的锁优化的思路有以下几种：
1：减少锁持有时间
例如：对一个方法加锁，不如对方法中需要同步的几行代码加锁；
2：减小锁粒度
例如：ConcurrentHashMap采取对segment加锁而不是整个map加锁，提高并发性；
3：锁分离
根据同步操作的性质，把锁划分为的读锁和写锁，读锁之间不互斥，提高了并发性。
4：锁粗化
这看起来与思路1有冲突，其实不然。思路1是针对一个线程中只有个别地方需要同步，所以把锁加在同步的语句上而不是更大的范围，减少线程持有锁的时间；
而锁粗化是指：在一个间隔性地需要执行同步语句的线程中，如果在不连续的同步块间频繁加锁解锁是很耗性能的，因此把加锁范围扩大，把这些不连续的同步语句进行一次性加锁解锁。虽然线程持有锁的时间增加了，但是总体来说是优化了的。
5：锁消除
锁消除是编译器做的事：根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程（即不会影响线程空间外的数据），那么可以认为这段代码是线程安全的，不必要加锁。
Java虚拟机中采取的锁优化策略：
1：偏向锁：锁对象偏向于当前获得它的线程，如果在接下来的没有被其他线程请求，则持有该锁的线程将不再需要进行同步操作（即：持有该锁的线程在接下来的执行中遇到同步块时不再需要lock和unlock了，直接执行即可）。当另一个线程申请该锁时，当前线程的偏向模式才会结束，让出该锁。
2：轻量级锁：syncrhoized的底层实现是通过监视器monitor来控制的，而monitorenter与monitorexit这两个原语是依赖操作系统互斥(mutex)来实现的。
互斥会导致线程挂起，并在较短的时间内又需要重新调度回原线程的，较为消耗资源。轻量级锁（Lightweight Locking）利用了CPU原语Compare-And-Swap(CAS，汇编指令CMPXCHG)，尝试在进入互斥前，进行补救，减少多线程进入互斥的几率。
如果偏向锁失败，那么系统会进行轻量级锁的操作，使用CAS操作来尝试加锁。如果轻量级锁失败，才调用系统级别的重量级锁（syncrhoized）来加锁。
3：自旋锁：当线程申请锁时，锁被占用，则让当前线程执行一个忙循环（自旋），看看持有锁的线程是否会很快释放锁。如果自旋后还没获得锁，才进入同步阻塞状态；
3.1：自适应自旋：自旋的线程自旋的时间为同一个锁上一次线程自旋并获得锁的耗时。如果对于这个锁，自旋很少有成功的，就不自旋了，避免浪费CPU资源。
为了尽量避免使用重量级锁（操作系统层面的互斥），JVM首先会尝试轻量级锁，轻量级锁会尝试使用CAS操作来获得锁，如果轻量级锁获得失败，说明存在竞争。但是也许很快就能获得锁，就会尝试自旋锁，将线程做几个空循环，每次循环时都不断尝试获得锁。如果自旋锁也失败，那么只能升级成重量级锁。
首先说一下锁的优化策略。
1，自旋锁
自选锁其实就是在拿锁时发现已经有线程拿了锁，自己如果去拿会阻塞自己，这个时候会选择进行一次忙循环尝试。也就是不停循环看是否能等到上个线程自己释放锁。这个问题是基于一个现实考量的：很多拿了锁的线程会很快释放锁。因为一般敏感的操作不会很多。当然这个是一个不能完全确定的情况，只能说总体上是一种优化。
举个例子就好比一个人要上厕所发现厕所里面有人，他可以：1，等一小会。2，跑去另外的地方上厕所。等一小会不一定能等到前一个人出来，不过如果跑去别的厕所的花费的时间肯定比等一小会结果前一个人出来了长。当然等完了结果那个人没出来还是要跑去别的地方上厕所这是最慢的。
然后是基于这种做法的一个优化：自适应自旋锁。也就是说，第一次设置最多自旋10次，结果在自旋的过程中成功获得了锁，那么下一次就可以设置成最多自旋20次。道理是：一个锁如果能够在自旋的过程中被释放说明很有可能下一次也会发生这种事。那么就更要给这个锁某种“便利”方便其不阻塞得锁（毕竟快了很多）。同样如果多次尝试的结果是完全不能自旋等到其释放锁，那么就说明很有可能这个临界区里面的操作比较耗时间。就减小自旋的次数，因为其可能性太小了。
2，锁粗化
试想有一个循环，循环里面是一些敏感操作，有的人就在循环里面写上了synchronized关键字。这样确实没错不过效率也许会很低，因为其频繁地拿锁释放锁。要知道锁的取得（假如只考虑重量级MutexLock）是需要操作系统调用的，从用户态进入内核态，开销很大。于是针对这种情况也许虚拟机发现了之后会适当扩大加锁的范围（所以叫锁粗化）以避免频繁的拿锁释放锁的过程。
3，锁消除
通过逃逸分析发现其实根本就没有别的线程产生竞争的可能（别的线程没有临界量的引用），而“自作多情”地给自己加上了锁。有可能虚拟机会直接去掉这个锁。
4，偏向锁和轻量级锁
这两个锁既是一种优化策略，也是一种膨胀过程所以一起说。首先它们的关系是：最高效的是偏向锁，尽量使用偏向锁，如果不能（发生了竞争）就膨胀为轻量级锁，这样优化的效率不如原来高不过还是一种优化（对比重量级锁而言）。所以整个过程是尽可能地优化。
首先说说偏向锁。
HotSpot的研究人员发现大多数情况下虽然加了锁，但是没有竞争的发生，甚至是同一个线程反复获得这个锁。那么偏向锁就为了针对这种情况。
举个例子，一个仓库管理员管着钥匙，然而每一次都是老王去借，仓库管理员于是就认识了老王，直接和他说，“行，你直接拿就是不用填表格了我记得你”。
讲一下偏向锁的具体过程。首先JVM要设置为可用偏向锁。然后当一个进程访问同步块并且获得锁的时候，会在对象头和栈帧的锁记录里面储存取得偏向锁的线程ID。
下一次有线程尝试获取锁的时候，首先检查这个对象头的MarkWord是不是储存着这个线程的ID。如果是，那么直接进去而不需要任何别的操作。如果不是，那么分为两种情况。1，对象的偏向锁标志位为0（当前不是偏向锁），说明发生了竞争，已经膨胀为轻量级锁，这时使用CAS操作尝试获得锁（这个操作具体是轻量级锁的获得锁的过程下面讲）。2，偏向锁标志位为1，说明还是偏向锁不过请求的线程不是原来那个了。这时只需要使用CAS尝试把对象头偏向锁从原来那个线程指向目前求锁的线程。这种情况举个例子就是老王准备退休了，他儿子接替他来拿钥匙，于是仓库管理员认识了他儿子，他儿子每次来也不用登记注册了。
这个CAS失败了呢？首先必须明确这个CAS为什么会失败，也就是说发生了竞争，有别的线程和它抢锁并且抢赢了，那么这个情况下，它就会要求撤销偏向锁（因为发生了竞争）。接着它首先暂停拥有偏向锁的线程，检查这个线程是否是个活动线程，如果不是，那么好，你拿了锁但是没在干事，锁还记录着你，那么直接把对象头设置为无锁状态重新来过。如果还是活动线程，先遍历栈帧里面的锁记录，让这个偏向锁变为无锁状态，然后恢复线程。
再说轻量级锁。这是偏向锁膨胀之后的产物。
加锁的过程：JVM在当前线程的栈帧中创建用于储存锁记录的空间（LockRecord），然后把MarkWord放进去，同时生成一个叫Owner的指针指向那个加锁的对象，同时用CAS尝试把对象头的MarkWord成一个指向锁记录的指针。成功了就拿到了锁。那么失败了呢？失败了的说法比较多。主流有《深入理解JVM》的说法和《并发编程的艺术》的说法。
《深入理解JVM》的说法：
失败了，去查看MarkWord的值。有2种可能：1，指向当前线程的指针，2，别的值。
如果是1，那么说明发生了“重入”的情况，直接当做成功获得锁处理。
其实这个有个疑问，为什么获得锁成功了而CAS失败了，这里其实要牵扯到CAS的具体过程：先比较某个值是不是预测的值，是的话就动用原子操作交换（或赋值），否则不操作直接返回失败。在用CAS的时候期待的值是其原本的MarkWord。发生“重入”的时候会发现其值不是期待的原本的MarkWord，而是一个指针，所以当然就返回失败，但是如果这个指针指向这个线程，那么说明其实已经获得了锁，不过是再进入一次。如果不是这个线程，那么情况2：
如果是2，那么发生了竞争，锁会膨胀为一个重量级锁（MutexLock）
《并发编程的艺术》的说法：
失败了直接自旋。期望在自旋的时间内获得锁，如果还是不能获得，那么开始膨胀，修改锁的MarkWord改为重量级锁的指针，并且阻塞自己。
解锁过程：（那个拿到锁的线程）用CAS把MarkWord换回到原来的对象头，如果成功，那么没有竞争发生，解锁完成。如果失败，表示存在竞争（之前有线程试图通过CAS修改MarkWord），这时要释放锁并且唤醒阻塞的线程。