Java 并发原理

## 1. 分布式事务协议

**Two/Three Phase Commit**





### 1.1 两阶段提交协议：2PC

#### 2PC 成立假设

1. 存在一个节点为协调者（`Coordinator`），其他节点为参与者（`Cohorts`），节点间可以进行通讯
2. 所有节点都预写日志，且日志被写入后即保持在可靠的存储设备上，即使节点损坏也不会导致日志消失
3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复



#### 2PC 流程（阶段）

- **第一阶段：投票阶段**
  1. `Coordinator` 询问所有 `Cohorts` 是否可以执行 **提交操作（`vote`）**，并等待所有 `Cohorts` 响应
  2. `Cohorts` 询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
  3. 所有`Cohorts`响应 `Coordinator` 发起的询问。如果 `Cohorts`的事务实际执行成功，则它返回一个 **“同意”** 消息；如果执行失败，则它返回一个 **“中止”** 消息
- **第二阶段：提交执行阶段**
  - 所有`Cohorts`在第一阶段响应响应为**“同意”**时：
    1. `Coordinator` 向所有`Cohorts`发出 **正式提交（`commit`）** 的请求
    2. `Cohorts` 正式完成操作，并释放在整个事务期间内占用的资源
    3. `Cohorts` 向 `Coordinator` 发送 **“完成”** 消息
    4. `Coordinator`  接收所有 `Cohorts`反馈的 **“完成”** 消息后，完成事务
  - 任意`Cohorts`在第一阶段响应为 **“中止”** 时：
  - `Coordinator` 在第一阶段询问超时前无法获取所有`Cohorts`的响应消息时：
    1. `Coordinator`  向所有参与者发出 **回滚操作（`rollback`）** 的请求
    2. `Cohorts` 利用之前写入的 undo 信息执行回滚，并释放占用的资源
    3. `Cohorts` 向 `Coordinator`  发出 **回滚完成** 消息
    4. `Coordinator`  收到所有 `Cohorts` 节点反馈的 **回滚完成** 消息后，取消事务。
  - 不管最终结果如何，第二阶段都会结束当前事务



#### 2PC 的缺点

1. 执行过程中，所有参与节点都是**事务阻塞型**。当节点占用公共资源时，其他任务不可用
2. `Cohorts` 故障，`Coordinator` 只能等待超时失败，没有其他容错机制
3. `Coordinator` 发生故障，`Cohorts`会一直阻塞
4. 2PC无法解决的问题：`Coordinator` 发出 commit 消息后宕机，而唯一接受到这消息的 `Cohorts` 也宕机，这样即使通过选举重新指定 `Coordinator`  后，也无法确定事务的状态



### 1.2 三阶段提交协议：3PC



#### 与2PC的差异

- 引入超时机制。同时在协调者和参与者中都引入超时机制。
- 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。



#### 3PC 的三个阶段

三个阶段提交有 `CanCommit、PreCommit、DoCommit` 三个阶段。

##### 1. CanCommit 阶段

1. 事务询问：`Coordinator`  向所有 `Cohorts` 发送 `CanCommit` 请求，并等待响应
2. 响应反馈：`Cohorts` 接收到 `CanCommit` 请求后，如果认为自身可以顺利执行事务，则返回 **YES** 响应，否则返回 **NO**



##### 2. PreCommit 阶段

- 如果所有 `Cohorts` 均反馈为 **YES** 这执行 `PreCommit` 阶段：
  1. 发送预提交请求：`Coordinator` 向所有 `Cohorts` 发送 `PreCommit` 请求，进入 **Prepared** 阶段
  2. 事务预提交： `Cohorts` 接受到 `PreCommit` 请求后，执行事务，记录 undo 和 redo 信息
  3. 响应反馈：如果`Cohorts`执行完事务操作，则返回 **ACK 响应** ，并等待最终指令
