> **摘要**: 构建慢这件事最磨人——它不报错、不阻塞提交，就是让每个人每天干等半小时。去年我们团队 20 个人被 30 分钟的单次构建拖了半年，靠一份构建耗时报告定位到真正瓶颈，从 JVM 参数、并行构建、依赖治理到模块拆分逐项治理，最后压到 3 分钟。这篇文章把整个调优过程复盘出来：怎么测量、怎么定位、每一项优化值多少分钟、哪些参数是讹传的坑，附诊断脚本和检查清单。

**适用版本**: Maven 3.9 / JDK 17 / Jenkins 2.4xx LTS（文中优化手段同样适用于 Gradle 项目，思路相通）

## 一、构建慢是什么体验，先讲三件真事

### 1. 刷 30 分钟手机的日子

我们单体项目全量构建要 30 分钟，20 个开发每人每天至少等 5 次。算下来团队每天有 50 个工时耗在"看进度条"上。最讽刺的是等待里真正在编译的时间不到三分之一——剩下全在下载依赖、跑无用插件、串行编译互相干等。所有人都抱怨，但没人说得清慢在哪，只好一直忍着。

### 2. 构建到一半，OutOfMemoryError

内存报错最迷惑人。第一次遇到 `Java heap space`，我的第一反应是加 `-Xmx`——加到 8g 还崩。翻日志才发现是 `Metaspace` 不足：项目接了一堆注解处理器，加载的类数量爆炸，堆再大也救不了元空间。方向错了，参数调得再狠也是白费。

### 3. 紧急发布排在 15 个任务后面

线上出问题要紧急发版，打开 Jenkins 一看构建队列 15 个任务，前面还有 3 小时的工作量。那一刻才明白：单次构建 30 分钟不是个人体验问题，是整个团队的交付风险——队列长度 × 单次耗时，就是你离"能救火"的距离。

这三件事凑齐，我们停了两天的需求，专门做了一次构建性能治理。结果比预期好得多。

## 二、先算账：性能治理值多少人力

按 20 人团队、每人每天构建 5 次、人力成本 500 元/小时计：

| 指标 | 优化前 | 优化后 | 改善 |
|------------|-------------|-------------|------------|
| **单次构建耗时** | 30 分钟 | 3 分钟 | 下降 90% |
| **每人每天等待** | 150 分钟 | 15 分钟 | 节省 2.25 小时/人 |
| **团队每日总耗时** | 50 小时 | 5 小时 | 节省 45 小时 |
| **人力成本** | 25,000 元/天 | 2,500 元/天 | 节省 22,500 元/天 |
| **月度节省** | - | - | 约 45 万元 |

这是工作时间的账。还有一笔 CI 资源的账：单次构建从 30 分钟压到 3 分钟后，构建节点从 5 台减到 2 台（并行能力上去了，排队自然短了），按每台 2.5 万元/年算，一年省 7.5 万元。

数字摆在这里不是为了震撼，而是为了立项——性能治理最难的从来不是技术，是让团队愿意停下来两天做这件事。账算清楚，这个决定就容易做了。

## 三、调优路线全景

整个治理按四步走，顺序很重要：先测量，再动 JVM，然后治依赖，最后动架构——跳过测量直接调参数，是构建调优里最常见的弯路：

