提示：

1.请先在项目安装好expo工具

2.在expo上注册自己的账号

3.申请apple 开发者账号1年99美金

在项目根目录(eas.json目录)执行下列操作：

前置操作（打包流程一般只执行一次的操作）：

1

eas credentials 

一键创建证书,无脑选第一个选项

后续操作(每次打包需要修改或者执行的命令)：

1.项目添加配置文件：

app.config.js

1
2
3
4
5
6
7
8
9
10
11
12

ios: {
  supportsTablet: true,
  bundleIdentifier: "xxx.app",//这个是ios应用的appid，去apple developer中心找
  config: {
    usesNonExemptEncryption: false,
    googleMapsApiKey: "YOUR_IOS_GOOGLE_MAPS_KEY",
  },
  newArchEnabled: false,
  infoPlist: {
    NSLocationWhenInUseUsageDescription: "需要访问您的位置以便在地图上显示",
    NSLocationAlwaysUsageDescription: "需要访问您的位置以便在地图上显示",
  },

app.json

1
2
3
4
5
6
7
8
9
10
11
12
13

"ios": {
  "supportsTablet": true,
  "bundleIdentifier": "funmap.app",
  "config": {
    "usesNonExemptEncryption": false,
    "googleMapsApiKey": "YOUR_IOS_GOOGLE_MAPS_KEY"
  },
  "newArchEnabled": false,
  "infoPlist": {
    "NSLocationWhenInUseUsageDescription": "需要访问您的位置以便在地图上显示",
    "NSLocationAlwaysUsageDescription": "需要访问您的位置以便在地图上显示"
  }
},

expo不指定，默认选择app.config.js。

2.添加认证测试设备

1

eas device:create

添加真机设备,选择website方法，真机相机操作后，下载描述文件，安装，安装完成进入expo提示的ready的网页即可。

3.expo构建应用

1

eas build --profile preview --platform ios

profile指定环境，开发，预发或者生产，platform指定构建平台

这一步会出现网页链接，点击。

等待status为finished,点击install按钮。

相机扫描二维码安装或者链接复制到手机上安装。

PS:如果下载后应用出现无法验证完整性时，确保前面的app.config.js配置有没有问题，重点bundleIdentifier。

https://cursor.directory/

本篇文章会尽力讲清楚的问题有：

1.dump文件oom文件分析，介绍mat工具的使用，常见分析字段。

2.介绍oom分析流程，如何使用mat。

使用MAT导入OOM时的dump文件。

会有一个overview视图，记录了整个堆在崩溃时的大小。

在下方有三个分栏。

Action中Histogram可以用来分析堆中各个对象大小的直方图。

Reports中Leak Suspects是MAT自动分析当前堆存在内存泄漏的报告。

拿到这个dump文件，我们着重分析，到底是什么原因导致了OOM。

直方图内容如上：

Class Name代表类名，

Objects代表该类在堆中对象的个数,

Shallow Heap代表这些对象除开自己引用的内容，本身占用的内存大小，

Retained Heap代表对象包含自身以引用的总占用的内存大小。

我们以图上BatchImportForwardOrderDTO为例：

BatchImportForwardOrderDTO 的内存组成

1. 对象头（Object Header）：
   • Java 对象的头部包含对象的元数据，如哈希码、GC 标志、锁状态、类指针等。
   • 这个部分的大小通常是 12 字节（32 位 JVM）或 16 字节（64 位 JVM，启用了对象指针压缩）。
2. 实例字段（Instance Fields）：
   • BatchImportForwardOrderDTO的所有成员变量（基本类型和引用类型）都会占用一定的内存空间：
     • 基本类型（如 int、boolean）：直接在对象中分配并占用字节数。
     • 引用类型（如 String、数组、其他对象）：占用 4 或 8 字节（根据 JVM 的设置和指针压缩），这些字段是指向实际对象的引用，不计算引用对象的大小。
3. 对齐填充（Padding）：
   • 为了满足内存对齐要求（通常是 8 字节对齐），对象的总大小会被填充到最近的 8 的倍数。
   • 这个填充部分在 Shallow Heap 中计算。

例子：BatchImportForwardOrderDTO 内存布局

假设 BatchImportForwardOrderDTO 类定义如下：

1
2
3
4
5
6
7

public class BatchImportForwardOrderDTO {
    private int id;                    // 4 bytes
    private boolean active;            // 1 byte
    private String orderNumber;        // 4 or 8 bytes (reference)
    private List<String> items;        // 4 or 8 bytes (reference)
    // padding bytes to align
}

1. 对象头：16 字节（假设 64 位 JVM，指针压缩）。
2. 字段内存 一共13字节 4+1+4+4
3. 填充（Padding）：对齐至 8 字节的倍数，因此可能会有额外的字节填充。

合计：16 + 4 + 1 + 4 + 4 = 29 字节，但因为对齐需求，总会填充至最近的 8 字节倍数，即 32 字节（Shallow Heap）。

所以一个BatchImportForwardOrderDTO的Shallow Heap大概占用了29个字节。

所以通常Retained Heap通常都比Shallow Heap大。

回到上图，我们发现业务命名的对象，CustomerOrderDO和CustomerOrdersGoodsDO，BatchImportForwardOrderDTO占比都比较高，但是总得来说也才70MB还不足导致内存溢出。

我们注意到char[]占比特别高，已经到了231MB。

所说char[]这种基本类型很多地方用到，但是相对于String来说还是太大了。

所以我们推测应该有一个非常大的字符数组。（就算不是，也可以都看看哪里有异常）

右键需要找引用的对象，选择图上的按钮。

果然有一个字符数组高达160mb

通过后面的insert into语句，判断是一个sql。

了解到这个接口逻辑是一个类似于订单上传的接口，最大10w条。

通过代码排查发现，数据库创建订单没有做分批插入，导致10w个订单都在一个sql里插入，从而产生了一个巨大的char数组。

同理其他业务对象也是10w个，也可以都分批处理，从而减小内存占用。

栈实现方法比较

补充说明

1. 固定大小数组：

   • 最简单的实现，但缺乏灵活性。
   • 在确切知道栈大小不会超过某个限制时很有用。
   • 对于小型栈，可能是最高效的选择。

2. 动态数组：

   • Java的ArrayList就是这种实现。
   • 提供了固定数组的优势，同时克服了大小限制。
   • 扩容操作虽然代价高，但分摊后平均复杂度仍为O(1)。

3. 链表：

   • 非常灵活，特别适合大小频繁变化的栈。
   • 在内存受限或需要频繁插入/删除大量元素的场景中表现良好。
   • 缺点是空间开销较大，且缓存性能较差。

4. 双端队列：

   • 如Java的ArrayDeque，是现代Java中推荐的栈实现。
   • 结合了数组和链表的优点。
   • 在大多数情况下，这是最佳的选择，除非有特殊需求。

选择哪种实现取决于具体的使用场景、性能需求和资源限制。在实际应用中，除非有特殊需求，否则使用语言标准库提供的实现（如Java的ArrayDeque）通常是最佳选择。

“缓存友好“是指一种数据结构或算法在访问内存时能够有效利用计算机的缓存系统，从而提高性能。要理解这个概念，我们需要了解一些计算机体系结构的基础知识：

• 计算机的内存层次结构：从快到慢依次是CPU寄存器、高速缓存（L1、L2、L3）、主内存（RAM）、硬盘。
• 缓存行（Cache Line）：CPU从主内存读取数据时，会一次性读取一块连续的内存区域（通常是64字节），这就是一个缓存行。

一个数据结构被称为”缓存友好”，通常意味着：

1. 数据在内存中连续存储：这样可以利用空间局部性原理，一次性将更多相关数据加载到缓存中。
2. 访问模式可预测：这有助于缓存预取机制的效率。
3. 减少缓存未命中：尽量避免在内存中跳跃式访问数据，这会导致频繁的缓存未命中。

本篇文章会尽力讲清楚的问题有：

1.什么叫分布式系统，分布式系统和集群的区别，分布式系统的演变？

2.什么是分布式事务，为什么要分布式事务，什么场景需要分布式事务？

3.一致性模型有哪些类型？

4.如何根据业务选择分布式事务方案？

其余非核心问题：如何划分微服务？

1.分布式系统和集群

分布式系统是将单体系统，根据模块拆分开来，不同系统有不同的业务逻辑，在多台不同的服务器中部署不同的服务模块，通过远程调用协同工作，对外提供服务。

和分布式的反义词就是集中式，相当于单体项目，所有功能都在一个系统内。

集群：是指在多台不同的服务器中部署相同应用或服务模块，构成一个集群，通过负载均衡设备对外提供服务。

2.分布式事务

个人觉得知道为什么要用分布式事务比使用分布式事务更重要。

先看这个经典场景：

分布式电商系统中，有两个服务，分别是订单服务和库存服务。

用户下单流程可以分为：

用户发起订单接口–>

创建订单(A)[订单服务，订单数据库]，

扣减库存(B)[库存服务，库存数据库]，

更新订单状态(C)[订单服务，订单数据库]

–>用户客户端响应订单创建结果

这个过程后端分为了三个阶段。

每一个阶段都有可能失败，但是某些阶段失败，会让事情变得难以处理。

比如在A成功，B失败时，此处的失败可以是B系统返回的业务失败，也有可能是本身网络的失败。

假设网络原因，B调用超时，此时订单服务应该怎么处理？

1. 继续更新订单状态，但是如果库存扣减失败了，此时就是超卖。
2. 不更新订单状态，但是如果库存扣减成功，此时就是少卖。

有人说，再去查一遍库存不就好了，问题是此时再去查库存，这个数据不准确，因为库存系统可能还在处理中。

以上两个处理方式，无论是哪种处理，都是无法接受的。

又有人说，那复制一份库存到订单库中不就好了，当成本地事务去做，事务成功全部成功，事务失败全部失败。

没错，这样看似数据一致了，不会有超卖，少卖的情况，但是最新的数据依然在库存库中。

假设此时库存由于某些原因需要添加扣减库存，例如业务要求这个sku卖得很好，我仓库还有货，给我马上再加点库存，你怎么确保订单的库存修改成功呢？

同样的流程

• 库存服务创建本地事务
• 新增或者减少库存(A)[库存服务，库存数据库]，
• 发送rpc请求同步到订单库中(B)[订单服务，订单数据库]，
• 提交事务(C)[库存服务，库存数据库]

同理在上述阶段，

第三步失败，无论怎么处理，依然会造成少卖或者超卖现象。

由此可见，在分布式系统中，想要保证数据一致，需要另外的方法–也就是分布式事务。

3.一致性模型

强一致性：

每个客户端的读操作都返回最近一次写操作的结果。也就是说客户端再任意时刻，看到的数据都是一致的。

适合在金融交易系统，银行系统中处理，如银行账户余额、交易处理等，要求每个操作都必须看到最新的数据，确保数据准确性。

弱一致性：

允许不同的客户端存在一定程度的数据不一致。

适用场景：

• 缓存系统：例如 Memcached，允许数据在缓存和后端存储之间保持一定的延迟一致性。
• 日志系统：记录日志的系统可能允许日志在不同节点之间有一定的延迟。

开源中间件：

• Memcached：一个分布式缓存系统，主要关注性能，允许缓存和底层存储之间存在数据不一致。
• **Redis (使用集群模式)**：在 Redis 集群模式下，由于主从复制机制的延迟，可能会出现弱一致性问题。

最终一致性：

最终一致性是一种弱一致性模型的特殊形式，它保证在没有新的更新操作的情况下，系统中的所有副本最终将达成一致状态。

特点：

• 短期不一致：系统可能在短期内处于不一致状态，但最终会一致。
• 高可用性：允许系统在部分副本不可用时继续操作。

适用场景：

• 社交媒体：如点赞、评论等，系统允许短暂的不一致，但最终所有副本会同步一致。
• 分布式数据库：适合对最终一致性要求较高的系统，能够容忍一定的延迟。

开源中间件：

• Cassandra：一个分布式 NoSQL 数据库，设计为最终一致性，支持高可用性和扩展性。
• DynamoDB：Amazon 提供的分布式数据库，允许配置一致性模型，包括最终一致性。
• Riak：另一个分布式 NoSQL 数据库，采用最终一致性模型，优化了高可用性。

4.分布式事务的类别和选型

根据上述的一致性模型，我们可以选择对应的分布式事务类型，

• 强一致：2PC，3PC
• 最终一致：TCC，本地消息表，Saga
• 弱一致性：最大努力通知

2PC：

角色有协调者和参与者。

sequenceDiagram
    participant C as 协调者
    participant P1 as 参与者1
    participant P2 as 参与者2
    C->>P1: 发送准备请求
    C->>P2: 发送准备请求
    P1-->>C: 回复准备就绪(本地事务写Undo/Redo日志)或中止
    P2-->>C: 回复准备就绪(本地事务写Undo/Redo日志)或中止

流程：

1. 准备阶段（Prepare Phase）：事务管理器（TM）询问所有参与者（如数据库）是否准备好提交事务。参与者执行事务操作，写Undo/Redo日志，但不会立即提交。参与者回复yes or no。
2. 提交阶段（Commit Phase）：如果所有参与者都准备好了，事务管理器将通知它们提交事务；如果任何一个参与者未准备好，事务管理器将通知所有参与者回滚事务。在这个阶段，参与者会根据事务管理器的指令执行提交或回滚操作，并释放事务过程中使用的锁资源。

sequenceDiagram
    participant C as 协调者
    participant P1 as 参与者1
    participant P2 as 参与者2
    alt 所有参与者准备就绪
        C->>P1: 发送提交请求
        C->>P2: 发送提交请求
        P1-->>C: 确认提交完成，本地事务commit
        P2-->>C: 确认提交完成，本地事务commit
    else 任一参与者未准备就绪
        C->>P1: 发送回滚请求
        C->>P2: 发送回滚请求
        P1-->>C: 确认回滚完成，本地事务执行undo log
        P2-->>C: 确认回滚完成, 本地事务执行undo log
    end

2PC比较明显的问题：

1.协调者单点问题：TM崩溃，整个事务无法运行下去。

2.阻塞问题:

• 参与者阻塞
  • 参与者在prepare阶段会锁定资源，等二阶段才会释放，这过程中，其他事物无法获得锁定资源，导致阻塞问题在系统中传播，造成连锁阻塞。
  • 并且由于参与者不知道协调者的决策，在没收到TM的消息前，会永久锁定资源。
  • 此时也没办法自主回滚或者提交，否则会数据不一致，破坏了2PC的原子性。
• 协调者阻塞

3PC:

角色分为协调者和参与者。

%%{init: { "sequence": { "width": 300, "height": 400, "messageAlign": "center" } } }%%
sequenceDiagram
    participant C as 协调者
    participant P1 as 参与者1
    participant P2 as 参与者2
    
    Note over C,P2: 阶段1：Prepare
    C->>P1: Prepare?
    C->>P2: Prepare?
    P1-->>C: Yes
    P2-->>C: Yes
    
    Note over C,P2: 阶段2：PreCommit
    C->>P1: PreCommit
    C->>P2: PreCommit
    P1-->>C: ACK，本地事务记录undo log redo log
    P2-->>C: ACK，本地事务记录undo log redo log
    
    Note over C,P2: 阶段3：Commit
    C->>P1: Commit
    C->>P2: Commit
    P1-->>C: 已完成
    P2-->>C: 已完成
    
    Note over C,P2: 事务完成

流程：

由图可知三阶段其实就是多了一个预先提交阶段。

阶段1：Prepare

• 协调者向所有参与者发送 Prepare 请求，询问是否可以执行事务。
• 参与者检查自身状态，如果可以执行事务，回复 Yes；否则回复 No。
• 在这个例子中，两个参与者都回复了 Yes。

阶段2：PreCommit

• 如果所有参与者在第一阶段都回复 Yes，协调者发送 PreCommit 请求。
• 参与者收到 PreCommit 后，执行事务但不提交，将结果写入 undo 和 redo 日志。
• 参与者完成准备工作后，回复 ACK（确认）。

阶段3：Commit

• 协调者收到所有参与者的 ACK 后，发送 Commit 请求。
• 参与者收到 Commit 后，正式完成事务提交。
• 参与者完成提交后，向协调者发送”已完成”消息。

不同阶段网络分区情况：

sequenceDiagram
    participant C as 协调者
    participant P1 as 参与者组1
    participant P2 as 参与者组2
    C->>P1: 发送Prepare
    C->>P2: 发送Prepare
    P1-->>C: 准备就绪
    Note over C,P2: 网络分区发生
    Note over C,P2: 情况1：如果有参与者处于准备阶段就回滚，否则无事发生

如何解决阻塞问题的：

协调者在Prepare阶段挂掉，重启后检查参与者状态，如果没有参与者处于Prepare阶段；那么无事发生。

如果至少一个参与者，收到了Prepare，处于准备阶段了，所有Prepare参与者会等待超时时间自动回滚。

若协调者在发送完pre-commit请求后发生故障，如果至少有一个参与者处于pre-commit状态，那么所有的参与者都会转到这个状态，然后提交事务。

如果没有参与者处于pre-commit状态，那么调用abort命令。

关键点就在于3pc中各个参与方约定好了在哪个阶段等待超时后做一致的操作，就像一阶段都abort,第二阶段只要有参与者处于pre-commit那么大家都提交，否则回滚。

当然此处各个节点之间依然会发生网络分区，假设a,b,c,d四个节点，a处于pre-commit阶段，启动b,c和a正常通信，知道至少一个处于pre-commit阶段，准备继续commit，但是d网络分区，此时d处于两难阶段。

所以3PC仅容忍单点故障，协议不允许协调者和参与者同时停机或者存在网络分区。

3PC的优缺点：

优点：

1.通过约定阶段执行一致的动作从而解决了协调者单点问题。

2.通过Prepare阶段，降低了资源争抢并互相阻塞的概率，提高了并发性。

缺点：

1.性能开销大，3PC增加了很多网络通信的步骤，流量消耗大。

2.仅容忍单点故障，协议不允许协调者和参与者同时停机或者存在网络分区

TCC：

TCC角色有TC事务协调者，TM事务管理者，RM资源管理者和参与分布式事务的业务服务。

1
2
3
4
5
6
7
8
9
10
11

事务管理者(TM)：

Seata 中用于创建和决议事务结果的实体,一般集成于业务调用链路的上游.

资源管理者(RM)：

Seata 中用于管理资源的实体,一般情况下等同于微服务中的提供方(provider),管理其所在服务中的资源,如数据库资源等.

事务协调者(TC)：

Seata 中用于2pc方式的事务模式统一协调事务的实体(SAGA除外),其可由事务管理者驱动或自身驱动进行事务的二阶段行为.

举例：

1
2
3
4
5

在订单，库存，优惠券三个服务中，用户下单，订单服务作为服务发起者,
此时订单服务就是TM，负责创建和决议事务，控制全局事务的边界。
而库存和优惠券服务就是RM资源管理者，参与全局事务，管理自己服务的资源。
TC在TCC中由Seata框架提供，负责对事务进行协调。
TC在二阶段中，接受TM或者自身驱动的方式，发送二阶段命令timeoutRollback rollback commit给RM。

TCC一共两个阶段，第一阶段是Try，通常是锁定资源，第二阶段是cancel或者commit。

TCC通常分为三个类型，分别是通用型，异步确保型，补偿性TCC。

1.通用型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

问题一：Try阶段,其中一个调用超时怎么处理？
1.RM发送cancel请求，让从服务取消，此时注意空回滚.
2.cancel请求也超时了怎么办，从服务设置超时时间，自动回滚。
3.加入事务id=x的try请求比cancel请求慢了，此时需要注意（防悬挂），这时就根据事务版本不再处理try锁定逻辑。
	详解：
	在RM发送try超时时，从业务可能执行成功，可能失败。（RM明确知道try失败）
  假设我们策略是从业务接受二阶段的调用时间超时自动回滚，在从业务执行成功的前提下，自动回滚，而其他从业务收到RM发送cancel，从业务数据会一致。

  假设我们策略是从业务接受二阶段的调用时间超时自动回滚，在从业务执行失败的前提下，自动回滚（空回滚），而其他从业务收到RM发送cancel，从业务数据会一致。

问题二：Try都成功了，发送二阶段请求超时如何处理？
1.此时资源都锁定成功，RM对超时的从业务重发二阶段请求，设置最大次数并告警。
2.此时从业务在try成功后，不能根据自己的超时时间自动回滚，会造成数据不一致的情况。
	详解：
	在RM调用try阶段成功后，二阶段调用失败。（RM明确知道try成功）
  此时从业务的try是一定成功的。
  假设我们策略是从业务在接收二阶段的调用等待超时自动回滚，此时就有问题。
  因为从服务并不知道第二阶段发送的是confirm还是cancel，贸然执行cancel会导致数据不一致。

  所以第二阶段，从服务不能自动回滚，而RM会对调用超时的从业务一直执行最开始发送的二阶段请求，直到调用成功或者最大次数报警。

适用场景

适用于从业务服务属于同步调用，其结果会影响主业务服务的决策，并且执行时间确定且较短的业务。

如互联网金融企业最核心的三个服务：交易、支付、账务：

当用户发起一笔交易时，首先访问交易服务，创建交易订单；然后交易服务调用支付服务为该交易创建支付订单，执行收款动作，最后支付服务调用账务服务记录账户流水和记账。

为了保证三个服务一起完成一笔交易，要么同时成功，要么同时失败，可以使用通用型 TCC 解决方案，将这三个服务放在一个分布式事务中，交易作为主业务服务，支付作为从业务服务，账务作为支付服务的嵌套从业务服务，由 TCC 模型保证事务的原子性。

交易服务Try:

创建交易单，状态交易待完成。

​ 支付服务Try:

​ 创建支付单，状态待支付。

​ 账户服务Try:

​ 冻结账户对应交易金额。

​ 提交账户本地事务。

​ 提交支付本地事务。

提交交易本地事务。

在递归提交本地事务的过程，会有很短暂的不一致，这个影响吗？

二阶段TCC框架调服务的confirm接口:

交易服务confirm:

​ 支付服务confirm:

​ 账户服务confirm:

​ 扣除买家冻结资金；增加卖家可用资金。

​ 提交账户本地事务。

​ 支付服务修改支付订单为完成状态，完成支付

​ 提交支付本地事务。

提交交易本地事务。

整个分布式事务结束。

TCC优点：可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好。

TCC 另一个作用就是把两阶段拆分成了两个独立的阶段，通过资源业务锁定的方式进行关联。资源业务锁定方式的好处在于，既不会阻塞其他事务在第一阶段对于相同资源的继续使用，也不会影响本事务第二阶段的正确执行，这个模型相比Seata的AT模式并发更高。

只有在prepare阶段会阻塞，其他阶段都是并发。

2.异步确保型

顾名思义，异步确保型就是有一方从业务是消息服务，利用消息的可靠性和异步性，保证订阅消息的从业务的二阶段的执行。

和通用型差不多–Try阶段，消息服务，创建在数据中创建一条待发送的消息记录，同样注意防悬挂和空回滚。

confirm或者cancel阶段，将记录状态设置为允许发送或者取消和删除记录。

消息服务中定时任务定期扫描没有发送完成或者取消的消息记录。从服务做好幂等即可。

优点：

1.从服务接入成本低，订阅消息记录，消息服务改造成本比从服务低。

2.消息数据独立存储，独立伸缩，降低从服务之间的耦合度。

缺点：

由于是异步，实时性相比通用性更差点。

适用场景

由于从服务执行时间不定，适合用最终一致性时间敏感度较低的，在服务处理结果不影响主服务决策的场景（只被动的接收主业务服务的决策结果）。

例如会员注册和赠送积分。

会员注册成功，一定赠送积分。

会员注册失败，一定不赠送积分。

积分只会被动接受会员服务的决策，且最终一致性时间敏感度不高。

3.补偿型

在补偿性的TCC事务中，从服务只需要提供两个接口，Do 和 Compensate。

Do 接口直接执行真正的完整业务逻辑，完成业务处理，业务执行结果外部可见；

Compensate 操作用于业务补偿，抵消或部分抵消正向业务操作的业务结果，Compensate操作需满足幂等性。

优点:

从服务改造成本低，在原有Do的业务逻辑上，单独写一个补偿接口。

缺点：

由于Do完成的是整个业务逻辑，做不到事务隔离。并且补偿接口也可能失败。超异常次数时需要人工介入。

适用场景：

适合那些无法做try,cancel,comfirm接口的服务或者系统和外部系统，且从服务的成功失败影响主服务的决策，且并发冲突小的场景，因为一旦发生并发，数据不一致的案例相比其他TCC会变多。

例子：

A机票订购服务，B航空公司网关，C航空公司网关。

A需要同时在B，C中购买联乘机票。单独其中一班意义不大。

1.可见性

JMM内存模型，对volatile操作后本地缓存失效,线程都去主存读最新的值。涉及到MESI缓存一致性模型。

详细的后面再补。

2.禁止指令重排

1. JMM 中的顺序性保障:
   • JMM 保证了对 volatile 变量的读写操作具有顺序性。具体来说，它确保了在 volatile 变量的写操作之前的所有操作不能被重排序到写操作之后，反之亦然。
   • 这种顺序性保障主要针对的是编译器和 JMM 的优化，例如，在编译器优化时，JMM 会防止重排序带来的问题。
2. CPU 层面的重排序:
   • 即使 JMM 确保了在编译器和 JVM 层面的顺序性，实际的 CPU 可能仍然进行重排序，以优化指令的执行顺序。
   • 这种重排序可能会导致在多核处理器环境中，某些操作的顺序被改变，从而影响程序的正确性。
3. 内存屏障的作用:
   • 内存屏障（Memory Barriers）是硬件层面上的机制，用于确保 CPU 的执行顺序符合程序的预期。
   • 内存屏障的插入会阻止 CPU 在特定的操作之间进行重排序。例如，StoreStore Barrier 可以阻止写操作的重排序，StoreLoad Barrier 可以阻止写操作和读操作之间的重排序。
   • 这些屏障可以确保不同 CPU 核心之间的缓存一致性，并确保所有线程看到的内存状态是一致的。
4. 结合起来:
   • volatile 关键字提供了对变量的基本顺序性保障，但为了确保在硬件层面的正确性，JMM 需要通过内存屏障来实现。
   • 在实际的实现中，JMM 会在对 volatile 变量的读写操作前后插入适当的内存屏障，以确保 CPU 的行为与 JMM 规范相符。

总的来说，volatile 提供了编译器和 JMM 层面的顺序性保障，但内存屏障确保了硬件层面的顺序性和可见性。两者结合在一起，确保了多线程环境下的正确性。

内存屏障有四个：

1. LoadLoad（读读屏障）：先执行屏障前的 读，后执行屏障后的 读。
2. LoadStore（读写屏障）：先执行屏障前的 读，后执行屏障后的 写。
3. StoreLoad（写读屏障）：先执行屏障前的 写，后执行屏障后的 读。
4. StoreStore（写写屏障）：先执行屏障前的 写，后执行屏障后的 写。

疑惑点：

1.到底是JMM还是内存屏障保证了指令不乱序？

都是，内存屏障本质在不同操作系统上是不同的指令，JMM为了屏蔽不同操作系统的差异，自己定义了以上四个命令，实际用的还是操作系统提供的命令。

2.内存屏障指令在代码上位置？

加的位置：严格意义上，如果完全确保volatile的顺序：

比如wirte命令，假设在该命令之前有读取，我们需要确保读取在wirte之前执行,所以加LoadStore；

假设在该命令之前有写入，我们需要确保读取在wirte之前执行,所以加StoreStore；

假设在该命令之后有读取，我们需要确保读取在wirte之后执行,所以加StoreLoad；

假设在该命令之后有写入，我们需要确保写入在wirte之后执行,所以加StoreStore；

所以位置如下：

1

LoadStore,StoreStore|write|StoreLoad,StoreStore

如果是read命令：

1
2
3
4
5
6
7
8
9

// LoadLoad 屏障：确保后续读取不会重排序到 volatile 读取之前
LoadLoad();

// 读取 volatile 变量
volatileValue = x;

// LoadStore 屏障：确保后续写入不会重排序到 volatile 读取之前
LoadStore();

背景：最近突然收到了腾讯hr的电话，问我有没有兴趣去，岗位是交付研发工程师，后来得知职位除了研发还有部分项目管理的要求。

一面1个小时10分钟。

两道算法，加项目和八股。

算法

两道算法都很简单。

1.两个数组相加，按照正常数字加法运算，得到新数组

例：[1,2,3] [4,5] = [1,6,9]

要考虑进位,还有最高位进位数组长度的扩容。

这道没ac，后面那道没想到，说了方案。勉强通过。

2.判断括号的有效性。

leetcode经典题，不过面试前没刷，大概5个月没刷题了，这次相当于裸面。

核心就是用栈左括号入栈，右括号出栈匹配，最后栈空为有效。

这题也没ac

1

(()()[]({})},这个情况没过，当时只有10分钟做这道题，没找出原因。。。

这两道题都很简单，怪自己没好好准备。

八股

八股用的java，double为什么不精确，各种集合的如何使用，原理，是否线程安全。

mysql explain关键字，慢查询优化方法，索引失效，索引数据结构，其他引擎的索引。

项目

说了skywalking怎么自动打点的，怎么优化接口。

我感觉是不是由于岗位非纯研发，所以面试的题，还挺简单的，本来都准备好被吊打了。不清楚有没有下一面qaq。。。

synchronized

基于JVM监视器实现，只支持非公平锁，不需要手动释放锁。

ReentrantLock

基于AQS在java应用层实现，可以非公平和公平锁，支持tryLock无阻塞访问锁，需要手动释放锁。

CAS实现原理

cas在底层是调用native方法，该方法由C++实现。

如果是多处理器，则会加上lock前缀。

带有 lock 前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。

通过这一点就可以实现多处理器同步。

另一种方式是缓存锁定，CPU有多级缓存机制，每一个缓存的最小单元是缓存行，

在L3缓存是cpu共享的，由于CPU从主存加载数据局时，会复制数据到L3，l2,l1中。读取时，会依次从l1,l2,l3读取。

所以缓存锁定在L3中锁定对应的缓存行，那么其他cpu就没有办法对相应的缓存行进行修改。

为了避免缓存锁定的数据在其他cpu不一致的情况，在这里还有MESI一致性协议去确保一致性。

简单来说，假设最开始缓存是独占状态Exclusive，只有一个cpu拥有，在其他cpu获取从主存中加载了该数据，那么缓存变为Shared状态，并且数据一致，假设某个cpu修改了缓存数据，那么缓存行变为Modified状态，只有该cpu的缓存和主存中的数据一致，而其他cpu的缓存行则是invaild状态，此时会去内存中再次加载该数据，通过这样实现了数据的一致性。

1.公平锁和非公平锁区别。

一个获取锁时，直接Cas尝试state，失败再放入等待队列。非公平。

一个获取锁，先放入等待队列。公平。

2.共享锁和独占锁的区别。

共享锁在获取锁时，会cas将共享资源的数量减一。也就是允许多个线程操作共享变量。

独占锁只允许同一时刻只有一个线程占有锁。

3.获取锁流程？

尝试获取锁，判断state是否为0，Cas修改，修改失败调用acquire方法获取，这个方法会调用到自定义的tryacquire方法，设置当前线程为独占线程，失败则addWaiter到同步队列中。

添加到同步队列会先判断是否存在有效节点，没有直接尝试获取锁。

有就拿尾结点，将尾节点作为当前节点的前驱结点。

没有尾节点，会创建一个新的dummy头结点，也作为尾节点。

4.当线程被封装为Node，入队后何时会被唤醒呢？

每一个Node都会做的一个自旋操作。

获取前置节点，是否为头指针，如果是，尝试获取锁，获取锁成功，将自己设置为虚节点。

如果获取锁失败（可能被非公平锁抢了）或者p前置节点不是头结点，判断自己是否需要阻塞。（需要细看）。

在判断自己是否需要阻塞的过程中会把前驱节点是cancel状态的节点删除。

5.cancel状态是怎么来的？

Node在自旋过程中，如果成功获取到锁，会设置failed=false，但是没有获取到锁，并且自旋过程中出现了异常，此时会被finally执行，finally判断failed=true，就把当前节点设置为取消节点。在设置过程中，也会遍历前面的取消节点，找到一个<0的节点，和后面<0的节点连接。

6.如何释放锁？

调用relase方法，调用自定义tryrelases方法，获取当前可重入次数，判断当前线程是否是持有锁线程，是就减一，如果state为0了，那么就设置独占线程为null。tryrelases返回值代表当前这个时刻锁是否没有线程获取了，也就是state应该是0的状态。如果是true，那么会获取head节点，在获取他的waitstaus状态，如果waitstaus==0,说明后继线程正在运行，如果小于0代表被挂起，那么就唤醒。

ReentrantLock有Sync成员变量，还有两个内部类，NotFairSync和FairSync所以初始化时可以选择。

当调用ReentrantLock的lock方法时，实际调用的是Sync的lock方法，非公平会这个时候直接尝试设置state。失败了都调用acquire方法。

acquire是AQS的方法，这个方法会调用自定义类的tryAcquire方法和acquireQueued方法。

ReentrantLock的tryAcquire的方法中在NotFairSync和FairSync加入了可重入的判断逻辑，NotFairSync依旧是先尝试获取state，而FairSync则是会先判断hasQueuedPredecessors()队列是否有有效节点，然后再获取锁。

如果获取锁失败，就会调用AQS的acquireQueued方法。

1
2
3
4
5

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

acquireQueued中有每个线程都执行的自旋逻辑：

1.获取前驱节点P。

2.如果p是头结点，那么尝试获取锁。（所以对于同步队列而言，只有在队列虚节点的next才有机会去获取锁）

3.此时可能会被非公平锁抢占。

4.获取锁成功，就把当前节点设置为head,原来节点清空。

5.失败或者非head节点就会判断自己是否需要阻塞。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

判断方法为如果前置节点是signal（-1）代表资源就绪等待被唤醒，所以当前节点得阻塞。

如果>0代表，前置节点是cancel状态，我们需要帮忙删除这些cancel的节点。并且不需要阻塞进入下一个循环。

如果是0 or PROPAGATE,我们会将前置节点设置为SIGNAL状态，并且也不阻塞，进入下一次循环。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)
        /*
         * This node has already set status asking a release
         * to signal it, so it can safely park.
         */
        return true;
    if (ws > 0) {
        /*
         * Predecessor was cancelled. Skip over predecessors and
         * indicate retry.
         */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        /*
         * waitStatus must be 0 or PROPAGATE.  Indicate that we
         * need a signal, but don't park yet.  Caller will need to
         * retry to make sure it cannot acquire before parking.
         */
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

在这些过程中出现异常，该node会被设置为cancel状态。

在addWaiter方法中，也会初始化CLH队列，创建虚节点，并且添加当前节点到尾节点。

在设置节点使用CAS的方式。

释放调用unlock到release方法,调用自定义的tryRelease方法。tryRelease做了一些重入的减法操作。返回值为是否释放了锁。

1
2
3
4
5
6
7
8
9

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

unparkSuccessor会将当前node设置为0的状态，以避免阻塞next节点。

除此之外，会尝试把next后所有cancel节点删除，并且唤醒一个非cancel节点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

private void unparkSuccessor(Node node) {
    /*
     * If status is negative (i.e., possibly needing signal) try
     * to clear in anticipation of signalling.  It is OK if this
     * fails or if status is changed by waiting thread.
     */
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);

    /*
     * Thread to unpark is held in successor, which is normally
     * just the next node.  But if cancelled or apparently null,
     * traverse backwards from tail to find the actual
     * non-cancelled successor.
     */
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}