- 如果任何一个`Cohorts`响应为 **NO**：执行事务的中断
- 等待超时，`Coordinator` 没有接收到`Cohorts`的响应：执行事务的中断
  1. 发送中断请求：`Coordinator` 向所有 `Cohorts` 发送 **abort 请求**
  2. 中断事务： `Cohorts` 接收到 **abort 请求** 之后（或者超时之后），执行事务中断



##### 3. doCommit 阶段

- **执行提交：**

  1. 发送提交请求：`Coordinator` 接受到所有 `Cohorts` 的 **ACK 响应** ，从预提交进入到提交状态，并向所有  `Cohorts` 发送 `doCommit` 请求
  2. 事务提交： `Cohorts` 接受到 `doCommit` 请求之后，执行正式的事务提交，并在完成之后释放所有资源
  3. 响应反馈：事务提交完成之后，向`Coordinator` 发送 **ACK 响应**
  4. 完成事务：`Coordinator` 接收到所有 `Cohorts` 的 **ACK 响应** 之后，完成事务

  

- **中断事务:**（`Coordinator` 没有接收到 `Cohorts` 的 **ACK**，发送的不是ACK或者超时）

  1. 发送中断请求：`Coordinator` 向所有 `Cohorts` 发送 **abort 请求**
  2. 事务回滚： `Cohorts`  接收到 **abort 请求**后，利用其在 `ProCommit` 阶段记录的信息来回滚事务，并释放资源
  3. 反馈结果： `Cohorts` 完成事务回滚后，向`Coordinator` 发送 **ACK 消息**
  4. 中断事务：`Coordinator` 接收到  `Cohorts` 反馈的 **ACK 消息** 后，执行事务的中断





## 2. 分布式事务方案

### 2.1 全局事务（DTP模型）

**DTP模型：** 由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model

**DTP 规定的三种角色：**

1. **`AP`**: **Aplication** 应用系统。即我们开发的业务系统，在业务过程钟，可以使用**资源管理器**提供的事务接口来实现分布式事务

2. **`TM`:** **Transaction Manager** 事务管理器

   - 分布式事务的实现由 `TM` 来完成，`TM` 提供分布式事务的操作接口，这些接口 **TX 接口**
   - `TM`  还管理着所有的资源管理器（`RM`）,通过它们提供的 **XA 接口** 来统一调度这些 `RM` ，以实现分布式事务
   - `DTP`只是一个模型，具体 `TM` 可以采用 2PC, 3PC, Paxos 等协议去实现分布式事务

3. **`RM`:** **Resource Manager** 资源管理器

   - 能够提供数据服务的对象都可以是 `RM` 。比如：数据库、消息中间件、缓存等。**数据库即为分布式事务中的资源管理器**
   - `RM` 能够提供单数据库的事务能力，它们通过 **XA接口** 将本地数据库的提交、回滚等能力提供给 `TM` 调用，以帮助 `TM` 实现分布式的实物管理
   - **XA** 是 DTP 模型定义的接口，用于向 `TM` 提供该 `RM` （该数据库）的提交、回滚等能力
   - `DTP`只是一套实现分布式事务的规范， `RM` 具体的实现是由数据库厂商来完成的。

   

### 2.2 基于可靠消息服务的分布式事务





### 2.3 最大努力通知（定期校对）



### 2.4 TCC（两阶段型、补偿型）

**TCC即为Try Confirm Cancel，它属于补偿型分布式事务。**

**三个步骤：**

1. `Try`:尝试待执行的业务
   - 这个过程不执行业务，只是完成所有业务的一致性检查，并预留执行需要的全部资源
2. `Confirm`:执行业务
   - 使用 `Try` 阶段预留的业务资源执行业务
3. `Cancel`:取消执行的业务
   - 业务执行失败，进入 `Cancel` 阶段，释放所占用资源，回滚 `Confirm` 阶段执行的操作

分布式容错之分布式事务

**人间忽晚，山河已秋。暮然回首，悠悠已三年。**

面试我们公司的时候，本来是觉得进不了，除了基础回答得还行，所有分布式框架，原理我都不懂。尤其面试官都在和我说，“你下次简历可以写上你平时自己做的东西，不一定是你上家公司的项目”，我基本就确定不过了。感觉挺可惜的，因为面试官问的东西我在上家公司基本没接触过。但是结果显而易见，我还是进了。挺惊喜，也挺感谢的。



