rxjava 的 computation 调度器默认创建与 cpu 核心数相等的线程，并尽可能将其调度到不同物理核心上，主要目的是提升缓存局部性与执行效率，而非强制绑定；实际分配仍由操作系统调度器决定。
rxjava 的 computation 调度器默认创建与 cpu 核心数相等的线程，并尽可能将其调度到不同物理核心上，主要目的是提升缓存局部性与执行效率，而非强制绑定；实际分配仍由操作系统调度器决定。
在 RxJava 中，Schedulers.computation() 是专为纯 CPU 密集型任务（如数据转换、数学计算、JSON 解析等）设计的调度器。它默认创建的线程数等于 Runtime.getRuntime().availableProcessors() —— 即系统可用逻辑 CPU 核心数（含超线程）。但关键点在于：这些线程并非简单地“数量匹配”，而是通过设计倾向（而非硬性绑定）实现更优的底层执行表现。
为什么强调“distinct cores”？核心动因是缓存局部性（Cache Locality）
现代多核 CPU 中，每个核心通常拥有私有的 L1/L2 缓存。当一个线程长期运行在同一核心上时，其热点数据（如循环变量、中间计算结果、对象引用）更可能驻留在该核心的高速缓存中，从而极大减少访问主内存的延迟。反之，若线程频繁被 OS 迁移至不同核心（即“cache bouncing”），每次迁移都会导致缓存失效（cache miss）、冷加载（cold cache），显著拖慢计算密集型任务的整体吞吐。
RxJava 的 computation 调度器通过以下机制促进局部性：
- 使用固定大小的单线程线程池（
ScheduledThreadPoolExecutorwith 1-thread-per-worker），避免线程复用带来的上下文抖动； - 每个 worker 封装一个独占线程，确保同一订阅链中的连续任务（如
map→filter→reduce）尽可能在同一线程上串行执行，既保障操作符内部状态一致性，又减少跨核同步开销； - 配合 JVM 和 OS 的亲和性启发（如 Linux CFS 的负载均衡策略），在系统负载未饱和时，内核倾向于将长期活跃线程保留在原核心。
⚠️ 注意：RxJava 不提供 CPU 亲和性（CPU affinity）控制，也不调用
pthread_setaffinity_np或taskset等系统级 API。所谓“must run on distinct cores”是一种常见误解——实际行为是尽力而为（best-effort）：当所有 computation 线程均处于活跃计算状态（fully saturated）时，OS 调度器更大概率将它们分发至不同核心以平衡负载；但若存在空闲核心或系统启用了节能策略（如 Intel SpeedShift），部分线程仍可能被临时调度至同一核心。立即学习“Java免费学习笔记（深入）”；
对比：自定义调度器为何不具备此特性？
当你使用 Schedulers.from(Executor) 包装一个通用线程池（如 Executors.newFixedThreadPool(4)）时，该池中的线程不具备计算场景优化意图：
- 线程可能被复用于 I/O 或混合型任务；
- 无内置机制保障任务顺序性与无重入（reentrancy），导致某些 operator 需额外同步；
- 更重要的是，JVM 不会对这类线程施加任何调度偏好，OS 完全按默认策略调度，缓存局部性无法保障。
示例对比：
// ✅ 推荐：利用 computation 调度器的局部性与语义保证
Observable.range(1, 1000000)
.map(x -> x * x) // CPU-bound
.filter(x -> x % 7 == 0)
.subscribeOn(Schedulers.computation())
.blockingSubscribe();
// ⚠️ 不推荐：失去局部性与调度语义
ExecutorService customPool = Executors.newFixedThreadPool(4);
Scheduler customScheduler = Schedulers.from(customPool);
Observable.range(1, 1000000)
.map(x -> x * x)
.subscribeOn(customScheduler) // 缓存行为不可控，且无顺序保证优势
.blockingSubscribe();总结
-
Schedulers.computation()的“核心数线程 + 倾向分离调度”是一种面向硬件特性的性能优化设计，核心目标是降低缓存失效开销，提升 CPU 密集型并行吞吐； - 它不突破 OS 调度边界，也不替代
Thread.setAffinity，但通过合理的线程模型与使用约束（仅用于 CPU 任务），与底层协同达成更优效果； - 若你的场景涉及大量非计算型任务、需精细控制核心绑定，或运行在实时性要求极高的环境，应结合系统工具（如
taskset、cgroups）或专用库（如 Java 19+ 的Thread.Builder+ScopedValue配合 native affinity）进一步优化，而非依赖 RxJava 自身调度器。
