并发与并行
并发：多个线程轮流使用CPU执行任务，将CPU的时间分割成合适大小的时间片，每一个线程拿到时间片之后就会利用CPU资源执行任务，当时间到了之后就会把CPU资源释放，并且保存线程的上下文，比如程序计数器，栈帧等资源。由于CPU执行速度很快，所以用户肉看看不出程序的停顿 ，看起来是多个事务同时运行。
并行：本来就是一批线程运行在一个CPU核上，另一批运行在另一个核上，他们之间不需要抢夺CPU资源，天然的并行。
线程与线程池的状态
线程的状态
（1）初始化：创建线程
（2）运行：
就绪状态：线程已经准备好，还没有拿到CPU时间片。例如：线程调用start()、线程sleep()结束、线程时间片用完、线程拿到对象锁等。
运行中状态：已经拿到CPU时间片，开始运行
（3）阻塞BLOCKED：等待阻塞、同步阻塞、其他阻塞，例如等待锁资源释放的时候会进入阻塞状态，自旋一段时间如果获取不到锁就释放CPU，状态由用户态转为内核态，由内核统一维护一个entry list存放阻塞的线程。
（4）等待WAITING：例如执行wait方法，底层调用的是unsafe.park()，执行wait方法的线程会被挂起，自动释放CPU和锁资源，状态从用户态转为内核态，由内核统一维护一个wait set存放需要等待通知的线程，WAITING需要显式的被唤醒。当调用notify方法会从wait set里面挑一个线程放入entry list，然后从entry list里挑一个线程唤醒去抢锁。
（5）超时等待：例如执行sleep(time)/wait(time)，不会释放锁资源，执行wait(time)，到达时间自动唤醒
（6）终止：线程run方法结束之后就终止了，虽然它可能是活的，但是不能继续执行任务，因为线程一旦终止就不能复生。
2.2. BLOCKED VS WAITING状态
BLOCKED状态针对的是线程竞争锁失败而设定的；WAITING状态针对的时线程条件等待唤醒而设定的。这两个状态首先场景不同，而且两种状态的设定可以让排查问题的时候更方便定位，一种是锁饥饿，一种是业务等待。
线程池状态
（1）RUNNING：正在运行，可以接受新任务。其中核心线程会阻塞式地获取任务，因此不会进入终止状态
（2）SHUTDOWN：调用shutdown()，从RUNNING->SHUTDOWN，不接受新任务，只处理任务队列中的任务
（3）STOP：调用shutdownNow()，从RUNNING/SHUTDOWN - > STOP，不接受新任务也不处理现有任务
（4）TIDYING：所有任务都已经执行完毕，并且活跃线程数为0。SHUTDOWN/STOP在任务都执行完的情况下进入TIDYING。之后会调用terminated()方法
（5）TREMINATED：TIDYING状态下执行terminated()进入终止状态u。
多线程主要解决什么问题？
（1）首先它是一种池化的概念，可以降低线程创建、销毁带来的开销，提升任务处理的响应速度。例如 Web 容器建立成千上万的 HTTP 连接。
（1）提升吞吐量（单位时间干更多活）：券平台在过滤券配置时并行过滤。
（2）降低接口延时：对于密集计算用线程池并行，监控日志上报单独开线程池批量定时发送降低主接口的延时。
（3）
start run wait sleep notify notifyAll的作用
start vs run：
start：
启动线程执行，此时线程出于就绪状态，等待CPU时间片，拿时间片之后就执行run方法。这就是真正启动线程了，各个线程之间是异步的效果
run：
就是线程类的普通方法，是线程体，如果使用Thread.run()，那它依然是主线程去执行这个run方法，开再多线程也是同步执行
wait vs sleep：
所属类不同：wait属于Object、sleep属于Thread
使用场景不同：wait必须在synchronized同步代码块内执行否则抛异常，sleep可以任意处执行。
释放锁资源不同：wait会释放锁，sleep不会
唤醒方式不同：wait方法需要通过notify、notifyAll唤醒，sleep可以主动唤醒。
线程进入状态不同：调用wait方法进入WAITING状态，调用sleep方法进入TIME_WAITING状态
notify：
属于Object的，执行notify方法会随机唤醒一个线程进入争夺队列取争夺锁资源
notifyAll
唤醒所有线程。
线程池与线程的创建方法
线程的创建方法：
继承Thread类、实现Runnable接口、实现Callable接口、线程池ExecutorService
线程池的创建方法：
Executors：线程池工具类（一般不用），创建固定的线程池：
newFixedThreadPool(线程数目)：请求队列无界，可能会产生OOM
newChachedThreadPool：线程数量无界，可能会OOM
newSingleThreadPool：请求队列无界，可能会产生OOM
newScheduledThreadPool：线程数量无界，可能会OOM
TreadPoolExecutors：自定义线程池
答：主要的配置有四点：核心线程数、最大线程数、工作队列和拒绝策略
核心线程数和最大线程数和CPU核数、任务类型有关，对于CPU密集型和IO密集型，配置是不一样的。
有一种公式：CPU密集型：N、N+1，IO密集型：N、2N+1
另一种公式：线程数=
IO密集型任务等待时间很长，这就意味着可以给更多的线程，在IO阻塞的时候处理别的就绪的IO
CPU密集型任务大部分时间都在做计算，给过多线程用处不大，还会增加上下文切换的开销
但是！实际上一般会先按照公式设一个初值，根据可接受的接口响应耗时来进行压测，根据压测情况调整
工作队列：SynchronousQueue（同步队列）、ArrayBlockingQueue（有界队列）、LinkedBlockingQueue（无界队列）、PriorityQueue（优先级队列）
拒绝策略：AbortPolicy（丢弃并抛异常），discardPolicy（直接丢弃），discardOldestPolicy（丢弃最早进入队列的，然后把这次任务加入队列），CallersRunPolicy（谁调用谁执行，除非线程池shutdown，则丢弃任务）。
线程池状态：
Running：接收新任务
shutdown：不接受新任务，处理现有任务
stop：不接受新任务也，中断现有的任务，直接停止工作
tidying：如果所有任务都已终止，并且有效线程数（workerCount）为0，然后调用terminated()钩子u方法进入terminated状态。
terminated：彻底终止
线程池创建之后，里面就有线程吗？
没有，但是可以进行线程池的预热，调用prestartAllCoreThreads（预热所有核心线程）、prestartCoreThreads（预热一个线程）
核心线程数会被回收吗？
核心线程默认不会被回收，可以调用allowCoreThreadTimeOut 设置为true。
五、线程安全的三大要素
答：
原子性：一个操作或者多个操作要么全部执行，要么都不执行，执行的过程中不会被打断。
例如：synchronized（monitorenter、monitorexit底层也是使用内存屏障实现的）、原子类、值赋值、引用的赋值。
可见性：多线程访问同一个变量时，一个线程修改了变量值，其他线程立即能看到
synchronized与lock（释放锁时会将变量值刷回主内存）、volatile（强制刷回主内存）
有序性：线程执行的顺序。程序编译时处理器和编译器会进行指令重排，指令重排对单线程没有影响，但是会影响多线程。
synchronized和lock、volatile、happens-before原则（如果满足，则可以指令重排）
六、线程调度
Linux：进程调度线程。调度策略：分时调度、先到先服务、时间片轮转
Windows：基于优先级和抢占调度算法调度线程
Java线程调度：协同式调度（线程自己决定执行多久，执行完了才会切换）、抢占式调度（操作系统分配执行时间）
七、多线程异步编程
对于线程执行结果有组合关系的时候可以使用ContDownLatch、CyclicBarrier、CompletableFuture
ContDownLatch：
CyclicBarrier：多个线程在一个屏障处等待，latch扣减为0之后会继续回复原始数值，进行下一轮循环。
public static void main(){
CyclicBarrier latch = new CyclicBarrier(2);
Thread t1 = new Thread(MyThread);
t1.start();
// 主线程执行到这里等待 latch被扣减为0再继续执行。，t1的run方法里还有finally代码块会再执行一次latch.await()
latch.await();
Thread t2 = new Thread(MyThread);
t1.start();
// 主线程执行到这里等待 latch被扣减为0，再继续执行。
latch.await();
Thread t2 = new Thread(MyThread);
t1.start();
// 主线程执行到这里等待 latch被扣减为0，再继续执行。
latch.await();
}
public void MyThread implements Runnable{
private CyclicBarrier cb;
public MyBarrier(CyclicBarrier cb){
this.cb=cb;
}
public void run(){
try{
System.out.println(Thread.currentThread.getName());
}catch{
}finally{cb.await();}
}
}
Future：
实现：
FutureTask
@Override
public UserInfo call(){
return User.getinfo();
}
});
executeService.submit(task);
UserInfo userinfo = task.get(); // 阻塞式获取结果
UserInfo userinfo = task.isDone(); // 轮询式获取结果
然而阻塞获取或者轮询获取都与异步编程相违背。
CompletableFuture：
实现：
CompletableFuture
UserInfo userinfo = task.get(2,TimeUnit.SECONDS);
UserInfo userinfo = task.get();
如果不用单独创建线程池，默认使用ForkJoinPool线程池
supplyAsync方法执行异步任务支持返回值
runAsync方法执行异步任务不支持返回值
get() 和 join() 方法都会阻塞式返回异步调用的结果，但是get会显式抛异常，join会打包异常返回。
任务回调：
一元依赖：一个completableFuture依赖于前一个CF任务的实现
thenRun（）：执行完第一个任务之后再执行第二个任务，二者之间没有参数传递，没有返回值
thenRunAsync（）：如果执行第一个任务传入了自定义的线程池，那么thenRun执行第二个任务的时候还会用这个线程池，但是thenRunAsync（）执行第二个任务不会用自定义线程池，而是用ForkJoin线程池。
thenAccept（）：将前一个Future任务执行完返回的结果作为本次任务的入参，传入回调方法中执行，但是回调方法没有返回值。
public class FutureThenAcceptTest {
public static void main(String[] args) throws ExecutionException, InterruptedException {
CompletableFuture
()->{
System.out.println("原始CompletableFuture方法任务");
return "捡田螺的小男孩";
}
);
CompletableFuture thenAcceptFuture = orgFuture.thenAccept((a) -> {
if ("捡田螺的小男孩".equals(a)) {
System.out.println("关注了");
}
System.out.println("先考虑考虑");
});
System.out.println(thenAcceptFuture.get());
}
}
thenApply（）：将前一个Future任务执行完返回的结果作为本次任务的入参，传入回调方法中执行，但是回调方法有返回值。
public class FutureThenAcceptTest {
public static void main(String[] args) throws ExecutionException, InterruptedException {
CompletableFuture
()->{
System.out.println("原始CompletableFuture方法任务");
return "捡田螺的小男孩";
}
);
CompletableFuture thenAcceptFuture = orgFuture.thenApply((a) -> {
if ("捡田螺的小男孩".equals(a)) {
System.out.println("关注了");
}
System.out.println("先考虑考虑");
});
System.out.println(thenApplyFuture.get());
}
二元依赖：一个CF任务依赖于两个CF任务
thenCombine（）：
CompletableFuture
{ //result1和result2分别为cf1和cf2的结果
return"result4";
});
多元依赖：一个CF任务依赖于多个CF任务
AllOf（）：
CompletableFuture
CompletableFuture
//这里的join并不会阻塞，因为传给thenApply的函数是在CF3、CF4、CF5全部完成时，才会执行 。
result3 = cf3.join();
result4 = cf4.join();
result5 = cf5.join();
//根据result3、result4、result5组装最终result;
return"result";
});
CF的原理：
一个CF对象里面有两个字段：result、stack（Completion链）。result存储的是当前CF任务执行完的结果。stack存储的是CF完成之后触发的动作，这些动作一个一个连在一起形成Completion链。
这里用到了观察者模式。当前CF任务是被观察者，后续依赖它的CF任务是观察者。
对于thenApply方法：
CF2依赖于CF1执行结束。
CF2=CF1.thenApply(()->{return ...})，此时CF1是被观察者、CF2是观察者
thenApply会接收一个函数式参数并把它封装到观察者的实现类UniApply（Completion的实现类）的fn里面作为一个回调函数，然后把UniApply注册到到CF1，也就是说压栈到CF1的stack里面。等CF1执行完毕之后会弹栈，执行回调函数。
对于thenCombine方法：
CF3依赖于CF2和CF1。
CF3=CF1.thenCombine(CF2,()->{ return .....})
这个时候就会把观察者的实现类为观察者的实现类为分别压栈到CF1和CF2里面。CF3会设置两个属性关联被依赖的CF1和CF2。
BiApply会检查依赖的两个CF是否都完成了，使用CAS设置状态避免重复触发。
对于AllOf：
CFn依赖于CF1、CF2...
CF4=CompletableFuture.AllOf(CF1,CF2,CF3);
观察者的实现类为BiRelay，等所有CF执行完成再触发，实际上就是构造一个平衡二叉树，从底往上层层通知直到根节点，触发回调监听。
注意事项：异步回调要传线程池！！！，如果不传，就会用ForkJoinPool的公共线程池，它的核心线程数=处理器数量-1，可能会造成性能瓶颈。
exceptionally（）：回调方法，将前一个任务的异常作为入参
whenComplete（）：某个任务执行完的回调方法，可以拿到上一个方法执行完的结果，无返回值；他返回的依然是上一个任务执行完的结果。
handle（）：某个任务执行完的回调方法，有返回值，是回调方法执行完的结果。
多任务组合处理：
.thenCombineAsync（task1，（s,w）->{ return... },executor）; 把两个任务（一个是task1，一个是当前的任务）的执行结果都作为方法入参传递到指定方法中，并且有返回值。
.applyToEither（）：将已经执行完成的任务作为方法入参，传递到指定方法中，且有返回值。
.allOf（）：等所有任务都执行完才返回结果，如果任意一个任务异常，在执行get方法的时候会抛异常
public class allOfFutureTest {
public static void main(String[] args) throws ExecutionException, InterruptedException {
CompletableFuture
System.out.println("我执行完了");
});
CompletableFuture
System.out.println("我也执行完了");
});
CompletableFuture
System.out.println("finish");
});
}
}
在我的牛券项目里，当用户使用券进行结算的时候，会查询可用券列表，这个时候我把商品券集合和非商品券集合转化为stream，然后分别创建一个CompletableFutureTask.AllOf任务，等待每一张优惠券对应的任务完成（任务的内容就是校验优惠券当前是否可使用，例如是否满足金额门槛，是否满足商品范围等等）。
这里异步执行需要传入线程池，否则会使用ForkJoinPool的线程，核心线程是CPU核数-1，性能会比较差。
最后调用CompletableFutureTask的AllOf方法，等待两个任务（商品券集合任务，非商品券集合任务）执行结束然后。调用thenRun（）方法去对可用优惠券列表的优惠券根据优惠金额进行排序，最后join()阻塞式获取执行结果。
八、CopyOnWriteArrayList
写时复制容器，读的时候不加锁，增删改的时候会加锁并且做同步复制，具体来说就是复制一份原数组，在副本上进行修改，修改结束之后把引用指向新数组。它不能保证强一致性，因为读的时候可能读到的是旧数据，它只能保证最终一致性。
JDK8的时候用的是Reentrantlock加锁，JDK17用的是synchronized加锁
缺点：会产生副本，占用内存，频繁写的情况下会多次复制性能会很差；读的时候可能存在一致性的问题
九、Vector
线程安全的List，使用的是synchronized锁
缺点：
● 它所有方法都是同步的，性能不好。
● 因为vector是线程安全的，所以效率低，这容易理解，类似StringBuffer，同时只能在尾部进行插入和删除操作，更加造成效率低；
● Vector空间满了之后，扩容是一倍，而ArrayList仅仅是一半；
● Vector分配内存的时候需要连续的存储空间，如果数据太多，容易分配内存失败；
十、线程之间如何传递数据
1、TransmittableThreadLocal（TTL）可以进行父子线程间数据传递，父线程创建TTL对象，子线程可以访问TTL内容。
2、线程池内线程共享TTL，使用TtlRunnable类包装Runnable。向线程池里submit TtlRunnable任务。
3、使用TtlExecutor包装线程池，提交任务到Ttl线程池中。
十一、线程池调优
调优的参数：核心线程、最大线程、阻塞队列、拒绝策略
调优的过程：根据CPU密集型和IO密集型、混合型设置线程池参数的初始值，压测根据系统的响应来调整最大线程数（最大线程可能涉及到线程上下文切换带来的开销），选择合适的阻塞队列，对于关键的任务选择CallersRunPolicy，非关键任务可以选择DiscardOldestPolicy。
使用Arthas、Prometheus监测线程池的状态，比如看线程的存活时间、平均处理任务的数量、阻塞队列内的任务数量等。
十二、Collections.synchronizedList()
在我的牛券项目中的用户查询优惠券功能中，我使用CF实现多线程异步编排，这里会并发地将优惠券写入可用和不可用的集合中，此时需要将ArrayList包装成线程安全的SynchronizedList集合。
使用Collections.synchronizedList（new ArrayList<>()）
SynchronizedList底层的每一个方法都被synchronized修饰，但是具体的操作依然是交给ArrayList代理，只是操作前需要获得锁。
十三、Synchronized与ReentrantLock的区别
（1）syn无需手动加锁与释放锁，Reen需要
（2）syn是JVM内置语义，可以进行锁粗化和锁消除，Reen是一个AQS的实子类。
（3）Reen可以实现公平锁，还具有响应中断、超时等待等特性。公平锁的吞吐量不高，一般不用。
十四、AQS
AQS主要包含三个内容：
state（volatile变量）：获取锁的线程通过CAS修改state的值来获取锁
同步队列：负责锁的获取与释放。线程获取锁失败就会封装成Node节点添加至队列尾部，当锁被释放的时候，头节点被唤醒获取锁。
条件队列：基于Condition接口实现，每一个Condition对象都有一个条件队列。当线程获取到锁之后，不满足条件的线程被挂起进入条件队列，直到其他条件显式唤醒。线程调用await()方法后被加入条件队列等待，直到被另一个线程signal()、signalAll()方法唤醒
同步队列与条件队列的区别：
（1）同步队列用于管理锁获取与释放，条件队列用于让线程等待条件满足
（2）同步队列是自动管理，没有获取到锁自动加入同步队列。条件队列可以通过Condition接口暴露给开发者，并且需要显式调用await和signal方法。
（3）对于AQS，同步队列只有一个，条件队列属于Condition对象，可以有多个。
解决并发问题只使用CAS就够了吗？
CAS只能保证原子性，而不能保证并发下的可见性与有序性。使用volatile可以保证可见性，并且通过禁止指令重排来保证有序性。
所以CAS和volatile是互补的，CAS提供原子性操作提高性能，volatile保证可见性与有序性。
CAS如何保证原子性？
CAS底层基于操作系统（硬件层面）cmpxchg指令实现的，CAS对应值的获取、比较、交换三个动作封装在一条cmpxchg指令当中不可中断。
（1）cmpxchg指令是原子性指令，CPU执行的时候会锁定总线，禁止其他CPU访问共享变量，然后比较与交换之后才释放总线。
（2）cmpxchg指令执行期间会禁止CPU中断，确保原子性。
（3）cmpxchg指令是基于硬件实现的，可以保证原子性。
CAS的可见性保障？
cmpxchg基于MESI缓存一致性协议实现，即为CPU所有核心的缓存都一致，一个核心执行cmpxchg，所有核心都会更新数据，确保对变量访问一致。
CAS的ABA问题如何解决？
附加版本号处理
十五、MESI与JMM
JMM：Java内存模型，定义了java的内存交互的规范来确保原子性、可见性和有序性。对于原子性，可以通过synchronized、volatile确保原子性；对于可见性，可以通过volatile、happens-before原则确保；对于有序性，可以通过volatile、sybchronized确保。
MESI：硬件层面的缓存一致性协议，用于确保多核处理器中不同处理器的缓存一致性。主要通过四个状态MESI（Modified、Exclusive、Shared、Invalid）来保证有序性。
具体来说，当一个处理器要修改缓存行数据时，先检查状态
如果时E、S状态，则直接读缓存中的数据，因为此时数据一致
如果是I状态，则读取共享内存中的数据到缓存，再处理
如果是M，则先刷新到主内存，再读主内存数据。
十六、volatile
volatile是java提供的一种轻量级同步机制，因为他不会产生synchronized那样的线程上下文切换。
可见性：volatile变量，JMM会被线程工作内存中信息刷到主内存中。
有序性：volatile会禁止指令重排保证有序性。
不保证原子性：
十七、虚拟线程
定义：虚拟线程是一种轻量级线程（用户线程），它时线程的另一种实现方式，它不同于之前的平台线程对操作系统线程进行封装，虚拟线程时将多个虚拟线程映射到少量的操作系统线程中，可以轻松做到百万级虚拟线程。
传统的平台线程是对操作系统的包装，在线程调度中存在用户态和内核态的切换，开销很大。此外平台线程的数量受到操作系统线程的影响。这样存在的问题：线程空闲状态下没有被释放（例如IO线程），而此时CPU利用率低，导致并发请求过来时无法创建更多线程进而影响并发性能。
过去情况是用异步编程提高并发量，但是异步编程存在大量回调函数，维护成本也很高。
轻量级线程由JVM管理的。传统线程类似于墙上的插座，插座被占满了，但是有些插座压根不通电，虚拟线程相当于在插座上接一个排插出来增加接口数量。
当把虚拟线程名称打印出来时，发现虚拟线程的载体依然是一个平台线程，当运行一百万个虚拟线程，发现平台线程只用了8个。
虚拟线程的载体是平台线程，平台线程有一个任务列表，里面有很多虚拟线程，这些平台线程处于Fork Join Pool中，当虚拟线程阻塞的时候会从平台线程卸载，然后当它恢复之后可以绑定到其他平台线程，也就是说虚拟线程与平台线程不是一一对应的，可以被重新调度到其他平台线程。
虚拟线程使用Thread.ofVirtual()创建
此外，它的创建与销毁中的内存开销低，上下文切换低。
使用：
Thread.startVirtualThread(()->{
System.sout.println();
});
虚拟线程的优势：
1、轻量级线程，不像平台线程那样会有很高的堆栈内存占用
2、线程的上下文切换、创建、销毁的开销小。
3、传统线程模型当IO阻塞时会导致整个线程被阻塞，并且阻塞唤醒有开销，而虚拟线程阻塞的时候可以直接挂起，开销小。
劣势：
1、高并发与高吞吐量，但是做不到低延迟
2
适用场景：
1、阻塞型任务，阻塞期间可以将平台线程资源让渡给其他任务，等结束阻塞之后再绑定到其他平台线程。
2、不适合计算密集型或者CPU密集型，因为它依然是基于平台线程，只是增加了并行的规模。
3、例如Tomcat、Netty都已经支持虚拟线程。
)
)
)
)
安装mysql 8.0.41)
