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

我们新开启了一个项目。项目仍然使用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依然存在，从业务上确认是必要的。所以，发现问题的解决，在我的认知范围和水平内，只是偶然的，但毕竟我还是协助解决了。