1.【Java原理系列】Java AtomicInteger原理用法源码详解
2.从HotSpot源码，码解深度解读 park 和 unpark
3.深入学习CAS底层原理
4.线程池也会导致OOM的码解原因
5.Java并发源码concurrent包

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

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

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

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

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

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

从HotSpot源码，深度解读 park 和 unpark

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

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

       其中，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来解锁。proteus源码导入hex

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

       在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，返回。ros 建图源码如果等于零，继续执行，阻塞等待。

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

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

深入学习CAS底层原理

       什么是CAS

       CAS是Compare-And-Swap的缩写，意思为比较并交换。以AtomicInteger为例，其提供了compareAndSet(intexpect,intupdate)方法，expect为期望值（被修改的值在主内存中的期望值），update为修改后的值。compareAndSet方法返回值类型为布尔类型，修改成功则返回true，修改失败返回false。

       举个compareAndSet方法的例子：

publicclassAtomticIntegerTest{ publicstaticvoidmain(String[]args){ AtomicIntegeratomicInteger=newAtomicInteger(0);booleanresult=atomicInteger.compareAndSet(0,1);System.out.println(result);System.out.println(atomicInteger.get());}}

       上面例子中，通过AtomicInteger(intinitialValue)构造方法指定了AtomicInteger类成员变量value的初始值为0：

publicclassAtomicIntegerextendsNumberimplementsjava.io.Serializable{ ......privatevolatileintvalue;/***CreatesanewAtomicIntegerwiththegiveninitialvalue.**@paraminitialValuetheinitialvalue*/publicAtomicInteger(intinitialValue){ value=initialValue;}......}

       接着执行compareAndSet方法，main线程从主内存中拷贝了value的副本到工作线程，值为0，并将这个值修改为1。如果此时主内存中value的值还是为0的话（言外之意就是没有被其他线程修改过），则将修改后的副本值刷回主内存更新value的值。所以上面的例子运行结果应该是true和1：

       将上面的例子修改为：

publicclassAtomticIntegerTest{ publicstaticvoidmain(String[]args){ AtomicIntegeratomicInteger=newAtomicInteger(0);booleanfirstResult=atomicInteger.compareAndSet(0,1);booleansecondResult=atomicInteger.compareAndSet(0,1);System.out.println(firstResult);System.out.println(secondResult);System.out.println(atomicInteger.get());}}

       上面例子中，main线程第二次调用compareAndSet方法的时候，value的值已经被修改为1了，不符合其expect的值，所以修改将失败。防火墙 源码上面例子输出如下：

CAS底层原理

       查看compareAndSet方法源码：

/***Atomicallysetsthevalueto{ @codenewValue}*ifthecurrentvalue{ @code==expectedValue},*withmemoryeffectsasspecifiedby{ @linkVarHandle#compareAndSet}.**@paramexpectedValuetheexpectedvalue*@paramnewValuethenewvalue*@return{ @codetrue}ifsuccessful.Falsereturnindicatesthat*theactualvaluewasnotequaltotheexpectedvalue.*/publicfinalbooleancompareAndSet(intexpectedValue,intnewValue){ returnU.compareAndSetInt(this,VALUE,expectedValue,newValue);}

       该方法通过调用unsafe类的compareAndSwapInt方法实现相关功能。compareAndSwapInt方法包含四个参数：

       this，当前对象；

       valueOffset，value成员变量的内存偏移量（也就是内存地址）：

privatestaticfinallongvalueOffset;static{ try{ valueOffset=unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));}catch(Exceptionex){ thrownewError(ex);}}

       expect，期待值；

       update，更新值。

       所以这个方法的含义为：获取当前对象value成员变量在主内存中的值，和传入的期待值相比，如果相等则说明这个值没有被别的线程修改过，然后将其修改为更新值。

       那么unsafe又是什么？它的compareAndSwapInt方法是原子性的么？查看该方法的源码：

/***AtomicallyupdatesJavavariableto{ @codex}ifitiscurrently*holding{ @codeexpected}.**<p>Thisoperationhasmemorysemanticsofa{ @codevolatile}read*andwrite.CorrespondstoCatomic_compare_exchange_strong.**@return{ @codetrue}ifsuccessful*/@HotSpotIntrinsicCandidatepublicfinalnativebooleancompareAndSetInt(Objecto,longoffset,intexpected,intx);

       该方法并没有具体Java代码实现，方法通过native关键字修饰。由于Java方法无法直接访问底层系统，Unsafe类相当于一个后门，可以通过该类的方法直接操作特定内存的数据。Unsafe类存在于sun.msic包中，JVM会帮我们实现出相应的汇编指令。Unsafe类中的CAS方法是一条CPU并发原语，由若干条指令组成，用于完成某个功能的一个过程。原语的执行必须是连续的，在执行过程中不允许被中断，不会存在数据不一致的问题。

