4. 并行构建配置：CMAKE_BUILD_PARALLEL_LEVEL、Ninja的并行机制、Make的-j参数调优

说到构建速度，并行编译绝对是性价比最高的优化手段。说白了，就是让CPU的每个核心都忙起来，别闲着。我见过太多项目，明明有16核的机器，构建时却只用一个核在那吭哧吭哧编译——这简直是暴殄天物。

这一章，我们就来聊聊CMake里怎么配置并行构建。我会把CMAKE_BUILD_PARALLEL_LEVEL、Ninja的并行机制、还有Make的-j参数，掰开揉碎了讲清楚。

4.1 并行构建的核心思路

先想一个问题：为什么并行构建能加速？

因为编译一个源文件，本质上是一个独立的任务。它不依赖其他源文件的结果（除非有头文件依赖）。所以，理论上你可以同时编译N个文件，N就是你的CPU核心数。

但这里有个坑——不是越多越好。我曾经在一个32核的服务器上，直接开了32个并行任务，结果编译速度反而比16个任务慢。为什么？因为磁盘I/O成了瓶颈。所有核心同时读头文件、写.o文件，硬盘直接扛不住了。

所以，并行度的设置，要综合考虑CPU核心数、内存大小、磁盘速度。嗯，这里要注意，别盲目追求大数字。

4.2 CMAKE_BUILD_PARALLEL_LEVEL：CMake的官方并行控制

从CMake 3.12开始，官方引入了CMAKE_BUILD_PARALLEL_LEVEL这个变量。它的作用很简单：告诉构建工具，最多用多少个并行任务。

我个人习惯在CMakePresets.json里设置它，这样团队所有人都用统一的配置。

// CMakePresets.json 示例
{
  "version": 3,
  "configurePresets": [
    {
      "name": "default",
      "displayName": "Default Config",
      "binaryDir": "${sourceDir}/build"
    }
  ],
  "buildPresets": [
    {
      "name": "release",
      "configurePreset": "default",
      "configuration": "Release",
      "jobs": 8
    }
  ]
}

你也可以在命令行里直接传参：

cmake --build build --parallel 8

或者设置环境变量：

export CMAKE_BUILD_PARALLEL_LEVEL=8
cmake --build build

这三种方式，优先级是：命令行参数 > 环境变量 > CMakePresets.json里的设置。我个人推荐用CMakePresets，因为它能跟项目配置一起版本管理，新人拉下来就能用。

4.3 Ninja的并行机制：天生就是为并行而生

Ninja这个构建工具，从设计之初就把并行作为第一优先级。它不像Make那样需要复杂的依赖解析，Ninja的构建文件（build.ninja）本身就是一张清晰的依赖图。

Ninja的并行机制，说白了就是「有多少资源，就干多少活」。它默认会使用所有可用的CPU核心。你不需要像Make那样手动指定-j参数，Ninja会自动检测。

但自动检测不一定是最优的。我在一个项目中遇到过，Ninja检测到了32核，直接开了32个任务，结果内存被吃光了，系统开始疯狂swap，编译速度反而下降。后来我手动限制到16个任务，速度直接翻倍。

限制Ninja并行度的方法：

cmake --build build --parallel 16

或者在CMakeLists.txt里设置：

set(CMAKE_JOB_POOLS "compile=16;link=4")
set(CMAKE_JOB_POOL_COMPILE compile)
set(CMAKE_JOB_POOL_LINK link)

这里我特别说一下CMAKE_JOB_POOLS。它允许你分别控制编译和链接的并行度。为什么链接要单独控制？因为链接是内存大户，尤其是链接大型静态库或可执行文件时，一个链接进程可能吃掉几个GB的内存。如果你同时开8个链接任务，内存直接爆炸。

我个人习惯：编译并行度设为核心数的1.5倍，链接并行度设为核心数的0.25倍。比如16核CPU，编译开24个任务，链接开4个任务。

4.4 Make的-j参数调优：老牌工具也有新玩法

Make的-j参数，大家应该都不陌生。但你真的用对了吗？

最基本的用法：

make -j8

这表示同时运行8个任务。但Make的并行机制有个问题——它不像Ninja那样有全局的依赖图。Make是递归调用的，每个子目录的Makefile独立运行。这就导致了一个现象：

假设你的项目有10个子目录，每个子目录里又有10个源文件。你执行make -j8，Make会同时进入8个子目录，每个子目录里再开8个任务。结果就是，实际并行任务数变成了8×8=64个！

我曾经在一个大型项目中踩过这个坑。项目有20多个子目录，我用了make -j16，结果系统直接卡死。后来一查，实际运行的编译任务数超过了300个。

解决方案有两个：

1. 使用非递归Make：把所有源文件放在一个Makefile里，避免递归调用。但这对于大型项目来说，维护成本太高。
2. 使用Ninja替代Make：这是最推荐的方案。Ninja没有递归问题，它的依赖图是全局的。

如果你坚持用Make，我建议这样调优：

# 限制递归深度
make -j8 --no-print-directory

# 或者使用-l参数限制负载
make -j8 -l 16.0

-l参数的意思是：当系统负载超过16.0时，不再启动新的任务。这能防止系统过载。

4.5 实战：不同场景下的并行度配置

我整理了一份配置参考表，你可以根据实际情况选择：

你想想看，如果CI服务器上同时跑多个构建任务，每个任务都占满所有核心，那其他任务就得排队等着。所以CI环境里，我一般会保守一点，只用到一半的核心。

4.6 避坑指南：并行构建的常见问题

最后，分享几个我踩过的坑：

• 内存不足导致OOM：我曾经在一个8GB内存的机器上，开了16个并行任务，结果编译到一半系统直接OOM（Out Of Memory）了。后来我加了CMAKE_JOB_POOLS限制链接并行度，问题解决。
• 磁盘I/O瓶颈：如果你用机械硬盘，并行度太高会导致大量随机读写，速度反而下降。SSD会好很多，但也要注意不要超过磁盘的IOPS上限。
• 头文件依赖冲突：并行编译时，多个任务可能同时修改同一个头文件的预编译头（PCH）。这会导致编译错误。解决方案是关闭PCH，或者使用Ninja的restat机制。
• 链接器冲突：某些老旧的链接器（如GNU ld）不支持并行链接。如果你遇到链接错误，试试把链接并行度设为1。

嗯，这一章的内容就到这里。并行构建配置，说白了就是找到那个「不多不少刚刚好」的点。多试试，多观察系统资源使用情况，你很快就能找到最适合自己项目的配置。