为什么线程不是越多越好？一文讲透上下文切换成本

在学习多线程编程时，很多初学者容易有一个误区：线程越多，程序就越快 。

然而实际情况是，过多线程不仅不会加速，反而可能让性能急剧下降。背后的原因就是 上下文切换成本。

一、什么是上下文切换？

在操作系统中，CPU 同时只能执行一个线程。当存在多个线程时，调度器会通过 时间片轮转 或 优先级机制 在不同线程之间切换。

上下文切换（Context Switch） 指的就是：

保存当前线程的 CPU 寄存器、程序计数器、内存映射等信息；
加载下一个线程的上下文；
切换执行权。

虽然这个过程对开发者透明，但对 CPU 来说是一种额外负担。

二、上下文切换的成本

CPU 开销
- 每次切换需要保存和恢复寄存器、程序计数器等状态。
- 切换太频繁会让 CPU 时间浪费在"切换"而非"计算"。
缓存失效
- CPU 有多级缓存（L1/L2/L3），切换线程后缓存命中率降低，增加内存访问延迟。
锁竞争加剧
- 多线程共享资源时，切换更频繁，线程更可能处于 BLOCKED 或 WAITING 状态。
调度延迟
- 线程数大于 CPU 核心数时，操作系统需要频繁调度，延迟明显。

三、为什么线程不是越多越好？

CPU 核心数量有限
- 一个 8 核 CPU 理论上同时最多执行 8 个线程，其余线程只能排队等待。
线程过多会导致"饿死"
- 部分线程可能长期得不到调度，造成延迟。
上下文切换成为瓶颈
- 当线程数远大于核心数时，CPU 花费大量时间在切换上，反而降低吞吐量。

类比：

就像餐馆里只有 4 个厨师（CPU 核心），如果同时安排 100 个订单（线程），厨师不停在不同菜之间切换，结果每道菜都做得更慢。

四、实战验证：线程过多反而更慢

示例代码：

java 复制代码

public class ContextSwitchDemo {
    public static void main(String[] args) throws InterruptedException {
        int threadCount = 1000; // 创建1000个线程
        Thread[] threads = new Thread[threadCount];

        for (int i = 0; i < threadCount; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    Math.sqrt(j); // 模拟计算
                }
            });
        }

        long start = System.currentTimeMillis();
        for (Thread t : threads) t.start();
        for (Thread t : threads) t.join();
        long end = System.currentTimeMillis();

        System.out.println("耗时: " + (end - start) + " ms");
    }
}

在 CPU 核心数有限的机器上，线程数越多，耗时往往并不会线性减少，甚至可能增加。

五、优化思路

控制线程数量
- 通常线程数 ≈ CPU 核心数 × 2（考虑 I/O 阻塞时）。
- 使用 Runtime.getRuntime().availableProcessors() 动态获取。
使用线程池
- 避免频繁创建和销毁线程，减少系统开销。
- 典型实现：Executors.newFixedThreadPool()。
区分 CPU 密集型与 I/O 密集型任务
- CPU 密集型：线程数 ≈ CPU 核心数。
- I/O 密集型：线程数可以更多，但要平衡。
利用异步和并发框架
- 比如 CompletableFuture、ForkJoinPool、Reactive 编程，减少线程切换。

六、总结

上下文切换是线程的隐性成本，涉及 CPU 状态保存与恢复、缓存失效和锁竞争。
线程并非越多越好，过多反而可能拖慢系统。
正确做法：合理控制线程数量，使用线程池，区分 CPU 密集和 I/O 密集任务。

理解上下文切换，有助于我们避免盲目追求"线程数量"，从而真正写出高性能并发程序。