并发复杂性的本质矛盾
| 驱动 | 目标 |
|---|---|
| 性能压力 | 充分利用多核，让任务真正并行执行 |
| 正确性要求 | 多核并发访问共享状态时保持一致 |
并发模型的作用
并发编程的核心目标，是在多主体同时推进的世界中保持系统一致性。 其根本抽象为三元组：
| 维度 | 含义 | 工程体现 |
|---|---|---|
| 分工 | 任务划分与职责分配 | 多线程、多进程、协程 |
| 同步 | 控制状态变化的时序 | 锁、信号量、屏障 |
| 互斥 | 保证共享状态安全 | 原子性操作、CAS机制 |
并发问题在时空维度上表现为以下五类典型模式：
| 问题类型 | 根因 | 典型表现 |
|---|---|---|
| 竞态条件 | 状态访问时序不确定 | 数据竞争 |
| 内存可见性 | 缓存一致性缺陷 | 非预期结果 |
| 死锁 | 资源循环依赖 | 系统停滞 |
| 活锁 | 相互礼让永空转 | 任务无法推进 |
| 饥饿 | 资源分配不公平 | 某些进程长期被忽视 |
并发代码的正确性依赖于执行时序，而时序由调度器决定，程开发者无法控制：
并发模型的多样性，源于对三个根本问题的不同回答：实体间如何通信、如何协调、错误如何避免。
| 类型 | 本质 | 思想 |
|---|---|---|
| 共享内存 | 我改变，你直接看到 | 直接、灵活，但需要外部约束 |
| 消息传递 | 我改变，告诉你，你再来看 | 间接、安全，通过通信代替共享 |
| 类型 | 本质 | 思想 |
|---|---|---|
| 动态约束 | 运行时检查，发现问题再处理 | 灵活，但出问题才知道 |
| 静态约束 | 编译时证明，不允许出错 | 强制安全，但牺牲灵活性 |
原子原语是构建上层思想的底层基础设施，包括不限于：
| 原语 | 作用 | 定位 |
|---|---|---|
| CAS（Compare-And-Swap） | 无锁原子操作，检测并交换 | 实现无锁数据结构的核心 |
| 内存屏障（Memory Barrier） | 防止指令重排，保证可见性 | 解决内存可见性的硬件手段 |
| 自旋锁 | 循环检测锁状态 | 轻量级锁实现 |
| Futex | 用户态+内核态混合锁 | Linux高性能锁原语 |
| 思想 | 回答 | 关键洞察 |
|---|---|---|
| 消除共享 | 共享本身是问题，让它不存在 | 函数式——问题消失比解决问题更优雅 |
| 隔离共享 | 共享无法消除，通过通信代替直接访问 | Actor/CSP——"谁做的"比"发生了什么"更重要 |
| 管理共享 | 共享无法消除，需要有序访问 | 锁——用权力换秩序，死锁源于权力获取时机不确定 |
| 方向 | 代表 | 核心追求 |
|---|---|---|
| 从直接到间接 | 共享内存 → 消息传递 | 降低耦合 |
| 从动态到静态 | 锁 → 类型系统 | 提前证明 |
| 从管理到消除 | 并发控制 → 不可变 | 本质解决 |
| 模型 | 本质抽象 | 思维核心 | 典型实现 |
|---|---|---|---|
| 线程锁模型 | 操作系统级映射 | 控制共享 | Java Threads, pthreads |
| 协程模型 | 用户态调度 | 控制流让渡 | Go, Kotlin, Python |
| Actor模型 | 状态封装 + 消息通信 | 消息驱动 | Erlang, Akka |
| CSP模型 | 通信通道同步 | 流动式协作 | Go channel |
| STM模型 | 内存事务 | 原子一致性 | Clojure STM |
| 所有权模型 | 类型约束安全 | 静态防错 | Rust |
| 无锁模型 | 原子操作 | 性能极致 | C++ Lock-Free |
| 数据流模型 | 有向依赖图 | 数据触发计算 | TensorFlow, Spark |
| 响应式模型 | 异步事件传播 | 声明式流 | RxJava, Reactor |
理解边界，本质是理解模型的假设何时失效。
原则1：先判断任务性质，再选模型
| 任务性质 | 适配模型 | 原因 |
|---|---|---|
| I/O密集 + 低并发 | 线程锁 | 实现简单，无需引入额外复杂性 |
| I/O密集 + 高并发 | 协程/CSP | 轻量级切换，并发成本低 |
| CPU密集 | 多线程/进程池 | 充分利用多核，避免协程饥饿 |
| 跨机器通信 | Actor | 位置透明，天然分布式 |
原则2：理解模型的天然边界
每种模型都有其设计正交性，强行跨越会导致复杂性激增：
| 模型 | 天然优势区 | 强行跨越后的代价 |
|---|---|---|
| 线程锁 | 低并发、简单逻辑 | 高并发下死锁、锁竞争激烈 |
| CSP | 单进程内解耦 | 分布式需引入额外机制 |
| Actor | 分布式、位置透明 | 顺序保证需额外构建 |
| STM | 无副作用原子更新 | I/O操作场景几乎无法使用 |
原则3：识别边界突破的预警信号
原则4：可组合优于单一模型
实际系统 = Reactor(I/O) + 线程池(CPU) + Actor/CSP(业务解耦)
警惕试图用单一模型解决所有问题。
| 常见误解 | 正确认知 |
|---|---|
| "协程比线程高效" | 仅在I/O密集场景成立；CPU密集场景线程池更优 |
| "Actor比CSP更先进" | Actor适合分布式，CSP适合单进程内解耦，无高下之分 |
| "锁是万恶之源" | 低并发下锁是最简单安全的方案 |
| "无锁一定优于有锁" | STM在冲突率高时性能退化更严重 |
1. 并发量级？
2. I/O密集还是CPU密集？
3. 需要跨机器通信吗？
4. 有多变量原子更新需求吗？
5. 团队对哪个模型最熟悉？
| 架构范式 | 核心机制 | 适用场景 |
|---|---|---|
| Reactor 模式 | 事件驱动 I/O 多路复用 | Web服务器、高并发连接 |
| Proactor 模式 | 异步I/O完成回调 | 高性能网络库 |
| 响应式架构（Reactive） | 消息驱动 + 背压 | 流式系统、微服务 |
架构层的并发，本质是"时间结构化"：将输入、计算、输出在时间维度上重新编排。
| 指标 | 关注点 | 典型优化 |
|---|---|---|
| 吞吐量 | 单位时间完成任务数 | 批处理、无锁队列 |
| 延迟 | 任务响应时间 | 协程、事件驱动 |
| 可伸缩性 | 并发数增长趋势 | 任务分片、水平扩展 |
| 稳定性 | 负载波动抵抗力 | 背压、熔断、限流 |
并发调试的核心困难源于两个根本特性：
| 特性 | 表现 | 调试影响 |
|---|---|---|
| 不可确定性 | 同一段代码，每次运行结果可能不同 | 错误难以复现 |
| 时间窗口依赖 | 问题只在特定操作交错下才触发 | 本地单步调试无法暴露 |
| 环境敏感性 | 开发环境正常，高并发才暴露 | 上线后才发现 |
并发错误的本质是多线程对共享状态的竞争，表现为时间维度上的不可确定性
| 原则 | 说明 |
|---|---|
| 命名一切 | 无论何种方式，启动一个线程就要给它一个名字，便于诊断和问题追踪 |
| 响应中断 | 程序应对线程中断作出恰当的响应，避免资源泄露 |
| 基于证据 | 不要臆测，根据控制台输出、日志、错误信息推断 |
| 复现优先 | 最好能复现 bug，记录复现步骤，验证修复有效性 |
并发程序正确性的评估方法分为四类：
| 方法 | 描述 | 局限性 |
|---|---|---|
| 手工验证 | 程序员手动检查代码确保符合规范 | 仅适用于小型并发程序 |
| 模型检查 | 将系统建模为有限状态机，穷举检查所有可能状态 | 大型程序状态空间爆炸 |
| 运行时验证 | 在程序运行时检查行为是否合规 | 无法覆盖所有执行顺序 |
| 形式化验证 | 数学方法证明程序在所有执行顺序下正确 | 成本高，仅限于关键系统 |
| 决策维度 | 关注要点 |
|---|---|
| 业务特征 | CPU密集 vs I/O密集 |
| 安全性需求 | 是否容忍数据竞争 |
| 团队能力 | 编程模型的复杂度 |
| 架构特征 | 分布式或本地内聚 |
语言对比简表：
| 语言 | 并发机制 | 模型类型 |
|---|---|---|
| Java | 线程池、Future、Akka | 线程锁 / Actor |
| Go | goroutine + channel | CSP |
| Rust | 所有权系统 | 类型安全 |
| Elixir | Actor（Erlang VM） | 分布式Actor |
| JS/Node | Event Loop | 单线程异步 |
| C++ | Lock-free + 线程库 | 原语级控制 |
从"控制并发" → "理解并发" → "让系统自行协调" 未来的并发系统将具备：