1、cpu疯狂的手段：
1.1、使用jmap指令分享jvm的堆运行情况，看实例了多少个对象
jmap -histo 11472|grep youx|sort -k 2 -g -r|less
youx : 代表实例对象含有包名（框内代表实例化个数）
1.2、查看高频使用cpu的线程队列情况 jstack 15543 |grep 3cfc -A 100
1.3、再实用 jstack [pid] >> log.log 命令将tomcat进程的jvm日志导出来分析
可以看到以上有大量的GC线程在等待cpu进行内存的回收，由于以上有大量非GC的线程在等待cpu处理业务，其所实例化的对象就一直内没有被回收从而导致大量的对象处于内存中，因此jvm疯狂的启用GC线程进行内存的回收
a、因此可能会导致系统的cpu飙升从而压垮服务器，导致系统服务无法运行
2、cpu飙升的原因2，因为我们的平台使用mysql-connector-java 链接包使用的是5.1.6，这个jar有一个jdbc连接池无法关闭的bug，从而导致系统有大量的jdbc链接进程在等待关闭，导致系统的负荷也过高，cpu也会出现飙高的现象。
3、cpu飙高的可能原因3：由于我们平台使用的redis缓存是自己搭建的私有服务，因此存在吞吐量没有优化的可能性，服务在链接redis时，由于在序列化过程redis的吞吐量较低，导致在连接redis的时候，假如有稍大流量的访问涌入的时候，
redis的链接池会被压垮从而导致大量的线程再等等redis的链接资源，从而导致整个系统的阻塞，
因此系统的cpu处于高运行状态，从而造成整个平台的瘫痪
在分析cpu飙高的过程中，原因2、3的截图显示，所使用的工具是通过jvisualvm （jvm虚拟机自带的工具）进行监控jvm运行的日志，将其导出通过使用eclipse的内存分析工具进行分析日志结果，所分析得出来的可能原因
导入jvm远程监控工具上导出的日志
jvm远程监控工具使用方法：https://blog.csdn.net/qq_31854907/article/details/86134137
4、从原因2、3的日志显示由于大量资源在等待资源执行，从而导致大量的任务在等待处理从而大量的线程处于阻塞状态，因此系统的cpu使用也存在飙高的可能性，
由于的平台在使用的过程中，为了方便监控程序的运行过程以及方便依据日志调查系统错误原因，因此会将系统的sql语句答应出来，从而导致大量的进程在竞争log日志数据输出权限，因此直接压垮系统的运行，导致cpu飙高
（有spring 配置日志数据切面，进行日志的统一输出）