java并发编程

Guava采用的是令牌桶算法，其核心是想通过限流器，必须拿到令牌

令牌桶算法

只需要记录下一个令牌产生的时间，并动态更新它，就能够轻松完成限流功能

BIO模型里，所有read()操作和write()操作都会阻塞当前线程，建立连接不发数据read()操作会一直阻塞

使用BIO模型，一般会为socket分配一个独立的线程，对于现在互联网场景，BIO线程模型无法解决百万连接问题。

Handler指I/O句柄，其中handler_event方法处理I/O事件，也就是每个Event Handler处理一个I/O handler;get_Handle()方法可以返回这个I/O的Handler

核心是Reactor类，register_handler()和remove_handler()可以注册和删除一个事件处理器

Netty中最核心的概念是事件循环（EventLoop）,负责监听网络事件并调用事件处理器进行处理。

一个网络连接只会对应到一个java线程，避免了各种并发问题

处理TCP连接请求和读写请求是通过两个不同的socket完成的。

另一个核心概念是EventLoopGroup,一般会创建两个EventLoopGroup,一个称为bossGroup,一个称为workerGroup。

1. 创建一个事件处理器

2. 创建了bossGroup和workGroup

3. 之后创建并初始化了ServerBootstrap

1. 内存分配更加合理，使用RingBuffer数据结构，数组在初始化时一次性全部创建，提升缓存命中率；对象循环利用，避免循环GC

2. 能够避免伪共享，提升缓存利用率

3. 采用无锁算法，避免频繁加锁、解锁的性能消耗

4. 支持批量消费，消费者可以无锁方式消费多个消息

RingBuffer本质也是数组，但是做了很多优化，其中一项是和内存分配有关的

程序的局部性原理 （在一段时间内的程序会限定在一个局部范围）

什么是伪共享

如何避免

利用管程实现的

本质和线程池一样，属于池化资源，作用是避免重量级资源的频繁创建和销毁，也就是避免数据库连接频繁创建和销毁

执行数据库操作步骤

FastList 解决了哪些性能问题

ConcurrentBag解决了哪些性能问题 （使用threadlocal避免并发）

本质是一种计算模型，所有的计算都是在Actor中执行的

需借助第三方类库Akka

Actor中的消息机制完全是异步的。而调用对象方法，实际上是同步的。

调用对象方法，需要持有对象的引用，所有的对象必须在同一个进程中

发送、接收消息的Actor可以不在一个进程，也可以不在同一台机器

基础的计算单元

接收消息可以做的事情

启动了4个线程来执行累加操作。整个程序没有锁，也没有CAS，但是程序是线程安全的

STM:软件事物内存，简称STM

借助第三方库，Multiverse是不错选择，将转账操作放到atomic(()->{ })

全称是 Multi-Version Concurrency Controll,也就是多版本并发控制

数据库事务开启时，会给数据库打一个快照，以后所有读写都基于这个快照。

STMTxn三个核心方法：读数据get()方法，写数据的set()方法和提交事务的commit()方法（互斥锁)

创建线程简单，只需要一行代码搞定

实现echo程序的服务端，用的是Thread-Per-Message模式，为每个建立的socket分配一个协程，方案更加简单。

协程的等待成本比线程低，所以基于协程实现同步非阻塞是一个可行方案。（OpenResty里实现的cosocket是一种同步非阻塞方案）

会使书写顺序和执行顺序不一致

可以使用三种基本控制结构来代替goto

不要以共享内存方式通信，要以通信方式共享内存

Golang中协程之间通信推荐的是使用channel

容量为0的channel在Golang中称为无缓冲的channel

容量大于0的称为有缓冲的channel

支持双向传输，可以将双向的channel变成单向的channel

Actor模型中没有channel

Actor模型发送消息是非阻塞的，而CSP模型中是阻塞的

CSP模型中，是能保证消息百分百送达的，可能会导致死锁

单核时代，所有的线程都在一颗CPU上执行，CPU缓存与内存的数据一致性容易解决。因为一个线程对缓存的写，对另外一个线程来说一定是可见的。

多核时代，每颗CPU都有自己的缓存，当多线程在不同的CPU上执行时，这些线程操作的是不同的CPU缓存，这时就不具备可见性了。

