有感于一个悬而未决的问题

我们新开启了一个项目。项目仍然使用tomcat作为容器发布,但是这次出现了高CPU占用的情况,当然使用了ssl证书,但是我们仍然遵照了生产其他tomcat的配置方式,使用的是apr(最初是nio,导致cpu资源无法释放)。这个tomcat还出现过几次假死。也在发现假死后把堆栈都输出以发现情况具体在哪里。但是,都没有解决。
由于是我在摆弄部署的事,研发leader跟我确认配置是否正确,把问题告诉了我,说CPU占用很高。我再三确认配置是正确后。凭借直觉(连接资源没有释放) ,用netstat -ap|grep PID。

在这里插入图片描述

由于最近在自学java的socket编程,所以对socket的一些基本原理有所了解,知道socket是通过TCP连接的,建立通道,需要关闭通道,眨眼就该关闭,所以Close_wait的数量还是多了点,同时这个连接还是https建立的。一下就get到了点,我多次运行查看命令,Close_wait数量没有任何变化,理论上这个值应该是动态变化的,猜测这个地方有问题。顺藤摸瓜看看网上有没有人遇到过,百度关键“tomcat apr CLOSE_WAIT”,找到这篇博客“https://www.cnblogs.com/saaav/p/6258831.html”
症状,基本和我们一样,接着基于博客的信息,我去排查我们tomcat的版本时间和bug修复时间,发现我们的版本是旧的,所以,升级tomcat版本就可以解决问题。而这种问题也可能是导致tomcat假死的真正原因,https://blog.csdn.net/lxlmj/article/details/53005021
接着,在可复现的测试环境,替换tomcat版本。验证假设。
最后,验证通过在生产环境升级。

感慨:懂的基础越多,解决问题的思路越开阔。好好学习,天天向上。

后记:截图中的CLOSE_WAIT依然存在,从业务上确认是必要的。所以,发现问题的解决,在我的认知范围和水平内,只是偶然的,但毕竟我还是协助解决了。