CPU亲和性绑定非必须但对多进程高并发服务（如gunicorn多worker）能减少上下文切换与缓存抖动；asyncio服务无需手动绑核，多进程模型才是主战场；需满足长期CPU密集、核心充足、存在跨核缓存失效等条件。
Python构建高并发服务时，CPU亲和性绑定不是“必须项”，但对性能敏感场景（如高频IO+计算混合型服务、多进程模型下的gunicorn/uwsgi worker）能显著减少上下文切换和缓存抖动，提升吞吐与稳定性。
明确哪些场景真正需要绑核
纯异步服务（如基于asyncio+uvloop的HTTP服务）通常不直接受益于手动绑核——事件循环本身已做良好调度；而多进程模型（如multiprocessing、gunicorn -w 4）才是绑核主战场。关键看是否满足：多个长期运行的CPU密集型worker、物理核心数充足、存在明显跨核缓存失效或调度抖动。
- Web服务用gunicorn启动8个sync worker，部署在16核机器上 → 适合按序绑定0-7号核心
- 后台任务进程池处理图像缩放，每个子进程持续占用CPU → 绑定可避免争抢L3缓存
- 单个Python进程+多线程 → 不建议绑核（GIL限制下线程无法并行计算，绑核反而可能加剧争抢）
用sched_setaffinity精准控制进程亲和力
Linux下最直接的方式是调用sched_setaffinity系统调用，Python可通过os.sched_setaffinity()（3.3+）实现。注意：该操作仅对当前进程有效，需在子进程创建后、业务逻辑开始前调用。
- 启动时传入CPU列表，例如只允许运行在核心2和核心5：
os.sched_setaffinity(0, {2, 5}) - 若在fork后设置，确保每个worker绑定不同核心，避免冲突（可用
os.getpid() % os.cpu_count()简单分片） - 绑定前检查权限：非root用户可能受限，生产环境建议用
sudo setcap cap_sys_nice+ep /usr/bin/python3授权
结合启动器自动化分配（以gunicorn为例）
不推荐硬编码绑核逻辑到应用代码中，更合理的是通过启动配置或wrapper脚本统一管理。gunicorn支持--preload + 自定义worker初始化钩子：
立即学习“Python免费学习笔记（深入）”；
- 写一个
bind_cpu.py，在post_fork中调用os.sched_setaffinity，按worker_id分配独占核心 - 使用
taskset命令行工具更轻量：taskset -c 0-3 gunicorn app:app --workers 4（把前4个worker限定在0~3号核） - 容器环境（Docker/K8s）优先用
--cpuset-cpus="0-3"，由cgroup统一管控，比进程内绑定更可靠
验证是否生效及常见陷阱
绑定不是一劳永逸，必须验证。用ps -o pid,psr,comm -p <pid>查看进程当前运行在哪颗CPU上（PSR列），或taskset -p <pid>查掩码。常见问题：
- 父进程绑核后，fork出的子进程默认继承亲和性 → 若未重设，多个worker可能挤在同一核
- 超线程（HT）核心（如0/16、1/17）共享缓存 → 避免将高负载worker同时绑定到SMT配对核
- 云主机存在“虚拟核”或频率动态调整 → 绑核前先用
lscpu确认物理拓扑，优先绑定物理核心而非逻辑ID
基本上就这些。CPU亲和性不是银弹，但它在合适的位置能稳住性能基线——尤其当你的服务从“能跑”迈向“跑得稳、跑得满”时，值得花半小时配好。