2018年7月2号入职的，那时候信息部刚搬来中公办公，但是入职第一天还要去总部办手续，早到后在等待秘书通知的时候，怀着忐忑的心情和一样办入职手续的人打招呼，嗯，那个人就是小黄。。我，小黄和老许几乎差不多同时入职的，一起参加的入职培训，还是同个组的（刚开始的时候现在组件和应用是同一个组），所以我们的关系自然都挺好的。也挺感谢这两个一起摸爬打滚的朋友。

入职之后，米哥找我们聊天，我印象挺深的，因为我总记得米哥说的，```你们的面试情况你们应该自己清楚，我希望你们多去拓展自己的知识面，目前重要的是多去拓展知识的广度，而不是深度```。主要是前半句记得清楚，因为我感觉自己面试挺差的，顺带后半句也记住了。现在想想当时不以为然的后半句，真的是有道理。米哥当然是个让人佩服的人，也特别感谢三年多来的照顾。

想感谢的人很多，这里就不矫情了，大家都心理有数。哈哈哈

中间经历挺多人事变动的，比如：拆成组件组和应用组，走了一个大佬，勇哥独立出财务组，很长一段时间整个组只有我和小黄两个人- -，后面又陆续来了wcr，小英等等。

组件的项目基本都摸个遍，除了组件的，还弄过oms对接苏宁的需求，财务系统，等等。印象最深就是18年下半年，我得 github 提交记录有300个- -对于我个人真的是受益良多。

渐渐的得心应手，已经让人沉浸在虚假的自我感觉良好里面，但是不得不承认这日子过得还是挺滋润了。

每当我开始过得很舒服的时候，我就会开始思考自己的局限性，可能是每个人的追求不一样吧，对于我来说，没有波折的日复一日是枯燥无味的。就像组件，究竟要往什么方向发展，以我匮乏的知识很难验证我的想法。所以我决定出去看一看。


#### **浅谈组件组**

提了离职后，米哥问过我一个问题，对于组件组有什么想法？我当时回的是，我们应该以一种产品的思维作为内驱根据实际需求去做一个东西、一个产品，而不是说业务组有需求，没人了、做不来，我们就去做。其实这个问题，在这之前想过，但是没有仔细思考。

这段时间，仔细思考了（我闲着无聊蛋疼就会想这些），首先说说组件组的定位和发展，一个强大的团队，定位和目标模糊依然会成为它的“阿喀琉斯之踵”，参考阿里的发展路程（阿里是叫中间件），组件组发展分为一下三个发展阶段：

1. **阶段一：** 为业务团队需求驱动，**为集团内部提供订制化的解决方案**。如阿里内部的中间件： HSF、Diamond 
2. **阶段二：** 从事开源，花费大量精力提升中间件的极致性能，**提升开源影响力**，引领技术先进性。如阿里开源的中间件：Dubbo、Spring Cloud Alibaba、RocketMQ、Nacos
3. **阶段三：** **商业化**产品，相比开源产品，提供更高的 SLA、更强大的功能、更友好的交互。如阿里云的：微服务引擎 MSE、消息队列 RocketMQ、分布式应用链路追踪 ARMS

目前我们组处于阶段一，阶段一到阶段二其实挺难的，至少在人员编制上就不太够。

我们会常说组件组和业务组，其实两种并没有高低之分，就像游戏转职的不同，业务组追求属性的均衡，全面的发展，而组件要求在特定方向深度的挖掘。那么组件的方向都有啥呢？常见有以下几种：

1. 微服务治理：RPC相关中间件，注册中心，配置中心，限流熔断，链路追踪等等
2. 消息队列
3. 存储中间件
4. 存储 Proxy。典型的如 ShardingSphere
5. 网关。
6. ServiceMesh

