rxjava 的 computation 调度器默认创建与 cpu 核心数相等的线程，并尽可能让每个线程长期运行在固定核心上，以提升缓存局部性与执行效率；但这并非硬性绑定，实际仍由操作系统调度器决定。
rxjava 的 computation 调度器默认创建与 cpu 核心数相等的线程，并尽可能让每个线程长期运行在固定核心上，以提升缓存局部性与执行效率；但这并非硬性绑定，实际仍由操作系统调度器决定。
RxJava 的 Schedulers.computation() 是专为计算密集型任务设计的调度器。它内部维护一个固定大小的线程池（默认线程数 = Runtime.getRuntime().availableProcessors()），且这些线程被有意设计为“长生命周期、低切换频率”的工作线程。其核心设计理念并非强制线程与物理核心一一绑定（Java 层面无法直接控制 CPU 亲和性），而是通过避免频繁线程迁移，配合操作系统调度策略，提高 L1/L2 缓存命中率——当一个线程持续在某个核心上执行时，其热点数据更可能保留在该核心的私有缓存中，显著减少因跨核迁移导致的缓存失效（cache bounce）和内存带宽争用。
值得注意的是：
- ✅ RxJava 不调用
pthread_setaffinity_np或Thread.setPriority等底层 API 实现核心绑定； - ✅ 它依赖的是线程池的静态分配 + 高负载下的自然驻留倾向：当所有计算线程持续忙碌时，OS 调度器倾向于复用已有核心上下文，降低上下文切换开销；
- ❌ 因此，“必定运行在不同核心”是理想行为，而非强保证——若系统存在高优先级中断、其他进程抢占或 NUMA 平衡策略介入，仍可能发生跨核迁移。
此外，每个 computation worker 本质是一个单线程的 ScheduledExecutorService（非 ForkJoinPool），这带来两大优势：
- 严格顺序执行：同一 worker 提交的多个任务按 FIFO 执行，无需额外同步，规避了重入（reentrancy）风险；
-
零调度开销：相比动态分发式线程池（如
Executors.newCachedThreadPool()），无任务队列竞争、无工作窃取（work-stealing）协调成本。
对比来看，若你使用 Schedulers.from(Executors.newFixedThreadPool(4))，虽线程数相同，但该 Executor 不具备核心驻留优化逻辑，且其线程可能被 OS 随意调度到任意核心，缓存局部性无法保障：
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
立即学习“Java免费学习笔记（深入）”；
// ❌ 无核心局部性保障：线程由通用 Executor 管理
Scheduler custom = Schedulers.from(Executors.newFixedThreadPool(4));
// ✅ 推荐用于 CPU 密集任务：computation 自动适配硬件并优化缓存行为
Scheduler compute = Schedulers.computation();
Observable.just(1, 2, 3, 4)
.map(x -> heavyComputation(x)) // 如矩阵运算、哈希计算等
.subscribeOn(compute)
.blockingSubscribe();⚠️ 注意事项：
- 若任务实际为 I/O 密集型（如网络请求、磁盘读写），请勿使用
computation()，应改用Schedulers.io()（基于弹性线程池）； - 在容器化环境（如 Docker/K8s）中，
availableProcessors()可能返回宿主机核数而非容器限制值，建议结合-XX:ActiveProcessorCount或cgroup v2配置修正； - 如需精确控制 CPU 亲和性（如实时系统场景），需借助 JNI（如
jna库调用sched_setaffinity）或外部工具（taskset），RxJava 本身不提供该能力。
总之，computation 调度器的设计哲学是：以最小侵入方式，借力 OS 调度规律，最大化多核 CPU 的计算吞吐与缓存效率——它不是魔法，而是对硬件特性和并发模式的深度协同。
