线程池本身不提供任务亲和性调度能力，需通过预绑定专用工作线程到固定CPU核心，并手动路由同组任务至该线程私有队列来实现缓存局部性优化。
线程池本身不提供“任务亲和性”调度能力，它按队列 FIFO 或优先级顺序分发任务，与 CPU 核心无关。要让同一批处理变量的任务尽量落在同一个 CPU 核心上运行，需在任务提交前主动绑定线程与核心，并配合线程池的结构做定制化设计——不是靠调度器自动识别“同批变量”，而是靠人为控制执行载体。
理解“任务亲和性”的真实含义
操作系统没有“按数据变量分组调度任务”的机制。所谓“同一批变量的任务跑在同一核心”，本质是：把这批任务统一交给一个**已绑定到固定 CPU 核心的专用工作线程**去串行或批量执行。关键不在任务本身，而在承载它的线程是否稳定驻留于某核心。
这依赖两个前提：
- 该线程从启动起就设置了 CPU 亲和性掩码（如只允许在核心 2 运行）
- 线程池不复用或迁移该线程（例如避免使用通用线程池，改用固定专属线程）
实现方式：绑定专用线程 + 手动分发任务
以 Linux 环境为例，常见可行路径如下：
- 为每组关键变量（如某个用户 ID、设备 ID、数据分片 key）预分配一个专用工作线程，并在创建时调用 sched_setaffinity() 将其绑定到指定核心
- 任务提交时不走通用队列，而是通过哈希（如 key % thread_count）路由到对应线程的私有任务队列
- 每个专用线程内部采用循环 take() 模式消费自身队列，确保所有同 key 任务都在同一 OS 线程中执行，进而稳定运行于同一物理核心
这种方式绕开了通用线程池的负载均衡逻辑，换来的是确定性的缓存局部性——L1/L2 缓存热数据持续复用，避免跨核迁移导致的 cache miss。
语言层适配要点
不同语言对线程亲和性的支持程度不同，需注意底层约束：
- Python：无标准库支持，需用 python-cpu-affinity 或 psutil.Process().cpu_affinity()（仅限进程级），更推荐用 threading.Thread 创建后，通过 os.sched_setaffinity() 绑定当前 OS 线程 ID
- Java：JVM 层面不暴露亲和性 API；可通过 JNA 调用 Linux sched_setaffinity，但只能作用于当前线程（即必须在 Runnable.run() 开头立即设置）
- C++26：支持 std::this_thread::set_affinity({2})，可在工作线程启动后直接声明目标核心，语义清晰且跨平台收敛度高
- C#：仅 Windows 有效，用 ProcessThread.ProcessorAffinity 设置，且必须在托管线程已映射到 OS 线程后操作（推荐在 Thread.Start() 后立刻获取并设置）
为什么不能依赖线程池自动实现？
主流线程池（如 Java 的 ThreadPoolExecutor、C++ 的 std::thread_pool、Python 的 concurrent.futures.ThreadPoolExecutor）设计目标是吞吐与公平，不是局部性。它们：
- 共享同一任务队列，调度器按空闲线程可用性分发，不感知任务语义
- 线程可能被系统抢占、迁移，甚至被线程池回收重建
- 即使开启“核心线程永驻”，也无法阻止内核调度器将该线程临时迁移到其他核心（除非显式设亲和性）
换句话说：线程池管“有没有人干活”，不管“谁在哪干”；而亲和性调度要解决的是“固定的人，在固定的地方，持续干同类活”。两者目标不同，需分层协作而非寄望一体实现。
