1.casԴ??????
2.编程「锁」事｜详解乐观锁 CAS 的技术原理
3.Linux基础组件之无锁消息队列ypipe/yqueue详解
4.画面设置cas是什么意思？
5.面试必问的CAS，你懂了吗？
6.C#中使用CAS实现无锁算法

casԴ??????

       我最近建立了一个在线自习室（App：番茄ToDO）用于相互监督学习，感兴趣的小伙伴可以加入。自习室加入码：D5A7A

       Java并发包下的类大多基于AQS（AbstractQueuedSynchronizer）框架实现，而AQS线程安全的实现依赖于两个关键类：Unsafe和LockSupport。

       其中，HUSKYLENS源码Unsafe主要提供CAS操作（关于CAS，在文章《读懂AtomicInteger源码（多线程专题）》中讲解过），LockSupport主要提供park/unpark操作。实际上，park/unpark操作的最终调用还是基于Unsafe类，因此Unsafe类才是核心。

       Unsafe类的实现是由native关键字说明的，这意味着这个方法是原生函数，是用C/C++语言实现的，并被编译成了DLL，由Java去调用。

       park函数的作用是将当前调用线程阻塞，而unpark函数则是唤醒指定线程。

       park是等待一个许可，unpark是为某线程提供一个许可。如果线程A调用park，除非另一个线程调用unpark(A)给A一个许可，否则线程A将阻塞在park操作上。每次调用一次park，需要有一个unpark来解锁。

       并且，unpark可以先于park调用，但不管unpark先调用多少次，都只提供一个许可，不可叠加。只需要一次park来消费掉unpark带来的许可，再次调用会阻塞。在线浏览linux源码

       在Linux系统下，park和unpark是通过Posix线程库pthread中的mutex（互斥量）和condition（条件变量）来实现的。

       简单来说，mutex和condition保护了一个叫_counter的信号量。当park时，这个变量被设置为0，当unpark时，这个变量被设置为1。当_counter=0时线程阻塞，当_counter>0时直接设为0并返回。

       每个Java线程都有一个Parker实例，Parker类的部分源码如下：

       由源码可知，Parker类继承于PlatformParker，实际上是用Posix的mutex和condition来实现的。Parker类里的_counter字段，就是用来记录park和unpark是否需要阻塞的标识。

       具体的执行逻辑已经用注释标记在代码中，简要来说，就是检查_counter是不是大于0，如果是，则把_counter设置为0，返回。如果等于零，继续执行，阻塞等待。

       unpark直接设置_counter为1，再unlock mutex返回。如果_counter之前的值是0，则还要调用pthread_cond_signal唤醒在park中等待的线程。源码如下：

       （如果不会下载JVM源码可以后台回复“jdk”，获得下载压缩包）

编程「锁」事｜详解乐观锁 CAS 的技术原理

       本文深入探讨乐观锁的核心实现方式——CAS（Compare And Swap）技术原理。CAS是精品加仓源码一种在多线程环境下实现同步功能的机制，相较于悲观锁的加锁操作，CAS允许在不使用锁的情况下实现多线程间的变量同步。Java的并发包中的原子类正是利用CAS实现乐观锁。

       CAS操作包含三个操作数：需要更新的内存值V、进行比较的预期数值A和要写入的值B。其逻辑是将内存值V与预期值A进行比较，当且仅当V值等于A时，通过原子方式用新值B更新V值（“比较+更新”整体是一个原子操作），否则不执行任何操作。一般情况下，更新操作会不断重试直至成功。

       以Java.util.concurrent.atomic并发包下的AtomicInteger原子整型类为例，分析其CAS底层实现机制。方法`atomicData.incrementAndGet()`内部通过Unsafe类实现。Unsafe类是底层硬件CPU指令复制工具类，关键在于compareAndSet（）方法的返回结果。

       `unsafe.compareAndSwapInt(this, valueOffset, expect, update)`

       此方法中，参数`this`是Unsafe对象本身，用于获取value的内存偏移地址。`valueOffset`是value变量的内存偏移地址，`expect`是期望更新的值，`update`是要更新的最新值。如果原子变量中的value值等于`expect`，则使用`update`值更新该值并返回true，否则返回false。

       至于`valueOffset`的来源，这里提到value实际上是volatile关键字修饰的变量，以保证在多线程环境下的内存可见性。

       CAS的底层是Unsafe类。如何通过`Unsafe.getUnsafe()`方法获得Unsafe类的实例？这是因为AtomicInteger类在rt.jar包下，因此通过Bootstrap根类加载器加载。Unsafe类的doit.im 源码具体实现可以在hotspot源码中找到，而unsafe.cpp中的C++代码不在本文详细分析范围内。对CAS实现感兴趣的读者可以自行查阅。

       CAS底层的Unsafe类在多处理器上运行时，为cmpxchg指令添加lock前缀（lock cmpxchg），在单处理器上则无需此步骤（单处理器自身维护单处理器内的顺序一致性）。这一机制确保了CAS操作的原子性。

       最后，同学们会发现CAS的操作与原子性密切相关。CPU如何实现原子性操作是一个深入的话题，有机会可以继续探索。欢迎在评论区讨论，避免出现BUG！点赞转发不脱发！

