as875784622的博客

计算结果存在依赖关系，这两个线程串行化（上一步的运算结果可以传给下一步），计算结果存在依赖关系，这两个线程串行化，接收任务的处理结果，并消费处理，无返回结果。哪个线程计算的速度快就返回哪个线程。对多个线程的计算结果进行合并计算。当前步骤报错，可以继续往下走。当前步骤报错，不会往下执行。

如果计算正确代码执行 whenComplete，计算错误则走 exceptionally。这与vue3.X前端获取接口的使用方式大致一样。假如在某东平台，需要比较多个入住商家卖《java编程思想》这本书，分别卖多少钱。希望的结果是输出，同一个产品在不同商家的价格清单。作用基本一样，只是使用join没有异常检查，而get有异常检查且必须抛出异常。whenComplete 直接获取对应的返回结果。

【代码】CompletableFuture基础用法。

并发：是在同一个实体上的多个事件，是在一台处理器上“同时”处理多个任务，同一个时刻，其实只有一个时间发生。并行：是在不同实体上的多个事件，是在多台处理器上同时处理多个任务，同一个时刻，大家都在做事情，各做个的事情互相不干扰。

有没有比读写锁更快的锁？：邮戳锁（票据锁）无锁--》独占锁--》读写锁--》邮戳锁StampedLock: 是jdk1.8中新增的一个读写锁，是对jdk1.5中读写锁ReentrantReadWriteLock的优化。stamp 戳记，代表锁的状态。当stamp返回零时，代表线程获取锁失败。并且当释放锁或者转换锁的时候，都要传入最初获取的stamp值。是由锁饥饿问题引出。

假设有1000个线程，其中读锁999个，写锁1个，每个读锁要读取10s，这样会造成写锁一直抢不到锁的情况，出现锁饥饿的问题。必须等到读锁释放锁后，获取写锁。因为读的线程特别多，而且读写锁中的读锁是一种悲观锁，没有读完是不会释放的，所以会造成写锁长时间获取不到锁，出现锁饥饿的现象。如果同一个线程持有了写锁，在没有释放写锁的情况下，它还可以继续获取读锁。遵循锁降级次序策略：先获取写锁-再获取读锁--在释放写锁，没有阻塞正常释放锁结束。遵循获得写锁---》再获取读锁---》再释放写锁的次序，写锁能降级成为读锁。

锁粗化，JIT 会将首尾相接，前后相邻且都是锁同一个对象的代码块，JIT即时编译器就会把这几个synchronized块合并为一个大块。JIT即时编译器对锁的优化。

synchronized锁优化的背景用锁能够实现数据的安全性，但是会带来性能的下降无锁能够基于线程并行提升程序性能，带来安全性的下降java5 synchronized默认是重量级锁，java6以后引入偏向锁和轻量锁，java15 逐步废弃了偏向锁锁升级的过程无锁---》偏向锁（一个线程重复请求）---》轻量锁(cas)---》重量锁为什么每个对象都可以成为一个锁？Monitor 可以理解为一种同步工具，也可以理解为一种同步工具，常常被描述为一个java对象。