1.hashmap

1.数据结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

static final int MAXIMUM_CAPACITY = 1 << 30;

static final float DEFAULT_LOAD_FACTOR = 0.75f;

static final int TREEIFY_THRESHOLD = 8; //转树的阈值

static final int UNTREEIFY_THRESHOLD = 6;//树退化的阈值

static final int MIN_TREEIFY_CAPACITY = 64; //转树最小容量阈值

transient Node<K,V>[] table;//Node的keyValue数组

transient Set<Map.Entry<K,V>> entrySet;

transient int size;//有多少个键值对

transient int modCount;//用来迭代和快速失败

int threshold;//临界点

final float loadFactor;//负载因子 小数点

0.如何遍历hashmap

1.遍历map.keyset(),然后获取value。

2.遍历map.entryset(),然后获取entry。

上面两种方式都不能直接删除或者新增元素。

使用迭代器可以在遍历期间新增和删除元素。

1、map.put(k,v)实现原理

第一步 首先将k,v封装到Node对象当中（节点）。第二步它的底层会调用K的hashCode()方法得出hash值。第三步通过哈希表函数/哈希算法，将hash值转换成数组的下标，下标位置上如果没有任何元素，就把Node添加到这个位置上。如果说下标对应的位置上有链表。此时，就会拿着k和链表上每个节点的k进行equal。如果所有的equals方法返回都是false，那么这个新的节点将被添加到链表的末尾。

