临近月底，用户量上来，发现业务进程频繁从Eureka上掉下来，观察后发现掉下来前进程CPU一直占用比较高。

按 方法查看堆栈信息，发现有个方法很可疑，发给开发人员查看，觉得表数据量太大，查询没有走索引，新建索引后，感觉情况有好转。

排查步骤如下：

1.使用top 定位到占用CPU高的进程PID

top

2.获取线程信息，并找到占用CPU高的线程

ps -mp pid -o THREAD,tid,time | sort -rn

3.将需要的线程ID转换为16进制格式

printf "%x\n" tid

4.打印线程的堆栈信息

jstack pid |grep tid -A 30

同时发现数据库连接有报“Connection reset”的异常，一时也发现不了问题，将dbcp2连接池换成durid。

通过durid的spring监控发现（果真非常强大），还是同样的方法读取行数非常大。

发现《 问题情况非常相似，因为在之前用jstack查看时，就是GC占用CPU非常高。

再仔细看代码，发现某种情况下，确实会读取全量表数据。

优化代码后，问题解决。