最近在整理C++并发编程笔记，写到Actor和CSP这两种设计模式时，我发现自己过去对它俩的理解一直有个明显的误区——总以为它们只是“多线程加消息队列”的不同写法。真要把它们用在工程里，才发现这两个模型背后的设计哲学、调度方式、容错手段差异非常大。这篇文章就是把我这些思考整理出来，顺便给出可以在C++里直接跑的示例代码，帮你建立一套属于自己的并发设计框架。
在正式讲之前，先说明一个核心概念：Actor把并发单元抽象成一个个拥有独立状态和邮箱的实体，通过消息异步通信；CSP则把并发单元看成顺序执行的过程，过程与过程之间通过Channel同步传递数据。它们都属于消息传递模型，而不是传统共享内存模型。简单说，传统并发靠锁保护共享数据，Actor和CSP则尽量避免共享，用通信代替同步。
这篇文章适合刚接触并发编程但已经写过线程锁的C++开发者，也适合想在公司内部推广更优雅并发架构的技术负责人。读完后，你会明白如何根据业务场景在Actor和CSP之间做选型，也能立刻动手实现一个能跑的Actor或Channel。
1. 并发模型选择的底层逻辑：为什么传统锁不够用
1.1 共享内存并发模型的死穴
先从一个反例说起。假设你有两个账户A和B，要把钱从A转到B，你的第一反应可能是锁住A，再锁B。但另一个线程正好从B转A，它锁住B后等A。两边都在等待对方释放锁，于是死锁。你可能会想：我按固定顺序加锁不就行了？问题是一个大型系统里有几十把锁、几十个线程，锁的获取顺序散落在不同的模块中，很难保证所有人一致。即使你通过分层、约定把顺序强制统一了，一旦需求调整，比如增加一个账户类型，整个加锁顺序的约束链又得重新梳理。
还有一类问题叫竞态条件。两个线程同时检查一个余额，都发现大于0，然后各自扣款，结果余额被扣成负数。你加上确实严格的锁后，问题似乎消失了，但性能开始下降。临界区越大，锁竞争越严重；临界区太小，又防不住更细的交互。更麻烦的是，多线程Bug具有极强的随机性，在测试环境跑一百次都没事，生产环境一上线就崩，这是共享内存并发的典型“非确定性”困境。
我并不是说锁没用。对于短临界区、低频共享变量，mutex是最高效的。但一旦业务逻辑变复杂、模块间协作变多，锁模型的维护成本就会指数级上升。你会发现代码里到处是lock_guard，但逻辑之间依然存在大量隐含依赖，你根本不知道哪个线程在哪个时刻持有锁。
1.2 “通过通信来共享”的核心价值
有一句在并发圈流传很广的话：Don’t communicate by sharing memory; share memory by communicating. 这正是Actor和CSP共同的思想基石。它们的核心思路不是把并发单元塞到同一个状态空间里竞争，而是让每个单元拥有自己的私有状态，然后通过发送消息、收发数据来完成协作。因为状态根本不共享，自然不需要用锁去保护，竞态和死锁的天花板就被大幅降低了。
你可以想象一个餐厅后厨。传统共享内存模式是几个厨师共用同一口锅，大家为了谁先放盐、谁翻炒吵得不可开交，必须由店长用锁来裁决。而Actor和CSP是每个厨师站在自己的灶台前，订单通过传菜窗口传递，食材用盘子交付。厨师之间不需要直接操作对方的锅铲，自然也不会因为抢工具打起来。
值得注意的是，Actor和CSP虽然共享同一哲学，但它们不是一回事。Actor更偏重“谁在处理”——每个Actor有自己的地址、邮箱和生命周期，消息通常异步到达，发送方不会等接收方处理完；CSP更偏重“数据怎么流动”——它关注的是进程之间通过Channel发生的交互，通常采用同步会合，发送方会阻塞直到接收方准备就绪。理解这句话，你已经掌握了这两种模型的本质差异。
1.3 C++开发者需要自己做哪些功课
遗憾的是，C++标准库并没有直接提供Actor或Channel这样的原语。你可以在C++17/20里用std::thread、std::mutex、std::condition_variable、std::atomic组合出一套；也可以直接引入第三方库，比如C++ Actor Framework（CAF）、SObjectizer、libcsp、antidot等。不过我认为，如果只是用库，不去理解底层实现，遇到诡异问题时还是抓瞎。下面两章我会先带你从零搭一个简化但足够演示原理的实现。
现代C++的一大优势是RAII和移动语义。我们可以把消息封装为std::function或者std::variant，用unique_ptr管理Actor状态，用move代替拷贝，极大降低消息传递的复制开销。另外，C++20的std::atomic_ref、std::latch/barrier也能在某些场景提供帮助。但要注意，这些只是工具，并不会直接把并发模型塞给你。真正的设计模式必须依靠你自己在架构层做取舍。
2. Actor模型：状态封装与异步消息传递
2.1 Actor模型的核心要素
Actor模型最早可以追溯到Carl Hewitt在1973年提出的计算模型，后来被Erlang发扬光大。一个Actor是一个最小的并发计算单元，它有且只有三件事能做：创建其他Actor、向其他Actor发送消息、以及决定收到下一条消息时的行为。每个Actor持有一个邮箱，其他Actor发来的消息先进入邮箱，Actor再从邮箱里逐条取出消息处理。整个过程中，Actor的内部状态是完全私有的，不会被外部直接读写。
与线程不同，Actor的粒度是消息级别。两个Actor之间的通信默认是异步的，发送方把消息扔进对方邮箱后就继续自己的工作，不用等接收方回应。这意味着没有锁、没有阻塞，也天然形成了解耦。每个Actor可以像独立的人一样，根据自己的节奏处理任务。
举个我实际用过的例子。在一个网络游戏服务端里，每个玩家连接对应一个Actor，玩家A向玩家B发送动作指令，只需发一条消息到B的邮箱，B的Actor在自己的线程里解析消息并更新状态。虽然两个玩家可能同时操作，但它们之间没有任何共享内存，因此不存在数据竞争。
从架构上看，Actor还天然支持了位置透明：你给另一个Actor发送消息时，并不需要关心它是在本线程、本进程还是远端机器上。Erlang/OTP的节点间通信就是这样做的，消息到达速度不同，但语义一致。这一点让Actor在分布式领域比CSP更自然。
2.2 C++实现Actor的关键设计
在C++里实现Actor，第一个要解决的是消息表示。最小实现你可以用std::function<void()>，把要执行的动作封装成无参函数，放入邮箱。这种方案足够灵活，但代价是类型不安全，也不便序列化，不适合做跨进程Actor。若要工程化，推荐用std::variant或自定义基类加类型擦除，让每条消息携带业务数据和命令类型。
第二个是邮箱实现。最简单的做法是std::queue加一把mutex加一个condition_variable，入队时加锁，出队时等待非空。它的缺陷是锁竞争，当某个Actor的邮箱成为热点时，性能会下降。更主流的方案是无锁队列，比如基于MPMC环形队列，配合busy-wait或park/unpark机制，在高吞吐场景下表现更好。但无锁队列实现难度高，工程上先用互斥锁完全够。
第三个是Actor的调度方式。最简单是每Actor一个线程，优点是无锁、低延迟，缺点是线程数受硬件限制，Actor多了会爆炸。业界常见的做法是使用线程池，把Actor映射到一组工作线程上，通过消息调度器决定哪个Actor可以运行。CAF会为每个Actor维护一个调度状态，当邮箱有新消息时被放入运行队列。由于每个Actor在某个时刻只会被一个线程执行，仍然不需要加锁。
还有一个容易忽略的点：消息本身应该是不可变的，或者至少不能被多个Actor同时修改。如果你在消息里用shared_ptr传递一个可变对象，那本质上还是在共享状态，不但解决不了竞态，反而会让数据竞争藏得更深。所以实现Actor时，消息类型应当设计成移动赋值并且无共享引用。
2.3 一个极简可运行的Actor代码示例
基于上面的设计思路，我写了一个最小的Actor骨架。它只有几十行，但包含了邮箱、工作线程、停止机制和消息发送。
#include <atomic> #include <condition_variable> #include <functional> #include <iostream> #include <mutex> #include <queue> #include <thread> class Actor { public: using Message = std::function<void()>; Actor() : worker([this] { run(); }) {} ~Actor() { send([this] { stop = true; }); worker.join(); } void send(Message msg) { { std::lock_guard<std::mutex> lock(mtx); queue.push(std::move(msg)); } cv.notify_one(); } private: void run() { while (!stop) { Message msg; { std::unique_lock<std::mutex> lock(mtx); cv.wait(lock, [this] { return !queue.empty() || stop; }); if (stop) break; msg = std::move(queue.front()); queue.pop(); } msg(); } } std::queue<Message> queue; std::mutex mtx; std::condition_variable cv; std::thread worker; std::atomic<bool> stop{false}; };这个实现里，外部调用send只会把lambda消息压入队列并唤醒工作线程，发送方立刻返回。工作线程在run里循环等待，取到一个消息就执行一个消息。Actor内部的所有字段，比如stop标志，只有工作线程能修改，所以不需要额外的锁保护。析构时发送一个停止消息，工作线程执行后退出，join完成生命周期管理。
利用这个基类，你可以很方便地派生出具体业务Actor。比如一个打印任务：
class PrinterActor : public Actor { public: PrinterActor() { send([] { std::cout << "actor started" << std::endl; }); } void print(int value) { send([this, value] { std::cout << "got: " << value << std::endl; }); } };调用print()时，lambda会把value捕获进去，在整个消息生命周期内有效。因为是异步，所以print()不会等待打印完成。如果你需要处理结果，则必须再定义一个“回复地址”，比如在消息中放入一个std::function回调，或者持有接收方Actor的指针并给接收方发送结果。
2.4 Actor模型的边界与适合场景
Actor模型非常适合那些“实体众多、彼此独立、异步交互”的场景。游戏服务器里的玩家对象、物联网网关里连接的设备对象、交易系统里的订单对象，都很适合抽象成Actor。每个Actor的私有状态天然被封装，外部无法乱改，配合监督树还能实现优雅的故障隔离和重启。
但Actor并不适合所有并发场景。比如高吞吐的数据流水线，如果每个数据包都要经过一个独立Actor，邮箱队列会产生大量临时对象和调度开销，反而不如CSP的Channel直观。异步模型也会带来顺序问题：Actor发送给同一个接收方的多条消息，虽然先进先出，但如果接收方在消息处理中途创建子Actor，子Actor的执行顺序就不一定了。因此，Actor更适合面向对象风格的“领域实体建模”，而不是面向数据流的管道建模。
3. CSP模型：同步Channel与顺序进程
3.1 CSP的核心思想与Actor的区别
CSP全称是Communicating Sequential Processes，由C. A. R. Hoare在1978年提出。它的核心是把系统拆成若干顺序执行的进程，这些进程之间通过Channel进行通信。Channel是显式的通信管道，而不是某个进程的私有邮箱。每个进程只在需要通信时才与Channel交互，除此之外，进程之间没有其他联系。
用一句话区分CSP和Actor：Actor像发信，信投到对方信箱后你就不用管了；CSP像打电话，必须双方都在线上，通话才算建立。因此CSP是同步的，发送方会阻塞直到接收方准备好；而Actor默认异步，发送方不等待接收方处理结果。
CSP最有名的大规模应用就是Go语言的goroutine和channel。实际上，Go的channel不像传统CSP那样严格无缓冲，它支持带缓冲的异步发送，但在语义上仍然是“通过channel通信，而不是通过共享内存”。正是因为这种同步性，CSP天然适合实现请求-响应模式，也方便做背压控制：数据不会无限堆积在某个进程里，因为发送方会被阻塞。
3.2 用C++实现一个可复用的Channel
接下来我写一个简单的Channel模板，它具备send、receive和close三个接口，线程安全，支持有界缓冲。为了聚焦核心逻辑，这里用了有界队列近似同步语义，容量设成1时，可以模拟“缓慢”的通信节奏。
#include <condition_variable> #include <mutex> #include <queue> #include <stdexcept> template<typename T> class Channel { public: explicit Channel(size_t capacity = 1) : capacity(capacity) {} void send(T value) { std::unique_lock<std::mutex> lock(mtx); cv_send.wait(lock, [this] { return queue.size() < capacity || closed; }); if (closed) { throw std::runtime_error("send on closed channel"); } queue.push(std::move(value)); cv_recv.notify_one(); } bool receive(T& value) { std::unique_lock<std::mutex> lock(mtx); cv_recv.wait(lock, [this] { return !queue.empty() || closed; }); if (queue.empty()) { return false; } value = std::move(queue.front()); queue.pop(); cv_send.notify_one(); return true; } void close() { std::lock_guard<std::mutex> lock(mtx); closed = true; cv_send.notify_all(); cv_recv.notify_all(); } private: std::queue<T> queue; std::mutex mtx; std::condition_variable cv_send; std::condition_variable cv_recv; size_t capacity; bool closed = false; };receive会一直阻塞，直到channel里有数据或者channel被关闭；关闭后如果队列为空，返回false，表示读取结束。send会在队列满时阻塞，直到有空间或者关闭。这个设计已经包含了典型的CSP语义：通信双方通过Channel间接联系，没有共享状态，队列本身是唯一被锁保护的对象。
真正的无缓冲同步Channel会更复杂：它需要记录是否有接收者正在等待，发送方要等接收方到位后才能交付数据。如果用这个有界缓冲版本，容量1其实就是一个“槽位”，并不是严格意义上的同步会合。但在实际工程里，很多CSP风格的代码都使用有缓冲Channel，因为完全同步会限制并行度，有缓冲有利于削峰填谷。如果你需要绝对同步，可以在send后把queue清空并通知发送方，这里留给读者作为练习。
3.3 多路选择与超时
CSP中经常需要在多个Channel上监听，Go的select可以随意监听任意多个channel。C++标准库没有原生select，手写一个多路复用器非常痛苦。原因在于条件变量不能同时等待多个channel，而轮询又浪费CPU。
我建议在实际C++代码里采用两种策略。第一种是拆分架构：让每个线程固定读一个channel，读到的消息放入一个统一的结果队列。第二种是使用成熟的库，比如CAF的select机制。如果你只是在实验代码里想要超时，可以给Channel增加timed_receive，用condition_variable的wait_for，而不是去包装std::async。用std::async做超时会非常危险，因为超时后你会得到一个被阻塞的线程，线程还拿着channel的锁，后续问题会极其难查。
Channel支持超时是实现分布式协同的重要能力。没有超时，一个慢消费者可能让整个生产者线程卡死，进而导致系统雪崩。因此，工程级Channel都应当支持阻塞等待超时，并且可以被打断取消。
3.4 CSP的实际适用场景
最适合CSP的是明确的“数据流”场景：流水线、扇入、扇出、队列、批量处理。比如日志系统里，几十个源线程把日志消息发送到同一个Channel，一个消费者线程集中写磁盘。Channel的容量就是自然缓冲区，当写入速度大于磁盘速度时，发送者会被阻塞，从而实现背压，防止内存被打爆。
CSP在代码里看起来很直接，因为它把每个并发单位变成了一个普通的顺序循环：读一个输入，处理，写一个输出。这种模式非常容易理解和测试。缺点是进程之间的耦合仍然隐含在Channel的共享中，一旦Channel数量增多，连接关系会变得难以管理。所以CSP适合小规模、结构清晰的并发协作，Actor则更适合需要隔离、恢复和分布式的场景。
4. 实战：用Actor与CSP构建一个并发任务分发系统
4.1 场景需求：任务从生成到结果汇总
假定我们要做一个并发任务处理服务。有一个任务生成器不断产生整数任务，三个Worker负责计算任务的平方，一个Collector汇总结果。整个处理过程要并发执行，不能丢任务，也不能出现数据竞争。
这个场景非常适合同时用CSP和Actor两种模型实现。CSP版本用一条“任务Channel”把任务派发给Worker，用另一条“结果Channel”把结果送回Collector；Actor版本则把生成器、Worker、Collector分别封装成Actor，消息异步流动。两种实现的核心区别在于通信方式和调度方式，我会对比它们的工程复杂度。
4.2 CSP实现：Channel即管道
我用前面写的Channel模板来实现。Producer发送10个任务后关闭任务Channel，三个Worker并发消费，结果统一送往结果Channel，Consumer收满所有结果后退出。
#include <atomic> #include <iostream> #include <thread> #include <vector> Channel<int> task_channel(4); Channel<int> result_channel(4); std::atomic<int> active_workers{3}; const int WORKER_DONE = -1; void producer() { for (int i = 0; i < 10; ++i) { task_channel.send(i); } task_channel.close(); } void worker() { while (true) { int t; if (!task_channel.receive(t)) break; result_channel.send(t * t); } if (--active_workers == 0) { result_channel.send(WORKER_DONE); } } void consumer() { while (true) { int r; result_channel.receive(r); if (r == WORKER_DONE) break; std::cout << "result: " << r << std::endl; } } int main() { std::thread p(producer); std::vector<std::thread> workers; for (int i = 0; i < 3; ++i) { workers.emplace_back(worker); } std::thread c(consumer); p.join(); for (auto& w : workers) w.join(); c.join(); return 0; }这段代码能跑，但有几个坑需要说明。第一，active_workers是std::atomic，多个worker从任务Channel退出后，最后一个负责发送WORKER_DONE标志。第二，result_channel的容量只有4，如果消费者消费不过来，生产者会阻塞，这是背压发挥作用。第三，多个worker同时向result_channel发送，channel内部的锁保证了线程安全，但发送顺序取决于调度器的竞争，所以最终结果的顺序是不确定的。
从这个例子可以看到，CSP实现将整个业务拆成几个顺序循环，代码很容易读懂。问题在于关闭语义必须在所有生产者之间协调好，否则很容易出现异常。这是CSP在工程里最需要注意的点。
4.3 Actor实现：消息即行为
Actor版本不需要显式的Channel，每个WorkerActor拥有自己的邮箱，ManagerActor通过send把任务派发给指定Worker。下面是核心结构。
class CollectorActor : public Actor { public: void collect(int result) { send([this, result] { std::cout << "result: " << result << std::endl; }); } }; class WorkerActor : public Actor { public: explicit WorkerActor(CollectorActor* collector) : collector_(collector) {} void compute(int task) { send([this, task] { int result = task * task; collector_->collect(result); }); } private: CollectorActor* collector_; }; class ManagerActor : public Actor { public: explicit ManagerActor(std::vector<WorkerActor*> workers) : workers_(workers) {} void dispatch(int task) { send([this, task] { int idx = next_++; workers_[idx % workers_.size()]->compute(task); }); } private: std::vector<WorkerActor*> workers_; int next_ = 0; };ManagerActor收到分发请求后，在自己的线程里决定把任务交给哪个WorkerActor，然后调用WorkerActor的compute。compute又把具体的处理逻辑封装成消息发给WorkerActor自己的邮箱。整个链路上没有任何锁，每个Actor的状态只被自己线程访问。
这个Actor版本相比CSP版本，最大的优势是WorkerActor内部状态可以被随意保存，比如每个Worker可以记录自己处理的任务数量，而不会与其他Worker冲突。缺点是消息类型和生命周期管理都要自己设计，代码量比CSP版本多不少。
4.4 对比与工程选型建议
| 维度 | CSP Channel | Actor |
|---|---|---|
| 通信方式 | 通过显式Channel同步/近同步 | 通过邮箱异步投递 |
| 背压控制 | Channel容量天然限制 | 需要有界邮箱或主动限流 |
| 数据顺序 | 单Channel内FIFO，多Channel竞争 | 同一Actor的邮箱FIFO |
| 状态封装 | 进程内局部变量，天然独立 | Actor私有状态，强封装 |
| 错误恢复 | 进程崩溃需外部监控 | 监督者Actor可重启子Actor |
| 调试难度 | Channel连接关系清晰 | 消息路径隐藏，需日志追踪 |
| 适合场景 | 数据流水线、扇入扇出 | 业务实体建模、分布式系统 |
我的建议很直接。如果你的核心架构是一条条数据管道，任务从一个Stage流向下一个Stage，用CSP。如果你的系统由大量长期存在的实体组成，每个实体有自己独立的状态和行为，比如用户、订单、设备连接，用Actor。两种模型可以混用，但混用时要明确边界，不要让Actor内部处理逻辑里又冒出一条Channel流水线，那样会同时失去两种模型的优势。
5. 常见问题与排查技巧实录
5.1 死锁与消息循环依赖
并发系统最常见的死锁是循环等待。在Actor模型里，如果ActorA等待ActorB的结果，同时ActorB等待ActorA的结果，而两边都是同步等待，就死锁了。在CSP模型里，如果两个Channel互相发送数据，发送方都阻塞等待对方接收，也会死锁。
解决思路有三个方向：一是把同步调用改成异步回调，发送消息后立刻返回，收到结果再继续；二是给所有同步等待设置超时，比如Channel的timed_receive超过100毫秒就抛出异常；三是引入监督者，如果一个Actor或进程持续无响应，监督者周期性心跳超时后强制重启它。
5.2 消息积压与内存爆炸
无界邮箱是Actor系统里的头号危险因素。消费者处理不过来时，生产者的消息仍然可以无限入队，内存很快被打满。而CSP因为带容量限制，天然会阻塞生产者，反而更安全。
解决办法是给邮箱设置最大长度，超过上限时采取丢弃、合并或拒绝策略。丢弃适合日志或监控指标，合并适合状态更新场景。对于任务分发系统，更推荐使用有界Channel作为邮箱底板，或者在Actor收到消息时检查队列负载并向上游反馈压力。
5.3 生命周期管理与线程泄漏
Actor和线程不同，它有停止语义。很多初学者的Actor基类没有析构时发送停止消息的逻辑，或者直接忘记join，导致程序退出时线程还挂在阻塞队列中。我的Actor基类里，析构函数先发送停止消息再join，这能保证线程一定退出。
CSP的关闭协议同样麻烦。多个生产者共享一个Channel时，绝不能由某个生产者单独关闭，否则其他生产者再发送就会崩溃。正确做法是等待所有生产者退出后，由协调者关闭Channel。如果无法判断，就使用引用计数或显式的结束消息，与任务数据一起传递。
5.4 调试工具与日志技巧
Actor和CSP的消息流看不见摸不着，调试难度比锁模型更高。强烈建议在开发阶段打开线程消毒器和内存消毒器：TSan可以检测数据竞争，ASan可以检测越界和悬空引用。GDB里可以查看所有线程的栈，通过backtrace找到阻塞点。
日志是排查并发问题的雷达。用spdlog打印发送方、消息类型、接收方和消息序号，可以还原整个消息链路。我习惯在Actor的send函数里加一个全局递增的trace_id，这样每个消息从创建到处理的耗时、路径都一目了然。生产环境不一定长期开着trace，但要保留开关，出问题时临时开起来定位。
5.5 避坑速查表
| 症状 | 可能原因 | 解决方案 |
|---|---|---|
| 程序卡死 | Actor或Channel循环等待 | 加超时，改用异步回调 |
| 内存持续增长 | 无界邮箱积压 | 有界队列，丢弃/合并策略 |
| 偶发数据错乱 | 消息内部共享可变对象 | 改为只传不可变或拷贝数据 |
| 退出时崩溃 | 未正确close Channel | 统一关闭协议，最后关闭 |
| 线程泄漏 | Actor析构未join | RAII析构发送停止消息并join |
| 数据竞争 | 多个线程直接访问Actor内部状态 | 所有状态修改放进Actor消息处理循环 |
| 结果乱序 | 并发处理天然无序 | 按顺序方案设计，或增加序号 |
写在最后的一点经验
我个人的体会是：Actor和CSP不是银弹，但它能让并发编程从“你盯着一堆锁死磕”变成“设计消息和连接结构”。在C++里，自己造轮子写一遍Actor和Channel，比直接拿库用一遍收获大得多。只有亲手踩过邮箱堆积、通道阻塞、线程退出这些坑，才能真正理解每一个设计取舍的原因。
如果你打算在正式项目里大规模使用，我建议不要直接把这篇文章里的极简实现搬上线。Actor至少需要有监督和重启机制，Channel至少需要支持超时和取消。可以优先评估CAF、SObjectizer这类成熟框架，把它们当作标准库之上的一层组合工具。最后再分享一个小技巧：无论是Actor消息还是Channel数据，尽量设计成有语义的类型，不要用裸int或裸struct当消息，否则三个月后你自己都看不懂消息在表达什么。