如其中有一个equals返回了true，那么这个节点的value将会被覆盖。

计算下标的代码

1
2

if ((p = tab[i = (n - 1) & hash]) == null)
     tab[i] = newNode(hash, key, value, null);

容量与上hash值

2、map.get(k)实现原理

第一步：先调用k的hashCode()方法得出哈希值，并通过哈希算法转换成数组的下标。第二步：通过上一步哈希算法转换成数组的下标之后，在通过数组下标快速定位到某个位置上。重点理解如果这个位置上什么都没有，则返回null。如果这个位置上有单向链表，那么它就会拿着参数K和单向链表上的每一个节点的K进行equals，如果所有equals方法都返回false，则get方法返回null。如果其中一个节点的K和参数K进行equals返回true，那么此时该节点的value就是我们要找的value了，get方法最终返回这个要找的value。

3、为何随机增删、查询效率都很高的原因是？

原因：增删是在链表上完成的，而查询只需扫描部分，则效率高。

HashMap集合的key，会先后调用两个方法，hashCode and equals方法，这这两个方法都需要重写。

4.转红黑树

当链表节点大于等于8，tab大于等于64会转成红黑树

5.扩容机制

扩容时需要计算新tab的容量和临界点，并且通过遍历tab的方式将每个entry放到新的tab中，在这个过程中，红黑树可能转换为链表。

