问题情况描述：

1.springboot服务运行访问一段时间后，日志里报com.alibaba.nacos.api.exception.NacosException: Request nacos server failed，并且还伴有Server healthy check fail,currentConnection之类的描述；

2.登录Nacos控制台查看，相关服务已经已经不在服务列表里了；

3.查看Springboot服务的日志，发现日志里还是有接收到请求并处理的相关日志记录，只是访问Nacos报错，说明服务并未宕掉。

问题定位原因：

Springboot服务数据库查询出现内存泄漏，服务长时间FullGc，导致服务“假死”的持续时间超过了Nacos心跳检测周期，然后Nacos将服务从注册列表里移除了。

主要体现在BoundedConcurrentHashMap缓存了很多in条件的查询，占用了大量堆内存未及时释放。

调整策略：

1）限制缓存大小：BoundedConcurrentHashMap允许你设置最大的缓存项数。你可以根据你的应用和硬件资源来设置一个合适的值，以防止缓存占用过多内存。 2）设置缓存过期时间：你可以为缓存项设置过期时间，以防止长时间不用的数据占用内存。你可以根据你的应用的需求来设置一个合适的过期时间。 3）优化查询：如果可能，你可以尝试优化你的查询，减少使用in条件。例如，你可以尝试使用join或者exists代替in。 4）使用更高效的缓存策略：如果以上方法都不能解决问题，你可能需要考虑使用更高效的缓存策略，例如LRU（Least Recently Used）或者LFU（Least Frequently Used）。

本次处理仅进行优化查询，减少了in条件里的穷举值数量。

排查过程：

1.在出现问题的第一时间不急着重启服务，获取Springboot服务的日志，记录Nacos服务列表情况。

2.使用命令采集相关数据

1）使用ps -ef | grep xxx 获取Springboot服务的进程ID号;

2）使用jstack命令获取java线程堆栈信息，jstack  > jstack.log，主要关注是否有死锁、阻塞的线程；

3）使用jmap命令获取java线程内存映射信息，jmap -dump:live,format=b,file=heap-dump2023.out ，主要用于内存分析；

4）使用jstat命令获取GC信息，jstat -gc > gc2023.out，主要用于确认FullGc的持续时间及频率。

3.使用相关工具对采集的相关数据进行分析

1）通过jca4614.jar对jstack.log日志进行分析，发现无死锁、阻塞现象。

2) 通过ha456.jar对heap-dump2023.out进行内存分析，发现有个对象占用了近70%的内存。

主要是这个类里面有许多对象汇总起来占用了大量内存

org/hibernate/internal/util/collections/BoundedConcurrentHashMap

但是ha456.jar这个工具好像不是很好找出这个里面的具体内容是什么，就不好定位到底是Springboot服务里哪里相关。

就换了一个内存分析工具MAT。

3）使用MAT对heap-dump2023.out进行内存分析，发现还是同样的对象占用着内存。

会发现还是org/hibernate/internal/util/collections/BoundedConcurrentHashMap，但是在这个工具里可以看到具体的查询sql，多查看几个这个对象，发现里面的sql都是这个in条件很多，但是每个in的个数不一样，现在情况就已经很符合预期了。

如果对应的数据库有开启sql执行历史记录功能，也可以在这些执行历史里进一步查找验证。

4）对gc2023.out进行分析，发现里面确实有持续时间比较长的FullGc，符合预期。

总结：

1.写查询sql是尽可能避免in条件很多的查询，否则可能会出现缓存sql过多。

2.考虑设置sql缓存的自动过期时间。

3.服务偶尔出问题时有可能会自行注册上去，但也有可能不会再注册上去，随机，因此尝试调整注册中心的心跳检测机制也还是会出现问题，还是得从根本上解决问题。

精彩链接

评论可见，请评论后查看内容，谢谢！！！
 您阅读本篇文章共花了：