知名网站建设是哪家便宜,做房产的一般用哪个网站,sem和seo哪个工作好,沈阳企业定制网站建设Java AQS 核心数据结构-CLH 锁
什么是CLH锁
CLH 锁是对自旋锁的一种改进#xff0c;有效的解决了以上的两个缺点。 第一个是锁饥饿问题。在锁竞争激烈的情况下#xff0c;可能存在一个线程一直被其他线程”插队“而一直获取不到锁的情况。第二是性能问题。在实际的多处理上…Java AQS 核心数据结构-CLH 锁
什么是CLH锁
CLH 锁是对自旋锁的一种改进有效的解决了以上的两个缺点。 第一个是锁饥饿问题。在锁竞争激烈的情况下可能存在一个线程一直被其他线程”插队“而一直获取不到锁的情况。第二是性能问题。在实际的多处理上运行的自旋锁在锁竞争激烈时性能较差。 首先它将线程组织成一个队列保证先请求的线程先获得锁避免了饥饿问题。其次锁状态去中心化让每个线程在不同的状态变量中自旋这样当一个线程释放它的锁时只能使其后续线程的高速缓存失效缩小了影响范围从而减少了 CPU 的开销。
CLH 锁数据结构很简单类似一个链表队列所有请求获取锁的线程会排列在链表队列中自旋访问队列中前一个节点的状态。当一个节点释放锁时只有它的后一个节点才可以得到锁。CLH 锁本身有一个队尾指针 Tail它是一个原子变量指向队列最末端的 CLH 节点。每一个 CLH 节点有两个属性所代表的线程和标识是否持有锁的状态变量。当一个线程要获取锁时它会对 Tail 进行一个 getAndSet 的原子操作。该操作会返回 Tail 当前指向的节点也就是当前队尾节点然后使 Tail 指向这个线程对应的 CLH 节点成为新的队尾节点。入队成功后该线程会轮询上一个队尾节点的状态变量当上一个节点释放锁后它将得到这个锁。
下面用图来展示 CLH 锁从获取到释放锁的全过程。 CLH 锁初始化时会 Tail 会指向一个状态为 false 的空节点如图1所示。当 Thread 1下称 T1请求获取锁时Tail 节点指向 T1 对应的节点同时返回空节点。T1 检查到上一个节点状态为 false就成功获取到锁可以执行相应的逻辑了如图2所示。当 Thread 2下称 T2请求获取锁时Tail 节点指向 T2 对应的节点同时返回 T1 对应的节点。T2检查到上一个节点状态为 True无法获取到锁于是开始轮询上一个节点的状态如图3所示。当 T1 释放锁时会将状态变量置为 False如图4所示。T2 轮询到检查到上一个节点状态变为 False则获取锁成功如图5所示。 CLH 锁 Java 实现解析 1、节点中的状态变量为什么用 volatile 修饰可以不用 volatile 吗
使用 volatile 修饰状态变量不是为了利用 volatile 的内存可见性因为这个状态变量只会被持有该状态变量的线程写入只会被队列中该线程的后驱节点对应的线程读而且后者会轮询读取。因此可见性问题不会影响锁的正确性。以上面的例子为例T2 会不断轮询T1的状态变量T1 将它的状态变更为 False 时 T2 没有立即感知也没有关系。该状态变量最终会写回内存并被 T2 终感知到变更后的值。
但要实现一个可以在多线程程序中正确执行的锁还需要解决重排序问题。在《Java 并发编程实战》一书对于重排序问题是这么描述的在没有同步的情况下编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的调整。在缺乏足够同步的多线程程序中要想对内存操作的执行顺序进行判断几乎无法得到正确的结论。对于 Java synchronized 关键字提供的内置锁(又叫监视器)Java Memory Model下称 JMM规范中有一条 Happens-Before先行发生规则“一个监视器锁上的解锁发生在该监视器锁的后续锁定之前”因此 JVM 会保证这条规则成立。
而自定义互斥锁就需要自己保证这一规则的成立因此上述代码通过 volatile 的 Happens-Before先行发生规则来解决重排序问题。JMM 的 Happens-Before先行发生规则有一条针对 volatile 关键字的规则“volatile 变量的写操作发生在该变量的后续读之前”。
2、CLH 锁是一个链表队列为什么 Node 节点没有指向前驱或后继指针呢
CLH 锁是一种隐式的链表队列没有显式的维护前驱或后继指针。因为每个等待获取锁的线程只需要轮询前一个节点的状态就够了而不需要遍历整个队列。在这种情况下只需要使用一个局部变量保存前驱节点而不需要显式的维护前驱或后继指针。
3、this.node.set(new Node()) 这行代码有何意义
如果没有这行代码Node 可能被复用导致死锁如下图所示 CLH 优缺点分析
CLH 锁作为自旋锁的改进有以下几个优点 性能优异获取和释放锁开销小。CLH 的锁状态不再是单一的原子变量而是分散在每个节点的状态中降低了自旋锁在竞争激烈时频繁同步的开销。在释放锁的开销也因为不需要使用 CAS 指令而降低了。公平锁。先入队的线程会先得到锁。实现简单易于理解。扩展性强。下面会提到 AQS 如何扩展 CLH 锁实现了 j.u.c 包下各类丰富的同步器。 当然它也有两个缺点第一是因为有自旋操作当锁持有时间长时会带来较大的 CPU 开销。第二是基本的 CLH 锁功能单一不改造不能支持复杂的功能。
AQS 对 CLH 队列锁的改造
针对 CLH 的缺点AQS 对 CLH 队列锁进行了一定的改造。
针对第一个缺点AQS 将自旋操作改为阻塞线程操作。
针对第二个缺点AQS 对 CLH 锁进行改造和扩展原作者 Doug Lea 称之为“CLH 锁的变体”。下面将详细讲 AQS 底层细节以及对 CLH 锁的改进。
AQS 中的对 CLH 锁数据结构的改进主要包括三方面扩展每个节点的状态、显式的维护前驱节点和后继节点以及诸如出队节点显式设为 null 等辅助 GC 的优化。正是这些改进使 AQS 可以支撑 j.u.c 丰富多彩的同步器实现。
扩展每个节点的状态
volatile int waitStatus;AQS 同样提供了该状态变量的原子读写操作但和同步器状态不同的是节点状态在 AQS 中被清晰的定义如下表所示
状态名描述SIGNAL表示该节点正常等待PROPAGATE应将 releaseShared 传播到其他节点CONDITION该节点位于条件队列不能用于同步队列节点CANCELLED由于超时、中断或其他原因该节点被取消
显式的维护前驱节点和后继节点
上文我们提到在原始版本的 CLH 锁中节点间甚至都没有互相链接。但是通过在节点中显式地维护前驱节点CLH 锁就可以处理“超时”和各种形式的“取消”如果一个节点的前驱节点取消了这个节点就可以滑动去使用前面一个节点的状态字段。对于通过自旋获取锁的 CLH 锁来说只需要显式的维护前驱节点就可以实现取消功能如下图所示
volatile Node prev;
volatile Node next;是在 AQS 的实现稍有不同。因为 AQS 用阻塞等待替换了自旋操作线程会阻塞等待锁的释放不能主动感知到前驱节点状态变化的信息。AQS 中显式的维护前驱节点和后继节点需要释放锁的节点会显式通知下一个节点解除阻塞如下图所示T1 释放锁后主动唤醒 T2使 T2 检测到锁已释放获取锁成功。 其中需要关注的一个细节是由于没有针对双向链表节点的类似 compareAndSet 的原子性无锁插入指令因此后驱节点的设置并非作为原子性插入操作的一部分而仅是在节点被插入后简单地赋值。在释放锁时如果当前节点的后驱节点不可用时将从利用队尾指针 Tail 从尾部遍历到直到找到当前节点正确的后驱节点。
辅助 GC
JVM 的垃圾回收机制使开发者无需手动释放对象。但在 AQS 中需要在释放锁时显式的设置为 null避免引用的残留辅助垃圾回收。