Linux基础组件之无锁消息队列ypipe/yqueue详解

       CAS定义

       比较并交换（compare and swap, CAS），在多线程编程中用于实现不被打断的数据交换，避免数据不一致问题。该操作通过比较内存值与指定数据，当数值相同则替换内存数据。

       为什么需要无锁队列

       锁引起的问题：cache损坏/失效、同步机制上的争抢、动态内存分配。

       有锁导致线程切换引发cache损坏

       大量线程切换导致cache数据失效，处理器与主存之间数据传输效率下降，影响性能。

       在同步机制上的争抢队列

       阻塞队列导致任务暂停或睡眠，大量时间浪费在获取互斥锁，而非处理数据，引发严重争用。

       动态内存分配

       多线程中动态分配内存导致互斥，线程频繁分配内存影响应用性能。

       无锁队列的实现

       无锁队列由ypipe_t和yqueue_t类构成，适用于一读一写场景。团队介绍html源码通过chunk模式批量分配结点，减少动态内存分配的互斥问题。批量分配大小根据业务场景调整，通常设置较大较为安全。利用spare_chunk存储未释放的chunk，降低频繁分配释放。预写机制减少CAS调用。巧妙的唤醒机制，读端等待无数据时进入等待状态，写端根据返回值判断队列是否为空以唤醒读端。

       无锁队列使用

       yqueue.write(count,false)用于写入元素并标记完成状态，yqueue.flush()使读端可见更新后数据。yqueue.read(&value)读取元素，返回true表示读到元素，返回false表示队列为空。

       ypipe_t使用

       write(val, false)更新写入位置，flush()刷新数据到管道，read()读取数据并更新可读位置。

       yqueue_t构造函数

       初始化队列，end_chunk总是指向最后分配的chunk，back_chunk仅在有元素插入时指向对应的chunk。

       front()和back()函数

       返回队列头和尾的可读写元素位置。

       push()和pop()函数

       push()更新写入位置，pop()更新读取位置并检测释放chunk，保持数据流。

       源码分析

       yqueue_t内部使用chunk批量分配，减少内存操作，spare_chunk存储释放的chunk以供再次使用。ypipe_t构建单写单读无锁队列，通过CAS操作控制读写位置，实现高效数据交换。

       ypipe_t / yqueue_t无锁队列利用chunk机制避免频繁内存动态分配，提升性能。通过局部性原理复用回收的chunk，减少资源消耗。flush()检测队列状态通知唤醒，优化数据交换过程。

画面设置cas是什么意思？

       CAS是Central Authentication Service的缩写，即集中式认证服务。它是一种用于Web应用程序的单点登录协议。CAS协议通过认证中心（服务器）来给多个服务提供认证服务，用户一次登录认证以后，便可以访问被授权的多个服务。CAS协议是一种开放源代码的协议，被广泛应用于大型企业和组织的身份认证系统中。

       CAS需要先部署一个认证服务器和多个应用程序服务器，然后在这些服务器之间建立信任关系。用户首次登录时，应该重定向到认证服务器，输入用户名和密码进行认证，并且一旦通过认证，用户将被重定向回要访问的应用程序服务器。以后的每次访问都无需再次认证。认证服务器和应用程序服务器之间使用安全令牌和Session来保障安全性。

       CAS的优点在于提供可靠的身份验证，减少了用户访问多个Web应用程序时的不必要的登录操作，避免了重复输入用户名和密码等问题。它广泛应用于大型企业和组织的身份认证系统中，例如教育机构、银行、保险公司、医院等。CAS的使用可以帮助企业或组织节省时间和成本，减少安全漏洞，提高用户体验并提高整个系统的安全性。