getAndIncrement方法剖析

       了解了CAS原理后，我们回头看下AtomicInteger的getAndIncrement方法源码：

/***Atomicallyincrementsthecurrentvalue,*withmemoryeffectsasspecifiedby{ @linkVarHandle#getAndAdd}.**<p>Equivalentto{ @codegetAndAdd(1)}.**@returnthepreviousvalue*/publicfinalintgetAndIncrement(){ returnU.getAndAddInt(this,VALUE,1);}

       该方法通过调用unsafe类的getAndAddInt方法实现相关功能。继续查看getAndAddInt方法的源码：

/***Atomicallyaddsthegivenvaluetothecurrentvalueofafield*orarrayelementwithinthegivenobject{ @codeo}*atthegiven{ @codeoffset}.**@paramoobject/arraytoupdatethefield/elementin*@paramoffsetfield/elementoffset*@paramdeltathevaluetoadd*@returnthepreviousvalue*@since1.8*/@HotSpotIntrinsicCandidatepublicfinalintgetAndAddInt(Objecto,longoffset,intdelta){ intv;do{ v=getIntVolatile(o,offset);}while(!weakCompareAndSetInt(o,offset,v,v+delta));returnv;}

       结合源码，我们便可以很直观地看出为什么AtomicInteger的getAndIncrement方法是线程安全的了：

       o是AtomicInteger对象本身；offset是AtomicInteger对象的成员变量value的内存地址；delta是需要变更的数量；v是通过unsafe的getIntVolatile方法获得AtomicInteger对象的成员变量value在主内存中的值。dowhile循环中的逻辑为：用当前对象的值和var5比较，如果相同，说明该值没有被别的线程修改过，更新为v+delta，并返回true（CAS）；否则继续获取值并比较，直到更新完成。

CAS的缺点

       CAS并不是完美的，其存在以下这些缺点：

       如果刚好while里的CAS操作一直不成功，那么对CPU的开销大；

       只能确保一个共享变量的原子操作；

       存在ABA问题。

       CAS实现的一个重要前提是需要取出某一时刻的数据并在当下时刻比较交换，这之间的时间差会导致数据的变化。比如：thread1线程从主内存中取出了变量a的值为A，thread2页从主内存中取出了变量a的值为A。由于线程调度的不确定性，这时候thread1可能被短暂挂起了，thread2进行了一些操作将值修改为了B，然后又进行了一些操作将值修改回了A，这时候当thread1重新获取CPU时间片重新执行CAS操作时，会发现变量a在主内存中的值仍然是A，所以CAS操作成功。

解决ABA问题

       那么如何解决CAS的ABA问题呢？由上面的阐述课件，光通过判断值是否相等并不能确保在一定时间差内值没有变更过，所以我们需要一个额外的指标来辅助判断，类似于时间戳，版本号等。

       JUC为我们提供了一个AtomicStampedReference类，通过查看它的构造方法就可以看出，除了指定初始值外，还需指定一个版本号（戳）：

/***Createsanew{ @codeAtomicStampedReference}withthegiven*initialvalues.**@paraminitialReftheinitialreference*@paraminitialStamptheinitialstamp*/publicAtomicStampedReference(VinitialRef,intinitialStamp){ pair=Pair.of(initialRef,initialStamp);}

       我们就用这个类来解决ABA问题，首先模拟一个ABA问题场景：

