4. 多线程与并发：Python GIL的影响、多进程方案、异步IO在摄像头采集中的应用

说到多摄像头采集，Python 的并发问题总是绕不开的坎。很多新手一上来就开多线程，结果发现帧率不升反降。我当年第一次做四路 USB 摄像头同步时，就踩过这个坑。今天咱们把 GIL、多进程、异步 IO 这三板斧掰开揉碎讲清楚。

4.1 Python GIL 对摄像头采集的影响

GIL 是什么？说白了就是 Python 解释器里的一把大锁。同一时刻，只有一个线程能执行 Python 字节码。你开 8 个线程采集 8 路摄像头，实际上它们还是在抢同一把锁。

为什么会这样？因为摄像头采集时，大部分时间花在等待硬件返回数据上。这个等待过程会释放 GIL，其他线程就能趁机执行。但一旦开始做图像处理——比如缩放、格式转换、特征提取——GIL 就死死卡住。

我在项目中遇到过这样的情况：用 4 个线程采集 4 路 1080p 摄像头，纯采集时帧率还能维持在 25fps 左右。但一旦加入 OpenCV 的 resize 和颜色空间转换，帧率直接掉到 8fps。这就是 GIL 在作祟。

场景	GIL 影响程度	实际表现
纯采集（等待帧）	低	多线程有效，帧率接近线性提升
采集 + 简单处理	中	帧率提升有限，约 1.5-2 倍
采集 + 复杂处理	高	帧率不升反降，甚至不如单线程

4.2 多进程方案：绕过 GIL 的正确姿势

多进程方案的核心思路很简单：每个进程有自己的 GIL，互不干扰。你开 4 个进程，就有 4 把锁，4 个 CPU 核心可以同时跑。

但多进程不是银弹。进程间通信（IPC）的开销比线程间通信大得多。你想想看，线程共享内存，进程得靠队列、管道、共享内存来传数据。

4.2.1 进程池 + 队列模式

我个人习惯用 multiprocessing.Pool 配合 Manager.Queue。每个采集进程只管往队列里丢帧，主进程从队列里取帧做同步和时间戳对齐。

from multiprocessing import Process, Queue
import cv2

def capture_worker(cam_id, queue):
    cap = cv2.VideoCapture(cam_id)
    while True:
        ret, frame = cap.read()
        if not ret:
            break
        # 带上时间戳，方便后续同步
        queue.put((cam_id, time.time(), frame))

queues = [Queue(maxsize=30) for _ in range(4)]
processes = []
for i in range(4):
    p = Process(target=capture_worker, args=(i, queues[i]))
    p.start()
    processes.append(p)

# 主进程从各队列取帧做同步
while True:
    frames = []
    for q in queues:
        frames.append(q.get())
    # 这里做帧对齐和时间同步
    sync_frames(frames)

4.2.2 共享内存方案

如果帧数据量特别大（比如 4K 分辨率），队列的序列化反序列化开销会吃掉所有性能。这时候得用共享内存。

Python 的 multiprocessing.shared_memory 模块（3.8+）可以直接在进程间共享 numpy 数组。我去年做的一个 8 路 4K 项目，就是用共享内存把帧传输延迟从 15ms 降到了 2ms。

from multiprocessing import shared_memory
import numpy as np

# 创建共享内存块
shm = shared_memory.SharedMemory(name='frame_0', create=True, size=1920*1080*3)
frame_buffer = np.ndarray((1080, 1920, 3), dtype=np.uint8, buffer=shm.buf)

# 子进程直接写入
frame_buffer[:] = captured_frame

# 主进程直接读取
process_frame(frame_buffer)

4.3 异步IO在摄像头采集中的应用

异步 IO 是另一种思路。它不依赖多线程或多进程，而是用事件循环来调度任务。Python 的 asyncio 库就是干这个的。

但有个问题：OpenCV 的 VideoCapture.read() 是阻塞调用，没法直接用在 asyncio 里。怎么办？用 loop.run_in_executor 把阻塞调用丢到线程池里跑。

4.3.1 异步采集框架

import asyncio
import cv2

async def async_capture(cam_id):
    cap = cv2.VideoCapture(cam_id)
    loop = asyncio.get_event_loop()
    while True:
        # 把阻塞的 read 放到线程池执行
        ret, frame = await loop.run_in_executor(None, cap.read)
        if not ret:
            break
        # 异步处理帧
        await process_frame_async(frame)

async def main():
    tasks = [async_capture(i) for i in range(4)]
    await asyncio.gather(*tasks)

asyncio.run(main())

这个方案的好处是：你可以在等待帧数据的同时，做其他事情。比如同时处理网络请求、更新 UI、写日志。我做过一个实验：4 路摄像头采集 + 同时推送 RTMP 流，异步方案比多线程方案 CPU 占用低了 20%。

4.3.2 异步 vs 多进程：怎么选？

维度	异步 IO	多进程
CPU 利用率	单核，适合 IO 密集型	多核，适合 CPU 密集型
帧处理能力	弱，处理复杂任务会阻塞事件循环	强，每个进程独立处理
内存开销	低，共享同一进程空间	高，每个进程独立内存
编程复杂度	中等，需要理解 async/await	较高，需要处理 IPC
适用场景	纯采集 + 轻量处理 + 网络传输	采集 + 复杂图像处理 + 编码

4.4 三种方案对比总结

咱们用一张图来总结这三种方案的核心区别和适用边界。

4.5 实战选型建议

说了这么多，到底怎么选？我根据实际项目经验，给几个具体建议：

• 2-4 路 720p 摄像头，纯采集 + 显示：用异步 IO 就够了。代码简单，资源占用低。
• 4-8 路 1080p 摄像头，需要做拼接或检测：上多进程。每个进程处理 1-2 路，用共享内存传帧。
• 8 路以上 4K 摄像头：别用 Python 了，换 C++。Python 的多进程调度开销在超高分辨率下扛不住。
• 混合场景（采集 + 网络推流 + 本地存储）：异步采集 + 多进程处理 + 异步推流。各层用队列解耦。