1.AQS与ReentrantLock详解
2.源码分析： Java中锁的源码种类与特性详解
3.7个连环问题揭开java多线程背后的核心原理！
4.Java原理系列Java AtomicInteger原理用法源码详解
5.reentrantlock如何保证可见性?分析
6.Volatile的实现原理(看这篇就够了)

AQS与ReentrantLock详解

       J.U.C包中的Java.util.concurrent是一个强大的并发工具库，包含多种处理并发场景的源码组件，如线程池、分析队列和同步器等，源码由知名开发者Doug Lea设计。分析鱼刺模块源码本文将深入讲解Lock接口及其关键实现ReentrantLock，源码它在并发编程中的分析重要性不可忽视，因为大部分J.U.C组件都依赖于Lock来实现并发安全。源码

       Lock接口的分析出现，弥补了synchronized在某些场景中的源码不足，提供了更灵活的分析并发控制。ReentrantLock作为Lock的源码一种实现，支持重入，分析即同一线程可以多次获取锁而不必阻塞。源码这种特性在处理多方法调用场景时避免了死锁问题。

       ReentrantReadWriteLock则允许读写操作并发进行，提高了读操作的并发性，避免了写操作对读写操作的阻塞，适用于读多写少的场景。在内存缓存示例中，读写锁通过HashMap以读写锁保护，确保并发访问的线程安全。

       ReentrantLock的实现核心是AQS（AbstractQueuedSynchronizer），它是Lock实现线程同步的核心组件。AQS提供了独占和共享锁两种功能，如ReentrantLock就基于AQS的独占模式。AQS内部维护了一个volatile状态变量，不同的实现类根据其具体需求定义其含义。

       ReentrantLock的源码分析中，我们看到lock()方法如何通过AQS的队列机制实现线程阻塞和唤醒。例如，NofairSync.lock展示了非公平锁的实现，涉及CAS（Compare and Swap）操作，保证了线程安全。Unsafe类在这其中发挥了关键作用，提供了低层次的内存操作，如CAS操作。

       总结来说，ReentrantLock和AQS是Java并发编程中的重要基石，通过理解它们的工作原理，可以更好地应对并发环境中的问题。

源码分析： Java中锁的种类与特性详解

       在Java中存在多种锁，包括ReentrantLock、网页源码文本Synchronized等，它们根据特性与使用场景可划分为多种类型，如乐观锁与悲观锁、可重入锁与不可重入锁等。本文将结合源码深入分析这些锁的设计思想与应用场景。

       锁存在的意义在于保护资源，防止多线程访问同步资源时出现预期之外的错误。举例来说，当张三操作同一张银行卡进行转账，如果银行不锁定账户余额，可能会导致两笔转账同时成功，违背用户意图。因此，在多线程环境下，锁机制是必要的。

       乐观锁认为访问资源时不会立即加锁，仅在获取失败时重试，通常适用于竞争频率不高的场景。乐观锁可能影响系统性能，故在竞争激烈的场景下不建议使用。Java中的乐观锁实现方式多基于CAS（比较并交换）操作，如AQS的锁、ReentrantLock、CountDownLatch、Semaphore等。CAS类实现不能完全保证线程安全，使用时需注意版本号管理等潜在问题。

       悲观锁则始终在访问同步资源前加锁，确保无其他线程干预。ReentrantLock、Synchronized等都是典型的悲观锁实现。

       自旋锁与自适应自旋锁是另一种锁机制。自旋锁在获取锁失败时采用循环等待策略，避免阻塞线程。自适应自旋锁则根据前一次自旋结果动态调整等待时间，提高效率。

       无锁、偏向锁、轻量级锁与重量级锁是Synchronized的锁状态，从无锁到重量级锁，锁的竞争程度与性能逐渐增加。Java对象头包含了Mark Word与Klass Pointer，Mark Word存储对象状态信息，传世引擎源码而Klass Pointer指向类元数据。

       Monitor是实现线程同步的关键，与底层操作系统的Mutex Lock相互依赖。Synchronized通过Monitor实现，其效率在JDK 6前较低，但JDK 6引入了偏向锁与轻量级锁优化性能。

       公平锁与非公平锁决定了锁的分配顺序。公平锁遵循申请顺序，非公平锁则允许插队，提高锁获取效率。

       可重入锁允许线程在获取锁的同一节点多次获取锁，而不可重入锁不允许。共享锁与独占锁是另一种锁分类，前者允许多个线程共享资源，后者则确保资源的独占性。

       本文通过源码分析，详细介绍了Java锁的种类与特性，以及它们在不同场景下的应用。了解这些机制对于多线程编程至关重要。此外，还有多种机制如volatile关键字、原子类以及线程安全的集合类等，需要根据具体场景逐步掌握。

