关于系统卡顿排查

2019-6-11值班日，合箱出现卡顿，平均每次合箱请求要5 ~ 10s才能处理完，正常情况1s处理完。(此接口会通过HttpClient去调一个三方接口)。
值班同学给的解释是，将HttpClientPoolUtil工具内定义为了局部变量，每次方法调用都会初始化一个连接池，每次接口调用都会重复创建连接池+连接，占用了过多资源导致页面假死。由于处在封网阶段，修改后代码不能发布，通过重启机器释放资源暂时解决。

但是我仍有几点疑问：
1. 三个仓都要调用合箱接口，为什么只有1号仓出现了这个问题
2. 重复创建连接池+连接造成的资源占用是全局的，为什么只有合箱接口受影响，其他接口运作正常
3. 所以可能跟调用的链接有关，可能是这个url的服务方响应慢，但是此处没打日志没法追溯。但是为啥重启机器情况确实好了很多？（恼火）
4. 所有还可能是cm.setDefaultMaxPerRoute(20)，1号仓路由(host)的最大连接数达到了最大。但是看代码，每次方法调用都会创建连接池，这样看那每次调用只会用1个路由的1个连接啊？或者其实根本没有创建多个连接池？且连接没释放（为什么没有释放？代码上是释放了连接的）
搞不懂。。明天我值班看下吧
https://blog.csdn.net/github_30602055/article/details/79013937