JUC并发编程与源码分析学习笔记

Future是Java5新加的一个接口，它提供了一种异步并行计算的功能。
如果主线程需要执行一个很耗时的计算任务，我们就可以通过future把这个任务放到异步线程中执行。
主线程继续处理其他任务或者先行结束，再通过Future获取计算结果。

Future优点

Future缺点

对于简单的业务场景使用Future完全OK

通过上面的Futrue我们知道 futrue阻塞的方式和异步编程的设计理念相违背，而轮询的方式会消耗无畏的CPU资源。因此，JDK8设计出CompletableFuture

public class CompletableFuture<T> implements Future<T>, CompletionStage<T> {

CompletionStage

利用核心的四个静态方法创建一个异步操作 | 不建议用new

关键就是 |有没有返回值|是否用了线程池|

CompletableFuture优点

获取结果

主动触发计算

thenApply 计算结果存在在依赖关系，使得线程串行化。因为依赖关系，所以一旦有异常，直接叫停

handle 类似于thenApply，但是有异常的话仍然可以往下走一步

thenAccept 接收任务的处理结果，并消费处理，无返回结果|消费型函数式接口

任务之间的顺序执行

CompleteFuture和线程池说明（非常重要）

applyToEither方法，快的那个掌权

thenCombine 合并

悲观锁认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改

悲观锁的实现方式
1.synchronized关键字
2.Lock的实现类都是悲观锁

适合写操作多的场景，先加锁可以保证写操作时数据正确。显示的锁定之后再操作同步资源

乐观锁认为自己在使用数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作

乐观锁的实现方式
1.版本号机制Version （ABA问题）
2.最常采用的是CAS算法，Java原子类中的递增操作就通过CAS自旋实现的

适合读操作多的场景，不加锁的性能特点能够使其操作的性能大幅提升

1.synchronized实现使用的是moniterenter和moniterexit指令（moniterexit可能有两个）
2.那一定是一个enter两个exit吗？（不一样，如果主动throw一个RuntimeException，发现一个enter，一个exit，还有两个athrow）

调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否被设置。如果设置了，执行线程会将先持有monitore然后再执行方法，最后在方法完成（无论是正常完成还是非正常完成）时释放monitor

ACC_STATIC, ACC_SYNCHRONIZED访问标志区分该方法是否是静态同步方法

ReentrantLock lock = new ReentrantLock(true);

是指多个线程按照申请锁的顺序来获取锁，这里类似排队买票，先来的人先买后来的人在队尾排着，这是公平的

默认是非公平锁

是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁，在高并发环境下，有可能造成优先级翻转或饥饿的状态（某个线程一直得不到锁）

为什么会有公平锁/非公平锁的设计？为什么默认是非公平？

什么时候用公平？什么时候用非公平？

在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁(前提，锁对象得是同一个对象)，不会因为之前已经获取过还没释放而阻塞。

如果是1个有 synchronized 修饰的递归调用方法，程序第2次进入被自己阻塞了岂不是天大的笑话，出现了作茧自缚。
所以Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

隐式锁Synchronized

显式锁Lock

是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去，如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。

系统资源不足

进程运行推进的顺序不合适

资源分配不当

demo

纯命令

图形化

三个方法了解过吗？用在哪？
如何停止一个运行中的线程？
如何中断一个运行中的线程？

概念

三大方法

public void interrupt()                      实例方法，实例方法interrupt()仅仅是设置线程的中断状态为true，发起一个协商而不会立刻停止线程；

public static boolean interrupted()  静态方法，Thread.interrupted();判断线程是否被中断，并清除当前中断状态这个方法做了两件事：
1 返回当前线程的中断状态
2 将当前线程的中断状态设为false（这个方法有点不好理解，因为连续调用两次的结果可能不一样）

public boolean isInterrupted()         实例方法，判断当前线程是否被中断（通过检查中断标志位）

相关面试题

使用Object中的wait()方法让线程等待，使用Object中的notify()方法唤醒线程

使用JUC包中Condition的await()方法让线程等待，使用signal()方法唤醒线程

LockSupport类可以阻塞当前线程以及唤醒指定被阻塞的线程

线程先要获得并持有锁，必须在锁块（synchronized或lock）中

必须要先等待后唤醒，线程才能够被唤醒

概念

主要方法

重点说明

面试题

JMM(Java内存模型Java Memory Model，简称JMM)本身是一种抽象的概念并不真实存在它仅仅描述的是一组约定或规范，通过这组规范定义了程序中(尤其是多线程)各个变量的读写访问方式并决定一个线程对共享变量的写入何时以及如何变成对另一个线程可见，关键技术点都是围绕多线程的原子性、可见性和有序性展开的

JMM的关键技术点都是围绕多线程的原子性、可见性和有序性展开的

1 通过JMM来实现线程和主内存之间的抽象关系。
2 屏蔽各个硬件平台和操作系统的内存访问差异以实现让Java程序在各种平台下都能达到一致的内存访问效果

是指当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道该变更 ，JMM规定了所有的变量都存储在主内存中

指一个操作是不可中断的，即多线程环境下，操作不能被其他线程干扰

对于一个线程的执行代码而言，我们总是习惯性认为代码的执行总是从上到下，有序执行。但为了提供性能，编译器和处理器通常会对指令序列进行重新排序。Java规范规定JVM线程内部维持顺序化语义，即只要程序的最终结果与它顺序化执行的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序

优缺点：
JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的机器对指令进行重排序，使得机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。
但是，指令重排可以保证串行语义一致，但没有义务保证多线程间的语义也一致（即可能产生“脏读”），简单说，两行以上不相干的代码在执行的时候有可能先执行的不是第一条，不见得是从上到下顺序执行，执行顺序会被优化

指令重排的三种表现
1.编译器优化的重排
2.指令并行的重排
3.内存系统的重排

小结

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到的线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成，其简要访问过程

1.线程之间的共享变量存储在主内存中(从硬件角度来说就是内存条)

2.每个线程都有一个私有的本地工作内存，本地工作内存中存储了该线程用来读/写共享变量的副本(从硬件角度来说就是CPU的缓存，比如寄存器、L1、L2、L3缓存等)

1.我们定义的所有共享变量都存储在物理主内存中

2.每个线程都有自己独立的工作内存，里面保存该线程使用到的变量的副本（主内存中该变量的一份拷贝）

3.线程对共享变量所有的操作都必须先在线程自己的工作内存中进行后写回主内存，不能直接从主内存中读写（不能越级）

4.不同线程之间也无法直接访问其他线程的工作内存中的变量，线程间变量值的传递需要通过主内存来进行（同级不能相互访问）

在JMM中，如果一个操作执行的结果需要对另一个操作可见性或者代码重新排序，那么这两个操作之间必须存在happens-before（先行发生）原则。
逻辑上的先后关系

如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前

两个操作之间存在happens-before关系，并不一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法

1.次序规则

2.锁定规则

3.volatile变量规则

4.传递规则

5.线程启动规则(Thread Start Rule)

6.线程中断规则(Thread Interruption Rule)

7.线程终止规则(Thread Termination Rule)

8.对象终结规则(Finalizer Rule)

可见性

有序性

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量立即刷新回到主内存中。

当读一个volatile变量时，JMM会把该线程对应的工作内存设置为无效，直接从主内存中读取共享变量。

所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取。

内存屏障（也称内存栅栏，内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作），避免代码重排序。内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令 ，通过这些内存屏障指令，volatile实现了Java内存模型中的可见性和有序性，但volatile无法保证原子性 。

内存屏障之前的所有写操作都要回写到主内存，
内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)

