谁说加锁性能差了？那是你不会优化！

本文主要是介绍谁说加锁性能差了？那是你不会优化！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在 JDK 1.6 之前，synchronized 性能令人担忧，但是 1.6 之后，JVM 团队针对 synchronized 做了很多的优化，让 synchroized 在性能层面相比较 ReentrantLock 不相上下。那么，JVM 团队做了哪些优化呢？

首先说，怎么才能优化？我们知道，“锁” 其实是互斥同步的具体实现，而互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要用户态转到内核态来完成。这些操作给系统的并发性能带来了很大的压力。

所以，优化的方向就是减少线程的阻塞，因为挂起线程和恢复线程需要切换到操作系统的内核状态。

Java 1.6 为了减少获得锁和释放锁带来的性能损耗，引入了 “偏向锁“ 和 ”轻量级锁“ ，在 Java SE 1.6 中，锁一共有4个状态，从低到高依次是：无锁状态，偏向锁状态，轻量级锁状态，重量级锁状态。这几个状态会随着竞争情况逐渐升级（即膨胀）。注意：锁升级之后不能降级（具体原因后面讲）。

偏向锁
轻量级锁
重量级锁
锁消除
锁粗化
除了虚拟机，程序员自己如何优化锁

1. 偏向锁

虚拟机的团队根据经验发现，大多数情况下，锁不仅不存在多线程竞争，而且总是有同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单的测试一下对象头的 “Mark Word” 里是否存储着指向当前线程的偏向锁。

如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下 Mark Word 中偏向锁的标识是否设置了1（表示当前还是偏向锁）：如果没有设置，则使用CAS 竞争锁；如果设置了，则尝试使用CAS 将对象头的偏向锁指向当前线程。

可以说，偏向锁的 “偏”，就是偏心的 “偏”，他的意思就是这个锁会偏向于第一个获得他的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要同步。

当有另外要给线程去尝试获取这个锁时，偏向模式宣告结束，后续的操作将升级为轻量级锁。

注意：偏向锁可以提高有同步但无竞争的程序性能，他同样有缺陷：如果程序中大多数的锁总是被多个不同的线程访问，那偏向模式就是多余的。1.6之后的虚拟机默认启用偏向锁，可以使用JVM参数来关闭：-XX：-UseBiasedLocking=false；程序将默认进入轻量级锁状态。

可以看到，Mark Word 是实现偏向锁的关键。而后面的轻量级锁也是通过这个实现的。

2. 轻量级锁

什么是轻量级锁呢？ “轻量级” 是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制称为 “重量级” 锁。首先需要强调一点，轻量级锁并不是用来代替重量级锁的，他的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能损耗。

线程在执行同步块之前，JVM 会先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头的 Mark Word 复制到锁记录中，官方称为 Displaced Mark Word. 然后线程尝试使用CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。

如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便会尝试使用自旋来获取锁，注意：这里线程并没有挂起自己，而是通过一定次数的自旋（默认10次，可以使用 -XX：PreBlockSpin 修改），防止切换到内核态导致的开销。

如果有2个以上的线程争用同一把锁，那么轻量级锁将会失效，升级到重量级锁。

那么为什么升级到重量级锁之后不能降级呢？假设一下：如果锁升级到重量级之后，拿到锁的某个线程被阻塞了，等待了很久，那么轻量级线程将会一直自旋等待，消耗CPU性能。所以，在升级到重量级锁后，就不能降级了，防止轻量级锁自旋消耗CPU。

可以看到偏向锁和轻量级锁的差别，偏向锁在第一个线程拿到锁之后，将把线程ID 存储在对象头中，后面的所有操作都不是同步的，相当于无锁。而轻量级锁，每次获取锁的时候还是需要使用CAS来修改对象头的记录，在没有线程竞争的情况下，这个操作是很轻量的，不需要使用操作系统的互斥机制。

3. 重量级锁

相比较轻量级锁是通过自旋来获取锁的，重量级锁则是通过操作系统将线程切换到内核态并阻塞来实现的。代价十分高昂。

下面看看各个锁的优缺点对比：

什么时候使用什么锁，大家可以看看。

4. 锁消除

什么是锁消除呢？指的是 JIT 编译器在运行时，对一些没有必要同步的代码却同步了的锁进行消除。可以说时一种彻底的锁优化。通过锁消除，可以节省毫无意义的请求锁时间。

那么你们一定会问，谁会这么傻，不需要同步还去同步啊？

请看下面的代码：

public String[] createStrings(String[] args) {Vector<String> v = new Vector<>();for (int i = 0; i < 100; i++) {v.add(Integer.toString(i));}return v.toArray(new String[]{});}

注意：v 变量只在这一个方法中使用，只是一个单纯的局部变量，分配在栈中，也就没有线程安全的说法，任何同步都是没有必要的，而Vector 的add 操作都是同步的。所以虚拟机检测到这个情况，会将锁去除。

锁消除涉及一个技术：逃逸分析。所谓逃逸分析就是观察某一个变量十分会逃出某一个作用域。在本例中，变量v没有逃出函数外，如果函数返回的不是 string 数组，而是 v 本身，那么就任务 v 逃逸出了当前函数。也就是说 v 可能被其他线程访问。如果是这样，虚拟机就不能消除 v 的锁操作。

5. 锁粗化

原则上，我们在编写代码的时候，总是推荐将同步块尽可能的小。这样是为了使得需要同步的操作数量小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。

大部分情况下，这个原则是正确的。如果如果一系列连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁的同步操作也会导致不必要的性能损耗。

如果虚拟机探测到很多零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部。即加大了同步块。

6. 除了虚拟机，程序员自己如何优化锁

减小锁的持有时间
减小锁的粒度
使用读写锁替换独占锁
锁分离

减小锁的持有时间

其实这个很简单，你的锁持有的时间长，后面的线程等待的时间就长，一个线程等待1秒，10000个线程就多等待了10000秒，因此，只在必要时进行同步，这样就能明显减少线程持有锁的时间。提高系统的吞吐量。

减小锁的粒度

这个和我们上面说的虚拟机帮助我们粗化时反的。但是，我们说，大部分情况下，减小锁的粒度也削弱多线程竞争的有效手段，比如 ConcurrentHashMap，他只锁住了 Hash 桶中的某一个桶，不像HashTable 一样锁住整个对象。

使用读写锁替换独占锁

我们之前在说 Java 世界的三把锁的时候说哪三把锁，内置锁，重入锁，读写锁，就是我们现在说的读写锁 ReadWriteLock，使用读写锁来替代独占锁是减小锁粒度的一种特殊情况，在读多写少的场合，读写锁对系统性能是有好处的。可以有效提高系统的并发能力。因为读操作不会影响数据的完整性和一致性，就像 ConcurrentHashMap 的 get 方法一样，根本不需要加锁，这个时候又要说说 HashTable ，该容器连 get 方法都加锁。你可以想象一下。

锁分离

如果将读写锁进一步延伸，就是锁分离，读写锁根据读写操作功能的不同，进行了有效的分离。而 JDK 的 LinkedBlockingQueue 则是锁分离的最佳实践。在进行 take 操作和 put 操作使用了两把不同的锁。因为他们之间根本没有竞争关系，或者说，使用队列的数据结构，将原本耦合的业务分离了。