3、CPU性能调优：CPU上下文切换分析、CPU密集型任务优化、线程池调优策略

各位同学，咱们今天聊聊CPU调优。说实话，这是整个性能调优里最硬核的部分之一。我见过不少团队，业务代码写得挺溜，一到高并发就崩，查来查去，根子都在CPU这里。

CPU调优，说白了就三件事：别让CPU瞎忙活、别让CPU频繁换挡、别让线程打架。咱们一个一个说。

3.1 CPU上下文切换分析

先问个问题：你的CPU真的在干活吗？

很多时候，CPU看起来跑得飞起，实际上大部分时间都在做「上下文切换」。什么是上下文切换？就是CPU从一个任务切换到另一个任务时，要保存当前状态、加载新状态。这个过程本身不产生任何业务价值，纯粹是开销。

我在项目中遇到过最夸张的一次，一台8核服务器，CPU利用率才30%，但系统响应慢得像蜗牛。一查，每秒上下文切换次数高达20万次。说白了，CPU大部分时间都在「换衣服」，根本没空干活。

怎么分析上下文切换？

我习惯用 vmstat 和 pidstat 这两个工具。先看个例子：

# 每1秒输出一次，共输出5次
vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 123456  1234 56789    0    0    10    20  500 8000 12  8 80  0  0

注意看 cs 这一列，就是每秒上下文切换次数。8000次，对于8核机器来说，已经偏高了。如果超过1万，你就要警惕了。

⚠️ 我曾经踩过的坑： 有一次线上告警，我盯着CPU利用率看半天，发现才60%，觉得没问题。后来一个老同事提醒我看上下文切换，一看吓一跳——每秒3万次。原来是一个第三方库用了大量短连接，每次请求都创建销毁线程。从那以后，我养成了习惯：看CPU之前，先看上下文切换。

上下文切换的三种类型

类型 触发原因 典型场景
线程切换 时间片耗尽、线程阻塞 线程数过多、锁竞争激烈
中断处理 硬件中断、软中断 网卡中断过多、定时器密集
系统调用 用户态/内核态切换 频繁IO操作、锁操作

你想想看，如果线程数设置得特别大，比如一个8核机器开了200个线程，那CPU大部分时间都在做线程切换。我建议，活跃线程数不要超过CPU核心数的2倍，这是经验值。

3.2 CPU密集型任务优化

CPU密集型任务，说白了就是「算力活儿」。比如视频编码、图像处理、加密解密、科学计算。这类任务的特点：CPU一直100%跑着，但上下文切换很少。

优化这类任务，核心思路就一条：让CPU只干一件事，别打断它。

优化策略一：绑定CPU核心

我习惯用 taskset 把进程绑定到特定核心上。这样做的好处是：CPU缓存命中率更高，因为数据一直在同一个核心的L1/L2缓存里。

# 将进程绑定到CPU 0和1
taskset -c 0,1 ./my_cpu_intensive_app

嗯，这里要注意：绑定核心后，其他进程就不能用这两个核心了。所以一般建议留一个核心给操作系统用。

优化策略二：减少内存访问

CPU算得再快，也得等内存把数据送过来。我见过一个图像处理程序，每次循环都从内存读一个像素，处理完再写回去。改成一次读一行、用寄存器缓存中间结果后，性能提升了3倍。

💡 个人经验： 对于CPU密集型任务，尽量使用局部变量（栈上分配），避免频繁的堆内存分配。栈上分配几乎不花时间，堆分配涉及系统调用，开销大得多。

优化策略三：利用指令集

现代CPU都有SIMD指令集（如AVX、SSE），可以一次处理多个数据。我建议，如果做数值计算，尽量用现成的数学库（如Intel MKL、OpenBLAS），它们已经针对指令集做了优化。

// 普通写法
for (int i = 0; i < N; i++) {
    c[i] = a[i] + b[i];
}

// 使用SIMD（伪代码）
__m256 va = _mm256_load_ps(&a[i]);
__m256 vb = _mm256_load_ps(&b[i]);
__m256 vc = _mm256_add_ps(va, vb);
_mm256_store_ps(&c[i], vc);

你看，一次处理8个float，速度能快好几倍。不过，手写SIMD代码容易出错，我建议优先用库。

3.3 线程池调优策略

线程池，是Java后端最常用的并发工具。但调不好，反而会拖垮系统。

我记得有一次，一个同事把线程池核心线程数设成了200，最大线程数500。结果一上线，CPU直接飙到100%，系统响应时间从10ms变成了10秒。为什么？因为线程数太多，上下文切换把CPU耗光了。

核心参数怎么设？

参数 建议值 说明
corePoolSize CPU核心数 + 1 对于CPU密集型任务
corePoolSize CPU核心数 * 2 对于IO密集型任务
maxPoolSize corePoolSize * 2 留一些余量应对突发
workQueue 有界队列，大小100-1000 防止内存溢出

你想想看，如果任务主要是计算，线程数超过CPU核心数，反而会因为切换而变慢。如果是IO密集型（比如数据库查询、HTTP调用），线程可以多一些，因为线程在等待IO时不会占用CPU。

一个实用的线程池配置

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,          // corePoolSize: 4核CPU
    8,          // maxPoolSize: 留点余量
    60,         // keepAliveTime
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(500),  // 有界队列
    new ThreadPoolExecutor.CallerRunsPolicy()  // 拒绝策略
);
🔑 关键点： 一定要用有界队列！我见过太多因为无界队列导致内存溢出的案例。队列满了怎么办？用CallerRunsPolicy，让提交任务的线程自己执行，这样能自然形成背压。

监控线程池状态

我习惯在代码里加一个定时任务，每10秒打印一次线程池状态：

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
scheduler.scheduleAtFixedRate(() -> {
    log.info("线程池状态 - 活跃线程: {}, 队列大小: {}, 已完成任务: {}",
        executor.getActiveCount(),
        executor.getQueue().size(),
        executor.getCompletedTaskCount());
}, 0, 10, TimeUnit.SECONDS);

为什么要监控？因为配置是死的，流量是活的。如果发现队列一直堆积，说明线程数不够；如果活跃线程一直等于corePoolSize，说明任务处理速度跟得上。

⚠️ 我曾经踩过的坑： 有一次线上故障，线程池队列满了，但拒绝策略用的是AbortPolicy，直接抛异常。结果业务方没捕获，导致大量请求失败。后来我改成CallerRunsPolicy，虽然响应时间变长了，但至少不会丢请求。记住：宁可慢，不能丢。

小结

CPU调优，说到底就是三句话：

  • 减少上下文切换：线程数别太多，锁别太激烈
  • 让CPU专心干活：绑定核心、减少内存访问、用SIMD
  • 线程池要精细调：根据任务类型设参数，用有界队列，加监控

嗯，这些经验都是我在一次次线上故障中总结出来的。下次遇到CPU问题，别急着加机器，先看看上下文切换，再看看线程池配置。很多时候，调优就在这些细节里。

← 上一章 📖 返回目录 下一章 →