粗分

细分

概念：保证不同线程对某个变量完成操作后结果及时可见，即该共享变量一旦改变所有线程立即可见

volatile变量的读写过程：read(读取)→load(加载)→use(使用)→assign(赋值)→store(存储)→write(写入)→lock(锁定)→unlock(解锁)

如果存在数据依赖关系 ，禁止重排序；但重排后的指令绝对不能改变原有的串行语义！这点在并发设计中必须要重点考虑

重排序的分类和执行流程

CAS （CompareAndSwap）
CAS有3个操作数，位置内存值V，旧的预期值A，要修改的更新值B。
当且仅当旧的预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做或重来
当它重来重试的这种行为叫 自旋

demo

上面三个方法都是类似的，主要对4个参数做一下说明。
var1：表示要操作的对象
var2：表示要操作对象中属性地址的偏移量
var4：表示需要修改数据的期望的值
var5/var6：表示需要修改为的新值

CAS这个理念 ，落地就是Unsafe类

它是CAS的核心类，由于Java方法无法直接访问底层系统，需要通过本地（native）方法来访问，Unsafe相当于一个后门 ，基于该类可以直接操作特定内存\ 的数据 。Unsafe类存在于sun.misc包中，其内部方法操作可以像C的指针一样直接操作内存，因为Java中CAS操作的执行依赖于Unsafe类的方法。