当然，对于目前流行的容器化，k8s来讲，组件落地云原生，构建云计算平台，这些也都是方向。不同的方向就像不同的业务系统，像物流，供应链，商城，oa，方向不同熟悉的东西也都大不相同，那么对于一个组件开发者的一个基本素质要求又都有啥呢。大概有以下几项：

1. 语言基础。如java的集合，并发，jvm 等，当然像如今的 go 也是推荐学的。学过一段时间的 go ，我觉得它还是挺不错的。
2. 操作系统基础。
   - 文件IO。pageCache，mmap，direct IO...
   - 进程线程。 green thread，协程...
   - 内存/CPU。cgroup，cache line，bound core ...
3. 网络基础。TCP + HTTP 原理，NIO、Netty、gRpc、HttpClient等框架
4. 分布式相关知识。 CAP， paxos，raft，zab，2pc/3pc，base 等理论知识
5. 源码阅读能力。
6. 保持技术热情，拥抱变化。目前中间件都在拥抱云原生，相对的就需要中间件开发者拥有 K8s 的基础认知能力，熟悉 pod、service、deployment、statefulSet、operator 这些 K8s 的基本概念。

以上就是我对组件组的浅薄看法。



#### **开分享会**

关于**开分享会**这件事情，在晋升高级申请的述职报告中，我武断地说，我们公司的分享会流于形式，没有啥意义，大家都是为了kpi。后面我反思了下，其实是我想法进入了误区，在这里向 hr 的小伙伴道歉。当然，hr 们说开分享主要是能提高个人影响力，我是不认同的。

我觉得和别人分享，最终不是别人能获得多少，而是为了能教别人，你获得了多少。这里面涉及到一个学习转化率的问题。转化率就像课堂上老师常说的，“大家回去消化消化”，消化了多少其实就是转化率的问题，提高转化率意味着提高学习的效率。

我们常见的学习是看书，看视频，记忆，这由外而内的部分我称之为**输入**。而当我们使用学习的知识点，分享，教别人，这由内而外的部分称之为**输出**。

而在分享的过程中，我们会去**“自圆其说”**，这个时候就会进行查漏补缺，对于不懂的，模糊不清的地方会去弄到懂（输入）。所以这样一想分享会倒是挺不错的一个活动。

当然这种方法需要的成本比较高，这里推荐个简单的方法给大家：神神经经地莫名其妙和空气说话从磕磕碰碰到出口成章一不小心就吓死同事的终极无敌超级内卷的简化版教学学习法之虚拟对象教学。

它的做法很简单，**首先**在你脑海虚拟一个对象（类似你的七姑八婶的实际存在的人），想想它就在你身边，**然后**你出声和它分享你学习的知识，就完了。这里的重点是出声，一定是要能组织出的语言，而不是觉得你大概讲了啥。这算是一个简化版的讲课学习法，无聊的时候可以试试，哈哈哈。

其实想说的还有很多，我最大的一个问题就是好为人师，正所谓，三年学说话，一生学闭嘴，所以就此打住吧。

人生不相见，动如参与商。感谢各位，再见。

2021离职报告

## 1. 锁的分类

### 1.1 大纲

- 是否锁同步资源：
  - 锁住：悲观锁
  - 不锁住：乐观锁
- 锁同步资源失败，是否阻塞
  - 不阻塞：自旋锁，适应性自旋锁
- 同步资源竞争区别：
  - 不锁资源，一个线程修改资源，其他线程重试：无锁
  - 同一个线程执行同步资源时自动获取资源：偏向锁
  - 多个线程竞争同步资源时，没有获取资源的线程自旋等待锁释放：轻量级锁
  - 多个线程竞争同步资源时，没有获取资源的线程阻塞等待唤醒：重量级锁
- 多线程竞争锁时是否要排队：
  - 排队：公平锁
  - 不排队：非公平锁
- 一个线程中多个流程能不能获取同一把锁
  - 能：可重入锁
  - 不能：非可重入锁
- 多个线程能不能共享一把锁：
  - 能：共享锁
  - 不能：排它锁





