一、什么是cpu飙高？
一般指程序运行时cpu占用率过高
linux系统中，我们使用top命令，会看到正在运行进程的cpu使用率等，同时在最上面也会看到总的cpu使用率，当总的cpu使用率过高，如果有运维监控平台，则一般我们会设置阈值大于80%就会发生报警。
一般来讲，我们说的cpu飙高指的是系统总的cpu高。我们会看到有用户进程使用的cpu使用率可能会300%乃至600%等，这时候如果是正常的cpu密集型计算导致，其实我们来看系统总的cpu使用率统计，它可能并不高，所以这种情况我们可认为是正常的（只有导致系统cpu整体飙高，我们这时候才认为不正常、当然先决条件是要排除一些客观因素后）。
可参考下图，红色框选出来的即为总的cpu使用率。
图（一） 上图是top命令下的界面展示
二、为什么会cpu飙高？
cpu密集型计算
针对于程序的执行，对硬件资源的使用情况，我们可以分为cpu密集型计算和io密集型计算。对于一些cpu密集型计算，如果对cpu的压榨特别狠，则会产生cpu飙高。
对于web服务访问量增大就有可能cpu飙高
如果某一时刻有很多用户来访问某一web服务，需要处理大量请求而导致cpu飙高。
图 (二） 上图是个80个用户并发访问的loadrunner图形化状态展示
图（三） 上图是nmon工具对后台服务器的监控界面 如图三所示，其中cpu使用率高达95%（cpu utillisation中
User%指代的是用户态下（也就是目态）cpu使用率，Sys%指代的是管态下，cpu的使用率），这是在80个用户并发的情况下达到的，需要查明原因是因为用户访问量上去正常导致，还是程序里面有不合理的地方而导致，本图中所示是程序里有不合理的地方而导致。
不合理的定时任务资源调度也会导致cpu飙高
程序中某一位置代码写的不合理而导致的cpu飙高：
比如：
使用hashMap容器计算处理一些数据时，出现了一些不合理的操作。
多线程任务时，线程发生死锁。
不合理的多线程高并发程序。
在调用数据库查询时，极短的时间内频繁调用模糊查询（这时候不仅对数据库有资源占有压力，也对应用服务器有一定的资源占有压力）。
低版本jdk下易发生（有些写法低版本jdk是不适用的，因为有些操作，它的底层没有像高版本被优化过）。
三、如何躺平式处理cpu飙高问题
不合理程序导致的cpu飙高
1、定位导致cpu飙高的源头进程
可以通过使用top命令看到cpu最高的进程号，观察其属于哪个应用。
如图一所示，可以看到cpu使用率排第二的是一个java程序，如果java程序cpu使用率很高，则可以进一步追踪进去，观察它是由于哪个线程导致的cpu飙高。
top直接使用top命令
2、定位导致cpu飙高的线程
依然使用top命令，通过高cpu的应用进程号查到该进程下那些线程cpu占用率最高。
top -Hp pid 可以查看某个进程的线程信息(pid为进程号)，此linux命令，其中参数H指展示线程信息，p指代展示对应的哪个进程号。
3、查看导致cpu飙高的线程堆栈
使用jstack命令查看cpu占用率高的堆栈信息，这时候，如果是有问题的程序，堆栈信息里面就已经会有所体现了。
另外，jstack命令属于java sun jdk的tools工具命令，需要在linux中配置jdk环境变量才可以使用，或者直接用jstack命令的全路径名执行。
先将第一二步进程对应的使用率最高的线程号转换为16进制，留待接下来的命令使用，使用 printf "%x\n" pid转换，例如：printf "%x\n" 25553，其中25553就是线程号（25553转换为16进制是63d1）。接下来使用 jstack 25556 | grep 63d1 -A 50 ，（25556是使cpu飙高的25553线程所属的进程号,63d1是线程号25553转为16进制后的值）使用此命令后，基本上有问题就可以看出来了，包括代码原因导致的异常显示，或者线程死锁，阻塞等。
4、找到异常堆栈分析原因
找到异常堆栈后，查看是否有自己程序中开发的数据的代码行，直接去应用程序源码的对应位置分析该处是否写的有误。
一般在第三步中使用jstack命令后，出现在堆栈信息中的程序代码很大概率是问题代码，可以到具体代码行去排查和看了，如果实在发现不了问题，可以直接换写法看结果是否还是如此，或者猜测法猜测。
5、由原因进行程序优化和问题修复或改进
根据排查出的问题，进行代码优化。
如果出现的是tps瓶颈或者吞吐量问题，那么这时候就可以考虑jvm层进行优化一波了，具体优化原理，可移步作者的jvm专栏进行查看。（一般需要调优垃圾回收器，堆参数，gc回收阈值等，还可以调整解释和编译执行的阈值等）
web服务因访问量增多而导致的cpu飙高
web服务因访问量增多而导致的cpu飙高是很正常的cpu飙高，这时候我们可以考虑增加硬件资源，或者做集群来分流，更倾向于高并发导致。
初期开发完毕后，在性能测试以后，肯定要进行分析，这时候就是探究是因为什么原因导致的cpu升高了，可以把并发慢慢提上去，如果初期小并发就出现问题了，那很大可能就是代码有问题了！
躺平式
其实cpu飙高问题很常见，不要碰到cpu飙高就畏之如虎，其实排查解决起来很简单，前置条件理清，可能发生的大的原因其实就是以上所列出来那些，只要按照作者说的那个步骤，基本问题不大就处理掉了。
当然，也有一些极端情况，如cpu温度过高等导致cpu飙高及其它…，这种情况我们基本碰不到的。 jstack是常用的命令，一般通过它就可以排查出问题了，我们也可以设置服务器运行时的jvm参数，设置记录gc日志和oom信息，由此在发生相关异常情况时即可快速定位。也可在使用jstat命令查看gc信息，jstat命令在这里不做细说。
在这里贴出来个jvm配置参数
//weblogic setDominEnv.sh
JAVA_OPTIONS="-Xms3072 -Xmx3072m -XX:+UseG1GC -xloggc:/home/weblogic/gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/weblogic/oom"
//tomcat catalina.sh
JAVA_OPTS="-Xms3072 -Xmx3072m -XX:+UseG1GC -xloggc:/home/weblogic/gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/weblogic/oom"
这些参数是jvm参数，与服务器中间件无关，所以参数不用做更改，只是配置的位置和脚本变量根据不同的中间件有所不一样而已。其中-Xms是最小堆空间，-Xmx是最大堆空间，weblogic最大最小堆空间配置一样即可，tomcat最大最小堆空间可根据实际情况配置。-xlogGc是gc日志记录的地方，-XX:+heapDumpPath是堆溢出时导出堆文件的目录路径
另：jvm可被监控，只要开启监控端口即可，另外客户端启动监控时要注意该jdk版本是否和被监控jdk版本一致或者稍大。小版本jdk jvisualvm工具不可监控大版本jvm。java的jdk包下的jdk目录bin目录下有一些jdk 工具，jvisualvm是其中一个。可通过jvm监控，观察服务运行jvm内部的平稳性，对于jvm的平稳性是有要求的，不宜极大波动（可类比天地板）（频繁）。
//jvm监控端口开放配置，如上，也配置在jvm参数中即可
"-Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false "
四、一个栗子
栗子概要：高并发下大量模糊查询的cpu飙高。
环境：
oracle数据库
webloigc应用容器。
……
以前，有一次做完一个项目，信心满满，业务测试后觉得一点问题也没有，可以投产了。
但是就在投产前的三个星期，进行投产前的最后一步——性能测试的时候，出问题了！
只有10并发的访问量，cpu使用率居然超过了80%，纳尼？这是什么鬼，首先检查了压力测试录制的c脚本，发现 脚本里面是需要点击多条件联合查询页，这个里面有模糊查询（后置模糊是可以索引命中的），对于主检索字段都建了索引，基本可以优化的都优化了，最后发现忘了一步，对于多条件联合检索，是需要创建联合索引才可以，而且要包括所有的会联合的字段。
最后发现做了此种操作后，还是不行，虽然比以前好多了，但是并发量稍微上去，cpu还是容易飙高，定位后还是模糊查询导致，这时候进行了默认首页数据缓存，彻底解决了这个联合查询页默认点击后的cpu飙高问题。
稍微解释一下：如果模糊查询过慢，会导致请求线程处理等待等，这时候频繁访问，老线程得不到释放，其实是很容易让cpu升起来的，因为每个线程都会占用一定的资源，尤其是在并发下。
上面的这个栗子，只是个简单的栗子，但是说明什么？说明出现cpu飙高问题，需要在整体环境下进行考虑和排查，而不能仅仅局限于程序运行的服务器环境和程序本身，整体环境下考虑才能更完整、更容易找到真正的cpu飙高原因，原因找到了，剩下的其实就是确定优化方案，这一步就相对容易了。
