PermSize&MetaspaceSize区别

前言

一位阿里小伙伴谢照东:xiezhaodong.me大神在群里提出一个问题：怎么查看Metaspace里具体包含的是什么类？起因是他的某个服务设置了-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m，但是通过jstat -gcutil pid查看M的值为98（M的=MU/MC），即Metaspace区的使用量达到了512m*98%。遗憾的是，这个推算是错误的。本文不是要讲解如何查看Metaspace里具体包含的是什么类（因为我也知道怎么查看，哈），而是说说从JDK7的PermSize到JDK8的MetaspaceSize的区别。

JDK7的PermSize

JDK7以及之前的JDK版本，我们通过配置JVM参数-XX:PermSize来控制这块内存的初始容量，配置-XX:MaxPermSize控制最大容量。JVM在启动的时候会根据-XX:PermSize初始化分配一块连续的内存块，这样的话，如果-XX:PermSize设置过大，就是一种非常赤果果的浪费，例如设置-XX:PermSize=64m -XX:MaxPermSize=64m，那么PC（Perm Capacity）就是64M，即JVM一启动就会占用64M内存：

JDK7 PC&PU By afei

在笔者一台1G内存的阿里云服务器上运行一个简单的程序，如果设置-XX:PermSize=1024m，那么JVM都无法初始化，JVM参数如下：

/opt/jdk1.7.0_80/bin/java -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCDetails -Xmx32m -Xms32m -Xmn16m  -XX:PermSize=1024m  -XX:+AlwaysPreTouch  StringTest

报的错误信息如下--不能分配足够的内存：

[afei@afei myjava]$ /opt/jdk1.7.0_80/bin/java -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCDetails -Xmx32m -Xms32m -Xmn16m  -XX:PermSize=1024m  -XX:+AlwaysPreTouch  StringTest
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000c0000000, 1073741824, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 1073741824 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /home/afei/myjava/hs_err_pid31121.log

如果设置-XX:PermSize=512m，能够正常运行，且这个Java进程占用内存超过500M。

JDK8的MetaspaceSize

JDK8以后的版本，移除了Perm，引入了Metapsace，那么Metaspace相比Perm有什么优点呢？还是来做一些简单的测试。

以笔者测试环境上某个服务为例，配置了-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m，通过jstat -gcutil pid查看M的值为98.32，即Metaspace的使用率也达到了98.32%：

JDK8 Metaspace By afei

但是，再通过jstat -gc 4210 2s 3命令查看，通过MU/MC计算Metaspace的使用率确实达到了98.32%。但是MC即Metaspace Capacity只有55296k，并不是参数MetaspaceSize指定的256M：

JDK8 MC&MU By afei

然后再在笔者一台1G内存的阿里云服务器上运行同一个简单的程序，这次设置-XX:MetaspaceSize=1024m，Java进程却能正常启动并运行良好，JVM参数如下：

/opt/jdk1.8.0_131/bin/java -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCDetails -Xmx32m -Xms32m -Xmn16m  -XX:MetaspaceSize=1024m  -XX:+AlwaysPreTouch  StringTest

总结

JDK8中无论-XX:MetaspaceSize和-XX:MaxMetaspaceSize两个参数如何设置，随着类加载越来越多不断扩容调整，直到MetaspaceSize（如果没有配置就是默认值20.8m，可以通过命令java -XX:+PrintFlagsFinal -version |grep MetaspaceSize查看）触发FGC（如果Old区配置CMS，那么触发的就是CMS GC），上限是-XX:MaxMetaspaceSize，如果使用量达到这个参数的值，就会触发Full GC。

那么-XX:MetaspaceSize=256m这个参数的含义到底是什么呢？其实，这个JVM参数是指Metaspace扩容时触发FGC的初始化阈值，对于这个参数有几个要点需要了解：

1. 如果没有配置参数-XX:MetaspaceSize，那么触发FGC的阈值就是21807104（约20.8M）；

2. 如果配置了参数-XX:MetaspaceSize=256m，那么触发FGC的阈值就是配置的值256M；

3. Metaspace由于使用不断扩容到-XX:MetaspaceSize参数指定的量，就会发生FGC；且之后每次Metaspace扩容可能发生FGC；

4. 如果Old区配置CMS垃圾回收，那么扩容引起的FGC也会使用CMS算法进行回收；

5. 如果MaxMetaspaceSize设置太小，可能会导致频繁FGC，甚至OOM；

建议

1. MetaspaceSize和MaxMetaspaceSize设置一样大；

2. 具体设置多大，建议在压测环境稳定运行一段时间后通过jstat -gc pid确认这个值并设置稍微大一些即可（对于大部分项目256m即可）。

验证配置CMS前提下，达到MetaspaceSize但是还没有达到MaxMetaspaceSize，触发的是CMS GC

笔者的环境，服务启动后，MU的值稳定在55M左右，那么如果设置JVM参数-XX:MetaspaceSize=50m -XX:MaxMetaspaceSize=128m按照上面的推理，会发生一次CMS GC，事实也确实如此，部分gc日志如下所示（让人哭笑不得的是，Metaspace引起的CMS GC，但是GC日志中却没有Metaspace使用情况相关信息）：

... ...
14.841: [GC (CMS Initial Mark) [1 CMS-initial-mark: 58004K(131072K)] 70447K(249088K), 0.0055264 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
14.847: [CMS-concurrent-mark-start]
14.931: [CMS-concurrent-mark: 0.084/0.084 secs] [Times: user=0.20 sys=0.01, real=0.09 secs] 
14.931: [CMS-concurrent-preclean-start]
14.933: [CMS-concurrent-preclean: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
14.933: [CMS-concurrent-abortable-preclean-start]
15.378: [CMS-concurrent-abortable-preclean: 0.434/0.445 secs] [Times: user=1.47 sys=0.01, real=0.45 secs] 
15.379: [GC (CMS Final Remark) [YG occupancy: 69119 K (118016 K)]2018-03-20T11:28:37.249+0800: 15.379: [GC (CMS Final Remark) 2018-03-20T11:28:37.249+0800: 15.379: [ParNew: 69119K->5190K(118016K), 0.0214183 secs] 127124K->66735K(249088K), 0.0216553 secs] [Times: user=0.06 sys=0.00, real=0.02 secs] 
15.444: [CMS-concurrent-sweep-start]
15.479: [CMS-concurrent-sweep: 0.035/0.035 secs] [Times: user=0.14 sys=0.00, real=0.04 secs] 
15.479: [CMS-concurrent-reset-start]
15.483: [CMS-concurrent-reset: 0.004/0.004 secs] [Times: user=0.01 sys=0.01, real=0.00 secs]
... ...

通过14.841: [GC (CMS Initial Mark) [1 CMS-initial-mark: 58004K(131072K)] 70447K(249088K), 0.0055264 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]这行日志可知：Old区还远远达不到70%（-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70）触发CMS GC的条件。所以，这次CMS GC是Metaspace区扩容达到-XX:MetaspaceSize=50m触发的。

---

如果读完觉得有收获的话，请点赞并关注公众号【阿飞Javaer】，多谢！