大家好，今天小热关注到一个比较有意思的话题，就是关于MultiThreadedHttpConnectionManager的问题，于是小编就整理了2个相关介绍MultiThreadedHttpConnectionManager的解答，让我们一起看看吧。
文章目录：
一、MultiThreadedHttpConnectionManager在哪个jar包里
import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
如果用的idea环境，pom中配置如下即可自动引入jar：
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
</dependency>
方法class所在的jar路径
二、HttpClient 设置不当引发的一次雪崩!
一. 事件背景
我最近负责的网上实时接口服务，遇到了频繁的 "Address already in use (Bind failed)" 问题。显然，这是一个端口绑定冲突的情况。经过排查，发现大量 "time_wait" 的网络连接占用端口，导致端口被占用（最高时达到6万+个），使得 HttpClient 在并发时因申请端口冲突。
具体情况如下:
为解决 "time_wait" 问题，我参考了资料并结合自己的思考，决定通过连接池保存 TCP 连接，减少 HttpClient 在高并发时随机打开的端口数量，同时复用有效连接。然而，在设置连接池最大连接数时，引入了新的问题。
二. 问题过程
基于业务高峰时的1分钟1.2万次 PV 和接口平均响应时间1.3秒（复杂广告推广效果模拟系统，这种场景下高响应时间是业务需求），估算 QPS 为 260。根据业务日志，每次连接建立耗时1.1秒左右，预留70%以上的缓冲空间以防连接数设置过小导致系统故障，最大连接数估计为500。
为了最小化对业务代码的改动并快速验证优化效果，我使用了 HttpClient3.1 的 MultiThreadedHttpConnectionManager。进行线下多线程测试后，发现并发度确实高于无线程池时。在南京机房进行小流量上线验证，效果符合预期后，计划全量上线北京机房，结果上线后出现了未预见的系统异常。
三. 案情回顾
在流量全量转移后，一切如预期，但第二天早上用户反馈页面无法打开。通过询问，确定问题出在连接池调用后端服务的部分。于是，我将排查思路集中在线程池故障上。
四. 深入排查
发现约1/3实例进程崩溃，但业务流量未变，导致单台机器流量升高，使得存活实例更容易崩溃。我查看了进程挂死的原因。
怀疑连接池设置问题，因为线程数和 CPU 状态最易受影响。立即监控 CPU 状态和线程数。
1、CPU状态
Java 进程 CPU 占用率极高，是平时的近10倍。
2、线程数监控状态
在10点左右，多个机器线程数迅速增加，甚至超过虚拟化平台的2000线程数限制，导致实例被杀。南京机房小流量上线未出现此问题，可能与流量较少有关。
分析线程数快速增加的原因时，我怀疑最大连接数设置不当限制了并发度。通过回滚实例并观察连接情况，发现连接线程并发度显著降低。分析 Java 进程中分配的子线程，确认问题。
jstack 日志揭示大量线程在等待连接池获取连接，导致线程堆积，引起接口响应时间上升，加重线程堆积，形成恶性循环，最终导致线程数超限。
五. 案情总结
这次雪崩事件的根本原因是连接池参数设置不当。总结整个事件，提出了优化方案，包括压测方案和配置调整策略，以避免类似问题。
在技术升级时，需谨慎对待新引入的技术点。出现问题后，重点分析特征和规律，找到问题根源。本次事件提醒我们在技术改造时需更加周全。
到此，以上就是小编对于MultiThreadedHttpConnectionManager的问题就介绍到这了，希望介绍关于MultiThreadedHttpConnectionManager的2点解答对大家有用。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。