本课程的主旨及目标
•导致应用CPU高的常见原因
•定位问题的大体思路
•定位问题的具体方法
•实际案例
应用CPU高常见原因
•1.程序计算比较密集
•2. 程序死循环、死锁
•3.程序逻请求堵塞
•4.IO读写太高 （df –h看看磁盘是不是满了）
•5.自创线程没有限制（线程池）
•6.不合理的创建对象，导致频繁GC
定位问题的具体方法
1.不管什么情况先用top命令查看资源消耗，找到消耗大量CPU资源的进程pid，我们一般都是java进程排名第一
2.输入top –p pid 来单独监控该进程
3.在第2步的监控界面输入H，获取当前进程下的所有线程信息
4.找到消耗cpu特别高的线程编号（可能会有多个），这里是6752
5.将第4步得到的线程编号6752转成16进制是1a60,因为jstack输出的线程栈信息中，线程ID是以十六进制展示的。
6.切换到jbossuser用户【pid对应的进程用户，这里一般是java进程用户】
7.因为没有jstack这个文件的环境变量，所以要先export PATH="$PATH:/opt/wildfly/openjdk/openjdk-1.8.0_92/bin"
8.使用命令 jstack $pid | grep “线程id” –A 30，把信息打印出来【这里的-A 30指的是30行】【线程id：根据第5步得到的1a68在pid线程信息里面去找对应线程内容】，也可以写到文件中，下载下来，通过16进制的线程id来搜索定位代码段。
9.通过jstack命令来查看下当前内存状态，解读线程信息，定位具体代码位置,接下来就是找开发人员确认问题，看这段代码是否可以优化。
实际案例
案例一：
定位到cpu过高是IO读写太高 ,接下来就是找开发人员确认这段代码是否可以优化
案例二：
两个线程执行过程中，需要对两个对象进行加锁，且加锁的顺序不一致，导致了死锁的产生，简单的修复方法是：对两个对象的加锁顺序一致。
注意：必须有两个可以被加锁的对象才能产生死锁，只有一个不会产生死锁问题
案例三：
案例四：
案例五：
1.生产环境heap堆内存不断上升导致oom，pst环境复现heap堆内存不断上升。经过分析堆内存创建的windq主题或队列WindqQueue、WindqTopic方式会缓存到连接工厂，缓存的对象并不是根据唯一的key去缓存，而是直接使用对象的引用作缓存，导致jvm无法回收这部分内存（比如新建同一个sendOperationTopic的主题Object1，Object2，Object1和Object2都会缓存到连接工厂）。
2.pst环境百万数据重试发现栈内存溢出，由于递归调用导致，已将递归方法修改为循环的方式去调用。
结果：修改后pst环境内存回收稳定，无连接工厂大对象，堆内存，无栈内存溢出，cpu使用情况稳定。
发现程序异常前通过执行指令，直接生成当前JVM的dump文件，15434是指JVM的进程号
jmap -dump:format=b,file=serviceDump.dat 15434
