【原创】经验分享：一个Content-Length引发的血案(almost....)

前言

上周在工作中遇到一个问题，挺有意思，这里记录一下。上周在工作中遇到一个问题，挺有意思，这里记录一下。标题起的很唬人，这个问题差点引发血案，花哥还是很严谨的一个人，后面备注了almost....

在测试环境中，前端调用我们服务一个接口时发现巨慢无比，响应时间超过了30s，简直无法忍受！！

查看日志显示是我们服务在通过Feign请求调用另一个服务的GET接口时一直超时，然后重试了一直直到失败。 但是奇怪的是手动通过ip+端口请求这个超时的GET接口时却响应速度很快。

这就很奇怪了，之前一直调用好好的接口，怎么现在就一直超时呢？此时的我是满脑子问号。。。

现象

前端调用我们服务(这里叫做服务A)的一个查询接口，这里前端用的是POST请求，我们服务又会通过Feign调用到另一个服务(这里叫做服务B)的一个接口，这个接口对外提供GET形式的调用。

从现象上来看就是调用我们服务特别慢，一个请求响应几十秒，具体流程如下：

问题排查

当时脑子中出现的疑惑就是太奇怪了，之前一只调用的接口不应该会出现这种情况，而且手动通过ip+端口去调用的话响应速度很快的，于是找了服务B对外开发的同学一起看，因为自己忽略了一些重要的日志信息，所以这里走了不少弯路，在同事的帮助下自己也将这个问题梳理清楚了。

问题的根本原因是我们在GET请求的Header中传递了Content-Length参数，而且服务B近期添加了一个jar包，jar中有一个拦截器做了一些事情导致了这个问题。我这里从源码层面上梳理下整个问题的根本原因，以及以后如何避免此类问题！

对于这个问题，自己本地分别启动服务A和服务B，以DEBUG模式启动，发现可以稳定重现，而且可以看到在调用服务B卡住时候的堆栈信息：