核心问题在于Jenkins资源供给与任务需求失衡，需同步优化调度可见性、资源弹性和任务轻量化：清队列前须识别高优任务并精准取消低优项；按业务打标匹配agent，限流与超时策略下沉至流水线；K8s agent需调优参数并隔离生产资源；构建阶段应预热依赖、禁用后台进程、清理冗余Git分支。
核心业务发布流因 Jenkins 队列阻塞而长时挂起，本质是资源供给与任务需求严重失衡。不能只清队列或重启服务，需从“调度可见性、资源弹性、任务轻量化”三个刚性环节同步切入。
快速释放积压队列，避免雪崩扩散
紧急情况下可清空队列，但必须前置判断：
- 执行 Jenkins.instance.queue.clear() 前，先在脚本控制台运行 Jenkins.instance.queue.items.collect{[it.task.name, it.getInQueueSince()]} 查看排队任务名与等待时长，识别是否含正在构建的 PR 或生产发布任务
- 若存在高优发布任务（如 release/* 或带 deploy-prod 标签的任务），应单独跳过清理，改用 Jenkins.instance.queue.cancel(item) 精准取消低优测试任务
- 清队列后立即检查代理节点状态：是否存在大量 offline 或 disconnected 节点？这类节点常因网络抖动或 Docker daemon 异常导致假在线，需手动重连或自动巡检脚本干预
精准匹配 agent 资源与流水线需求
多数排队并非因为“没资源”，而是“资源不匹配”。关键在标签（label）和限制策略对齐：
- 为不同业务类型定义专属 agent 标签：例如 java-build、node-e2e、prod-deploy，并在流水线中显式声明 agent { label 'prod-deploy' }，避免所有任务挤在默认 built-in 节点上
- 禁用全局“Throttle Concurrent Builds”插件的粗粒度限制，改为在每条关键流水线内使用 options { throttle(['prod-pipeline'], throttleEnabled: true) }，按业务域限流而非全站一刀切
- 对长时任务（如 E2E 测试）强制设置超时：timeout(time: 30, unit: 'MINUTES') { ... }，防止单个慢任务锁死整个部署通道
提升 agent 弹性响应能力
静态节点无法应对突发流量，必须让资源“随需而生”：
- 若使用 Kubernetes 插件，确认 maxRequestsPerHost ≥ 5，idleMinutes ≤ 3，避免 Pod 创建延迟或空闲过久被误删
- 为生产发布类流水线配置专用 nodeSelector 和 tolerations，确保其能调度到高可用、高 IO 的物理节点或 GPU 节点，不与 CI 构建混抢资源
- 在 Jenkins 主节点 JVM 启动参数中增加 -XX:+UseG1GC -XX:MaxGCPauseMillis=200，缓解 Full GC 导致的 STW 卡顿——这是高并发下主节点自身成为瓶颈的隐性原因
剥离非核心步骤，缩短单次构建耗时
队列本质是“等待时间总和”，压缩单个构建耗时比单纯加机器更有效：
- 将镜像拉取、依赖下载等 I/O 密集操作移到 beforeAgent true 块中预热，或使用 Nexus 代理 + 本地缓存层加速
- 禁止在构建过程中启动后台守护进程（如本地 mock server），这类进程易继承 Jenkins 管道文件描述符，导致构建卡在“Waiting for process to finish…”；确需启动，用 nohup command &>/dev/null & 并显式关闭 stdout/stderr
- 对 Git 拉取慢问题，优先清理远端冗余分支（尤其 feature/ 开头的已合并分支），比重启 Git 服务更能治本
