为何Gitlab CI中执行make -j8没有并行效果，如何缩短构建时长？

• Gitlab Runner资源配额限制：默认Docker执行器会对运行任务的容器做CPU配额限制，无论是公共Runner还是多数自建Runner的默认单任务CPU配额都远低于普通家用PC的可用核心数。此时即使指定make -j8，实际可用核心数不足会导致并行逻辑无法生效，甚至会因为进程频繁切换产生额外开销，拉低编译速度。你可以在CI脚本中添加nproc命令打印当前环境可用核心数，直接确认资源配额是否被限制。
• Makefile依赖树错误：CMake生成的Makefile如果存在错误的依赖声明，会导致并行编译时大量任务阻塞等待前置依赖完成，极端情况会直接退化为串行执行。你可以在本地执行make -j8 all --dry-run查看任务执行顺序，确认并行逻辑是否符合预期，排除CMake配置错误问题。
• Docker IO瓶颈：Docker默认的overlay2存储驱动存在分层写入开销，如果Runner宿主机使用机械硬盘，C++编译过程中大量头文件展开、目标文件生成的IO操作耗时会远高于本地直接读写磁盘的速度，IO瓶颈会直接成为编译耗时的主要短板。
• 内置串行步骤未配置并行支持：部分CMake配置会隐式添加代码生成、静态检查等自定义序列化步骤，这类步骤如果没有声明并行支持，会占用绝大多数构建时间，后续编译步骤的并行逻辑再快也无法缩短整体耗时。你可以给make命令添加-d参数输出调试日志，定位耗时最高的具体步骤。
• make版本不兼容：部分轻量Docker镜像内置的是BSD make而非GNU make，-j参数的解析逻辑存在差异，可能导致并行配置完全不生效，可以在CI脚本中执行make --version确认版本是否和本地一致。

• 动态匹配并行核心数：不要硬编码-j8，改用make -j$(nproc) all自动匹配当前环境的可用核心数，避免指定的并行数远高于可用核心数产生的额外开销。
• 调整Runner资源配额：如果是自建Runner，在config.toml的Docker配置段添加cpus = "8"（按需调整为你需要的核心数），同时调高内存配额，避免编译过程中内存不足触发swap拖慢速度。
• 开启编译缓存：配置ccache或者sccache将编译产物缓存到Runner宿主机或者共享存储，增量构建时不需要重新编译未修改的源文件，通常可以将后续构建的耗时压缩到一分钟以内。
• 优化Docker存储配置：将Runner宿主机的存储介质更换为SSD，同时将构建目录挂载为Docker卷，绕过overlayFS的分层写入开销，大幅降低IO耗时。
• 拆分构建任务：将项目的静态库、动态库、可执行文件等拆分为独立的CI阶段，使用多个Runner并行构建不同组件，进一步缩短整体构建时长。

内容的提问来源于stack exchange，提问作者topkek