操作系统允许某个进程执行一小段时间，例如50毫秒，过了50毫秒操作系统就会重新选择一个进程来执行（称为“任务切换”），这50毫秒称为“时间片”。

任务切换的时机大多数是在时间片结束的时候，高级语言里一条语句往往需要多条CPU指令完成。操作系统做任务切换，可以发生在任何一条CPU指令执行完。

把一个或者多个操作在CPU执行的过程中不被中断的特性称为原子性。

利用双重检查创建单例对象，在new操作时（可能触发空指针异常）

是java虚拟机规范定义的，用来屏蔽掉java在各种不同的硬件和操作系统对内存的访问的差异，这样就可以实现java程序在各种不同的平台上能达到内存访问的一致性。

底层怎样实现

volatile关键字并不是java语言的特产，古老的C语言也有，它最原始的意义就是禁用CPU缓存。

变量X可能被CPU缓存而导致可见性问题（1.5版本对volatile语义进行了增强，加入了Happens-Before规则）

①程序顺序性规则

②volatile变量规则

③传递性

④管程中锁的规则

⑤线程start()规则

⑥线程join()规则

final修饰变量时，初衷是告诉编译器：这个变量生而不变，可以可劲儿优化。

在1.5以后java内存模型对final类型变量的重排进行了约束。现在只要我们提供正确构造函数没有“逸出”，就不会出问题。(一定要避免逸出)

同一时刻只有一个线程执行称之为互斥

线程进入临界区之前，首先尝试加锁lock(),如果成功，则进入临界区，此时线程持有锁；否则就等待，直到持有锁的线程解锁；持有锁的线程执行完临界区的代码后，执行unlock().

优化后增加了受保护的资源R，其次要保护资源R就得为它创建一把锁LR；最后针对这把锁LR，我们还需在临界区添上加锁操作和解锁操作。

另外，在锁LR和受保护资源之间用一条线做了关联。

修饰范围

具体实现

隐式规则

受保护资源和锁之间的关联关系是N：1的关系

用不同的锁对受保护资源进行精细化管理，能够提升性能。（细粒度锁）

用每个资源一把锁就可以了

this这把锁可以保护自己的余额this.balance,却保护不了别人的余额target.balance

锁能覆盖所以受保护资源

用Account.class作为共享锁。Account.class是所有Account对象共享的，而且这个对象是java虚拟机在加载Account类的时候创建的，不用担心它的唯一性。

代码： synchronized(Account.class) { if (this.balance > amt) { this.balance -= amt; target.balance += amt; } }

1.互斥，共享资源X和Y只能被一个线程占用

2.占用且等待，线程T1已经取得共享资源X，在等待共享资源Y的时候，不释放共享资源X；

3.不可抢占，其他线程不能强行抢占线程T1占有的资源

4.循环等待，线程T1等待线程T2占有的资源，线程T2等待线程T占有的资源，就是循环等待。

1.破坏占用且等待条件

2.破坏不可抢占条件

3.破坏循环等待条件

同一时刻，只允许一个线程进入synchronized保护的临界区，当有一个线程进入临界区，其他线程就只能进入等待队列里等待。

这个等待队列和互斥锁是一对一的关系，每个互斥锁都有自己独立的等待队列。

当调用wait()方法后，当前线程会被阻塞，并且进入到等待队列中，这个等待队列也是互斥锁的等待队列。

线程在进入等待队列的同时，会释放持有的互斥锁，线程释放锁后，其他线程就有机会获得锁，并进入临界区了。

notify()是会随机地通知等待队列中的一个线程，而notifyAll()会通知等待队列中的所有线程。

什么是线程安全？

如何写出线程安全的程序？

是指某个操作无法执行下去（如死锁、活锁、饥饿）

阿姆达尔(Amdahl)定律

Java SDK并发包里之所以有那么多东西，有很大一部分原因就是要提升在某个特定领域的性能。

解决方法

性能度量的指标

指的是管理共享变量以及对共享变量的操作过程，让他们支持并发。 （每个加锁的对象都绑定着一个管程（监视器））

synchronized关键字、wait()、notify()、notifyAll()

Hasen模型

Hoare模型

MESA模型

除非经过深思熟虑，否则尽量使用notifyAll()

满足的三个条件