1.计算容量和临界点

主要逻辑在下面：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
if (oldCap > 0) {
//当老容量已经大于最大容量时，临界点设置为Integer的最大值
    if (oldCap >= MAXIMUM_CAPACITY) {
        threshold = Integer.MAX_VALUE;
        return oldTab;
    }
    //如果老容量扩大两倍小于最大值并且老容量大于默认容量16时，新容量为老容量扩大两倍，临界点同样扩大两倍
    else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
             oldCap >= DEFAULT_INITIAL_CAPACITY)
        newThr = oldThr << 1; // double threshold
}
//下面是初始化的阶段，初始化在有老临界点时，用理解点当容量，如果没有就用默认的容量和临界点
else if (oldThr > 0) // initial capacity was placed in threshold
    newCap = oldThr;
else {               // zero initial threshold signifies using defaults
    newCap = DEFAULT_INITIAL_CAPACITY;
    newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
if (newThr == 0) {
    float ft = (float)newCap * loadFactor;
    newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
              (int)ft : Integer.MAX_VALUE);
}

2.将老entry移动到新tab

我们思考一个问题，oldtab中有10个entry，我们怎么分配这10个entry在新tab中的下标呢？分配过程中我们还得保证这些entry放入的下标也是满足put运算的。

put计算下标的方法:

