HttpClient SSL Session默认设置导致线程阻塞几分钟的案例分析

几年前在做某学习APP的时候，评论服务（comment）访问评论后端服务（comment-server）正常RT在【几毫秒 ~ 几十毫秒】，偶尔（每隔几天）RT达到几十秒甚至几分钟，造成用户看不到评论列表，发表评论失败等不好的体验。,,系统交互关系,在应用调用依赖服务的时候，会记录下【时间戳，依赖类别，调用的接口，响应时间，状态码】等指标信息。
通过监控及日志信息，出现问题的时候与SLB交互的RT是【452秒】，初步定位是【SLB】或【comment-server】处理慢导致的，所以联系了运维同学、负责【comment-server】的同学一起排查。,,SLB日志,其中request_time：0.004秒，upstream_response_time：0.004秒,,应用日志,处理耗时【4毫秒】，看来锅是自己的。,应用访问SLB使用的是Apache HttpClient，代码抽象表达如下：,,代码示例,这个代码哪里似乎有问题？,通过查看GC Log，发现CMS GC耗时较长，与超时的时间点是能够对应上的，终于发现了线索。
发生CMS GC的时候，线程都在忙些什么呢？这时候LWP框架的线程dump起到了关键作用，下面对LWP简单做下介绍。,LWP是一个RPC框架，网络通讯框架使用的是netty。,,线程模型,,线程池配置,,拒绝策略,在线程blocked的时候，LWP框架打印出了当时的线程栈信息，发现所有业务线程都阻塞在了SSL交互过程中。,SSLSessionContext’s ssl session缓存(which is a SoftReference cache) 超时时间默认是86400s (24小时)，ssl session缓存大小默认是没有限制的，导致CMS GC处理SoftReference的时候耗时较长导致的。
算是JDK的一个Bug，如下：,,JDK Bug描述,设置SSLContext实例的sessionCacheSize、sessionTimeout，示例：,不仅https，对于使用SSL通讯的应用同样需要注意上面的问题。,