jvm 相关的线上问题，内存使用率飙升到 90%+ 等 处理手段

首先 top 找到疑似 pid

下面介绍几个命令：

jstack、jmap、jstat

jstack能得到运行java程序的java stack和native stack的信息。可以轻松得知当前线程的运行情况。最常用的还是jstack pid

得到运行java程序的内存分配的详细情况。例如实例个数，大小等。

示例
jmap -histo pid(查看实例)

-dump:[live,]format=b,file=

生成Java虚拟机的堆转储快照dump文件。

具体说明如下：

live参数是可选的，如果指定，则只转储堆中的活动对象；

如果没有指定，则转储堆中的所有对象。

format=b表示以hprof二进制格式转储Java堆的内存。

file=<filename>用于指定快照dump文件的文件名。

这是一个比较实用的一个命令，可以观察到classloader，compiler，gc相关信息。可以时时监控资源和性能。

排查手段：

num1：[机智]

用 top 和 jmap 命令，去对线上运行的系统 jvm 进程生成一个内存 dump 快照出来，然后把 dump 快照下载到本地，

num2：[机智]

用 MAT 这个工具就可以分析这个内存快照。

在 MAT 工具中我们会看到你的 jvm 里到底是什么破对象占用了那么大的空间，才导致了你的内存使用率飙升到 90%+ 的。

num3：[机智]

这个时候其实导致内存泄漏的原因有很多种，比如说你们自己代码写的不好，就是每次请求都创建某一类对象，这类对象给扔到某个 类 的 静态 map 里一直放着，从来不回收，也没法回收，导致这类无用对象一直增长，最后导致了 oom。

其实往往是一些引用的第三方框架 里面的隐藏的功能导致的 无用对象一直增长，最后导致了 oom

创建了大量的对象，瞬间就填满了年轻代，然后这个时候触发年轻代 gc 后，发现大量的对象是没法回收的，这个时候年轻代里的大量存活对象都转移到老年代里去了，老年代里几乎也被填满了，然后此时年轻代里因为流量瞬时再次被填满，老年代都塞满了存活对象，即使触发了老年代 gc 也没法回收他们，年轻代也没地方放这些存活对象了，

可能会收到报警说 jvm 年轻代和老年代内存使用率都超过了 90%。

比如：

dubbo 没用好导致的 dubbo 框架不停的创建出来大量的对象，占用了 90% 的内存，最后导致了内存溢出。

设置好对外提供的 dubbo protocol 协议，避免上面那种因为 protocol 协议没设置导致创建了大量的无用对象没法回收。