管程就是一个对象监视器。任何线程想要访问该资源，就要排队进入监控范围。进入之后，接受检查，不符合条件，则要继续等待，直到被通知，然后继续进入监视器。

初始状态、可运行状态、运行状态、休眠状态和终止状态。

1.NEW（初始化状态）

2.RUNNABLE（可运行 / 运行状态）

3.BLOCKED（阻塞状态）

4.WAITING（无时限等待）

5.TIMED_WAITING（有时限等待）

6.TERMINATED（终止状态）

1. RUNNABLE 与 BLOCKED 的状态转换

2. RUNNABLE 与 WAITING 的状态转换

3. RUNNABLE 与 TIMED_WAITING 的状态转换

4. 从 NEW 到 RUNNABLE 状态

5. 从 RUNNABLE 到 TERMINATED 状态

本质是提高程序性（指标）

“降低延迟，提高吞吐量”的方法

如果CPU和I/O设备的利用率都很低，那么可以尝试通过增加线程来提高吞吐量

CPU 密集型计算 （cpu计算时间长）

I/O 密集型的计算 （I/O计算时间长）

CPU的堆栈寄存器

局部变量就是放到栈里

关系

是否存在并发？

方法里的局部变量，因为不会和其他线程共享

仅在单线程内访问数据

将属性和实现细节封装在对象内部，外界对象只能通过目标对象提供的公共方法来间接访问这些内部属性

这些约束条件，决定了并发访问策略,可能存在竞态条件。

方案

原则

① 能够响应中断 （当我们给阻塞的线程发送中断信号的时候，能够唤醒它）

② 支持超时（没有获取到锁，不是进入阻塞状态，而是返回一个错误）

③ 非阻塞地获取锁 （获取锁失败，并不是进入阻塞状态，而是直接返回）

利用了volatile相关的Happens-Before规则

可重入锁：线程可以重复获取同一把锁

可重入函数：多个线程可以同时调用该函数

如果传入true就表示需要构造一个公平锁，反之表示构造一个非公平锁

① 永远只在更新对象的成员变量时加锁

② 永远只在访问可变的成员变量时加锁

③ 永远不在调用其他对象的方法时加锁

Lock&Condition实现管程只能使用前面的await()、signal()、signalAll()

synchronized实现的管程才使用wait()、notify()、notifyAll()

通俗点讲就是调用方是否需要等待结果，如果需要等待结果，就是同步；如果不需要等待结果，就是异步。

让程序支持异步的实现

调用线程通过调用 get() 方法等待 RPC 返回结果

当 RPC 结果返回时，会调用 doReceived() 方法，这个方法里面，调用 lock() 获取锁，在 finally 里面调用 unlock() 释放锁，获取锁后通过调用 signal() 来通知调用线程，结果已经返回，不用继续等待了。

普遍翻译为“信号量”，以前被翻译成信号灯。在编程世界里，线程能不能执行，也要看信号量是不是允许。

提出者：迪杰斯特拉，提出后一直都是并发编程的终结者，直到1980管程被提出才有第二选择

计数器

等待队列

三个方法

进入临界区之前执行一下 down() 操作，退出临界区之前执行一下 up() 操作就可以了。（acquire() =》 down() 操作，release() =》 up() 操作。）

两个线程 T1 和 T2 同时访问 方法过程

① 假设对象池的大小是 10，那么前 10 个线程调用 acquire() 方法，都能继续执行，相当于通过了信号灯，而其他线程则会阻塞在 acquire() 方法上。

② 通过信号灯的线程，分配了一个对象 t（这个分配工作是通过 pool.remove(0) 实现的），分配完之后会执行一个回调函数 func，而函数的参数正是前面分配的对象 t

③ 执行完回调函数之后，它们就会释放对象（这个释放工作是通过 pool.add(t) 实现的），同时调用 release() 方法来更新信号量的计数器。

④ 如果此时信号量里计数器的值小于等于 0，那么说明有线程在等待，此时会自动唤醒等待的线程。

概念

基本原则

与互斥锁的区别

① 首先声明了一个 Cache<K, V> 类（HashMap）,HashMap 不是线程安全的，这里用读写锁 ReadWriteLock 来保证其线程安全

② ReadWriteLock 是一个接口，它的实现类是ReentrantReadWriteLock，通过它创建了一把读readLock()和一把写锁writeLock()

