阻塞锁与自旋锁

https://www.dazhuanlan.com/2020/02/08/5e3e409f40b9f/
在学习JAVA并发包的时候发现其底层的实现是通过AQS框架来完成的，而AQS框架中维护了一个CLH队列，CLH队列使用了CLH锁，因此上网搜了下这方面的内容，发现原来在并行编程中有这么多的锁类型，索性做个总结，此为本篇内容的缘由.

1. 阻塞锁

阻塞锁是指当线程尝试获取锁失败时，线程进入阻塞状态，直到接收信号后被唤醒.(线程的状态包括新建、就绪、运行、阻塞及死亡）在JAVA中，能够唤醒阻塞线程的操作包括Object.notify, Object.notifyAll, Condition.signal, LockSupport.unpark(JUC中引入）

阻塞锁的优点是在线程获取锁失败后，不会一直处于运行状态（占用CPU）， 因此在竞争激烈的情况下， 阻塞锁的性能将明显优于自旋锁

2. 自旋锁

自旋锁的特性是，当线程尝试获取锁失败时（锁已经被其它线程占用了），它不会将线程切换为沉睡状态，而是开启无限循环，不断地轮询锁的状态（这也是“自旋”的来历），当锁状态被更改时，获取到锁并进入临界区.

自旋锁本身并没有关注公平性、可重入性等特性，另外，由于自旋锁的实现需要不断轮询锁的状态，因此需要占用CPU，适用于临界区时间很短的场景. 自旋锁又可进一步细分为排队自旋锁(TicketLock)、MCS锁以及CLH锁， 其中排队自旋锁解决的是公平性的问题

排队自旋锁： 排队自旋锁关注的是公平性问题，每个线程在尝试获取锁的时候都会被分发唯一的一个号码，而锁本身提供了服务号服务，类似于现实生活中的排队叫号服务，每个线程都有个号码，锁对象每次叫一个号，拿到相应事情的线程获得锁. 排队自旋锁虽然解决了公平性问题，但由于所有的线程都在读写同一个变量(服务号），因此每一次读写操作都必须同步处理器缓存，会导致大量的总线流量

MCS锁：MCS锁采用了链表的形式对尝试获取锁失败的线程排队，MCS锁自旋的是自身的本地变量，它是显式的队列，有真实的后继节点.

CLH锁： CLH锁和MCS非常类似，但CLH锁自旋的是前驱节点的变量, 它是隐式的队列，没有真实的后继节点

关于自旋锁的实现代码可以参见这里

3. JUC中的相关实现

在java的并发包中，提供了LockSupport类，它提供了阻塞与唤醒的原语操作. 事实上，JUC中的AQS框架就是基于CLH队列实现，但是它还使用LockSupport类进行了改良，使原来的CLH自旋锁变成了阻塞锁. 使用LockSupport类实现CLH阻塞锁的代码可以参见这里

关于JUC中的AQS框架源码的分析，可以查看这里

参考文献

CLH锁学习： http://googi.iteye.com/blog/1736570

自旋锁的比较与实现： http://coderbee.net/index.php/concurrent/20131115/577

JAVA锁的系列文章： http://ifeve.com/java_lock_see1/

MCS锁的文章： https://www.ibm.com/developerworks/cn/linux/l-cn-mcsspinlock/

JUC系列文章：http://www.cnblogs.com/skywang12345/p/java_threads_category.html

示例代码

各种锁的实现示例: https://github.com/Essviv/spring/tree/master/src/main/java/com/cmcc/syw/concurrency/lock
Particle System Modules FAQRedis源码剖析