注意Unsafe类中的所有方法都是 \ 修饰的，也就是说Unsafe类中的方法都直接调用操作系统底层资源执行相应任务

CAS是靠硬件实现的从而在硬件层面提升效率，最底层还是交给硬件来保证原子性和可见性

实现方式是基于硬件平台的汇编指令，在intel的CPU中(X86机器上)，使用的是汇编指令cmpxchg指令。

核心思想就是：比较要更新变量的值V和预期值E（compare），相等才会将V的值设为新值N（swap）如果不相等自旋再来

是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，
当线程发现锁被占用时，会不断循环判断锁的状态，直到获取。

这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。
若在OpenJDK源码中查看Unsafe.java这里while体现了自旋的思想假如是ture,取反false退出循环；假如是false，取反true要继续循环

demo

循环时间长开销很大

引出来ABA问题

利用 AtomicStampedReference（比较+版本号） 

有几个

常用API

有几个

有几个

有几个

有几个

阿里开发手册规范

使用场景

LongAdder

模拟下点赞计数器，看看性能

源码分析

1.ThreadLocal中ThreadLocalMap的数据结构和关系？
2.ThreadLocal的key是弱引用，这是为什么？
3.ThreadLocal内存泄漏问题你知道吗？
4.ThreadLocal中最后为什么要加remove方法？

实现每一个线程都有自己专属的本地变量副本(自己用自己的变量不麻烦别人，不和其他人共享，人人有份，人各一份)，
主要解决了让每个线程绑定自己的值，通过使用get()和set()方法，获取默认值或将其值更改为当前线程所存的副本的值从而避免了线程安全问题。

ThreadLocal提供线程局部变量。这些变量与正常的变量不同，因为每一个线程在访问ThreadLocal实例的时候（通过其get或set方法）都有自己的、独立初始化的变量副本。 ThreadLocal实例通常是类中的私有静态字段，使用它的目的是希望将状态（例如，用户ID或事务ID）与线程关联起来。

常用的五个方法：两个初始化 一个get 一个set 一个remove 

每个Thread内有自己的实例副本并且该副本只由当前线程自己使用
其他Thread不可访问，那就不存在多线程间共享的问题
统一设置初始值，但是每个线程对这个值的修改都是各自线程相互独立的

一句话：
假如synchronized或者Lock控制资源的访问顺序
利用ThreadLocal人手一份，大家各自安好，没必要抢夺

根据官方API，Thread是程序中执行的线程；ThreadLocal类提供线程局部变量
打开Thread.java类，发现每个Thread类里面有一个ThreadLocal类
而ThreadLocalMap是ThreadLocal的一个静态内部类

不再会被使用的对象或者变量占用的内存不能被回收，就是内存泄露

强引用 Reference

软引用 SoftReference

弱引用 WeakReference

虚引用 PhantomReference

当function01方法执行完毕后，栈帧销毁强引用 tl 也就没有了。但此时线程的ThreadLocalMap里某个entry的key引用还指向这个对象
若这个key引用是强引用，就会导致key指向的ThreadLocal对象及v指向的对象不能被gc回收，造成内存泄漏；
若这个key引用是弱引用，就大概率会减少内存泄漏的问题(还有一个key为null的雷，后面讲)。使用弱引用，就可以使ThreadLocal对象在方法执行完毕后顺利被回收且Entry的key引用指向为null

我们为threadLocal变量赋值，实际上就是当前的Entry(threadLocal实例为key，值为value)往这个threadLocalMap中存放。Entry中的key是弱引用，当threadLocal外部强引用被置为null(tl=null),那么系统 GC 的时候，根据可达性分析，这个threadLocal实例就没有任何一条链路能够引用到它，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话（这个tl就不会被干掉），这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏
所以在不使用某个ThreadLocal对象后，手动调用remove方法来删除它。

一定要进行初始化避免空指针问题ThreadLocal.withInitial(()- > 初始化值)

建议把ThreadLocal修饰为static

用完记得手动remove

对象头

实例数据

对齐填充

http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html

对象布局、GC回收和后面的锁升级就是对象标记MarkWord里面标志位的变化

在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁(monitor)是依赖于底层的操作系统的Mutex Lock(系统互斥量)来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因

Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁

我们说在java中每个对象都可以成为一把锁，因为在JVM中每个对象都一个monitor(监视器锁)。对应到C底层叫做Object Monitor，并用c定义了很多信息。再往下到操作系统中是基于Mutex Lock互斥锁实现，涉及到了用户态和内核态的切换，所以非常耗费资源

