问题描述几年前做学习类APP时，评论服务（comment）访问评论后台服务（comment-server），正常RT是【几毫秒】~几十毫秒】，偶尔（每隔几天）RT会达到几十秒甚至几分钟，导致用户看不到评论列表，无法发表评论等不良体验。分析流程系统交互关系系统交互关系网关和评论之间的通信协议是LWP（LaiWangProtocol）评论和SLB之间的通信协议是https评论调用评论-服务器超时？应用程序调用依赖服务时，会记录[时间戳、依赖类别、调用接口、响应时间、状态码]等指标信息。通过监控和日志信息，当出现问题时，与SLB交互的RT为【452秒】。初步定位是由于[SLB]或者[comment-server]处理速度慢导致的，所以联系了负责[comment-server]的运维同学】同学们一起检查。与SLB交互需要时间SLB日志request_time:0.004seconds,upstream_response_time:0.004secondscomment-serverprocessingtime-applicationlogprocessingtime-consuming[4毫秒]，看来是自己的错。查看代码应用使用ApacheHttpClient访问负载均衡，代码抽象表达如下：代码示例这段代码好像哪里有问题？GC引起的阻塞？通过查看GCLog，发现CMSGC耗时较长，对应超时的时间点，终于找到了端倪。当CMSGC发生时，线程在忙什么？这时候LWP框架的threaddump就起到了关键的作用。下面简单介绍一下LWP。线程模型LWP是RPC框架，网络通信框架使用netty。线程模型业务线程池线程池初始化线程池配置拒绝策略rejectionstrategy当线程被阻塞时，LWP框架打印出当时的线程堆栈信息，发现在SSL交互过程中所有业务线程都被阻塞了。问题根源是SSLSessionContext的ssl会话缓存（是一个SoftReference缓存）默认超时时间为86400s（24小时），ssl会话缓存的大小默认是无限的，导致CMSGC需要很长时间来处理SoftReference。是JDK的一个bug，如下：JDKBug描述解决方案设置SSLContext实例的sessionCacheSize和sessionTimeout，例子：sslContext.getClientSessionContext().setSessionCacheSize(1024);sslContext.getClientSessionContext().setSessionTimeout(60);SSL通信的应用也需要注意以上问题。
