4. 进程与线程抉择：GIL锁的真相，何时用多进程，何时用多线程
说到并行计算，有个绕不开的话题——GIL锁。很多新手一上来就说「Python多线程是假的」，这话对，也不全对。我刚开始做回测框架时也踩过这个坑，今天咱们把这事彻底聊透。
4.1 GIL锁到底是什么？
GIL，全称Global Interpreter Lock，全局解释器锁。说白了，就是CPython解释器里的一把大锁。它规定：同一时刻，只有一个线程能执行Python字节码。
为什么会这样？这得从Python的内存管理说起。Python的对象引用计数不是线程安全的，如果多个线程同时修改同一个对象的引用计数，内存就乱了。Guido老爷子当年图省事，直接上了把大锁。嗯，这个设计在单核时代没问题，但到了多核时代就成了瓶颈。
核心结论：CPU密集型任务，多线程在Python里基本没用。I/O密集型任务，多线程依然能打。
4.2 多线程的真相：什么时候该用？
我做过一个实验：用4个线程去计算100万次斐波那契数列。结果呢？单线程跑了2.3秒，4线程跑了2.8秒——反而更慢了！这就是GIL的「功劳」：线程切换的开销比并行计算带来的收益还大。
但换一个场景：用4个线程去下载100个股票的历史数据。单线程要等网络I/O，4线程几乎同时完成。为什么？因为线程在等待网络响应时，会释放GIL，其他线程就能趁机执行。
多线程适用的场景：
- 网络请求、文件读写等I/O操作
- 数据库查询、API调用
- 用户界面响应（保持界面不卡顿）
- 轻量级的并发任务（任务本身不消耗CPU）
我的经验：在回测中，数据获取阶段用多线程非常合适。比如同时拉取多只股票的历史K线，或者并行下载因子数据。我曾经用8个线程把数据下载时间从15分钟压缩到了3分钟。
4.3 多进程：真正的并行利器
多进程就不一样了。每个进程有自己独立的Python解释器和内存空间，GIL互不干扰。说白了，4个进程就是4个独立的Python程序在跑。
我做过对比：用4个进程计算同样的斐波那契数列，耗时从2.3秒降到了0.7秒。这才是真正的并行。
多进程适用的场景：
- CPU密集型的计算任务（策略回测、因子计算）
- 需要充分利用多核CPU的场景
- 任务之间数据隔离要求高
- 大规模并行回测
注意：多进程不是万能的。进程间通信（IPC）开销很大，数据传递需要序列化/反序列化。如果任务本身很轻量，进程创建和通信的开销可能抵消掉并行带来的收益。
4.4 实战抉择：回测中怎么选？
我整理了一个决策表，你在写回测框架时可以直接参考：
| 任务类型 | 推荐方案 | 原因 |
|---|---|---|
| 数据获取（网络I/O） | 多线程 | I/O等待时释放GIL，线程切换开销小 |
| 因子计算（CPU密集） | 多进程 | 需要真并行，GIL是瓶颈 |
| 策略回测（CPU密集） | 多进程 | 每个策略独立运行，天然适合进程隔离 |
| 实时行情推送 | 多线程 | I/O密集，且需要共享内存状态 |
| 参数优化（网格搜索） | 多进程 | 每个参数组合独立计算，完美并行 |
4.5 代码示例：多进程回测框架
下面是我在实际项目中用的一个简化版多进程回测框架。你想想看，如果单线程跑1000个参数组合，可能要等一整天。用多进程，8核机器上能压到2小时以内。
import multiprocessing as mp
import pandas as pd
import numpy as np
def run_backtest(params):
"""
单个策略的回测函数
params: (ma_short, ma_long, stop_loss)
"""
ma_short, ma_long, stop_loss = params
# 模拟回测逻辑
data = pd.DataFrame({
'close': np.random.randn(1000).cumsum() + 100
})
data['ma_short'] = data['close'].rolling(ma_short).mean()
data['ma_long'] = data['close'].rolling(ma_long).mean()
# 生成交易信号
data['signal'] = 0
data.loc[data['ma_short'] > data['ma_long'], 'signal'] = 1
data.loc[data['ma_short'] <= data['ma_long'], 'signal'] = -1
# 计算收益（简化版）
data['returns'] = data['close'].pct_change()
data['strategy_returns'] = data['signal'].shift(1) * data['returns']
sharpe = np.sqrt(252) * data['strategy_returns'].mean() / data['strategy_returns'].std()
max_drawdown = (data['strategy_returns'].cumsum().cummax() - data['strategy_returns'].cumsum()).max()
return {
'params': params,
'sharpe': sharpe,
'max_drawdown': max_drawdown
}
def parallel_optimization():
"""
多进程参数优化
"""
# 生成参数组合
param_grid = []
for short in [5, 10, 20]:
for long in [20, 50, 100]:
for sl in [0.02, 0.05, 0.08]:
param_grid.append((short, long, sl))
print(f"总参数组合数: {len(param_grid)}")
# 使用进程池并行执行
with mp.Pool(processes=mp.cpu_count()) as pool:
results = pool.map(run_backtest, param_grid)
# 整理结果
df_results = pd.DataFrame(results)
best = df_results.loc[df_results['sharpe'].idxmax()]
print(f"最优参数: MA短={best['params'][0]}, MA长={best['params'][1]}, 止损={best['params'][2]:.2%}")
print(f"最优夏普比: {best['sharpe']:.3f}")
return df_results
if __name__ == '__main__':
# 注意：多进程必须在 __main__ 中启动
results = parallel_optimization()避坑指南：我曾经犯过一个错误——在Windows上调试多进程代码时，忘记把入口代码放在 if __name__ == '__main__': 里面。结果进程无限递归创建，直接把16G内存吃满了。嗯，这个教训挺深刻的。
4.6 混合方案：鱼和熊掌兼得
实际项目中，我经常用混合方案。比如回测框架中：
- 数据层：用多线程并发获取数据
- 计算层：用多进程并行跑策略
- 结果汇总：用单线程或少量线程收集结果
这样做的好处是：数据获取阶段I/O密集，多线程效率高；策略计算阶段CPU密集，多进程真并行。各取所长，性能最优。
我的建议：别纠结「多线程还是多进程」这个二选一的问题。实际工程中，往往是两者结合。你想想看，一个完整的回测系统，数据获取、因子计算、策略回测、结果分析，每个阶段的计算特征都不一样。针对性地选择并行方案，才是高手之道。
4.7 知识体系总结
下面这张图是我梳理的决策流程，你可以保存下来当参考：
记住一个核心原则：看你的任务是在等CPU还是在等I/O。等CPU就用多进程，等I/O就用多线程。如果两者都有，那就分层处理。我在多个回测框架项目中验证过这个思路，效果都不错。