Python 3.13 os.process_cpu_count 怎么选并发度：容器配额、默认值与线程池边界

同一段 Python 并发代码，在宿主机上开 8 个进程，放进只给 2 个 CPU 配额的容器后却只应该开 2 个进程。Python 3.13 新增的 os.process_cpu_count() 就是用来回答“当前进程实际能用多少逻辑 CPU”的；它可能小于 os.cpu_count()，无法判断时还可能返回 None。

先把 os.cpu_count 与 os.process_cpu_count 分开

最小检查代码如下，直接在目标运行环境执行，不要只在开发机打印一次。

import os; system_cpus = os.cpu_count(); usable_cpus = getattr(os, "process_cpu_count", lambda: None)(); print({"cpu_count": system_cpus, "process_cpu_count": usable_cpus})

cpu_count() 返回系统中的逻辑 CPU 数；process_cpu_count() 返回当前进程可用的逻辑 CPU 数。后者受到 CPU affinity 等进程约束影响，所以容器里常见的结果是前者大、后者小。它不是“当前任务一定能拿到的 CPU 百分比”，也不替代业务层限流。

容器里并发度应该按哪个数起步

如果任务主要做 CPU 计算，可以把可用 CPU 数作为进程池的起点，再叠加业务上限。这里不建议直接把 None 传给自定义计算，因为不同机器上的回退行为会变得不透明。

import os; def cpu_budget(cap: int = 8) -> int: detected = getattr(os, "process_cpu_count", lambda: None)(); detected = detected if detected and detected > 0 else (os.cpu_count() or 1); return max(1, min(detected, cap)); workers = cpu_budget(); print(f"workers={workers}")

这个写法表达了三个判断：优先使用进程可用 CPU；检测不到时才回退到系统 CPU；最后用上限挡住测试环境或高配宿主机带来的过量并发。生产环境还应把实际 worker 数写入启动日志，方便和容器资源配置对照。

为什么不能把它当作所有任务的 worker 数

CPU 密集型的 JSON 压缩、图像处理、数值计算更适合参考这个数。网络请求、磁盘等待或数据库连接池则受外部并发限制影响，worker 数通常要结合超时、连接上限和服务端配额；盲目把 I/O 任务限制成 CPU 数，可能让吞吐下降。

Python 3.13 的 ProcessPoolExecutor 默认值变了什么

Python 3.13 起，ProcessPoolExecutor(max_workers=None) 的默认进程数使用 os.process_cpu_count()，而不是 os.cpu_count()。因此同一容器里升级解释器后，未显式指定 max_workers 的程序可能自动减少进程数，这是行为变化，不是任务丢失。

from concurrent.futures import ProcessPoolExecutor; def square(value: int) -> int: return value * value; with ProcessPoolExecutor(max_workers=2) as pool: print(list(pool.map(square, range(4))))

需要稳定容量时，显式传入经过业务约束的 max_workers；需要跟随容器配额时，保留默认值也可以，但要在升级回归中记录默认 worker 数。别只看任务结果是否正确，启动日志和进程数量同样是验收证据。

三个并发方案怎么选

对线程池而言，CPU 数也不是唯一答案；线程切换、阻塞比例和下游连接数往往更关键。文章的核心是先弄清“系统看见多少 CPU”和“进程能用多少 CPU”，再把这个事实放进具体资源模型。

升级后用一组小检查确认默认行为

1. 在 Python 3.12 和 3.13 的相同容器限制下分别打印 cpu_count() 与 process_cpu_count()。
2. 对没有传 max_workers 的进程池记录启动后的 worker 数，不要仅凭版本号猜测。
3. 对显式 worker 配置跑一次峰值内存、CPU throttling 和任务耗时测试。
4. 如果检测结果为 None，确认回退值不会突破连接池、内存或下游限流。

常见问题

process_cpu_count 一定比 cpu_count 小吗？

不一定。没有进程级 CPU 限制时可能相同；有 affinity 或容器约束时可能更小，无法确定时返回 None。

Python 3.13 升级后进程池变慢怎么办？

先记录新旧版本的默认 worker 数，再检查容器配额、CPU throttling 和任务类型。需要稳定容量时显式设置 max_workers，不要直接回退到系统 CPU 数。

可以用 process_cpu_count 设置数据库连接池吗？

只能作为一个容量参考。连接池还要受数据库最大连接数、请求并发和超时影响，通常需要更小的独立上限。

结语：把 CPU 探测值当作输入，不当作答案

os.process_cpu_count() 解决的是运行环境识别问题，真正的并发度仍由任务类型、内存、连接池和下游承载能力共同决定。Python 3.13 的默认进程池行为已经向“进程可用 CPU”靠拢，升级时补上日志和容量回归，才不会把默认变化误判成随机性能波动。