图解：为什么非公平锁的性能更高？

在 Java 中 synchronized 和 ReentrantLock 默认使用的都是非公平锁，而它们采用非公平锁的原因都是一致的，都是为了提升程序的性能。那为什么非公平锁就能提升性能呢？接下来我们一起来看。

非公平锁

非公平锁：每个线程获取锁的顺序是随机的，并不会遵循先来先得的规则，任何线程在某时刻都有可能直接获取并拥有锁。 这就好比磊哥去加油，到了加油站之后发现前面有人在加，于是我就在车里刷起了抖音，过了一会，前面的车加完油走了，但磊哥没注意到，还在车里愉快的刷着抖音。然而此时加油站又来了一辆车，发现有空闲的油枪，于是就抢先在磊哥之前把油加了。这里的油枪就是锁，没有按照到达的先后顺序得到油枪，这就是非公平锁。

公平锁

公平锁：每个线程获取锁的顺序是按照线程访问锁的先后顺序获取的，最前面的线程总是最先获取到锁。 这就好像上高速排队过收费站一样，所有的车要排队等待通行，最先来的车最先通过收费站。

性能对比

公平锁和非公平锁的性能测试结果如下，以下测试数据来自于《Java并发编程实战》：

从上述结果可以看出，使用非公平锁的吞吐率（单位时间内成功获取锁的平均速率）要比公平锁高很多。

性能分析

以上测试数据虽然说明了结果，但并不能说明为什么非公平锁的性能会更高？所以，接下来，我们通过分析公平锁和非公平的执行流程，来得到这个问题的答案。

公平锁执行流程

获取锁时，先将线程自己添加到等待队列的队尾并休眠，当某线程用完锁之后，会去唤醒等待队列中队首的线程尝试去获取锁，锁的使用顺序也就是队列中的先后顺序，在整个过程中，线程会从运行状态切换到休眠状态，再从休眠状态恢复成运行状态，但线程每次休眠和恢复都需要从用户态转换成内核态，而这个状态的转换是比较慢的，所以公平锁的执行速度会比较慢。

用户态 & 内核态

用户态（User Mode）：当进程在执行用户自己的代码时，则称其处于用户运行态。内核态（Kernel Mode）：当一个任务（进程）执行系统调用而陷入内核代码中执行时，我们就称进程处于内核运行态，此时处理器处于特权级最高的内核代码中执行。

为什么分内核态和用户态？

假设没有内核态和用户态之分，程序就可以随意读写硬件资源了，比如随意读写和分配内存，这样如果程序员一不小心将不适当的内容写到了不该写的地方，很可能就会导致系统崩溃。

而有了用户态和内核态的区分之后，程序在执行某个操作时会进行一系列的验证和检验之后，确认没问题之后才可以正常的操作资源，这样就不会担心一不小心就把系统搞坏的情况了，也就是有了内核态和用户态的区分之后可以让程序更加安全的运行，但同时两种形态的切换会导致一定的性能开销。

非公平锁执行流程

当线程获取锁时，会先通过 CAS 尝试获取锁，如果获取成功就直接拥有锁，如果获取锁失败才会进入等待队列，等待下次尝试获取锁。这样做的好处是，获取锁不用遵循先到先得的规则，从而避免了线程休眠和恢复的操作，这样就加速了程序的执行效率。

比如前几天磊哥去一个小营业厅办理网络移机的业务，去了之后发现前面有人在办业务，于是磊哥就告诉前面（办理业务）的小姐姐，“我门口休息一下，您等会办理完业务，麻烦去门口叫一下我”，小姐姐人也比较好，一口就答应下来了。

但在小姐姐办完业务之后叫我，和我回到柜台办理业务之间，是有一段空闲时间的，这和等待队列中的线程被唤醒和恢复执行之间是有一段空闲时间是一样的，而在这个空闲的时间中，营业厅又来了一个老李头来交话费，等老李交完话费，我恰好也刚回来可以直接办理业务了，这样就是一个“三赢”的局面。

老李头不用排在我后面等着缴话费，我也不用等老李头交完话费再办理移机，而且在单位时间内提高了营业员办理业务的效率，她也能早早的回家，这就是所谓的“三赢”。在更短的时间内执行更多的任务，这就是非公平锁的优势。

总结

本文我们介绍了公平锁和非公平锁的定义以及执行流程，从二者执行流程的细节可以看出，非公平锁因为不用按（顺）序执行，所以后来的锁也可以直接尝试获得锁，没有了阻塞和恢复执行的步骤，所以它的性能会更高。