☕【Java技术之旅】如何彻底认识AQS的原理(上篇)
📕每日一句📕
不知道大家喜不喜欢我新的写作风格呢，标题风格随便设计了一下，哈哈，希望给一些意见哦，
📕原子特性📕
在研究AQS框架时，会发现这个类很多地方都使用了CAS操作，在并发实现中CAS操作必须具备原子性，而且是硬件级别的原子性，Java被隔离在硬件之上，明显力不从心，这时为了能直接操作操作系统层面，肯定要通过用C++编写的native本地方法来扩展实现。
🚀Unsafe类的引入🚀
JDK提供了一个类来满足CAS的要求，sun.misc.Unsafe，从名字上可以大概知道它用于执行低级别、不安全的操作，AQS就是使用此类完成硬件级别的原子操作。最底层原子性处理器机器指令主要为：。
🤖Unsafe的定义🤖
Unsafe是一个很强大的类，它可以分配内存、释放内存、可以定位对象某字段的位置、可以修改对象的字段值、可以使线程挂起、使线程恢复、可进行硬件级别原子的CAS操作等等。
🤖Unsafe的使用🤖
但平时我们没有这么特殊的需求去使用它，而且必须在受信任代码（一般由JVM指定）中调用此类，例如直接 Unsafe unsafe = Unsafe.getUnsafe()；获取一个Unsafe实例是不会成功的，因为这个类的安全性很重要，设计者对其进行了如下判断，它会检测调用它的类是否由启动类加载器Bootstrap ClassLoader（它的类加载器为null）加载，由此保证此类只能由JVM指定的类使用。
当然可以通过反射绕过上面的限制，用下面的getUnsafeInstance方法可以获取Unsafe实例，这段代码演示了如何获取java对象的相对地址偏移量及使用Unsafe完成CAS操作，最终输出的是flag字段的内存偏移量及CAS操作后的值。分别为8和101。
Unsafe类让我们明白了java是如何实现对操作系统操作的，一般我们使用java是不需要在内存中处理java对象及内存地址位置的，但有的时候我们确实需要知道java对象相关的地址，于是我们使用Unsafe类，尽管java对其提供了足够的安全管理。
Java语言的设计者们极力隐藏涉及底层操作系统的相关操作，但此节我们本着对AQS框架实现的目的，不得不剖析了Unsafe类，因为AQS里面即是使用Unsafe获取对象字段的地址偏移量、相关原子操作来实现CAS操作的。
📕中断支持📕
线程的定义给我们提供了并发执行多个任务的方式，大多数情况下我们会让每个任务都自行执行结束，这样能保证事务的一致性，但是有时我们希望在任务执行中取消任务，使线程停止。
🚀中断的类型🚀
Java也没有提供任何可靠的方法终止线程的执行。线程调度策略中有抢占式和协作式两个概念，与之类似的是中断机制也有协作式和抢占式。
历史上Java曾经使用stop()方法终止线程的运行，他们属于抢占式中断。但它引来了很多问题，早已被JDK弃用。
stop()方法则意味着将释放该线程所持的所有锁，而且锁的释放不可控。即刻将抛出ThreadDeath异常，不管程序运行到哪里，但它不总是有效，如果存在被终止线程的锁竞争；
🚀抢占式中断🚀
第一点，将导致数据一致性问题，这个很好理解，一般数据加锁就是为了保护数据的一致性，而线程停止伴随所持锁的释放，很可能导致被保护的数据呈现不一致性，最终导致程序运算出现错误。
第二点，比较模糊，它要说明的问题就是可能存在某种情况stop()方法不能及时终止线程，甚至可能终止不了线程。
看如下代码会发生什么情况，看起来线程mt因为执行了stop()方法将停止，按理来说就算execute方法是一个死循环，只要执行了stop()方法线程将结束，无限循环也将结束。
其实不然，因为我们在execute方法使用了synchronized修饰，同步方法表示在执行execute时将对mt对象进行加锁，另外，Thread的stop()方法也是同步的，于是在调用mt线程的stop()方法前必须获取mt对象锁，但mt对象锁被execute方法占用，且不释放，于是stop()方法永远获取不了mt对象锁，最后得到一个结论，使用stop()方法停止线程不可靠，它未必总能有效终止线程。
}
🚀协作式中断🚀
经历了很长时间的发展，Java最终选择用一种协作式的中断机制实现中断。协作式中断的原理很简单，其核心是先对中断标识进行标记，某线程设置某线程的中断标识位，被标记了中断位的线程在适当的时间节点会抛出异常，捕获异常后做相应的处理。实现协作中断有三个要点需要考虑：
在Java层面实现轮询中断标识还是在JVM中实现；
轮询的颗粒度的控制，一般颗粒度要尽量小周期尽量短以保证响应的及时性；
轮询的时间节点的选择，其实就是在哪些方法里面轮询，例如，JVM将Thread类的wait()、sleep()、join()等方法都实现中断标识的轮询操作。
中断标识放在哪里？中断是针对线程实例而言，从Java层面上看，标识变量放到线程中肯定再合适不过了，但由于由JVM维护，所以中断标识具体由本地方法维护。在Java层面仅仅留下几个API用于操作中断标识，如下。
通过interrupt()方法设置中断标识：
如果在非阻塞线程则仅仅只是改变了中断状态，线程将继续往下运行，
如果在可取消阻塞线程中，如正在执行sleep()、wait()、join()等方法的线程则会因为被设置了中断状态而抛出InterruptedException异常，程序对此异常捕获处理。（Lock也有相关的LockInterrupt方法）
第一是轮询在哪个层面实现，这个没有特别的要求，在实际中只要不出现逻辑问题，在Java层面或JVM层面实现都是可以的。例如，常用的线程睡眠、等待等操作是通过JVM实现，而AQS框架里面的中断则放到Java实现（AQS和用户自定义的判断），不管在哪个层面上去实现，
在轮询过程中都一定要能保证不会产生阻塞 。第二是要保证轮询的颗粒度尽可能的小周期尽可能短，这关系到中断响应的速度。
第三点是关于轮询的时间节点的选取。
针对三要点来看看AQS框架中是如何支持中断的，主要在等待获取锁的过程中提供中断操作，下面是伪代码。只需增加加红加粗部分逻辑即可实现中断支持，在循环体中每次循环都对当前线程中断标识位进行判断，一旦检查到线程被标记为中断则抛出InterruptedException异常，高层代码对此异常捕获处理即完成中断处理。
总结起来就是AQS框架获取锁的中断机制是在Java层面实现的，
}
判断线程是否处于中断状态其实很简单，只需使用Thread.interrupted()操作，如果为true则说明线程处于中断位，并清除中断位。至此AQS实现了支持中断的获取锁操作。
🚀中断的总结🚀
从java发展过程分析了抢占式中断及协作式中断，由于抢占式存在一些缺陷现在已不推荐使用，而协作式中断作为推荐做法，尽管在响应时间较长，但其具有无可比拟的优势。
协作式中断我们可以在JVM层面实现，同样也可以在Java层面实现，例如AQS框架的中断即是在Java层面实现，不过如果继续深究是因为Java留了几个API供我们操作线程的中断标识位，这才使Java层面实现中断操作得以实现。
对于java的协作式中断机制有人肯定有人批评，批评者说java没有抢占式中断机制，且协作式中断机制迫使开发者必须维护中断状态，迫使开发者必须处理InterruptedException。
但肯定者则认为，虽然协作式中断机制推迟了中断请求的处理，但它为开发人员提供更灵活的中断处理策略，响应性可能不及抢占式，但程序健壮性更强。
📕阻塞/唤醒📕
根据前面的线程阻塞与唤醒小节知道，目前在Java语言层面能实现阻塞唤醒的方式一共有三种：suspend与resume组合、wait与notify组合、park与unpark组合。
suspend与resume因为存在无法解决的竟态问题而被Java废弃。
wait与notify也存在竟态条件，wait必须在notify之前执行，假如一个线程先执行notify再执行wait将可能导致一个线程永远阻塞，如此一来，必须要提出另外一种解决方案
park与unpark组合，它位于juc包下，应该也是因为当时编写juc时发现java现有方式无法解决问题而引入的新阻塞唤醒方式，由于park与unpark使用的是许可机制，许可最大为1，所以unpark与park操作不会累加，而且unpark可以在park之前执行，如unpark先执行，后面park将不阻塞。
Java真正意义上的语言层面上的并发编程应该从并发专家Doug Lea领导的JSR-166开始，此规范请求向JCP提交了向Java语言中添加并发编程工具，即在jdk中添加java.util.concurrent工具包供开发者使用，开发者可以轻松构建自己的同步器，而在此之前并发过程中同步都只能依靠JVM内置的管程。
AQS框架的阻塞和唤醒显然使用的是LockSupport类的park与unpark方法，分别调用的是Unsafe类的park与unpark本地方法。逻辑如下：
一条线程参与锁竞争，首先先尝试获取锁，失败的话创建节点并插入队列尾部，然后再次尝试获取锁，如若成功则不做其他任务处理直接返回，否则设置节点状态为待运行状态，最后使用LockSupport的park阻塞当前线程。
前驱节点运行完后将尝试唤醒后继节点，使用的即是LockSupport的unpark唤醒。
总的来说，java提供的juc并发工具包，在阻塞与唤醒操作方面由于suspend与resume存在各种各样问题，必须使用LockSupport中提供的方法操作。
AQS框架提供的另外一个优秀机制是锁获取超时的支持，当大量线程对某一锁竞争时可能导致某些线程在很长一段时间都获取不了锁，在某些场景下可能希望如果线程在一段时间内不能成功获取锁就取消对该锁的等待以提高性能，这时就需要用到超时机制。
在JDK1.5之前还没有juc工具，当时的并发控制职能通过JVM内置的synchronized关键词实现锁，但对一些特殊要求却力不从心，例如超时取消控制。
JDK1.5开始引入juc工具完美解决了此问题，而这正得益于并发基础框架AQS提供了超时的支持。
为了更精确地保证时间间隔统计的准确性，实现时使用了System.nanoTime()更为精确的方法，它能精确到纳秒级别。超时机制的思想就是在不断进行锁竞争的同时记录竞争的时间，一旦时间段超过指定的时间则停止轮询直接返回，返回前对等待队列中对应节点进行取消操作。往下看实现的逻辑，
上面正是在前面章节锁的获取逻辑中添加超时处理，核心逻辑是不断循环减去处理的时间消耗，一旦小于0就取消节点并跳出循环，其中有两点必须要注意，一个是真正的阻塞时间应该是扣除了竞争入队的时间后剩余的时间，保证阻塞事件的准确性，我们可以看到每次循环都会减去相应的处理时间；
另外一个是关于spinForTimeoutThreshold变量阀值，它是决定使用自旋方式消耗时间还是使用系统阻塞方式消耗时间的分割线，juc工具包作者通过测试将默认值设置为1000ns，即如果在成功插入等待队列后剩余时间大于1000ns则调用系统底层阻塞，否则不调用系统底层，取而代之的是仅仅让之在Java应用层不断循环消耗时间，属于优化的措施。
至此AQS框架在获取锁的过程中提供了超时机制，超时的支持让Java在并发方面提供了更完善的机制，更多的并发策略满足开发者更多需求。