7个连环问题揭开java多线程背后的核心原理！

       很多java入门新人一想到java多线程， 就会觉得很晕很绕，什么可见不可见的，也不了解为什么sync怎么就锁住了代码。

       因此我在这里会提多个问题，如果能很好地回答这些问题，那么算是你对java多线程的原理有了一些了解，也可以借此学习一下这背后的核心原理。

       Q: java中的主内存和工作内存是指什么？

       A:java中， 主内存中的对象引用会被拷贝到各线程的工作内存中， 同时线程对变量的修改也会反馈到主内存中。

       主内存对应于java堆中的对象实例部分（物理硬件的内存）

       工作内存对应于虚拟机栈中的部分区域（ 寄存器，高速缓存）

       工作内存中是拷贝的工作副本

       拷贝副本时，不会吧整个超级大的对象拷贝过来， 可能只是微相册 源码其中的某个基本数据类型或者引用。

       因此我们知道各线程使用内存数据时，其实是有主内存和工作内存之分的。并不是一定每次都从同一个内存里取数据。

       或者理解为大家使用数据时之间有一个缓存。

       Q: 多线程不可见问题的原因是什么？

       A:这里先讲一下虚拟机定义的内存原子操作：

       lock: 用于主内存， 把变量标识为一条线程独占的状态

       unlock : 主内存， 把锁定状态的变量释放

       read: 读取， 从主内存读到工作线程中

       load: 把read后的值放入到 工作副本中

       use： 使用工作内存变量， 传给工作引擎

       assign赋值: 把工作引擎的值传给工作内存变量

       store： 工作内存中的变量传到主内存

       write： 把值写入到主内存的变量中

       根据这些指令，看一下面这个图，　然后再看之后的流程解释，就好理解了。

       read和load、store、write是按顺序执行的， 但是中间可插入其他的操作。不可单独出现。

       assgin之后， 会同步后主内存。即只有发生过assgin，才会做工作内存同步到主内存的操作。

       新变量只能在主内存中产生

       工作内存中使用某个变量副本时，必须先经历过assign或者load操作。 不可read后马上就use

       lock操作可以被同一个线程执行多次，但相应地解锁也需要多次。

       执行lock时，会清空工作内存中该变量的值。 清空后如果要使用，必须重新做load或者assign操作

       unlock时，需要先把数据同步回主内存，再释放。

       因此多线程普通变量的读取和写入操作存在并发问题， 主要在于2点：

       只有assgin时， 才会更新主内存， 但由于指令重排序的情况，导致有时候某个assine指令先执行，然后这个提前被改变的变量就被其他线程拿走了，以至于其他线程无法及时看到更新后的内存值。

       assgin时从工作内存到主内存之间，可能存在延迟，同样会导致数据被提前取走存到工作线程中。

       Q: 那么volatile关键字为什么就可以实现可见性？可见性就是并发修改某个值后，这个值的公文系统源码修改对其他线程是马上可见的。

       A: java内存模型堆volatile定义了以下特殊规则：

       当一个线程修改了该变量的值时，会先lock住主存， 再立刻把新数据同步回内存。

       使用该值时，其他工作内存都要从主内存中刷新！

       这个期间会禁止对于该变量的指令重排序

       禁止指令重排序的原理是在给volatile变量赋值时，会加1个lock动作， 而前面规定的内存模型原理中， lock之后才能做load或者assine，因此形成了1个内存屏障。

       Q: 上面提到lock后会限制各工作内存要刷新主存的值load进来后才能用， 这个在底层是怎么实现的？

       A:利用了cpu的总线锁+ 缓存一致性+ 嗅探机制实现， 属于计算机组成原理部分的知识。

       这也就是为什么violate变量不能设置太多，如果设置太多，可能会引发总线风暴，造成cpu嗅探的成本大大增加。

       Q: 那给方法加上synchronized关键字的原理是什么？和volatie的区别是啥？

       A:

       synchronized的重量级锁是通过对象内部的监视器（monitor）实现

       monitor的线程互斥就是通过操作系统的mutex互斥锁实现的，而操作系统实现线程之间的切换需要从用户态到内核态的切换，所以切换成本非常高。

       每个对象都持有一个moniter对象

       具体流程如下：

       首先，class文件的方法表结构中有个访问标志access_flags， 设置ACC_SYNCHRONIZED标志来表示被设置过synchronized。

       线程在执行方法前先判断access_flags是否标记ACC_SYNCHRONIZED，如果标记则在执行方法前先去获取monitor对象。

       获取成功则执行方法代码且执行完毕后释放monitor对象

       如果获取失败则表示monitor对象被其他线程获取从而阻塞当前线程

       注意，如果是sync{ }代码块，则是通过在代码中添加monitorEnter和monitorExit指令来实现获取和退出操作的。

       如果对C语言有了解的，可以看看这个大哥些的文章Java精通并发-通过openjdk源码分析ObjectMonitor底层实现

       Q: synchronized每次加锁解锁需要切换内核态和用户态， jvm是否有对这个过程做过一些优化？

       A:jdk1.6之后， 引入了锁升级的概念，而这个锁升级就是针对sync关键字的

       锁的状态总共有四种，级别由低到高依次为：无锁、偏向锁、轻量级锁、重量级锁

       四种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，只能进行锁升级（从低级别到高级别），不能锁降级（高级别到低级别）

       因此sync关键字不是一开始就直接使用很耗时的同步。而是一步步按照情况做升级

       当对象刚建立，不存在锁竞争的时候， 每次进入同步方法/代码块会直接使用偏向锁

       偏向锁原理： 每次尝试在对象头里设置当前使用这个对象的线程id， 只做一次，如果成功了就设置好threadId， 只要没有出现新的thread访问且markWord被修改，那么久）

       2. 当发现对象头的线程id要被修改时，说明存在竞争时。升级为轻量级锁

       轻量级锁采用的是自旋锁，如果同步方法/代码块执行时间很短的话，采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效的。 CAS的对象是对象头的Mark Word， 此时仍然不会去调系统底层的方法做阻塞。

       3. 但是如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就会升级为重量级锁，也就是上面那个问题中提到的操作。

       Q: 锁只可以升级不可以降级, 确定是都不能降级吗？

       A:有可能被降级， 不可能存在共享资源竞争的锁。java存在一个运行期优化的功能需要开启server模式外加+DoEscapeAnalysis表示开启逃逸分析。

       如果运行过程中检测到共享变量确定不会逃逸，则直接在编译层面去掉锁

       举例：StringBuffer.append().append()

       例如如果发现stringBuffer不会逃逸，则就会去掉这里append所携带的同步

       而这种情况肯定只能发生在偏向锁上， 所以偏向锁可以被重置为无锁状态。

       本文分享自华为云社区，作者：breakDraw。