### 1.2 乐观锁 vs 悲观锁

**悲观锁**使用数据时先加锁，如 java 中的 synchronized 和 Lock

**乐观锁**不加锁，在更新数据前判断是否有线程更新了这个数据，没有则更新，有则报错或重试。在 java 中，乐观锁是通过无锁编程来实现的，如 CAS 算法，在原子类中的递增操作就是通过 CAS 自旋实现的。



**使用场景：**

- 悲观锁适合写多的场景，先加锁保证写操作时数据正确
- 乐观锁适合读多的场景。



#### 1.2.1 CAS 

`CAS` 全称 Compare And Swap（比较与交换），是一种无锁算法。在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。`java.util.concurrent`包中的原子类就是通过 CAS 来实现了乐观锁。

CAS算法涉及到三个操作数：

- 需要读写的内存值 V。
- 进行比较的值 A。
- 要写入的新值 B。

当且仅当 V 的值等于 A 时，CAS 通过原子方式用新值B来更新V的值（“比较+更新”整体是一个原子操作），否则不会执行任何操作。一般情况下，“更新”是一个不断重试的操作。



**CAS 的问题：**

1. **ABA问题**，最终比较的时候还是A，但是中间曾经被修改过，然后又修改回来
2. **循环时间长开销大**。CAS操作如果长时间不成功，会导致其一直自旋，给CPU带来非常大的开销。
3. **只能保证一个共享变量的原子操作**。







### 1.3 自旋锁 vs 适应性自旋锁

(锁同步资源失败，是否阻塞)

**自旋的必要性：**对于获取锁失败时，如果先进行阻塞（休眠，让出时间片），等到资源释放时在唤醒，这个过程需要切换 CPU 的状态，这种状态的切换需要耗费处理器时间。对于同步代码块的内容过于简单的情况下，状态切换的时间可能比执行代码地时间还长。让线程自旋等待资源释放，异常来避免线程切换的开销，这就是**自旋锁**

同理，如果**锁被占用的时间很长**，那么自旋的线程只会白浪费处理器资源

**自旋锁的实现原理同样也是CAS**，AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个自旋操作，如果修改数值失败则通过循环来执行自旋，直至修改成功。

**适应性自旋锁**: 自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，如果自旋刚刚成功并且持有锁的线程正在运行中，这准许自旋更长的瞬间。如果自旋很少成功获得过，则有可能直接阻塞线程，不做或者做少量自旋。





### 1.4 无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁

- **java对象头：** 对象头主要由 Mark Word（标记字段）、Klass Pointer（类型指针）构成

  - **Mark Word：** 存储对象的HashCode，分代年龄和锁标志位信息
  - **Klass Pointer：** 对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例

- **Monitor:** 可以理解为一个同步工具或一种同步机制，是线程私有的数据结构，每一个线程都有一个可用monitor record列表。每一个被锁住的对象都会和一个monitor关联

| 锁状态   | Mark Word 存储内容                                      | 标记 |
| -------- | ------------------------------------------------------- | ---- |
| 无锁     | 对象的 hashCode、对象分代年龄、是否是偏向锁（0）        | 01   |
| 偏向锁   | 偏向线程ID、偏向时间戳、对象分代年龄、是否是偏向锁（1） | 01   |
| 轻量级锁 | 指向栈中锁记录的指针                                    | 00   |
| 重量级锁 | 指向互斥量（重量级锁）的指针                            | 10   |



- **无锁**：没有对资源进行锁定，只有一个线程能修改成功：CAS
- **偏向锁**: 同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。
  - 一个线程访问同步代码块并获取锁时,会在Mark Word里存储锁偏向的线程ID
  - 再次进入时，检测Mark Word里是否存储着指向当前线程的偏向锁
- **轻量级锁**
  - 当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁
  - 自旋修改偏向锁的线程id
- **重量级锁**
  - 轻量级锁自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁

> 偏向锁通过对比Mark Word解决加锁问题，避免执行CAS操作。而轻量级锁是通过用CAS操作和自旋来解决加锁问题，避免线程阻塞和唤醒而影响性能。重量级锁是将除了拥有锁的线程以外的线程都阻塞。



