线上问题解决：java的CPU100％问题分析，定位及解决

一起探讨下，线上问题的处理思路。

问题合集

请求一个API接口返回json数据，慢请求

发送请求后，返回非常的慢。之前很快，突然变慢了。如何去分析，在公司经常出来问题，这个代码可能都不是你开发的。

测试工具模拟多个用户请求。

jcmd查看哪些程序在运行PID。

jstack PID

对于慢查询，线程的快照中可能残留，线程执行的内存。执行的栈，调用链路，很久没有执行完，这个线程执行需要一定的时间，如果查看到多个代码段执行的频次比较高，这些代码就比较可疑。线程执行的时候有个时间跨度，这个时间跨度，也比较可疑，也就是执行一段代码的时间比较长。

找到对应的package包，找到指定的行。

感觉网络有问题，可以通过ping，或者curl请求下指定接口，看看反应时间。

有老铁活可以通过 JvisualVM 查看，但是生产环境一般都不让开发人员直接操作的，中间可能存在跳板机。可以通过windows的跳板机来查看JVM的情况。

死锁的情况

示例

如何分析，比第一个例子相对简单，其实打印的tack已经展示了问题。

多线程wait

示例

线程过多

一个系统很多的功能，其实在运行的过程中，热点代码不是特别多的，线程过多的情况，一般是机器配置不行，解决不了大量的过来的请求导致的。

查看CPU情况，网络连接数情况，在上线之初，4核8G容纳500个并发没有问题。先看网络连接，这就是基本所有互联网大型公司都有网络监控这块，

示例

CPU100%

jcmd找到对应的进程PID。

top -H -p PID 获取到占用CPU最大的那个线程ID。

通过window计算器切换成开发者模式 将线程ID 转成16进制的数字 转换后就是 【0x数字】。

jstack 进程PID > a.log。

搜索a.log中的 nid=【0x数字】就可以定位到代码的位置了。

由于单个线程产生死循环的其实很少的，除非你使用了第三方的工具，一般使用了第三方工具的就会产生死循环，否则很难开发人员自杀式的写成直接死循环。掌握上边的使用技巧就可以了。

示例

CPU升高

CPU升高，任务处理不过来了，肯定会堆积，堆积的结果，内存也会升高，这是一个相辅相成的。不可能单独抛开一方面不去管，内存和CPU还是有关联关系的。

（二）线上处理问题

CPU

内存

网络

系统日志 tail - f /var/log/messages 很多东西都可以变成系统日志反应出来。

很多买人买的云服务器，内存比较低，可能java进程突然就消失了，其实就是linux本身有个机制，超过内存值的时候就会kill。系统内存块耗尽的时候干掉一些进程

日志文件定时的清理：log4j file，一定要定义规则什么时候删除文件。这个东西真的很致命，一旦满了，程序很容易写满。

PS：一般的生产服务器CPU稳定在80-85以内，不会让资源利用率太高，也不会太低，资源利用率很高的话，留一些剩余的空间，证明你的机器买了那么多可能就是浪费，CPU和内存都是一样的。在高并发的情况，一般都是需要提前做优化，做测试的，往往有时候大家的一些编码习惯导致的出其不意的问题。网络突然慢了，请求慢了，都可以按照这个思路来定位问题。