假设cap = 1000=16,newcap = 32

那么tab[i=(cap-1)&hash]，也就是

11111&111 = 15

10111&111 = 15

所以，以上两个都在同一个下标tab[15]。

而在resize中，计算方法为newIndex = hash&oldcap，也就是hash&1000。

11111&1000=1

10111&1000=0

我们知道同一个index中的entry的hashcode，假设cap转为2进制为n位，那么在n-1位上的特征值都是一样的，但是第n位不一样，刚好resize中就利用了这个区别的特征值，用来区分是在原index还是在原index+oldcap。

所以11111在15+oldcap=31的下标

10111在15的原index

那么思考一下，这个下标计算方式，满足新的tab的put计算方式吗，是的。

我们知道通过put是&tab.length-1的计算方法，并且cap一定是2的n次幂，所以不管怎么扩容，无非就是&时多加几位1罢了。

11111&1111= 31

10111&1111= 15

这样就把原链表分成了两个链表放在了不同的index上。

下面是源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

table = newTab;
if (oldTab != null) {
    for (int j = 0; j < oldCap; ++j) {
        Node<K,V> e;
        if ((e = oldTab[j]) != null) {
            oldTab[j] = null;
            if (e.next == null)
                newTab[e.hash & (newCap - 1)] = e;
            else if (e instanceof TreeNode)
                ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
            else { // preserve order
                Node<K,V> loHead = null, loTail = null;
                Node<K,V> hiHead = null, hiTail = null;
                Node<K,V> next;
                do {
                    next = e.next;
                    if ((e.hash & oldCap) == 0) {
                        if (loTail == null)
                            loHead = e;
                        else
                        //尾插法
                            loTail.next = e;
                        loTail = e;
                    }
                    else {
                        if (hiTail == null)
                            hiHead = e;
                        else
                         //尾插法
                            hiTail.next = e;
                        hiTail = e;
                    }
                } while ((e = next) != null);
                if (loTail != null) {
                    loTail.next = null;
                    newTab[j] = loHead;
                }
                if (hiTail != null) {
                    hiTail.next = null;
                    newTab[j + oldCap] = hiHead;
                }
            }
        }
    }
}
return newTab;

