先用一个能够发生OOM的程序模拟一下：

/**
 * -Xms60m -Xmx60m -XX:SurvivorRatio=8
 */
public class GCTest {
    public static void main(String[] args) {
        ArrayList<byte[]> list = new ArrayList<>();
        for (int i = 0; i < 1000; i++) {
            byte[] arr = new byte[1024 * 100];//100KB
            list.add(arr);
            try {
                Thread.sleep(120);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

GC启动参数设置为：-Xms60m -Xmx60m -XX:SurvivorRatio=8

一、排查OOM

我们可以比较Java进程的启动时间以及总 GC 时间(GCT 列)，或者两次测量的间隔时间以及总GC时间的增量，来得出GC时间占运行时间的比例。

如果该比例超过20%，则说明目前堆的压力较大;如果该比例超过90%，则说明堆里几乎没有可用空间，随时都可能抛出OOM异常。

我们执行jstat -gc -t 18168 1000 10，这代表1秒打印出1行，一共10行，-t代表打印出Timestamp总运行时间，结果如下所示：

上方红色方框中代表Timestamp，而蓝色方框中代表垃圾回收时间，单位都是秒，如果让红色框框中的某两个值相减，假设这个值是num1，然后让对应行的蓝色框框中的另外两个值相减，假设这个值是num2，之后让num2/num1，得出的差值就是上述所说的GC时间占运行时间的比例。

虽然这种方式比较繁琐，但是在项目部署之后就需要使用命令行去看了，就没有可视化界面了，所以这种方式也要会 。

二、排查内存泄漏

jstat还可以用来判断是否出现内存泄漏。

步骤：

1、在长时间运行的 Java程序中，我们可以运行jstat命令连续获取多行性能数据，并取这几行数据中OU列（即已占用的老年代内存）的最小值。

2、我们每隔一段较长的时间重复一次上述操作，来获得多组OU最小值。如果这些值呈上涨趋势，则说明该Java程序的老年代内存已使用量在不断上涨，这意味着无法回收的对象在不断增加，因此很有可能存在内存泄漏。|