Find me

对于ReentrantLock来说，它本身是Lock接口的一个实现，AQS只是它使用的工具，所以，我们的思路是从Lock的角度切入，搞清楚它是如何利用AQS实现这套锁机制的。

又已知Java的锁机制是参考MESA，所以我们推测J.U.C.中相关逻辑框架应与上面描述的基本一致。

基本上所有的操作都在其中了，所以在资源释放的时候只需要唤醒后续节点就可以，甚至，共享资源的释放过程在当初获取资源的时候都可能执行过一次了。

CLH队列最显著的特点是当前节点是在前置节点的lock字段上自旋，因此CLH队列的离队操作非常简洁。同时我们注意到，因为它要基于前置节点自旋，所有它获取到的前置节点永远都是非空的，这点在代码中表现为tail节点有默认值，且从不置空，类似的，在AQS中的head节点除了初始化前之外也都是非空的。CLH的入队操作和离队操作都比较简单，入队只需要通过CAS将tail指向当前节点，之后再前置节点的lock字段上自选，离队只需要将当前节点的lock状态置为false即可。一般为模板方法，包含扩展点和执行逻辑。

从这个角度讲，不管是排他锁还是共享锁，唤醒后续节点都是不会产生错误的，只是会影响性能。已知AQS队列是一个双链，入队操作本身的逻辑只是“在保证head初始化的前提下，通过CAS将新节点变成新的tail，同时维护双链表结构”，这部分代码是各种类型的acquire的公用的代码，其逻辑也比较简单，见下。tryAcquireNanos与tryAcquireSharedNanos是两个有超时时间的获取锁的方法，作为api层依然没什么逻辑，但我们注意到，带有超时时间的获取锁的方法，他们对中断的处理可能都是抛出异常。

volatile保证的是可见性和有序性对于volatile的读操作，注意到：可以理解为volatile变量在读之后会加上loadload屏障和loadstore屏障关于里面的fence：什么是IRIW和MCA（multi-copy atomicity）对于volatile字段的写操作，注意到两点：可以理解为volatile变量在写之前加入了loadstore和storestore，在写之后加入了storeload 总结一下：代码在hotspot/src/share/vm/interpreter

缓存一致性的问题通常需要硬件支持，会有硬件性能损耗，并且随着CPU数量的增加而增加，比如一个96核的服务器，每个CPU运行一个线程，每个线程访问同一个变量V，当其中一个线程对V做出修改时，会把消息广播到其余的CPU上，这会造成极大的硬件性能损耗，所以SMP技术很难组件大规模的CPU系统。，它相当于一个暂存数据，有了它之后，CPU发出对应的指令后，不再同步等待响应，而是先把数据写入StoreBuffer，之后继续执行后面的指令，之后择机将StoreBuffer的数据刷回缓存行。

// 注意这里是加了锁的，保证了线程安全// 避免多个线程同时对一个线程调用start，从而导致非NEW状态的线程再次startpublic synchronized void start() { /** * This method is not invoked for the main method thread or "system" * group threa...

Thread的构造器都是调用了init方法，所以我们来看一下init方法private void init(ThreadGroup g, Runnable target, String name, long stackSize, AccessControlContext acc, ...