![012-maven-performance-monitoring-optimization-tencent 图 1](https://developer.qcloudimg.com/http-save/yehe-2059497/0fa618a33e7bb56fff56505b4579f087.png)

## 四、第一步：测量，别猜

调优最容易犯的错误是上来就改参数。我们先花了半天时间搞清楚"30 分钟到底花在哪"，结果出乎意料——编译本身只占 8 分钟，剩下 22 分钟在依赖下载和无效插件上。不测量，优化方向就是蒙的。

### 4.1 让 Maven 自己报耗时

Maven 3.9 起自带逐插件耗时统计，开启 `-Dmaven.build.debug` 级别的日志太重，更实用的是直接跑一次全量构建并留档：

```bash
# 全量构建并保留完整日志
mvn clean package -T 4C 2>&1 | tee build.log

# 统计各模块构建耗时（Building 行之间即一个模块的区间）
grep -E "Building |BUILD SUCCESS|Total time" build.log
```

### 4.2 一份诊断脚本，五分钟摸清家底

下面这个脚本是我们第一天就写好的，每次调优前后各跑一遍，数据说话：

```bash
#!/bin/bash
# maven-performance-diagnostic.sh —— 构建环境五项体检

echo "== Maven 构建环境诊断 =="

echo "[1] Java 版本："
java -version 2>&1 | head -1

echo "[2] Maven 版本与 JDK："
mvn -version 2>&1 | head -3

echo "[3] MAVEN_OPTS："
if [ -n "$MAVEN_OPTS" ]; then echo "$MAVEN_OPTS"; else echo "未配置（使用 JVM 默认值）"; fi

echo "[4] 本地仓库体积："
du -sh ~/.m2/repository 2>/dev/null || echo "未找到"

echo "[5] 无效缓存文件（.lastUpdated）数量："
find ~/.m2/repository -name "*.lastUpdated" 2>/dev/null | wc -l

echo ""
echo "提示：.lastUpdated 超过 1000 条说明仓库里积累了大量失败下载的残渣，"
echo "执行 find ~/.m2/repository -name '*.lastUpdated' -delete 清理后重试。"
```

**坑一：构建"突然变慢"，八成是仓库残渣**。有一次构建从 8 分钟涨回 25 分钟，排查网络、CPU 都正常，最后发现 `.lastUpdated` 文件积累了两万多条——Maven 每次解析依赖都要扫过这些失败记录。清理后立刻恢复。构建变慢先看仓库状态，再看别的。

### 4.3 测量结论决定优化顺序

我们测出来的耗时分布（你的项目一定不同，所以这一步必须自己做）：

| 耗时项 | 占比 | 对应优化手段 |
|--------|------|-------------|
| 依赖下载（未配镜像） | 40% | 配置镜像源 + 预下载 |
| 串行编译 | 27% | `-T` 并行构建 + 模块拆分 |
| 无用插件执行 | 18% | 裁剪插件 + skip 参数 |
| 真实编译 | 8% | JVM/GC 调优 |
| 测试与打包 | 7% | 测试分层 |

测量阶段的诊断路径——从现象出发，四类瓶颈各有各的确认手段，别跳步：

![012-maven-performance-monitoring-optimization-tencent 图 2](https://developer.qcloudimg.com/http-save/yehe-2059497/87f0a9ba189e02974b2f5819365a7270.png)

## 五、第二步：JVM 调优——先分清堆和元空间

### 5.1 按机器内存选配置

`MAVEN_OPTS` 是构建进程的 JVM 参数，默认值（堆 1/4 物理内存，元空间无上限但初始很小）对大项目不合适。我们的选型表：

```bash
# 8GB 内存开发机
export MAVEN_OPTS="-Xmx2g -Xms1g -XX:MaxMetaspaceSize=512m -XX:+UseG1GC"

# 16GB 内存（我们团队的标准配置）
export MAVEN_OPTS="-Xmx4g -Xms2g -XX:MaxMetaspaceSize=1g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

# 32GB 以上 / CI 构建节点
export MAVEN_OPTS="-Xmx8g -Xms4g -XX:MaxMetaspaceSize=2g -XX:+UseG1GC"
```

三个参数的含义值得说透：`-Xms` 设成和使用量接近是让 JVM 免去反复扩堆的开销；`-XX:MaxMetaspaceSize` 管的是类元数据——注解处理器、Lombok 这类工具会疯狂生成类，元空间不足报的就是 `Metaspace` OOM；`-XX:MaxGCPauseMillis=200` 给 G1 定暂停目标，构建是吞吐型任务，不必追极端低延迟。

**坑二：报 `Java heap space` 就无脑加 `-Xmx`，可能调错方向**。判别方法看报错全文：`Java heap space` 才是堆不够；`OutOfMemoryError: Metaspace` 是类元数据爆了，加 `-XX:MaxMetaspaceSize` 才有效，加 `-Xmx` 毫无用处。我们第一次就栽在这——堆加到 8g 还崩，白折腾一下午。

**坑三：网上流传的 `-XX:+AggressiveOpts` 和 `-XX:+UseFastAccessorMethods` 不要抄**。这两个参数一个已在 JDK 11+ 移除，一个是废弃的内部优化，抄进配置轻则打警告，重则新版本 JDK 直接启动失败。参数先在本地 `java -version` 对应版本上验证过再进团队配置。

### 5.2 CI 节点的额外考量

Jenkins 构建节点上，MAVEN_OPTS 要和节点总内存一起规划：一台 8 核 16G 的节点同时跑 2 个构建，每个构建 `-Xmx4g` 就会逼近上限，遇到 GC 高峰直接被 OOM killer 杀掉。CI 上的原则是"单构建内存 × 并发构建数 < 节点内存 × 0.8"，剩下的留给操作系统和文件缓存。

## 六、第三步：依赖治理——下载量减一半的最短路径

测量结果显示依赖下载占 40%，这一项的治理回报最直接：一是让下载走对路，二是让需要下载的东西变少。

### 6.1 镜像源：一行配置，40% 里的最大头

团队成员各自直连海外中央仓库，是下载慢的主因。统一走国内镜像源（腾讯云软件源或公司自建 Nexus），配合 CI 节点上的预下载：

```xml

<mirrors>
  <mirror>
    <id>tencent-cloud</id>
    <mirrorOf>central</mirrorOf>
    <name>Tencent Cloud Maven Mirror</name>
    <url>https://mirrors.cloud.tencent.com/nexus/repository/maven-public/</url>
  </mirror>
</mirrors>
```

```bash
# CI 节点构建前预拉全部依赖，构建期内不再发起网络请求
mvn dependency:go-offline
```

这一项单独贡献了约 6 分钟的降幅，是整次治理里"性价比之王"——配置量一行，收益最大。

### 6.2 依赖树体检：重复与冲突

```bash
# 看依赖树（verbose 模式标出被仲裁掉的版本）
mvn dependency:tree -Dverbose

# 找出同一构件出现多个版本的冲突
mvn dependency:tree | grep -E "^[+| \\\\]-" | sort | uniq -d
```

治理动作有两类。一是把版本仲裁收拢到父 POM 的 `dependencyManagement`，全工程只认一处声明的版本：

```xml
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>32.1.3-jre</version>
    </dependency>
  </dependencies>
</dependencyManagement>
```

二是把 starter 里用不到的传递依赖显式排除，我们用 Undertow 替换 Tomcat 时顺手做了这步：

```xml
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
  <exclusions>
    <exclusion>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-tomcat</artifactId>
    </exclusion>
  </exclusions>
</dependency>
```

**坑四：依赖冲突引发 ClassNotFoundException，根因多在"版本就近仲裁"**。Maven 对重复依赖默认取路径最浅、声明最靠前的版本——A 依赖 guava 20、B 依赖 guava 32，谁在前用谁，另一个版本被静默丢弃，缺类错误在运行期才爆。

解法不是撞大运调声明顺序，而是用 `dependencyManagement` 统一仲裁（上一段）。Enforcer 插件的 `banDuplicatePomDependencyVersions` 规则可以把它变成构建期报错，推荐常驻。

### 6.3 体积治理的边际收益要算清

JAR 体积优化（`jdeps` 分析、排除无用依赖、大资源外置 CDN）对构建本身收益有限，主要收益在部署链路——镜像更小、传输更快。别指望靠瘦包把构建从 30 分钟省出 10 分钟，它省的是别的环节。

## 七、第四步：架构优化——从 30 分钟到 3 分钟的主战场

### 7.1 多模块拆分

单体 50 万行代码编译 30 分钟，拆成 5 个模块后单模块最大 4 分钟，且模块之间可以并行。我们的拆分结果：

```text
优化前（单体）:
my-monolith/                  编译 30 分钟

优化后（多模块）:
my-platform/
├── platform-common/          编译 2 分钟（被依赖，最先构建）
├── platform-core/            编译 3 分钟
├── user-service/             编译 4 分钟
├── order-service/            编译 4 分钟
└── product-service/          编译 4 分钟
```

**坑五：拆模块最容易踩循环依赖**。拆到一半 Reactor 报 `cyclic reference`——user-service 引 order-service，order-service 又反过来引 user-service。

解法是把两边共享的接口和 DTO 下沉到 `common-api` 模块，让依赖变成单向扇出，`mvn validate -X | grep cyclic` 可以提前定位循环。拆分的正确顺序是先拆最底层的公共代码，再往上拆业务模块，反过来做必然撞循环。

### 7.2 并行构建与增量编译

```bash
# -T 4C：按 CPU 核数开 4 线程并行构建（Reactor 会按依赖关系调度）
mvn clean package -T 4C
```

```xml

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.11.0</version>
  <configuration>
    <useIncrementalCompilation>true</useIncrementalCompilation>
  </configuration>
</plugin>
```

**坑六：`-T` 线程数不是越大越好**。我们试过 `-T 1C` 全开，8 核机器上构建反而从 8 分钟涨到 11 分钟——线程间内存争抢和模块输出交错日志的 IO 冲突吃掉了并行收益。实测 `-T 4C`（半数核）在我们项目上最优。另一个隐藏代价：并行构建下模块日志是交错的，排查单模块问题时要配合 `-pl module-a -am` 单模块构建复现。

### 7.3 CI 上的组合拳

Jenkins 流水线里，模块级并行构建进一步压缩耗时：

```groovy
stage('Parallel Build') {
    parallel {
        stage('Build user-service') {
            steps { sh 'mvn clean install -pl user-service -am -T 2C' }
        }
        stage('Build order-service') {
            steps { sh 'mvn clean install -pl order-service -am -T 2C' }
        }
    }
}
```

**坑七：并行 stage 抢同一个本地仓库会互相污染**。两个并行 stage 在同一节点上跑 `mvn install`，写同一个 `~/.m2/repository`，偶发构件损坏且极难排查。

解法两条路：要么每个 stage 用独立 workspace（各配 `-Dmaven.repo.local` 指向不同目录）；要么放弃 stage 级并行、只用 `-T` 的 Reactor 级并行——后者才是 Maven 官方支持且安全的方式，我们的最终选择。

## 八、优化效果：每一分钟都有出处

治理全程的数据（基线：单体项目、默认 JVM、直连中央仓库）：

| 优化项 | 优化前 | 优化后 | 降幅 | 依赖的前置条件 |
|--------------|--------|--------|--------|--------------|
| 配置镜像源 + 预下载 | 30 分钟 | 24 分钟 | 20% | 无 |
| JVM 参数调整 | 24 分钟 | 21 分钟 | 12% | 镜像已配 |
| 裁剪无用插件 | 21 分钟 | 17 分钟 | 19% | 测量定位 |
| 并行构建 -T 4C | 17 分钟 | 9 分钟 | 47% | 模块已拆分 |
| 多模块拆分 + 增量编译 | 17 分钟 | 5 分钟 | 71% | 架构改造 |
| CI 模块级并行 | 5 分钟 | 3 分钟 | 40% | 本地仓库隔离 |

两句话概括：前 9 分钟靠"别浪费"（镜像、参数、裁剪），后 18 分钟靠"改结构"（拆模块、并行化）。没有一步是玄学，每步都有测量数据兜底——如果你的耗时分布和我们的不一样，这个执行顺序就该不一样，照抄清单不如照抄方法。

![012-maven-performance-monitoring-optimization-tencent 图 3](https://developer.qcloudimg.com/http-save/yehe-2059497/3d1590ee348992da0e7e65379091c836.png)

## 九、检查清单与日常守护

调优不是一次性的。构建耗时像房间灰尘，不扫就积。我们把检查项固化成清单，每季度过一遍：

```markdown
## Maven 构建性能检查清单

### 环境配置
- [ ] MAVEN_OPTS 已按机器内存配置（16GB 参考值见 5.1 节）
- [ ] GC 日志已开启（-Xlog:gc），异常暂停可追溯
- [ ] settings.xml 已配置国内镜像源

### 构建配置
- [ ] -T 并行线程数经过实测选型（不是照抄 4C）
- [ ] 增量编译已开启
- [ ] 无用插件已裁剪（对照耗时报告）

### 依赖治理
- [ ] .lastUpdated 文件数 < 1000（CI 上配自动清理）
- [ ] 版本仲裁统一在 dependencyManagement
- [ ] 依赖树无 unresolved 冲突

### 架构与 CI
- [ ] 模块间依赖单向扇出，无循环
- [ ] 并行 stage 的本地仓库已隔离（或仅用 -T 并行）
- [ ] 构建耗时趋势有监控（见下方说明）
```

**坑八：没有耗时趋势监控，退化是无声的**。我们调优完成两个月后构建悄悄涨回 12 分钟，没人察觉——因为每次只慢一点。后来在 Jenkins 上加了构建时长趋势图（Stage View 自带，配合简单脚本记录到表格），超过基线 50% 就告警。性能治理的最后一公里不是优化技巧，是让退化可见。

## 十、总结：方法比清单重要

复盘整次治理，最终交付的是三个数字：单次构建 30 分钟到 3 分钟（降 90%）、构建节点 5 台到 2 台、每年合计节省约 45 万元人力加 7.5 万元资源成本。

比数字更重要的是方法，四步循环：**先测量**（耗时分布决定优化顺序）→ **消除浪费**（镜像、参数、裁剪，拿回前 9 分钟）→ **改造结构**（模块化与并行，拿回后 18 分钟）→ **持续守护**（趋势监控让退化可见）。

两个最容易踩的坑再强调一遍：报 OOM 先看是 heap 还是 Metaspace，方向错了全白费；`-T` 线程数要实测，不是核数拉满就最快。

> 如果本文对你有帮助，欢迎点赞、收藏、转发。有问题或建议，欢迎评论区交流。行文仓促，定有不足之处，欢迎各位朋友批评指正。


**推荐资源**

- [腾讯云软件源](https://mirrors.cloud.tencent.com/)：Maven 镜像加速，本文 6.1 节的镜像配置直接可用
- [腾讯云 CODING DevOps](https://cloud.tencent.com/product/coding-ci)：云端构建趋势可视化，可作为自建监控的托管替代


**专栏导航**

- 上一篇：[Maven 与 Jenkins CI/CD 集成实战](https://cloud.tencent.com/developer/article/2756336)
- 下一篇：Maven 安全漏洞扫描集成

摘要: 构建慢这件事最磨人——它不报错、不阻塞提交，就是让每个人每天干等半小时。去年我们团队 20 个人被 30 分钟的单次构建拖了半年，靠一份构建耗时报告定位到真正瓶颈，从 JVM 参数、并行构建、依赖治理到模块拆分逐项治理，最后压到 3 分钟。这篇文章把整个调优过程复盘出来：怎么测量、怎么定位、每一项优化值多少分钟、哪些参数是讹传的坑，附诊断脚本和检查清单。

Maven 构建性能监控与调优：30 分钟构建压到 3 分钟的完整过程

构建慢这件事最磨人——它不报错、不阻塞提交，就是让每个人每天干等半小时。去年我们团队 20 个人被 30 分钟的单次构建拖了半年，靠一份构建耗时报告定位到真正瓶颈，从 JVM 参数、并行构建、依赖治理到模块拆分逐项治理，最后压到 3 分钟。这篇文章把整个调优过程复盘出来：怎么测量、怎么定位、每一项优化值多少分钟、哪些参数是讹传的坑，附诊断脚本和检查清单。

开发工具

构建耗时从30分钟优化到3分钟的真实复盘，涵盖测量定位、JVM参数避坑、镜像加速、并行构建与模块拆分全流程，附诊断脚本与检查清单，适用Maven3.9/JDK17，Gradle思路相通。

漏洞扫描

代码解释

Java

CDN免费试用


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Maven 构建性能监控与调优：30 分钟构建压到 3 分钟的完整过程-腾讯云开发者社区-腾讯云

Maven 构建性能监控与调优：30 分钟构建压到 3 分钟的完整过程

Maven 构建性能监控与调优：30 分钟构建压到 3 分钟的完整过程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