synchronized和对象头图

多线程访问情况

升级流程

无锁

偏向锁

轻量级锁

重量级锁

Just In Time Compiler，一般翻译为即时编译器

从JIT角度看相当于无视它，synchronized(o)不存在了，
这个锁对象并没有被共用扩散到其它线程使用，
极端的说就是根本没有加这个锁对象的底层机器码，消除了锁的使用

假如方法中首位相接，前后相邻的都是同一个锁对象，那JIT编译器就会把这几个synchronized块合并成一个大块，
加粗加大范围，一次申请使用即可，避免次次都申请和释放锁，提升了性能

在无锁状态下，Mark Word中可以存储对象的identity hash code值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的identity hash code值并将该值存储到Mark Word中。

对于偏向锁，在线程获取偏向锁时，会用Thread ID和epoch值覆盖identity hash code所在的位置。如果一个对象的hashCode()方法己经被调用过一次之后，这个对象不能被设置偏向锁。因为如果可以的化，那Mark Word中的identity hash code必然会被偏向线程Id给覆盖，这就会造成同一个对象前后两次调用hashCode()方法得到的结果不一致。

升级为轻量级锁时，JVM会在当前线程的栈帧中创建一个锁记录(Lock Record)空间，用于存储锁对象的Mark Word拷贝，该拷贝中可以包含identity hash code，所以轻量级锁可以和identity hash code共存，哈希码和GC年龄自然保存在此，释放锁后会将这些信息写回到对象头。

升级为重量级锁后，Mark Word保存的重量级锁指针，代表重量级锁的ObjectMonitor类里有字段记录非加锁状态下的Mark Word，锁释放后也会将信息写回到对象头。

字面意思

技术解释

和AQS有关的

进一步理解锁和同步器的关系

加锁会导致阻塞

解释说明

AQS基本结构

AQS自身

内部类Node

ReentrantLock的原理

从最简单的lock方法开始看看公平和非公平

非公平锁走起，方法lock()

源码解读

读写锁定义为
一个资源能够被 多个读线程 访问，或者被 一个写线程 访问，但是不能同时存在读写线程。

『 读写锁 ReentrantReadWriteLock 』 并不是 真正意义上的读写分离， 它只允许读读共存，而读写和写写依然是互斥的，
大多实际场景是 “读/读”线程间并不存在互斥关系 ，只有"读/写"线程或"写/写"线程间的操作需要互斥的。因此引入ReentrantReadWriteLock。
   
一个ReentrantReadWriteLock同时只能存在一个写锁但是可以存在多个读锁，但不能同时存在写锁和读锁( 切菜还是拍蒜选一个 )。 
也即 一个资源可以被多个读操作访问或一个写操作访问 ，但两者不能同时进行。 
  
只有在读多写少情境之下，读写锁才具有较高的性能体现

锁降级：将写入锁降级为读锁(类似Linux文件读写权限理解，就像写权限要高于读权限一样)

读写锁降级演示

源码解析

1.公平性：支持公平性和非公平性。
2.重入性：支持重入。读写锁最多支持65535个递归写入锁和65535个递归读取锁。
3.锁降级：遵循获取写锁、获取读锁在释放写锁的次序，写锁能够降级成为读锁
4.读写锁除了读读不互斥，读写、写读、写写都是互斥的

StampedLock是JDK1.8中新增的一个读写锁，也是对JDK1.5中的读写锁ReentrantReadWriteLock的优化。
邮戳锁也叫票据锁
stamp（戳记，long类型）代表了锁的状态。当stamp返回零时，表示线程获取锁失败。并且，当释放锁或者转换锁的时候，都要传入最初获取的stamp值。

锁饥饿问题

如何缓解锁饥饿问题？

StampedLock类的乐观读锁闪亮登场

所有获取锁的方法，都返回一个邮戳（Stamp），Stamp为零表示获取失败，其余都表示成功；

所有释放锁的方法，都需要一个邮戳（Stamp），这个Stamp必须是和成功获取锁时得到的Stamp一致；

StampedLock是不可重入的，危险(如果一个线程已经持有了写锁，再去获取写锁的话就会造成死锁)

StampedLock有三种访问模式

StampedLock 不支持重入，没有Re开头

StampedLock 的悲观读锁和写锁都不支持条件变量（Condition），这个也需要注意。

使用 StampedLock一定不要调用中断操作，即不要调用interrupt() 方法

如果需要支持中断功能，一定使用可中断的悲观读锁 readLockInterruptibly()和写锁writeLockInterruptibly()