Q71: 多线程 vs 多进程，如何选择？
核心结论
多线程和多进程没有绝对优劣，核心取决于你更看重什么：
- 共享数据的低成本
- 故障隔离
- 扩展边界
- 调试和运维复杂度
对在线游戏服务来说，常见结论不是二选一，而是分层组合：
- 进程之间做职责隔离
- 进程内部按需要使用少量线程
一、两者真正的差别不在概念，在边界
1. 多线程
优势通常在：
- 共享内存方便
- 跨线程通信成本低
- 适合同一进程内的协作
问题也很明显：
- 共享状态带来同步复杂度
- 一个严重错误可能拖垮整个进程
- 调试竞态和死锁成本高
2. 多进程
优势通常在：
- 隔离性强
- 故障域更清晰
- 更适合职责边界明显的模块拆分
代价是：
- 进程间通信更重
- 部署和观测更复杂
- 数据共享要显式设计
二、在线游戏里真正该怎么判断
关键通常不是“哪个更先进”，而是看业务边界。
如果一个模块：
- 状态独立
- 故障不应影响别的模块
- 可以通过消息交互
那它更适合独立进程。
如果一个模块：
- 需要高频共享数据
- 强依赖同一地址空间
- 线程协作成本低于 IPC
那它可能更适合留在进程内。
三、为什么很多 MMO 架构偏向多进程
因为很多核心职责天然可以分层：
- 登录
- 网关
- 场景逻辑
- 数据库代理
- 后台服务
拆成多进程后，通常更容易做到：
- 故障隔离
- 按模块扩容
- 独立观测和部署
这比把所有逻辑堆进一个超大多线程进程更稳。
四、多线程依然很重要，但更适合进程内部局部使用
例如：
- I/O 线程
- 后台任务线程
- 数据库工作线程
- 压缩、序列化等辅助线程
也就是说，多线程更适合解决“同一进程内怎么更高效地做事”，多进程更适合解决“系统边界和故障域怎么划分”。
五、不要只看性能，也要看故障成本
很多团队容易只盯：
- 创建开销
- 上下文切换
- IPC 成本
但在线服务更实际的问题还包括：
- 一个模块崩了影响多大
- 定位问题是否容易
- 是否能单独发布和重启
这些往往会让多进程更有吸引力。
六、工程上更稳妥的组合
很多成熟系统最终都会落成：
- 组件级多进程
- 组件内部少量线程
- 线程之间避免大规模共享状态
这样既有隔离性，也能保留进程内协作效率。
七、常见误区
1. 多线程一定比多进程快
局部通信可能更快，但整体系统未必更稳、更易扩展。
2. 多进程一定更高级
如果边界没划好，只会得到更多 IPC 和更多运维成本。
3. 必须全线程化或全进程化
现实工程里最常见的是混合方案。
参考资料
- 多进程服务拆分与线程模型设计实践资料