cup占用率过高
常见能够引起CPU100%异常的情况都有哪些？
- Java 内存不够或者溢出导致GC overhead limit exceeded。
- 代码中互相竞争导致的死锁。
- 特别耗费计算资源的操作，比如正则匹配，Java中的正则匹配默认有回溯问题，复杂的正则匹配引起的CPU异常。
- 死循环引起的CPU高度密集计算。
针对第1种，根据Oracle官方资料，GC overhead limit exceeded表示JVM一直在GC导致应用程序变慢，具体量化指标就是JVM执行垃圾回收花费超过98%的时间，但释放出的可用堆内存却少于2%，连续多次（一般5次）GC回收的内存都不足2%的情况下就会抛出此异常。
经过垃圾回收每次释放的内存都少于2%很容易又被新生对象填满，JVM快速进入下一次垃圾回收，无限循环，由此引起频繁的GC长期消耗我们服务器CPU资源，从而使CPU使用率达到100%
我们可以使用-XX:-UseGCOverheadLimit这个参数关闭GC overhead limit exceeded，但这样治标不治本，建议检查应用程序的内存使用是否合理以及是否需要增加堆内存。
测试代码
public class Test {
public static void main(String[] args) {
System.out.println("测试死循环对 CPU 影响");
for (int i = 0; i < Integer.parseInt(args[0]); i++) {
new Thread(()->{
System.out.println(Thread.currentThread().getName());
while (true){
}
},"线程："+i).start();
}
}
}Linux 编译运行 Test.java 程序
运行 Test 程序，启动 1 个死循环线程
top 命令查看 cpu 使用情况
按大写 C 可以按 CPU 从大到小排序
可以看到 Test 的 CPU 使用率 100%，和 window 区别很大（window CPU 100% 就卡死了），我的 Linux 服务器是 2 核的，总 CPU 使用率 50 %，服务器也不会卡，简单理解就是把一个核跑满了
查看进程下的线程详情 top -H -p 18515
再按一下H ，可以查看的线程的id
将线程 18515的 pid 转为 16 进制 printf "0x%x\n" 18515
根据16进制格式的线程ID查找线程堆栈信息
jstack pid |grep tid -A 50
可以看到第 7 行代码引起的，从源代码可以看到是 while(true) 引起的，简单说一下 grep 参数
- grep -A n 显示匹配指定内容及之后的 n 行
- grep -B n 显示匹配指定内容及之前的 n 行
- grep -C n 显示匹配指定内容及其前后各 n 行
输出整个进程的快照到文件 jstack 18515>> jstack.log
内存泄漏问题排查
1、查询gc情况（每1秒钟打印一次gc情况）
jstat -gcutil pid 1000查询结果含义:
S0:幸存区1占用率
S1:幸存区2占用率
E:Eden区占用率
O:老年区占用率
M:元数据区（java8,相当于java7及之前的永久代的概念）使用大小
ccs:压缩后使用率
YGC:young gc 次数，
YGCT:young gc耗时
FGC:full gc次数
FGCT:full gc耗时
GCt:GC共耗时
2、查询进程信息
#查询占用内存的进程(shift+m排序)
top
#存活的对象占用内存前100排序
jmap -histo:live 41843 | head -n 1003、查询进程里面详细信息
jmap -heap 41843如果Jave类的内存异常则检查代码
如果发现频繁的gc是因为新生代、老年代、永久代分配的大小有问题，则可以通过修改设置解决
eg：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:PermSize=64M -XX:MaxPermSize=128M -XX:MaxTenuringThreshold=0参数含义：
- -Xmx3550m 堆最大容量(heap max size)
- -Xms3550m 堆最小容量(heap min size)
- -Xmn2g 年轻代大小
- -Xss256k 每个线程栈容量大小(stack size)
- -XX:NewRatio=4 年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代），设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5；
- -XX:SurvivorRatio=4 年轻代中Eden区与Survivor区的大小比值，设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
- -XX:PermSize=64M 初始分配的永生代容量
- -XX:MaxPermSize=128M 永生代最大容量
- -XX:MaxTenuringThreshold=0 设置垃圾最大年龄
-Xmn对系统性能影响较大，Sun官方推荐配置为整个堆的3/8；JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。
JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右；
-XX:MaxTenuringThreshold如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
使用jvisualvm进行排查
找到jdk的安装目录，再bin目录下有一个jvisualvm.exe，运行它即可
装入dump文件
点击类，进行分析
可以查看各个类实例的个数，找到那个对象的实例比较多，占用内存较大
排查方法包括三步：
- 获取堆内存快照dump
1、通过jmap指定打印他的内存快照dump(Dump文件是进程的内存镜像。可以把程序的执行状态通过调试器保存到dump文件中)
2、使用vm参数获取dump文件(可以指定生成dump文件的文件目录）
有的情况是内存溢出之后程序则会直接中断，而jmap只能打印在运行中的程序，所以建议通过参数的方式的生成dump文件
- VisualVM去分析dump文件
- 通过查看堆信息的情况，定位内存溢出问题