如果缓存中没有缓存目标对象，那么就需要从数据库中加载，然后写入缓存，写缓存需要用到写锁，调用了 w.lock() 来获取写锁。

获取写锁之后，我们并没有直接去查询数据库，而是重新验证了一次缓存中是否存在，再次验证是否存在，我们才去查询数据库并更新本地缓存

再次验证能够避免高并发场景下重复查询数据的问题。

锁的升级：先是获取读锁，然后再升级为写锁（在ReadWriteLock 不支持的）

锁的降级：释放写锁前，降级为读锁（获取读锁的时还是持有写锁的）

加载进缓存的数据不是长久有效的，而是有时效的，当缓存的数据超过时效，也就是超时之后，这条数据在缓存中就失效了。而访问缓存中失效的数据，会触发缓存重新从源头把数据加载进缓存。

读锁

写锁

数据库的version 字段就类似于 StampedLock 里面的 stamp。

读多写少的场景 性能很好，基本上可以替代 ReadWriteLock，但是 StampedLock 的功能仅仅是 ReadWriteLock 的子集

StampedLock 不支持重入

StampedLock 的悲观读锁、写锁都不支持条件变量

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

每次创建新的新的线程是一个耗时的操作，后面对计数器执行减1操作，通过latch.countDown()来实现，在主线程中通过调用latch.await()来实现对计数器等于0的等待。

两次查询操作能够和对账操作并行，对账操作依赖查询操作的结果，是生产者消费者模型，需要有个队列，来保存生产者生产的数据，而消费者则从这个队列消费数据。

线程 T1 和线程 T2 的工作要步调一致，不能一个跑得太快，一个跑得太慢，只有这样才能做到各自生产完 1 条数据的时候，通知线程 T3。

CyclicBarrier 是一组线程之间互相等待

CyclicBarrier 的计数器是可以循环利用的

组合操作需要注意竞态条件问题，即便每个操作都能保证原子性，也不能保证组合操作的原子性。

在容器领域一个容易被忽视的“坑”是用迭代器遍历容器。

（一） List

（二） Map

(三) Set

(四) Queue

提供了CAS指令（Comare And Swap,即“比较并交换”）

自旋

带来的问题：ABA问题（两个A虽然相等，但是第二个A的属性可能已经发生变化了。所以）

1.原子化的基本数据类型

2.原子化的对象引用类型

3.原子化数组

4.原子化对象属性更新器

5.原子化的累加器

线程池的使用方是生产者，线程池本身是消费者。

核心是 ThreadPoolExecutor

强烈建议使用有界队列（无界队列易导致OOM错误）

默认拒绝策略要慎重使用（当任务过多会触发执行拒绝策略）

注意异常处理问题，捕获所有异常并按需处理

3个submit方法

1个FutureTask工具类

Future 接口5个方法

将 FutureTask 对象提交给 ThreadPoolExecutor 去执行。

利用 FutureTask 对象可以很容易获取子线程的执行结果。

1.无需手工维护线程，没有繁琐的手工维护线程的工作

2.代码更简练并且专注于业务逻辑，几乎所有代码都是业务逻辑相关的

3.语义更清晰

1. static CpmpeltableFuture<void> runAaync(Runnable runnable)

2. static <U> CompletableFuture<U> supplyAsync<Supplier<U> supplier>

3. static CompletableFuture<void> runAsync(Runnable runnable,Executor executor)

4. static <U> CompletableFuture<U> runAsync(Runnable runnable,Executor executor)

1.描述串行关系

2.描述AND汇聚关系

3.描述OR汇聚关系

4.异常处理

Future <V> submit(Callable<V> task);

Future<V> submit(Runnable task,Vresult);

Future<V> task() throws InterruptedException;

Future<V> poll();

Future<V> poll(long timeout,TimeUnit unit) throws InterruptedException;

Dubbo有一种叫做Forking集群模式，在这种模式下，并行地调用多个查询服务，只要一个成功返回，整个服务就可以返回了（缺点是消耗资源偏多）

一个阶段是任务分解，也就是将任务迭代地分解子任务，直至直接计算出结果

另一个阶段是结果合并，即逐层合并子任务的执行结果，直至获得最终结果

是一个并行计算框架，主要用来支持分治任务模型

Fork对应的是分治人物模型里的任务分解，Join对应的是结果合并