Java原理系列Java AtomicInteger原理用法源码详解

       Java的原子类AtomicInteger，是《Java原理用法示例及代码规范详解系列》的一部分，关注和收藏以获取最新内容。它用于在多线程环境中进行安全的整数操作，如get(), set(), incrementAndGet(), compareAndSet()等，提高并发性能，适用于计数器、标记位等场景。

       AtomicInteger的核心原理基于CAS操作，内部使用volatile修饰的int变量保证可见性和原子性。CAS操作确保在多线程环境中，对整数的修改是原子性的，避免了竞态条件和数据不一致。如果CAS操作失败，它会通过循环重试确保操作成功。

       在使用AtomicInteger时，如计数器递增和条件判断，应避免竞态条件。通过额外的同步手段如锁或Lock接口，可以确保整个操作序列是原子的。AtomicInteger提供的方法如getAndIncrement()，保证了这些操作的线程安全。

       场景上，AtomicInteger在计数器、并发任务处理和共享变量的线程安全操作中大显身手。例如，网站访问计数和任务完成数量统计，AtomicInteger确保了这些操作的原子性，输出的计数始终准确。

       总的来说，AtomicInteger是处理多线程整数操作的理想选择，为并发编程提供了一种高效且线程安全的解决方案。

reentrantlock如何保证可见性?

       理解ReentrantLock的可见性，首先需要掌握Java内存模型(JMM)中的volatile特性和happens-before原则。volatile变量在写操作时，会将本地缓存中的共享变量副本刷新至主内存，确保其他线程能读取到最新值。反之，当线程读取volatile变量时，本地缓存中相应变量副本将失效，进而读取主内存中的最新数据。通过在ReentrantLock源码中查看，我们可以发现其对volatile变量的操作遵循了这一机制，确保了可见性。

       ReentrantLock在实现可见性时，主要依赖于它的内部类Sync，具体实现为读写锁和公平锁。读写锁（ReadWriteLock）允许多个线程同时读取共享资源，但禁止写操作与读操作同时进行。这在很大程度上提高了并发效率。而公平锁则确保了线程获取锁的顺序与线程请求锁的顺序一致，确保了线程间的公平性。

       ReentrantLock通过内部类Sync来确保可见性，实现了锁的公平性和非公平性。公平锁中，当一个线程请求锁时，它会等待在锁队列的末尾，直到前面的线程释放锁。而非公平锁则允许线程跳过等待队列中的其他线程，直接尝试获取锁，这在高并发环境下能显著提升效率。不过，为了确保可见性，无论公平锁还是非公平锁，ReentrantLock在使用volatile关键字修饰的成员变量来控制线程的等待和唤醒状态，以此保证了不同线程间的可见性。

       综上所述，ReentrantLock的可见性通过遵循Java内存模型中的volatile特性和happens-before原则来实现。无论是读写锁还是公平锁，通过内部类Sync来管理线程请求、等待和释放锁的过程，确保了不同线程在执行并发操作时，能够及时获取到最新状态的共享资源。通过这种方式，ReentrantLock有效地实现了可见性，保证了并发程序的正确性和一致性。

