【JDK源码】从源码看公平锁和非公平锁得区别
从源码看公平锁和非公平锁得区别
一：理论解释
公平锁：ReentrantLock通过构造器参数设置为true就是公平锁。
非公平锁：synchronized 关键字，ReentrantLock默认就是非公平锁。
公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。
- 优点：所有的线程都能得到资源，不会饿死在队列中。
- 缺点：吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大。
非公平锁：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。
- 优点：可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。
- 缺点：你们可能也发现了，这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。
那为什么公平锁得性能吞吐量大，非公平锁得吞吐量小呢？
二：从源码角度解释
我们以ReentrantLock为例子解释公平锁和非公平锁差异。了解差异之前要知道ReentrantLock得实现原理AQS。
这个可以看我之前写得文章
https://editor.csdn.net/md/?articleId=116279057
ReentrantLock可以通过参数来确定是否为公平锁。
我们看到通过参数，创建公平锁和非公平锁。
对于Lock得接口得lock方法，公平锁和非公平锁有两种实现。
公平锁在加锁前，都会通过hasQueuedPredecessors()去判断AQS队列是否有线程等待，如果有不会执行后面得CAS获取锁，返回false,执行后面得入队操作。
在非公平锁中，获取锁得时候直接通过CAS尝试获取锁,获取失败后才执行acquire()方法，而不是和公平锁那样直接执行acquire()方法，而且在acquire()方法中，非公平锁也不会判断AQS队列中是否有线程等待获取锁。
直接就是CAS获取锁。
三：为什么非公平锁性能高
非公平锁通过CAS获取锁得性能高。非公平锁在有锁竞争得情况下每次都要执行,LockSupport.park();
来阻塞线程。
这样导致cpu上下文切换，导致性能比较低。
