线上查看进程内存，CPU情况

常见问题 1：CPU 利用率高

CPU 使用率是衡量系统繁忙程度的重要指标，一般情况下单纯的 CPU 高并没有问题，它代表系统正在不断的处理我们的任务，但是如果 CPU 过高，导致任务处理不过来，从而引起 load 高，这个是非常危险需要关注的。 CPU 使用率的安全值没有一个标准值，取决于你的系统是计算密集型还是 IO 密集型，一般计算密集型应用 CPU 使用率偏高 load 偏低，IO 密集型相反。

问题原因及定位：

1 频繁 FullGC/YongGC

查看 gc 日志

jstat -gcutil pid 查看内存使用和 gc 情况

2 jstack 查找

ps -ef | grep java 找到 Java 进程 id

top -Hp pid 找到使用 CPU 最高的线程

printf ‘0x%x’ tid 线程 id 转化 16 进制

jstack pid | grep tid 找到线程堆栈

常见问题 2：load 高

load 指单位时间内活跃进程数，包含运行态（runnable 和 running）和不可中断态（ IO、内核态锁）。关键字是运行态和不可中断态，运行态可以联想到 Java 线程的 6 种状态，如下，线程 new 之后处于 NEW 状态，执行 start 进入 runnable 等待 CPU 调度，因此如果 CPU 很忙会导致 runnable 进程数增加；不可中断态主要包含网络 IO、磁盘 IO 以及内核态的锁，如 synchronized 等。

问题原因及定位：

1 iowait，等待 IO

vmstat 查看 blocked 进程状况

jstack -l pid | grep BLOCKED 查看阻塞态线程堆栈

常见问题 3：持续 FullGC

在了解 FullGC 原因之前，先花一点时间回顾下 jvm 的内存相关知识：

内存模型

新 new 的对象放在 Eden 区，当 Eden 区满之后进行一次 MinorGC，并将存活的对象放入 S0；

当下一次 Eden 区满的时候，再次进行 MinorGC，并将存活的对象和 S0 的对象放入S1（S0 和 S1 始终有一个是空的）；

依次循环直到 S0 或者 S1 快满的时候将对象放入 old 区，依次，直到 old 区满进行 FullGC。

回收器

年轻代常用 ParNew，复制算法，多线程并行；

老年代常用 CMS，标记清除算法（会产生内存碎片），并发收集(收集过程中有用户线程产生对象)。

关键常用参数

CMSInitiatingOccupancyFraction 表示老年代使用率达到多少时进行 FullGC；

UseCMSCompactAtFullCollection 表示在进行 FullGC 之后进行老年代内存整理，避免产生内存碎片。

问题原因及定位：

1 prommotion failed

从S区晋升的对象在老年代也放不下导致 FullGC（fgc 回收无效则抛 OOM）。

1）survivor 区太小，对象过早进入老年代。

jstat -gcutil pid 1000 观察内存运行情况；

jinfo pid 查看 SurvivorRatio 参数；

2）大对象分配，没有足够的内存。

日志查找关键字 “allocating large”；

profiler 查看内存概况大对象分布；

3）old 区存在大量对象。

实例数量前十的类：jmap -histo pid | sort -n -r -k 2 | head -10

实例容量前十的类：jmap -histo pid | sort -n -r -k 3 | head -10