Volatile的实现原理(看这篇就够了)

       探讨并发编程的核心要素——原子性、可见性与有序性，Volatile作为关键角色，在多线程环境中确保了可见性与有序性，成为轻量级同步机制的代表。本文旨在全面剖析Volatile的实现原理，通过理论与实践相结合的方式，帮助读者深入理解并熟练掌握Volatile变量的正确运用。

       Volatile关键字与Java内存模型

       在深入探讨Volatile前，首先回顾Java内存模型的三要素——原子性、可见性与有序性，这是并发编程的基石。

       1. 原子性

       原子性指的是不可分割的操作，确保操作要么全成功要么全失败。例如，简单的读取与赋值操作是原子的，而复杂的操作如自增、加法等则不是。

       2. 可见性

       当一个线程修改共享变量时，其他线程能够立即访问到修改后的值。

       3. 有序性

       编译器与处理器为优化性能可能改变指令顺序，但这种重排序不影响单线程执行，却可能干扰多线程执行的正确性。

       Volatile的作用与限制

       Volatile作为类型修饰符，为共享变量赋予了两层语义：确保多线程下的可见性与禁止指令重排序。然而，它只能保证单次读写操作的原子性，对于复杂操作如自增等不适用。

       Java内存模型详解

       Java内存模型（JMM）提供了一组规则，定义了变量在主内存与工作内存中的访问方式，以实现跨平台的一致性。

       1. 变量存储在主内存

       每个线程拥有自己的工作内存，用于存储变量的副本，线程间变量传递需通过主内存同步。

       2. 独立的工作内存

       每个线程独立，其工作内存中变量的副本仅线程可见，不与其他线程共享。

       Volatile的实现原理

       Volatile通过特定的内存模型操作确保可见性与有序性，其原理基于Java内存模型的规则，通过lock、unlock、read、load等操作实现。

       1. lock

       锁定共享变量，确保线程独占。

       2. unlock

       解除锁定，其他线程有机会访问。

       3. read

       从主内存读取变量值。

       4. load

       将读取值存储到工作内存。

       5. use

       将值传递给代码执行引擎。

       6. assign

       将处理结果回写到工作内存。

       7. store

       将工作内存更新同步至主内存。

       8. write

       最终写入共享变量。

       指令规则

       Volatile通过上述操作确保多线程环境中的可见性与有序性，实现内存模型的规则。

       源码案例

       本文介绍了Volatile的实现原理，包括理论知识与源码实例，帮助读者理解其在并发编程中的应用。欲了解更多内容，欢迎访问作者主页获取视频详解与技术连载。

       ---END---

