本文主要是介绍谁说加锁性能差了？那是你不会优化！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在 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 操作使用了两把不同的锁。因为他们之间根本没有竞争关系，或者说，使用队列的数据结构，将原本耦合的业务分离了。
7. 总结
今天我们总结了一些锁的优化，有虚拟机的优化，比如偏向锁，轻量级锁，自旋锁，锁粗化，锁消除， 也有我们自己的优化策略，需要平时写代码的时候注意，比如减少锁的持有时间，减小锁的粒度，在读多写少的场合使用读写锁，尽量通过合理的设计分离锁。
总之，并发是门艺术。如何提高并发的性能是每个高级程序员的追求。
这篇关于谁说加锁性能差了？那是你不会优化！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
