公平锁和非公平锁

在⼤多数情况下，锁的申请都是⾮公平的，也就是说，线程1⾸先请求锁A，接着线程2也请求了锁A。那么当锁A可⽤时，是线程1可获得锁还是线程2可获得锁呢？这是不⼀定的，系统只是会从这个锁的等待队列中随机挑选⼀个，因此不能保证其公平性。这就好⽐买票不排队，⼤家都围在售票窗⼝前，售票员忙的焦头烂额，也顾及不上谁先谁后，随便找个⼈出票就完事了，最终导致的结果是，有些⼈可能⼀直买不到票。⽽公平锁，则不是这样，它会按照到达的先后顺序获得资源。公平锁的⼀⼤特点是：它不会产⽣饥饿现象，只要你排队，最终还是可以等到资源的；synchronized关键字默认是有jvm内部实现控制的，是⾮公平锁。⽽ReentrantLock运⾏开发者⾃⼰设置锁的公平性。

1、为什么会有公平锁/⾮公平锁的设计为什么默认⾮公平？

1. 恢复挂起的线程到真正锁的获取还是有时间差的，从开发⼈员来看这个时间微乎其微，但是从CPU的⻆度来看，这个时间差存在的还是很明显的。所以⾮公平锁能更充分的利⽤CPU 的时间⽚，尽量减少 CPU 空闲状态时间。

2. 使⽤多线程很重要的考量点是线程切换的开销，当采⽤⾮公平锁时，当1个线程请求锁获取同步状态，然后释放同步状态，因为不需要考虑是否还有前驱节点，所以刚释放锁的线程在此刻再次获取同步状态的概率就变得⾮常⼤，所以就减少了线程的开销。

2、使⽤公平锁会有什么问题

公平锁保证了排队的公平性，⾮公平锁霸⽓的忽视这个规则，所以就有可能导致排队的⻓时间在排队，也没有机会获取到锁，这就是传说中的 “锁饥饿”

3、什么时候⽤公平？什么时候⽤⾮公平？

如果为了更⾼的吞吐量，很显然⾮公平锁是⽐较合适的，因为节省很多线程切换时间，吞吐量⾃然就上去了；否则那就⽤公平锁，⼤家公平使⽤。