要控制 parallel 分支的最大并发数，先绕不开一个问题：parallel 步骤本身没有并发数参数，能传的只有分支定义和 failFast。所以实际配置通常是借助 lock 插件做步骤级控制。这里先不说多少并发合适，第一步是判断当前构建是否需要被限制并发。

先判断：什么时候才需要限制 parallel 并发

当parallel中的分支任务涉及共享资源（如数据库连接、第三方API、同一台构建机的特定工具）时，并发数过高可能引发超时、限流或内存溢出。一个实用的判断标准是：连续运行同一构建时，如果偶发失败且错误信息包含资源不可用、连接被拒或超时，大概率是并发过多。另一种情况是并行分支数量超过节点上的执行器总数，导致任务排队，反而降低整体吞吐。此时可以通过限制parallel的并发数来保护下游系统，同时避免无意义的排队等待。如果所有分支都是纯计算且不带I/O，通常不需要额外限制，默认并发即可。

这个判断标准需要结合自己的构建频率和资源监控来看。如果连续跑十次只失败一两次，且失败集中在同一类资源报错，就可以开始考虑限制。如果只是偶发抖动，先不做改动，保留原始日志做基线。

用 lock 插件做精确控制

在Jenkins Pipeline中，parallel步骤本身没有并发数参数，想要限制并行分支的数量，通常要借助lock插件。在声明式或脚本式流水线中，将parallel调用包裹在lock块里，例如lock(resource: 'my-resource', quantity: 2) { parallel branchA: {...}, branchB: {...} }。quantity表示允许同时获取锁的最大数量，超过后其他分支会等待，直到有锁释放。需要注意，lock的resource名称要全局唯一，否则可能导致不同流水线互相干扰。可以在共享库中封装一个带并发控制逻辑的公共步骤，避免各处重复写锁。使用lock前先安装Lockable Resources插件，并确认Jenkins版本兼容。

这里补充一个操作前提：lock 里的 resource 名称需要提前在 Jenkins 的 Lockable Resources Manager 里定义好，并分配好资源数量。如果直接写一个不存在的名称，插件会尝试自动创建，但不同版本行为不一样，可能构建直接失败。建议在全局配置里把资源维护成一个清单，例如“shared-db-conn”数量为 2，然后在流水线里引用这个名字。

lock 块会把整个 parallel 的入口锁住，也就是说，只有获取到锁的构建才会进入并行分支，没获取到的会在 lock 处阻塞等待。这个等待时间如果没有上限，可能会一直卡到任务超时。所以生产流水线里建议给 lock 加 time 和 unit 参数，例如 time: 5, unit: 'MINUTES'。

常见误区：parallel 后面不能加数字

有用户会尝试 parallel(2) { ... } 这种写法，想直接指定并发数。这个写法在 Groovy 语法里是无效的，因为 parallel 是一个步骤，不是可重载的方法。声明式流水线里，parallel 是阶段级的指令，只能接受包含分支定义的 map；脚本式流水线里，parallel 的参数可以是 map 加可选 failFast。没有位置用来写数字。如果确实想限制并发，要么用 lock/throttle 插件在步骤级别控制，要么把每个并行分支分配到固定执行器数的节点上，用节点执行器数量做间接限制。后者需要额外维护多个节点，成本高，通常不推荐。

使用 lock 时的常见坑

使用lock限制parallel并发时，最容易踩的坑是忘记释放锁。lock插件在块结束时会自动释放，但如果分支内部有异常被捕获且没有抛出，流程可能不进入lock块的完成逻辑，导致锁一直被占用。因此，建议在所有异常路径上都重新抛出或使用finally结构。另外一个常见问题是quantity设置大于实际资源数，比如资源只有2个，却设置quantity为3，那样锁实际上会超发。建议先准确统计可用资源数目，再设置quantity。验证方法是在构建日志中搜索lock相关的acquire/release记录，或者打开Lockable Resources管理页面观察锁定状态。

这里还需要注意锁的粒度。如果 parallel 的一个分支运行时间长，而其他分支很快结束，整个 lock 块的持有时间由最长分支决定，并发槽位可能被浪费。一个典型场景是：分支 A 跑 5 分钟，分支 B 跑 1 分钟，quantity 为 2，那么第 5 分钟时只有 A 在运行，第二个槽位空置。这种情况可以考虑缩小锁的粒度，让每个分支内部分别 lock 不同的资源，或者直接放弃对整个 parallel 加锁，只锁真正有资源共享的步骤。

验证是否生效，并保守调整

限制并发后的第一件事不是看构建是否变快，而是确认限制真的生效。简单做法是在每个并行分支开头输出当前 build 的唯一标识和时间，例如 sh 'echo "$BUILD_TAG start $(date +%T)"'，然后有意设置一段 sleep，观察控制台日志里同一时刻出现的分支数量。如果同一时间点有超过 quantity 个分支同时存在，需要检查 lock 的 resource 名称是否一致，quantity 是否被正确传入，以及 parallel 是否确实在 lock 块之内。也可以打开 Lockable Resources 管理页面，在构建运行期间查看资源是 locked 还是 free，记录一下实际占用的锁数量。

确认限制生效后，再根据系统表现调整。建议先按最保守的值设置，比如先设成 1，观察系统稳定后再逐步上调。如果并发数从 1 调到 2 后，构建耗时下降明显且没有资源报错，继续往上调；如果开始出现超时或排队，及时回退。注意把 quantity 参数化，比如通过 env 或参数传入，方便运维调整，不需要改流水线代码。还要给 lock 加上超时保护，例如 lock(resource: 'my-resource', quantity: 2, time: 5, unit: 'MINUTES')，避免等待死锁。最后，限制并发只是保护机制，不是性能提升方案。如果下游资源本身容量不足，降低并发只是让问题不那么刺眼，最终还是要评估是否扩容或改造。