面试必问的CAS，你懂了吗？

       CAS（Compare-and-Swap）是一种实现并发算法时常用的技术，Java并发包中的多个类采用了CAS技术。面试中经常涉及这一概念，本文旨在深入解析CAS的原理。

       在介绍CAS之前，我们通过一个例子来理解其应用。这个例子在运行过程中可能会陷入死循环，通过检查线程状态，发现IDEA监控线程的介入导致了问题。解决这一死循环的方法是使用DEBUG模式运行程序或调整代码逻辑。

       通过volatile关键字的使用，我们可以观察到，其只能确保可见性，而不能保证原子性。在并发场景下，对于自增操作等非原子操作，volatile并不能保证正确结果。因此，解决这类问题的关键是引入原子操作。

       引入synchronized关键字是一种常见的解决方法，通过加锁实现原子操作，确保每次操作的正确性。然而，频繁使用synchronized会导致性能下降，因此引入Java并发包中的原子操作类（如AtomicInteger）成为了更优选择。

       AtomicInteger的`getAndIncrement()`方法即是CAS操作的实例，它通过一系列原子操作确保每次自增操作的正确性和性能。进一步分析，我们发现其底层实现调用了`compareAndSwapInt`方法，即CAS的核心实现。

       CAS（Compare-and-Swap）本质上是一个比较并替换操作，它需要三个操作数：内存地址、旧的预期值和目标值。执行过程中，当内存地址的值与预期值相等时，CAS尝试将内存地址的值修改为目标值。若失败，则获取最新值，重新尝试，直至修改成功。

       深入到源码层面，可以看到`AtomicInteger`类中的`getAndIncrement()`方法最终调用了`compareAndSwapInt`方法，而`compareAndSwapInt`在Unsafe类中被实现。通过调用`Atomic::cmpxchg`方法，我们能够看到具体的汇编指令实现。

       `Atomic::cmpxchg`方法的实现依赖于系统是否为多处理器环境，以优化性能。它通过`LOCK_IF_MP`宏决定是否添加`lock`前缀，这一优化措施在单处理器环境下通常没有必要，但在多核处理器中能够提升性能。

       CAS操作的缺点包括循环时间长导致的开销大、仅支持单一共享变量的原子操作，以及ABA问题。ABA问题是由于CAS操作的特性导致，即在读取值后，值在后续操作中可能被改回原始值，从而产生误判。为解决ABA问题，Java并发包提供了带有版本控制的原子引用类`AtomicStampedReference`。

       在使用CAS操作时，需要考虑其对并发正确性的影响，尤其是ABA问题。如果并发场景中存在可能的ABA问题，传统互斥同步可能比原子类更高效。

       综上所述，理解CAS的原理和其在并发编程中的应用对于深入学习Java并发技术至关重要。掌握CAS操作的原理、优缺点及其解决方法，将有助于更高效、正确地处理并发问题。

C#中使用CAS实现无锁算法

       CAS（Compare-and-Swap）操作是一种多线程并发编程中常用的原子操作，用于实现多线程间的同步和互斥访问。它通过比较内存地址处的值与期望的旧值是否相等来实现这一目标。若相等，则将新值写入该内存地址；否则不做任何操作。CAS 操作的原子性由硬件层面的CPU指令保证，通常通过 Interlocked 类在 C# 中实现。

       在C#中，我们使用Interlocked类的CompareExchange方法来实现CAS操作。此方法接收三个参数：内存地址、期望的旧值和新值。如果内存地址处的值与期望的旧值相等，则将新值写入该内存地址并返回旧值；否则不执行任何操作。通过判断返回值与期望的旧值是否相等，我们可以得知CompareExchange操作是否成功。

       在使用CAS实现无锁算法时，我们通常需要在更新数据后执行进一步的操作。结合while(true)循环，我们可以在每次尝试更新数据后检查是否成功。如果失败，则继续尝试，直到成功为止。

       以下是一个简单的计数器示例，它使用CAS实现了一个线程安全的自增操作。在CLR底层源码中，我们也经常看到使用类似方法实现线程安全计数器的代码。同时，队列类也使用CAS实现线程安全的入队和出队操作，该操作更为复杂，需要不断检查是否有其他线程修改数据。

       在复杂的无锁算法中，每一步操作都必须考虑是否被其他线程修改。每一步操作非原子，因此我们不仅依赖CAS操作，还必须确保在执行每个操作前检查数据是否被修改。类比薛定谔的猫，我们不知道数据状态直到尝试修改时才确定。

       通过测试代码，我们可以观察到在一定数量的操作中，需要重试的次数。这个重试次数取决于队列中是否有数据可供操作，而在多线程环境下，每次操作的结果可能有所不同。

       CAS是一种乐观锁机制，假设数据未被其他线程修改，若未修改则直接修改，若已修改则重新获取数据并再次尝试修改。在实现复杂的数据结构时，我们不仅依赖CAS操作，还需注意数据是否被其他线程修改，以及处理可能的分支情况。