订单查询接口 P99 从 200ms 涨到 32 秒，jstack 里 196 个线程停在 SocketInputStream.socketRead0，线程池活跃数一直等于 maximumPoolSize。日志里能对上时间点，这种反而好排。
任务里同步调下游 HTTP 接口，超时给了 30 秒，下游一抖动线程就全挂在那儿等。线程池被 IO 等待占满，新任务只能排队。这一点先确认清楚，后面就不用反复试。
jstack 1 | grep -B 2 -A 8 'socketRead0' | head -40
curl -o /dev/null -s -w '%{time_total}\n' http://downstream/health
「线程池阻塞 IO」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
报错里带路径的，先去看那个路径在不在、权限对不对。同一份配置存在多处的，先确认改的是被加载的那一份。
处理上按这个顺序：把下游超时压到 2 秒 连接超时单独设 500ms；线程池按 IO 等待比例扩容 或者改用异步客户端；给每个下游单独分池 避免一个接口拖垮全部；压测时人为注入 5 秒延迟 看池还能不能接新任务。
结果对不对很好判断，下游延迟 5 秒时接口 P99 保持在 3 秒内，活跃线程数不再顶到上限。