新闻速览使用HTTP Client踩到的一个坑，你一定要避免

五连环画

前言作为软件开发者，我们知道一切看似正常的系统，不知埋藏着多少坑。今天跟大家分享一个战过程中遇到的HTTP C使用不当导致的坑。加速器的具体问题可以到我们网站了解一下，也有业内领域专业的客服为您解答问题，为成功合作打下一个良好的开端！

笔者通过问题的表象一路追踪下去，比较终找到导致问题的根源：HTTP C。结论很简单，先卖个关子，但分析的过程值得你借鉴。

问题现象场景：几乎每个系统都有异步调用方服务的功能，所负责的系统基于阻塞队列现了一个消息队列，来调用方服务。为了确保幂等性，队列是顺序消费。这就导致一个问题，一旦其中一个消息被阻塞，后面的消息就法消费。当队列满时，也法向队列中添加消息。

看似：极其偶发的场景下，消息队列被阻塞十多分钟。这是什么鬼?

下面就开始了问题的逐步排查。

问题排查首先想到的是，是不是消息队列现的底层机制有问题。比如消息队列是通过()轮训+睡眠来现生产者和消费者的持续存取数据。

既然消息被阻塞，是否是因为(睡)过头了?后来一想，即使CPU进行了分片处理，也不至于睡眠那么就不会被唤醒。同时也不太可能是线程被掉。因为，如被掉了，整个队列就挂了，不会延迟后恢复正常。

在此处困惑了很久，看了消息队列现的源码很久，没有突破。于是，与朋友探讨了一下，一句话提醒了我：可能不是睡眠的问题，而是生产者或消费者的问题。

于是仔细扒日志，发现还真是的：生产者向队列中丢了一次数据，持续很长时间没有再丢数据;消费者在生产者向队列丢数据之后几分钟还有消费的日志。很明显，生产者是被消费者阻塞了。

初步结论：消费者消费时间过长，导致队列满了，生产者向队列添加数据时被阻塞。

经验性猜测：消费者中有HTTP请求，HTTP请求可能长时间持有连接未释放。

问题根源当分析定位到是HTTP请求的原因，就很好解决了。首先分析了日志，发现的确有一个HTTP请求，请求前打印了请求参数，但始终没看到返回结果的打印。扒日志终于看到，返回结果的日志是在15分钟之后打印出来的，日志内容为对方服务异常。

再看看代码，发现HTTP请求是基于HTTP C现的，而当初写这段代码的人并没有设置超时时间。为了保持业务脱敏，找了一段类似的代码：

S PWJSON(S , S )E { CHC= HCD(); HP P =HP(); PH("C-T",";=UTF-8"); SE=SE(,CN("UTF-8")); CT(""); PE(); CHR=(P); HE= E(); S= EUS(, "UTF-8");;}像上述代码一样，设置了请求参数，但未指定HP的超时时间。看似正常的代码，隐藏着一个巨大的坑，导致的结果就是HTTP请求一直等待。

笔者所遇到的情况还好，对方设置的超时时间为15分钟，还给返回了结果。如果对方未设置超时时间，可能就一直等待了，当业务量比较大时，会导致灾难的发生!

HTTP C的超时设置找问题往往是比较难，当找到问题时，解决起来就容易多了。HTTP
C的不同版本有不同的设置超时时间的方式，这也算是HTTP C的又一大弊端吧，API版本变动太大。

43版本的配置：

CP()P(CCPNCONNECTION_TIMEOUT,10000);CP()P(CCPNSO_TIMEOUT,10000);43以后版本的配置：

RC C = RC()ST(10000)CT(10000)();GC(C);其中，CT为连接超时时间，单位为毫秒。

ST为请求获取数据的超时时间，单位毫秒。如果访问一个接口，指定时间内法返回数据，就直接放弃此次调用。

其他版本的使用，建议参考一下相关的API说明了。

小结在践的过程中，我们经常会遇到一些莫其妙的问题，而这些问题导致的原因可能是践经验不足，也可能是对API的使用不够熟练。而经验来自哪里?来自像本文这样一个个问题的排查、总结、积累而获得。

比如，读完本篇文章，你已经知道了：当使用HTTP
C时一定要设置超时时间。同时，你肯定也能举一反，凡是在HTTP调用时都需要考虑一下超时时间及对应的异常处理。