publicclassAtomticIntegerTest{ publicstaticvoidmain(String[]args){ AtomicReference<String>atomicReference=newAtomicReference<>("A");newThread(()->{ //模拟一次ABA操作atomicReference.compareAndSet("A","B");atomicReference.compareAndSet("B","A");System.out.println(Thread.currentThread().getName()+"线程完成了一次ABA操作");},"thread1").start();newThread(()->{ //让thread2先睡眠2秒钟，确保thread1的ABA操作完成try{ TimeUnit.SECONDS.sleep(2);}catch(InterruptedExceptione){ e.printStackTrace();}booleanresult=atomicReference.compareAndSet("A","B");if(result){ System.out.println(Thread.currentThread().getName()+"线程修改值成功，当前值为："+atomicReference.get());}},"thread2").start();}}

       运行程序，输出如下：

       使用AtomicStampedReference解决ABA问题：

publicclassAtomicIntegerextendsNumberimplementsjava.io.Serializable{ ......privatevolatileintvalue;/***CreatesanewAtomicIntegerwiththegiveninitialvalue.**@paraminitialValuetheinitialvalue*/publicAtomicInteger(intinitialValue){ value=initialValue;}......}0

       程序输出如下：

线程池也会导致OOM的原因

       线程池的使用与内存管理

       在编程过程中，我们可能会遇到OOM问题，比如“java.lang.OutOfMemoryError: pthread_create (KB stack) failed: Try again”。这个问题通常与线程创建过多相关。然而，人们往往忽视了一点：线程池也可能导致内存溢出。本文将探讨线程池可能导致内存溢出的原因，以及如何解决这一问题。

       一、线程池的基本理解

       要了解线程池，首先需要从其参数入手，了解其基本工作流程：在任务开始执行时，线程池会先检查当前线程池数量是否达到核心线程数，未达到则创建核心线程执行任务；如果超过核心线程数，任务会放入阻塞队列等待，当阻塞队列满且未达到最大线程数时，会创建非核心线程执行任务；若达到最大线程数，则执行饱和策略。

       核心线程不会回收，非核心线程会在使用完毕后根据keepAliveTime和unit进行回收。这一设计使得核心线程一直存活，占用内存资源。如果创建了大量线程池，就会导致内存溢出。

       二、核心线程如何避免释放资源

       为了避免核心线程因执行完毕而释放资源，我们需要让核心线程进入BLOCKED或WAITING状态，从而在有新任务时被唤醒，进入RUNNABLE状态继续执行。这样，核心线程在执行任务间断时不会进入TERMINATED状态，从而避免释放资源。

       三、线程池源码分析

       在ThreadPoolExecutor类中，当使用线程池执行任务时，会调用execute方法。该方法内部使用了AtomicInteger和自旋（spin）操作来管理线程数量，以实现高效的状态控制和线程创建。当线程数量不足核心线程数时，会调用addWorker方法创建核心线程。

       addWorker方法分为上下两部分，上半部分主要用于状态判断和线程数量的增加，下半部分创建Worker对象并启动线程执行任务。Worker对象内部包含任务和执行该任务的线程，线程的创建依赖于传入的线程工厂。

       四、线程池生命周期与资源管理

       线程池的生命周期分为RUNNING、SHUTDOWN、STOP、TIDYING和TERMINATED等状态。shutdown()和shutdownNow()方法可以改变线程池的状态，但对资源管理影响较小。核心线程不会因执行完毕而立即释放资源，非核心线程在使用完毕后根据keepAliveTime和unit进行回收。

       五、结论与思考

       通过部分源码分析，我们了解到线程池可能导致内存溢出的原因，关键在于核心线程的持续占用资源。不断创建线程池不一定导致内存溢出，取决于线程池的大小、核心线程数、keepAliveTime以及任务执行情况。在实际应用中，合理设置线程池参数，以及正确处理任务调度，是避免内存溢出的关键。

Java并发源码concurrent包

       深入JAVA杨京京：Java并发源码concurrent包

       在JDK1.5之前，Java并发设计复杂且对程序员负担重，需考虑性能、死锁、公平性等。JDK1.5后，引入了java.util.concurrent工具包简化并发，提供多种并发模型，减轻开发负担。

       Java并发工具包java.util.concurrent源自JSR-，包含用于并发程序的通用功能。该包由Doug Lea开发，旨在提供线程安全的容器、同步类、原子对象等工具，减少并发编程的复杂性。

       并发容器如阻塞队列、非阻塞队列和转移队列等，实现线程安全功能，不使用同步关键字，为并发操作提供便利。

       同步类如Lock等，提供线程之间的同步机制，确保数据一致性。原子对象类如AtomicInteger、AtomicLong等，提供高效的原子操作，避免同步锁，实现线程安全。

       原子操作类在多线程环境中实现数据同步和互斥，确保数据一致性。实际应用场景包括线程安全的数据结构和算法实现。

       java.util.concurrent.atomic包中的原子操作类，使用硬件支持的原子操作实现数据的原子性，提高并发程序的效率和性能。

       值得一提的是，Java并发工具包还包含了Fork-Join框架，通过分解和合并任务，实现高效并行处理，减少等待其他线程完成时间，并利用工作偷取技术优化线程执行效率。

       Java线程池如ThreadLocalRandom类，提供高性能随机数生成，通过种子内部生成和不共享随机对象减少资源争用和消耗，提高并发程序的性能。