### 1.5 公平锁 VS 非公平锁

**公平锁**是指多个线程按照申请锁的顺序来获取锁。缺点是吞吐效率低，CPU 唤醒阻塞线程的开销大

**非公平锁**是多个线程加锁时直接尝试获取锁，获取不到才会到等待队列的队尾等待。如果获取锁时刚好锁释放，那么这个线程无需等待直接获取到锁。可以减少线程唤醒的开销，提高吞吐率，但是有可能排队的锁一直等不到锁。

**ReentrantLock** 默认使用非公平锁。有公平锁FairSync和非公平锁NonfairSync两个子





### 1.6 可重入锁 VS 非可重入锁

**可重入锁又名递归锁**，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。Java中 `ReentrantLock` 和`synchronized` 都是可重入锁，可重入锁的一个优点是**可一定程度避免死锁**。

```java
public class Widget {
    public synchronized void doSomething() {
        System.out.println("方法1执行...");
        doOthers();
    }

    public synchronized void doOthers() {
        System.out.println("方法2执行...");
    }
}
```

类中的两个方法都是被内置锁synchronized修饰的，doSomething()方法中调用doOthers()方法。因为内置锁是可重入的，所以同一个线程在调用doOthers()时可以直接获得当前对象的锁，进入doOthers()进行操作。

如果是一个不可重入锁，那么当前线程在调用doOthers()之前需要将执行doSomething()时获取当前对象的锁释放掉，实际上该对象锁已被当前线程所持有，且无法释放。所以此时会出现死锁。





### 1.7 独享锁 VS 共享锁

**独享锁也叫排他锁**，是指该锁一次只能被一个线程所持有。JDK中的synchronized和JUC中Lock的实现类就是互斥锁

**共享锁**是指该锁可被多个线程所持有。如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排它锁。获得共享锁的线程**只能读数据，不能修改数据**。



独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。







## 2.  AQS

java中的大部分同步类（Lock、Semaphore、ReentrantLock等）都是基于AbstractQueuedSynchronizer（简称为AQS）实现的。

AQS 是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架



### 2.1 ReentrantLock

ReentrantLock意思为可重入锁，指的是一个线程能够对一个临界资源重复加锁

**ReentrantLock 和 Synchronized 的对比**

|            | ReentrantLock                  | Synchronized     |
| ---------- | ------------------------------ | ---------------- |
| 锁实现机制 | 依赖 AQS                       | 监视器模式       |
| 灵活性     | 支持响应中断、超时、尝试获取锁 | 不灵活           |
| 释放形式   | 必须显示调用 unlock() 释放锁   | 自动释放监视器   |
| 锁类型     | 公平锁&非公平锁                | 非公平锁         |
| 条件队列   | 可关联多个条件队列             | 关联一个条件队列 |
| 可重入性   | 可重入                         | 可重入           |

```java
// **************************Synchronized的使用方式**************************
// 1.用于代码块
synchronized (this) {}
// 2.用于对象
synchronized (object) {}
// 3.用于方法
public synchronized void test () {}
// 4.可重入
for (int i = 0; i < 100; i++) {
	synchronized (this) {}
}
// **************************ReentrantLock的使用方式**************************
public void test () throw Exception {
	// 1.初始化选择公平锁、非公平锁
	ReentrantLock lock = new ReentrantLock(true);
	// 2.可用于代码块
	lock.lock();
	try {
		try {
			// 3.支持多种加锁方式，比较灵活; 具有可重入特性
			if(lock.tryLock(100, TimeUnit.MILLISECONDS)){ }
		} finally {
			// 4.手动释放锁
			lock.unlock()
		}
	} finally {
		lock.unlock();
	}
}
```

1. 基础概念

1.1 并发问题的来源

1.1.1 缓存导致的可见性问题

1. 分布式事务协议

1. 锁的分类

1.1 大纲

base elasticsearch

1.概述

1.1 基本概念