[redis 源码走读] maxmemory 数据淘汰策略

       Redis 是一个内存数据库，通过配置 `maxmemory` 来限定其内存使用量。当 Redis 主库内存超出限制时，会触发数据淘汰机制，以减少内存使用量，直至达到限制阈值。

       当 `maxmemory` 配置被应用，Redis 会根据配置采用相应的数据淘汰策略。`volatile-xxx` 类型配置仅淘汰设置了过期时间的数据，而 `allkeys-xxx` 则淘汰数据库中所有数据。若 Redis 主要作为缓存使用，可选择 `allkeys-xxx`。

       数据淘汰时机发生在事件循环处理命令时。有多种淘汰策略可供选择，从简单到复杂包括：不淘汰数据（`noeviction`）、随机淘汰（`volatile-random`、`allkeys-random`）、采样淘汰（`allkeys-lru`、`volatile-lru`、`volatile-ttl`、`volatile-freq`）以及近似 LRU 和 LRU 策略（`volatile-lru` 和 `allkeys-lru`）。

       `noeviction` 策略允许读操作但禁止大多数写命令，返回 `oomerr` 错误，仅允许执行少量写命令，如删除命令 `del`、`hdel` 和 `unlink`。

       `volatile-random` 和 `allkeys-random` 机制相对直接，随机淘汰数据，策略相对暴力。

       `allkeys-lru` 策略根据最近最少使用（LRU）算法淘汰数据，优先淘汰最久未使用的数据。

       `volatile-lru` 结合了过期时间与 LRU 算法，优先淘汰那些最久未访问且即将过期的数据。

       `volatile-ttl` 策略淘汰即将过期的数据，而 `volatile-freq` 则根据访问频率（LFU）淘汰数据，考虑数据的使用热度。

       `volatile-lru` 和 `allkeys-lru` 策略通过采样来近似 LRU 算法，维护一个样本池来确定淘汰顺序，以提高淘汰策略的精确性。

       总结而言，Redis 的数据淘汰策略旨在平衡内存使用与数据访问需求，通过灵活的配置实现高效的数据管理。策略的选择应基于具体应用场景的需求，如数据访问模式、性能目标等。