根本解决需从阻断、降级、监控三方面同步入手：立即用jstack定位并kill卡死子进程；代码层强制设置ProcessBuilder超时、独立有界线程池及调用熔断；长期替换为HttpClient或HTTP代理服务，并加强线程池指标与耗时监控。
核心问题不是“怎么调用Wget”，而是“没设超时 + 没控并发 + 没做隔离”，导致单次失败就卡死一个线程，持续数小时不释放。解决必须从阻断、降级、监控三方面同步入手。
立即止损：强制中断挂起线程
线上已出现数小时不返回的线程，需紧急干预：
- 用 jstack [PID] > jstack.log 导出线程快照，搜索 Wget 或 ProcessBuilder 相关堆栈，确认线程状态为 RUNNABLE 且停留在 java.lang.UNIXProcess.waitFor 或类似系统调用处
- 对确认卡死的进程（如 Linux 下的 wget 子进程），可执行 kill -9 [子进程PID] 强制终止 —— 注意：这是临时手段，不能替代代码修复
- 若使用 Spring 的 @Scheduled，默认单线程执行器，一个任务卡死即整个定时器停摆；应立刻改用带超时保护的异步执行方式，避免阻塞调度线程
根本修复：超时 + 并发 + 资源三层控制
Wget 是外部命令，不可控因素多，必须按“最差情况”设计防护：
-
进程级超时：不要依赖 Wget 自身的 --timeout（它只管网络层，不防卡在 DNS 或重定向中）。改用 Java 的 ProcessBuilder 配合 waitFor(long, TimeUnit)，例如：
process.waitFor(30, TimeUnit.SECONDS) —— 超时后主动 destroy() 子进程 - 线程级隔离：禁止在定时任务主线程或 Tomcat 线程池里直接起 Wget。应使用独立的、有界队列的线程池（如 ThreadPoolTaskExecutor），并设置 maximum-pool-size ≤ 3（Wget 本质是 IO 阻塞型，线程数过多反而加剧资源争抢）
- 调用频次熔断：在定时任务内增加失败计数和暂停机制。例如连续 2 次 Wget 超时，自动跳过本次执行，并记录告警；5 分钟内累计失败 ≥ 5 次，触发短时熔断（暂停后续 15 分钟）
长期规避：用更可控的替代方案
Wget 作为 shell 命令，在 Java 服务中属于高风险调用方式，应逐步替换：
- 优先改用 HttpClient 或 OkHttp，它们支持完整的连接超时、读取超时、写入超时、重试策略及连接池管理
- 若必须用命令行（如需特定 Wget 参数），应封装为独立轻量服务（如 Go 编写的 HTTP 代理），由主服务通过 HTTP 调用它，并设置严格超时（如 10s）
- 对非实时场景（如日志归档、离线抓取），改为消息队列驱动（如 Kafka + 消费者集群），天然具备失败重试、限流、隔离能力
可观测性补强：让问题不再“静默恶化”
故障反复发生，往往因缺乏有效信号：
- 暴露线程池指标：通过 Spring Boot Actuator 的 /actuator/metrics 查看自定义线程池的 active、queue、completed 数，配置 Prometheus 报警（如 queueSize > 10 持续 1 分钟）
- 记录关键耗时：在 Wget 执行前后打点，用 MDC 记录 traceId 和 start/end 时间，确保日志能定位到哪次调用卡住
- 添加子进程存活探针：定期检查残留的 wget 进程（ps aux | grep wget | grep -v grep），发现异常长时进程自动告警
