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





按 《Java进程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监控发现（果真非常强大），还是同样的方法读取行数非常大。









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





优化代码后，问题解决。