并发编程

1️⃣ 共享状态

多个执行单元访问同一数据。

后果：

数据竞争

不一致

Heisenbug

解决思路：

锁

原子操作

不共享（最优）

2️⃣ 顺序与可见性

不是“谁先写”，而是“谁看到什么”。

CPU、编译器、内存模型都会重排。

解决思路：

内存屏障

happens-before 关系

语言内存模型保证（Java / Rust）

3️⃣ 协调与阻塞

谁等谁？等多久？

错误设计会导致：

死锁

活锁

饥饿

解决思路：

条件变量

channel

async + await

超时 + 取消

4️⃣ 失败传播

并发中失败不是“return -1”。

一个任务失败，其他怎么办？

半完成状态如何回滚？

解决思路：

结构化并发

supervisor

失败隔离

解决思路

1️⃣ 共享内存模型（最难）

代表：

C / C++

Java 低层

pthread

特征：

锁、mutex、atomic

性能高

心智负担极重

适合：

内核

高频交易

极致性能模块

2️⃣ 消息传递模型（最稳）

代表：

Go channel

Erlang / Actor

Rust channel

特征：

不共享内存

通过消息传递状态

天然隔离

适合：

服务端

微服务

分布式系统

你之前对“跨进程响应式”的直觉，本质就在这里。

3️⃣ async / await（时间抽象）

代表：

JS

Rust async

Java CompletableFuture

特征：

协作式并发

单线程也可高并发

不等于线程安全

关键误区：

async 解决的是“等”，不是“共享”