我们在处理多个线程或者系统访问同一资源的时候就需要考量并发安全问题，不同的组件给我们处理并发安全问题的方式不一样，比如 java 中有 synchronized、@Transactional、ReentrantLock 等，mysql 中有读写锁意向锁、MVCC、事务等，操作系统中有信号量、compare-and-swap、内存屏障等，甚至在分布式系统中，我们也有 2pc、3pc、TCC、saga、可靠消息队列等机制维持事务准确性

这些处理并发安全性的方法看上去五花八门，但是将他们总结归纳抽象一下就会发现，处理安全性问题的工具大致分以下几类：

原子性

这里的原子性，可以理解成 java 中的一致性（JMM 模型），也可以理解成 acid 中的原子性，两者（db 和应用程序）所面对的问题相似，因此都有这个概念，原子性一般由事务来保证，毕竟事务的定义就是一组不可分割的操作，要么全部成功要么全部失败。对于 cap、base 则不用保证这个，因为业务过大时事务消耗过大

他是数据库事务、服务端、分布式处理中的一个重要概念，指的是一个不可分割的工作单位，包含的所有操作要么全部完成，要么全部不完成，不能停留在中间状态。这是为了确保数据的一致性和完整性

事务的保证主要由以下两种模块构成，分布式事务（又分柔性和刚性）不保证原子性：

• 1，乐观锁
• 2，回滚或者补偿

上锁

锁是最常见的并发控制手段，用于确保同一时间只有一个线程或进程可以访问共享资源。锁可以分为很多类，但是最直观的还是分为以下两类：

• 悲观锁：是上锁后执行一段操作，然后解锁，必然有一个上锁失败的流程！说白了就是让写流程排队等待。将多线程要干的事情合并成单线程去做，就不会有安全问题了
• 乐观锁：是上锁，写的时候可以数据和预期是否一致。这里校验和写入数据两个操作必须由操作系统底层提供原子性指令

上锁之后我们在不同的场景会面临不同的问题，我们又要额外的考虑方法去处理，这里举一些例子：

• 1，MySQL 中，四大隔离级别都需要上写锁，读锁分情况上。内部的优化有表锁行锁间歇锁（减少锁粒度）、意向锁（预定资源）等
• 2，Java 中使用 synchronized 关键字或者 ReentrantLock 类上锁，提供锁升级（根据并发线程数逐步升级所需资源）、锁消除、锁粗化、公平锁、可重入锁等优化
• 3，分布式锁一般是使用 redis SET 命令的 NX 和 EX 选项来实现带超时的分布式锁，例如 SET lock_key value NX EX。需要考量的问题有事务超时、锁提前释放、NX 的必要性等问题
• 4，操作系统内核提供了多种原子指令，如 test-and-set、compare-and-swap（CAS）等，用于实现原子操作。悲观锁实现有互斥锁、自旋锁、信号量、临界区等。这里的技术已经接近底层，需要考虑的只是在那种情况去使用那种技术而已

悲观锁中，可能有一步是上锁失败，会返回错误。这里的上锁失败其实指的是该地方已经有锁了，和预期不一致（预期是无锁状态）。那悲观锁的这一步是不是也是乐观锁呢。按照这种思路，两种锁其实同源，都是让并发的线程，按顺序去访问同一资源。无论多么大的事务，从操作系统级到 db 级，到程序级再到分布式级，其底层就是这么朴实无华的操作：上锁，让并发的线程，按顺序去访问同一资源

重试

原理和自旋锁一致，这些地方用到了重试：

• 1，我们在业务中，想要实现一个原子操作，调用下游接口失败，可能会进行重试，也就是访问下游失败后的补偿逻辑可能是重试
• 2，事务提交后，机器挂掉，可能会根据 redolog 进行重试操作
• 3，TCC 、saga 事务，为了保证最终一致性，会有重试操作

重试是不能保证原子性的，他是事务的实现方式之一

补偿（回滚）

• 1，mysql 中如果遇到死锁等情况，会用 undolog 做回滚
• 2，日常业务中可能做回滚，我们自己定义回滚补偿逻辑
• 3，使用 @Transactional 注解开启事务，在方法中进行数据库操作。如果发生异常，事务会自动回滚
• 4，saga 事务有补偿机制，不过需要我们来实现补偿逻辑

补偿是不能保证原子性的，他是事务的实现方式之一

事务

一组操作，用悲观乐观锁的方式，合成了满足原子性的一组操作。事务是一组操作的集合，这些操作要么全部成功，要么全部失败，确保数据的一致性和完整性

