无论在何处，有多重任务要处理时，并发编程总是要得到考虑的。比如有 IO 等待时的并发或 CPU 密集型时的并行计算，并发通常是指在同一个 CPU 上按时间片轮换执行，并行是任务在不同的 CPU 上执行。能有效使用 CPU 多核的语言可以让线程运行在不同的核上实现并行，如果是启动的子进程能由操作系统运行在其他 CPU 核上。

回到 AWS Lambda 中的 Python 代码，如果是处理 IO 等待，使用多线程并发就行，大致的代码如下：

with ThreadPoolExecutor(10) as executor:
    result = executor.map(task_function, task_inputs)

以上代码在 AWS Lambda 中是可以运行的。

如果是 CPU 密集型的任务，用 Python 的多线程就要歇菜了，因为存在著名的 Python's GIL 的约束。 这时候就必须要考虑多进程并行的方式，同时应知晓当前选择的 Lambda 运行环境有多少个 CPU 内核，因为如果是单核的话再多进程也无济于事，没必要启动多于核心数的进程。 底下是本人上篇博客测试收集的不同 AWS Lambda 内存选择对应的 CPU 核心数，以及实际可用内存大小的关系表 Read More

去年记录过一篇如何使用 Python 的线程，线程池的日志 Python 多线程编程, 需用到 threading.Thread, concurrent.futures.ThreadPoolExecutor。本文可以当作是上一文 Python 多线程编程的姊妹篇。

Python 的多线程受到 GIL(Global Interpreter Lock) 的限制，GIL 是一把加到了 Python 的解释器的锁，使得在任意时刻只允许一个 Python  进程使用 Python 解释器，也就是任意时刻，Python 只有一个线程在运行。

GIL 严重影响了计算密集型(CPU-bound) 的多线程程序，此时的多线程与单线程性能没什么差异，也发挥不了多核的威力。但对 I/O 密集型(I/O-bound) 影响不大，因为 CPU 多数时候是在等待。

为了突破 GIL 的 CPU 密集型程序的限制，可以使用非 CPython 解释器，如 Jython, IronPython 或 PyPy, 更为现实的做法就是使用子进程来替代线程去承担较为繁重的计算任务，因为 GIL 是加在进程上的，所以新的进程有独立的 GIL. Read More