5.2 慢构建病理分析：18 分钟到 4 分钟

5.2 慢构建病理分析：18 分钟到 4 分钟

本节摘要：构建耗时的优化顺序是先测量后动手，热点通常分布在依赖解析、测试执行与插件执行三段。提速手段按性价比排序：依赖缓存与预热、并行构建 -T、选择性构建、测试分层与守护进程。本节复盘 risk-engine 从 18 分钟到 4 分钟的完整优化战役。

一、先测量，再动手

流水线上的构建耗时悄悄爬到了 18 分钟，两个直接后果：合并请求的反馈半径严重超标（5.1 节的两分钟红线），团队开始绕过流水线手工打包——后者是质量防线的崩塌前兆。优化战役第一步不是改配置，是测量：

# 手段一：看总耗时分布（构建日志自带各阶段时间戳）
mvn clean install -DskipTests
# 输出：编译与打包段总耗时 3.4 分钟

mvn clean install -DskipTests=false
# 输出：总耗时 18 分钟 测试段净占 14 分钟
# 初步病理：不是编译慢 是测试慢

# 手段二：细看测试耗时分布（surefire 报告逐类统计）
# target 目录下的测试报告按类列出耗时
# 前五名：三个集成测试类共 11 分钟 两个慢单测共 2 分钟

# 手段三：开构建时间线分析（社区扩展输出各插件耗时）
# 发现依赖解析段 1.1 分钟 其中远程快照检查占 0.7 分钟
​

测量结论改变行动方向：如果先入为主去搞编译加速，14 分钟的测试大头纹丝不动。病理报告：集成测试串行执行 11 分钟、快照远程检查 0.7 分钟、编译与打包 3.4 分钟，其余是杂项。

二、按性价比排序的四个处方

处方一：测试分层（收益 11 分钟，最大头）。 三个集成测试类为什么串行 11 分钟？它们起真实数据库、互相抢端口，被强行标成串行执行。分层处置：单元测试留在快速段，集成测试挪到独立阶段并配测试容器（数据库用容器化实例，端口隔离后可并行）；两个慢单测本身是"伪装成单测的集成测试"，或修或移。

处方二：快照检查瘦身（收益 0.7 分钟）。 日常流水线每次构建都检查快照更新是浪费——依赖的变更由上游流水线统一拉取。日常构建加 -o 离线标志（依赖已由缓存任务备齐），夜间任务做一次带 -U 的全量刷新。这与第 3.6 节"随机漂移"的处置一脉相承：快照检查既慢又是漂移源。

处方三：并行构建（收益约 2 分钟）。 risk-engine 四模块依赖呈菱形，common 先行后 dao 与 rule 互不依赖可并行：

mvn clean install -T 1C
# -T 1C：每个 CPU 核一个线程 按依赖图调度无依赖冲突的模块并行
# 输出关键行：Using the MultiThreadedBuilder with 4 threads
​

并行的前提是插件线程安全：官方核心插件基本达标，自研与老旧第三方插件要逐个确认（@Mojo 注解的 threadSafe 标志，第 2.2 节写过）。此外测试并行还要处理共享资源（端口、临时目录、测试数据），否则偶现的互相踩踏比串行更伤。

处方四：选择性构建（CI 场景收益约 1 到 3 分钟）。 第 4.1 节的 -pl 加 -am 剪刀在流水线上的应用：变更只涉及 rule 模块时，快速段只构建 common 加 rule。

四个处方实施后的耗时清单：依赖恢复 0.5 分钟、编译与打包 1.5 分钟（并行后压缩）、单元测试 1.2 分钟、集成测试阶段 1 分钟（容器化并行后）——总耗时 4.2 分钟，反馈半径回到红线内。没动一行业务代码，全部是构建工程手段。

优化战役的完整决策顺序值得沉淀成表，任何团队拿来即用：

表里藏着本节的核心主张：排序靠前的是结构与制度，排序靠后的是资源堆叠。团队做反这个顺序的例子屡见不鲜——先加机器、再上守护进程，最后才发现 14 分钟的测试串行才是大头，前面两笔投入全部打水漂。

战役还有一个容易被忽略的收尾动作：把优化后的耗时基线写进流水线配置作为告警阈值（总耗时超过六分钟标黄、超过八分钟标红）。没有这条线，耗时会在未来半年里无声无息地爬回去——每个合并请求加两个测试、每个季度引入一批新依赖，每次只多几秒，谁也不值得为几秒开会。有了基线告警，爬升会在四分钟挡被看见，处置成本还停留在"挪两个测试"的量级。这与第 3.6 节的作战记录制度是同一个思想：可观测先于可优化，看不见的指标管理不了。

三、两个进阶选项与一个反面教材

进阶选项一：守护进程方案。常驻的构建进程免去每次 JVM 冷启动与插件加载，交互式本地构建提速明显；CI 上收益有限（每次都是全新容器）。团队本地开发采用后，增量构建的反馈进入秒级。

进阶选项二：测试选择策略。按变更影响面只跑受影响的测试（模块级用 -pl 剪刀，类级靠平台能力），配合全量夜间兜底。前提是测试本身分层清晰，否则"选择性漏测"的账迟早要还。

反面教材必须记录：战役初期有人提议"加钱上更强 CI 机器"，被否决的理由不是预算，是方向——硬件扩容治标不治病理，串行的 11 分钟测试在 32 核机器上还是 11 分钟（瓶颈在资源等待不在算力），而四个工程处方把它压到 1 分钟。先测量、先改结构，扩容永远是最后一档。

⚠️ 常见坑：把 -DskipTests 写进日常流水线命令来"提速"。跳过测试的持续集成只是自动打包机，质量防线形同虚设。提速的正道是分层与并行，不是把验证内容砍掉。

💡 关键直觉：构建耗时是条会自己生长的曲线——新测试、新模块、新插件都在给它加秒数。把耗时当作流水线的观测指标（每次构建记录、超阈值告警），才能在它爬回两位数之前介入。

本节要点回顾

• 先测量后动手：耗时分布（编译、测试、依赖解析、插件）决定处方方向，凭感觉优化是大忌；
• 测试分层是最大头：单测归快速段、集成测试容器化并行、伪装成单测的集成测试或修或移；
• 快照检查要瘦身：日常构建离线走缓存，夜间任务统一刷新，兼治慢与漂移；
• 并行三前提：模块依赖图支持、插件线程安全、测试无共享资源冲突；
• 硬件扩容是最后一档：治标不治病理，工程处方优先。

耗时问题进入稳态后，流水线又在满负荷时段抛出了新故障：内存溢出。下一节进入内存战场——fork、堆、元空间的三角关系与三类 OOM 的归属判定。