核心组件是ForkJoinPool,本质是一个生产者--消费者模式的实现，内部有多个任务队列，当我们通过ForkJoinool的invoke()或者submit()方法提交时，根据一定的路由规则提交到任务队列中，支持一种“任务窃取”的机制，如果其他线程空闲了可以窃取。

执行完后break

循环结束前增加Thread.sleep(随机时间)

更安全

不变性模式：简单来讲，就是对象一旦被创建之后，状态就不再发生变化

将一个类所有的属性都设置成final的，并且只允许存在只读方法，那么这个类基本上就具备不可变性了

利用享元模式可以减少创建对象的数量，从而减少内存占用

本质

对象的所有属性都是final,并不能保证不可变性

不可变对象也需要正确发布

java领域：CopyOnWriteArrayList和CopyOnWriteArrayAet由于无锁，所以将性能发挥到极致

操作系统领域：Btrfs(B-Tree File System)、aufs(advanced multi-layered unification )

函数式编程领域

Docker 容器镜像设计、分布式源码管理系统、Git

体现的是一种延时策略，只有在真正需要复制的时候才复制，而不是提前复制好（还支持按需复制）

一个线程调用ThreadId的get()方法，两次get()返回值相同

两个线程分别调用ThreadId的get()方法，两个线程的get()返回值是不同的

Thread这个类内部有一个私有属性threadLocals,其类型就是ThreadLocalMap,ThreadLocalMap的Key是ThreadLocal.每一个threadLocal对应一个Object类型的Value值

线程池和程序是同生共死的。

Thread持有的ThreadLocalMap一直都不会被回收，再加上ThreadLocal中Entry对ThreadLocal是弱引用，只要结束生命周期就被回收掉。

但Entry中的Value却被Entry强引用，所以Value的生命周期结束了，value也是无法被回收了。

JVM不能做到自动释放对Value的强引用，可以用try{}finally{}方案，手动释放资源

子线程继承父线程的线程变量

线程池中创建线程是动态的，很容易导致继承关系错乱

保护性地暂停：一个对象GuardedObject,内部有一个成员变量（受保护对象），以及两个成员方法get(Predicate<T> p)和onChanged(T obj）,参数p来描述前提条件，onChanged()就是提供对应的服务

本质上是一种等待唤醒机制的实现，只不过Guarded Suspension 模式将其规范化了

扩展后的GuardedObject内部维护了一个Map,其Key是MQ消息id,而Value是GuardedObject对象实例

增加了静态方法create()和fireEvent()

放到多线程场景里，就是一种“多线程版本的if”

是将edit()方法中对共享变量changed的赋值操作抽取到了change()中，这样的好处是将并发处理逻辑和业务逻辑分开

在某些特定场景下，也可以使用volatie来实现，但使用volatile的前提是对原子性没有要求

之所以采用scheduleWithFixedDelay()这种调度方式能保证同一时刻只有一个线程执行方法

将init()声明为一个同步方法，这样在同一时刻只有一个线程能够执行init()方法

用Balking模式来实现线程安全的单例模式

委托他人办理的方式，在并发编程领域总结为一种设计模式，简言之就是为每个任务分配一个独立的线程

网络编程里服务端的实现

实现方案的痛点

基于操作系统

基于轻量级线程池

Work Thread对应到现实世界里，其实就是车间里的工人。

是用阻塞队列做任务池，然后创建固定数量的线程阻塞队列中的任务。（类似于线程池）

java的线程池能够避免无限制地创建线程导致OOM，也能无限制接收任务导致OOM，建议创建有界的队列来接收任务

在创建线程池时，清晰地指明拒绝策略。

在实际工作中给线程赋予一个业务相干的名字

现象

方案

第一阶段主要是线程T1向线程T2发送终止指令

第二阶段是线程响应终止指令

监控系统发送采集指令给被监控系统的监控代理，监控代理接收到指令后，从监控目标收集数据，然后回传给监控系统。

shutdown()方法

shutdownNow()方法

任务队列

解耦

支持异步

生产者线程只需将数据添加到任务队列，然后消费者线程负责将任务从任务队列中批量取出并批量执行。

异步刷盘本质是一种分阶段提交

Thread-per-Message模式

Worker Thread模式

生产者-消费者模式