3.线程安全问题：

多线程put时，存在键值对丢失问题。

例如：

A线程put，进行resize操作。此时正好把老数组某个下标值为空，oldTab[j] = null;

B线程去resize，发现oldTab[j] = null;就没有迁移原来oldTab[j]的元素。

最后A线程把newTab换成oldtab，B线程把newTab1换成newTab，从而导致丢失了 oldTab[j]的元素。

除此之外，正常put也可能让一个key被另一个线程覆盖。

1.7版本的线程安全问题存在死循环，e.next和e相互引用。

2.ArrayList

ArrayList为object数组。默认容量为10.

1
2

private static final int DEFAULT_CAPACITY = 10;
transient Object[] elementData;

ArrayList的构造方法

1.带容量的构造：

容量>0就创建一个object[cap]数组。

==0就用原来的空数组引用。

<0异常。

2.空构造方法：

用默认空数组复制给elementData.

3.使用集合类初始化：

将集合转为数组后给elementData。

如果不是Object类，强制转为Object类。

如果集合长度为0，使用原来的空数组。

ArrayList的add操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public boolean add(E e) {
    ensureCapacityInternal(size + 1);  // Increments modCount!!
    elementData[size++] = e;
    return true;
}

public void add(int index, E element) {
    rangeCheckForAdd(index);

    ensureCapacityInternal(size + 1);  // Increments modCount!!
    System.arraycopy(elementData, index, elementData, index + 1,
                     size - index);
    elementData[index] = element;
    size++;
}

