首先直接给结论：没错，你碰到的就是MNG-2802这个从2007年至今都没彻底解决的并发写入bug。这个问题的根源很简单：当多个Maven进程（比如Jenkins上并行的构建任务）同时去更新本地仓库里的maven-metadata-local.xml时，Maven并没有做足够的同步控制，导致多个写入操作互相干扰，就会出现你看到的标签重复、内容乱码这类脏数据——你给出的末尾重复</versioning> </metadata>就是典型的并发冲突产物。

下面是几个实用的缓解方案，按优先级排序：

1. 临时应急：手动修复损坏文件 #

最直接的办法就是删掉损坏的maven-metadata-local.xml，下次Maven构建时会自动重新生成一份正确的元数据文件。如果担心误删，可以先把文件备份到其他目录再操作。

2. 减少并发冲突的核心手段 #

• 给Jenkins构建加互斥锁：如果你的Jenkins上有多个任务会操作同一个本地仓库目录，用Lockable Resources插件给该目录加个锁，确保同一时间只有一个任务能读写这个目录的元数据文件，从根源避免并发写入。
• 隔离每个构建的本地仓库：给每个Jenkins构建任务指定独立的本地仓库（在Maven命令里加-Dmaven.repo.local=/path/to/unique-repo-for-job），这样不同任务的元数据文件完全分开，不会互相干扰。这个方案对多任务并行构建的场景特别友好。

3. 调整Maven配置降低写入频率 #

• 修改快照依赖的更新策略：如果你的项目依赖了大量快照包，默认的always更新频率会频繁触发元数据文件写入。可以在settings.xml里把快照仓库的updatePolicy改成daily或者interval:60（每60分钟更新一次），减少写入次数：

  <repositories>
    <repository>
      <id>central-snapshots</id>
      <url>https://repo.maven.apache.org/maven2</url>
      <snapshots>
        <updatePolicy>daily</updatePolicy>
      </snapshots>
    </repository>
  </repositories>
  

• 尝试启用元数据更新的新逻辑：部分Maven版本支持-Dmaven.metadata.legacy=false参数，这个参数会改变元数据的更新方式，可能降低冲突概率，但注意不是所有版本都兼容，建议先在测试环境验证后再用到生产环境。

4. 长期根治：引入仓库管理工具 #

如果你的Jenkins集群并发构建量很大，搭建一个内部Maven仓库（比如Nexus、Artifactory）是一劳永逸的方案。所有构建任务从内部仓库拉取依赖，内部仓库会负责和公共仓库同步元数据，本地仓库只需要从内部仓库拉取，大大减少本地元数据的写入操作，自然就不会出现并发冲突问题，还能提升构建速度、节省带宽。

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