JVM内存机制与常见问题排查

Java内存模型：Java Memory Model，简称JMM。整体上，JVM内存包含堆内存和线程栈内存，原始数据类型和对象引用在栈内存上，对象(及其成员变量)、静态变量都在堆内存上。堆内存上的所有对象，可以被所有线程拿到，属于共享区域。大部分时候，我们处理的都是堆内存上的问题。

JVM的GC（垃圾回收）采用分代机制，即堆内存分为年轻代、老年代，年轻代里面继续分三块：新生代（Eden-Space）、两个存活区（S0、S1）。GC的大致过程是：创建对象时会在Eden区分配内存，GC的时Eden区和S区(S0和S1中非空的那个)中存活的对象复制到另外一个空的S区。S0和S1在任何时候都有一个空区域专门存储被年轻代GC后仍然存活的对象，这批对象在S0和S1中来回复制多次，最终达到一定存活时间的对象，被移到老年代。

在默认情况下，Eden:S0:S1的内存分配比例是：8:1:1。之所以来回复制，主要是为了解决GC后的内存碎片问题。

JVM采用的GC算法是：标记清除算法（Mark and Sweep）。

1. 标记：会遍历所有可达对象，这个阶段会让所有应用程序的线程暂停，导致STW停顿问题（Stop The
   World）；
2. 清除：不可达对象占用的内存被回收，以便重用；

JVM调优，很大程度上是GC的调优，下面我们先看看GC相关的知识点。为了方便后面做演示，我们新建一个Java工程（过程略）。

我们可以先来一段耗内存的代码：

List<Order> orderList=new ArrayList<>();
   while(true){
   Order order=new Order();
   order.setId(1);
   order.setName("Java In Action");
   order.setPrice(20.5);
   orderList.add(order);
   System.out.println( "Hello World!"+order);
  }

工程建议加上以下依赖，演示的时候会达成jar包，并用命令行执行：

<plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifest>
              <mainClass>com.learn.performance.MainApp</mainClass>
            </manifest>
          </archive>
        </configuration>
      </plugin>
    </plugins>

打包之后，在Linux上启动运行，笔者这里采用CentOS。下面我们看看怎么查看GC信息。

首先使用jps查看当前进程ID：

然后使用jstat查看GC情况：

jstat -gcutil 进程ID 间隔时间

解释：

S0: 新生代中Survivor space 0区已使用空间的百分比

S1: 新生代中Survivor space 1区已使用空间的百分比

E: 新生代已使用空间的百分比

O: 老年代已使用空间的百分比

M: 永久带已使用空间的百分比

YGC: 从应用程序启动到当前，发生Yang GC 的次数

YGCT: 从应用程序启动到当前，Yang GC所用的时间

FGC: 从应用程序启动到当前，发生Full GC的次数

FGCT: 从应用程序启动到当前，Full GC所用的时间

GCT: 从应用程序启动到当前，用于垃圾回收的总时间

当E和O区占比一直偏大，GC频繁时，就要开始注意系统的内存问题了。前面我们也提到过，GC时，会导致系统卡顿（STW），此时就必须要考虑调优了。

使用jstat查看GC，很多时候是为了线上快速定位问题。而在实际场景中，我们通常会考虑在整个运行阶段都将GC信息打到日志里面，等到出问题后，可以让运维拉日志排查问题。

要实现这个效果，需要新增启动命令-XX:+PrintGCDetails，它可以帮助打印GC细节，然后通过-Xloggc指定GC日志的输出文件。其中%p是进程ID的占位符：

java -XX:+PrintGCDetails -Xloggc:log/gc_%p.log  -jar PerformanceDemo-1.0.jar

这样，最终会在log目录下生成gc_[进程ID].log文件。在GC文件里面，大家可以看到一些默认的配置，比如初始化堆内存、最大堆内存、GC算法（UseParallelGC）假如想知道GC发生的时间，还可以加上-XX:+PrintGCDateStamps参数。

在实际场景中，我们会在启动时指定内存参数，比如：

java -Xmn80m -Xms200m -Xmx200m  -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -Xloggc:log/gc_%p.log  -jar PerformanceDemo-1.0.jar

解释:

• -Xmn 设置年轻代大小
• -Xms 设置初始内存，此值可以和-Xmx一样
• -Xmx 设置JVM最大可用内存

启动后，我们可以使用jmap命令查看内存使用情况：

jmap -heap 进程id

一旦发现堆内存占用比过大时，我们就需要搞清楚到底是哪些对象导致的，此时可以继续使用jmap命令来查看存活对象数量和大小：

jmap -histo:live 进程ID > jmapinfo

此时会把存活对象信息打到jmapinfo这个文件里面，我们可以打开文件看下：

可以很明显看出，我们自定义的Order对象是最多的（Double作为Order的属性之一）。这实际上就是调优的依据之一。

当系统真正出现OOM的时候，可能就直接挂了，这个时候我们是没办法使用jmap命令的，那怎么办呢？在生产环境中，我们通常会做OOM后生产内存dump文件的配置，新增的命令参数如下：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=log/heapdump.hprof

此时一旦OOM，会自动将当时的内存信息打到heapdump.hprof文件中，我们可以下载到本地，使用JDK自带的jvisualvm工具打开查看，效果如下：