1.无下标add

先检查是否能放下，然后数组++放入元素。

2.带下标add

检查index合理性，查看是否需要扩容，将后面的元素复制到后面一个位置。

3.ensureCapacityInternal

扩容如果没有默认容量大，则使用默认容量。

需要的容量大于目前的数组大小时，扩容。

新容量为老容量的1.5倍，如果还是小于需要的容量，那么直接用新容量，新容量大于int最大值用int最大值。

把老数组元素复制到新数组去。

3.ConcurrentHashMap

数据结构：1.7

segments数组继承了reentrlock，带有lock功能。

segments下有entry数组，冲突元素通过链表链接。

在Put时先调用segments的lock方法，采用的一种分段锁的思想减少冲突。

1.8 数据结构

Node数组，每个Node都是MapEntry<K,V>。

冲突用链表或者红黑树。

在put时，如果tab[i]为空则使用cas的方式放置第一个node，如果存在使用sync关键字同步tab[i]也就是node对象去同步其他线程操作。

扩容解析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

private transient volatile int sizeCtl;

/**
 * The next table index (plus one) to split while resizing.
 */
private transient volatile int transferIndex;

/**
 * Spinlock (locked via CAS) used when resizing and/or creating CounterCells.
 */
private transient volatile int cellsBusy;

/**
 * Table of counter cells. When non-null, size is a power of 2.
 */
private transient volatile CounterCell[] counterCells;

sizeCtl=0，代表正常情况，如果为正整数则是当前map有效元素个数。

sizeCtl=-1，代表map正在进行初始化。

sizeCtl<-1，代表map正在进行扩容，代表正在扩容的线程数。

判断过程：

1.while判断>=0是否有扩容条件，sizeCtl<=-1时，代表已经有线程进行扩容或者初始化了。

2.如果tab=null，cas设置-1，去初始化。

3.如果当前数组大小已经大于等于目标容量，代表已经扩容完成，退出循环。

4.如果tab=table也就是没有扩容完成时，在下面几种情况，当前线程不会参与扩容。

1
2
3
4

if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
    sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
    transferIndex <= 0)
    break;

• Stamp戳记不匹配
• sc == rs + 1 代表线程已经参与了扩容
• sc == rs + MAX_RESIZERS代表参与扩容的线程数已经最大了
• (nt = nextTable) == null 未创建新表，扩容未开始
• transferIndex <= 0同理扩容未开始