1，MySQL 中会使用 BEGIN/COMMIT/ROLLBACK 控制语句来管理事务，确保一组操作的原子性。同时按照隔离级别，提供 MVCC 优化，底层用锁加 redolog、undolog 实现（MySql 用重做的方式保证事务的准确性） 2，Java 中常用的是 Spring 事务管理，通过注解（如 @Transactional）管理事务 3，分布式事务中需要讨论的点很多，CAP 和 BASE 各有一套理论支持，比如 saga 等，这些大多通过重试来保证事务的准确性，但是在今天的大厂中，很少接入了这样的分布式事务，大多数都是各个业务自己保证事务的安全，如果失败进行回滚重试等操作。因此我们把 TCC、saga 事务的实现拆到上文介绍的模块里

事务由于需要保证一组操作的原子性，肯定是需要回退或者重做机制的，这两个功能是事务实现的核心。mysql 的 redolog、binlog 就提供了这个功能。而分布式事务中，由于事务太大，2pc、3pc 等一起重试、一起回滚的方案就不太行了。我们应该降低事务粒度，于是引入了 BASE 理论，将大事务拆开，分成小粒度，每个粒度直接自己控制回滚或者重试，一直到事务成功，saga、TCC 等都是这么做的，你在业务中也可以这么做

使用事务引入的额外问题，可能包含死锁（对，死锁不是上锁引入的问题，而是事务引入的问题）、重试操作的幂等性等问题，处理的方案包含降低锁粒度（行锁）、先预估资源（3pc）、按顺序获取资源等

一致性

ACID 中一致性指执行事务前后数据应当维护一个一致性状态，如 MySQL 中，付款的事务执行后，需要保证某个人在 db 中的金钱数量不能小于0，如果小于0，那就出现了一致性问题。事务需要使数据库从一个有效状态转换到另一个有效状态，ACID 中的一致性是数据库保证所有的约束没有被打破

如果被打破了，我们需要一定的机制，去处理这个一致性问题，比如回滚（原子性保证），比如回滚到上一个一致性状态（持久性保证），比如该事务变更导致的错误状态不能被其他事务看见（隔离性保证），这也是为什么有人说 ACID 就是说事务能够通过 AID 来保证这个 C 的过程，C 是目的，AID 都是手段

集群间一致性对应 CAP 中一致性，指的是数据在集群间维护一个相同的值，保证它需要集群机器间的同步方式，比如半同步全同步或者异步同步

BASE 中的最终一致性指分布式系统中某个事务最终会通过回滚或者重试的方式执行成功，允许中间的软状态

可见性/隔离性

可见性是 JMM 中的，隔离性是 ACID 中的

对于其它线程，改动到底可不可以访问到，或者说，应该什么时候访问到。这么一个简单的问题，被各种计算机学家和工程师使用各种技术去处理，最后将这个问题的难度演变成近似哲学问题的难度

我们其实很重视这个问题，举一些我们见过的概念做为例子：

• java 可见性：关于另外一个 B 线程的修改，我们 A 线程应该随时都可以访问到。这个概念注重修改同步到哪个级别，正常来说，java 的数据默认应当同步到内存，不然会有并发安全隐患。但是这也延伸出一个并发编程中的考量点，我们的数据同步到什么级别比较合适，是 cache 级，内存级，db 级，还是集群级？同时也要考量我们从什么级别读数据是安全的
• mysql 隔离性：关于另外一个 B 线程的修改，我们 A 线程应该随时都可以访问到吗？也许事务提交的时候才能读到，也许改了之后我就可以读到，也许出现一些不可重复读的问题

那么我们对可见性、隔离性做了什么处理呢：

• Java 的 volatile 关键字：确保变量的修改对所有线程可见。变量的读写操作会插入内存屏障以及使用缓存一致性协议，确保内存操作的顺序性
• C++ 的 std::atomic：提供了原子操作和内存顺序控制。通过内存顺序模型来控制内存操作的顺序
• 操作系统内存屏障：比如读屏障，确保所有在读屏障之前的读操作在读屏障之后的读操作之前完成。这一步其实是为了消除 os 底层优化对可见性造成的问题
• 操作系统缓存一致性协议：这个也是 volatile 底层原理之一，在多处理器系统中，MESI 协议确保每个处理器的缓存数据与其他处理器的缓存数据保持一致
• mysql MVCC：读数据时，用一致性非锁定读（版本号）思路。这是多线程读取数据时的优化，多亏了 MVCC，我们读取数据的时候可以无视写锁了，MVCC 底层又是基于 undolog 的

我们为了处理可见性问题引入了某种解法，这种解法又引入了某种问题，为了解决问题我们又会做出某种优化或者处理，直到达到一个大部分人都可以接受的状态

其他属性

其他属性都是各个模块针对自己的业务提出来的，这里抛砖引玉提出几个：

• Mysql 持久性：使用 binlog 实现，存到磁盘中视为持久化了，因为 db 所面临的是存储业务，所以他们将这个放进了确保事务的可靠性和数据的一致性的四大特性中
• java 有序性：这里指的是指令重排序破坏代码逻辑，需要使用 volatile 去处理