大白话聊聊Java并发面试问题之公平锁与非公平锁是啥？【石杉的架构笔记】

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）

周一至周五早8点半！精品技术文章准时送上！

1、写在前面

上篇文章（大白话聊聊Java并发面试问题之谈谈你对AQS的理解？）聊了一下java并发包中的AQS的工做原理，也间接说明了ReentrantLock的工做原理。

这篇文章接着来聊一个话题，java并发包中的公平锁与非公平锁有啥区别？

2、什么是非公平锁？

先来聊聊非公平锁是啥，如今你们先回过头来看下面这张图。

如上图，如今线程1加了锁，而后线程2尝试加锁，失败后进入了等待队列，处于阻塞中。而后线程1释放了锁，准备来唤醒线程2从新尝试加锁。

注意一点，此时线程2可还停留在等待队列里啊，还没开始尝试从新加锁呢！

然而，不幸的事情发生了，这时半路杀出个程咬金，来了一个线程3！线程3忽然尝试对ReentrantLock发起加锁操做，此时会发生什么事情？

很简单！线程2还没来得及从新尝试加锁呢。也就是说，还没来得及尝试从新执行CAS操做将state的值从0变为1呢！线程3冲上来直接一个CAS操做，尝试将state的值从0变为1，结果还成功了！

一旦CAS操做成功，线程3就会将“加锁线程”这个变量设置为他本身。给你们来一张图，看看这整个过程：

明明人家线程2规规矩矩的排队领锁呢，结果你线程3不守规矩，线程1刚释放锁，不分青红皂白，直接就跑过来抢先加锁了。

这就致使线程2被唤醒事后，从新尝试加锁执行CAS操做，结果毫无疑问，失败！

缘由很简单啊！由于加锁CAS操做，是要尝试将state从0变为1，结果此时state已是1了，因此CAS操做必定会失败！

一旦加锁失败，就会致使线程2继续留在等待队列里不断的等着，等着线程3释放锁以后，再来唤醒本身，真是可怜！先来的线程2竟然加不到锁！

一样给你们来一张图，体会一下线程2这无助的过程：

上述的锁策略，就是所谓的非公平锁！

若是你用默认的构造函数来建立ReentrantLock对象，默认的锁策略就是非公平的。

在非公平锁策略之下，不必定说先来排队的线程就就先会获得机会加锁，而是出现各类线程随意抢占的状况。

那若是要实现公平锁的策略该怎么办呢？也很简单，在构造ReentrantLock对象的时候传入一个true便可：

ReentrantLock lock = new ReentrantLock(true)

此时就是说让他使用公平锁的策略，那么公平锁具体是什么意思呢？

3、什么是公平锁？

我们从新回到第一张图，就是线程1刚刚释放锁以后，线程2还没来得及从新加锁的那个状态。

一样，这时假设来了一个线程3，忽然杀出来，想要加锁。

若是是公平锁的策略，那么此时线程3不会跟个愣头青同样盲目的直接加锁。

他会先判断一下：咦？AQS的等待队列里，有没有人在排队啊？若是有人在排队的话，说明我前面有兄弟正想要加锁啊！

若是AQS的队列里真的有线程排着队，那我线程3就不能跟个二愣子同样直接抢占加锁了。

由于如今我们是公平策略，得按照先来后到的顺序依次排队，谁先入队，谁就先从队列里出来加锁！

因此，线程3此时一判断，发现队列里有人排队，本身就会乖乖的排到队列后面去，而不会贸然加锁！

一样，整个过程咱们用下面这张图给你们直观的展现一下：

上面的等待队列中，线程3会按照公平原则直接进入队列尾部进行排队。

接着，线程2不是被唤醒了么？他就会从新尝试进行CAS加锁，此时没人跟他抢，他固然能够加锁成功了。

而后呢，线程2就会将state值变为1，同时设置“加锁线程”是本身。最后，线程2本身从等待队列里出队。

整个过程，参见下图：

这个就是公平锁的策略，过来加锁的线程所有是按照先来后到的顺序，依次进入等待队列中排队的，不会盲目的胡乱抢占加锁，很是的公平。

4、小结

好了，经过画图和文字分析，相信你们都明白什么是公平锁，什么是非公平锁了！

不过要知道java并发包里不少锁默认的策略都是非公平的，也就是可能后来的线程先加锁，先来的线程后加锁。

而通常状况下，非公平的策略都没什么大问题，可是你们要对这个策略作到内心有数，在开发的时候，须要本身来考虑和权衡是要用公平策略仍是非公平策略。

并发系列文章 ，正在更新中，欢迎关注：
大白话聊聊Java并发面试问题之volatile究竟是什么？
大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？
大白话聊聊Java并发面试问题之谈谈你对AQS的理解？
《大白话聊聊Java并发面试问题之公平锁与非公平锁是啥？》
《大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化？》 ，敬请期待

END

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授

推荐阅读：

一、拜托！面试请不要再问我Spring Cloud底层原理

二、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？

三、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

四、微服务架构如何保障双11狂欢下的99.99%高可用

五、兄弟，用大白话告诉你小白都能听懂的Hadoop架构原理

六、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

七、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

八、拜托，面试请不要再问我TCC分布式事务的实现原理坑爹呀！

九、【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？

十、拜托，面试请不要再问我Redis分布式锁的实现原理！

十一、【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提高10倍以上？

十二、亿级流量系统架构之如何支撑百亿级数据的存储与计算

1三、亿级流量系统架构之如何设计高容错分布式计算系统

1四、亿级流量系统架构之如何设计承载百亿流量的高性能架构

1五、亿级流量系统架构之如何设计每秒十万查询的高并发架构

1六、亿级流量系统架构之如何设计全链路99.99%高可用架构

1七、七张图完全讲清楚ZooKeeper分布式锁的实现原理

1八、大白话聊聊Java并发面试问题之volatile究竟是什么？

1九、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？

20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？