英协网
前言
昨天谢照东大神在群里提出一个问题：怎么查看Metaspace里具体包含的是什么，起因是他的某个服务设置了-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m，但是通过jstat -gcutil pid查看M的值为98（M的=MU/MC），即Metaspace区的使用量达到了512m*98%。遗憾的是，这个推算是错误的；
推理
以笔者测试环境上某个服务为例，配置了-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m，通过jstat -gcutil pid查看M的值为98.32，即Meta区使用率也达到了98.32%：
JDK8 Metaspace By afei
然后，再通过jstat -gc 4210 2s 3命名查看，结果如下图所示，计算MU/MC即Meta区的使用率确实达到了98.32%，但是MC，即Metaspace Capacity只有55296k，并不是参数MetaspaceSize指定的256m：
JDK8 MC&MU By afei
那么-XX:MetaspaceSize=256m的含义到底是什么呢？其实，这个JVM参数是指Metaspace扩容时触发FullGC的初始化阈值，也是最小的阈值。这里有几个要点需要明确：
- 如果没有配置-XX:MetaspaceSize，那么触发FGC的阈值是21807104（约20.8m），可以通过jinfo -flag MetaspaceSize pid得到这个值；
- 如果配置了-XX:MetaspaceSize，那么触发FGC的阈值就是配置的值；
- Metaspace由于使用不断扩容到-XX:MetaspaceSize参数指定的量，就会发生FGC；且之后每次Metaspace扩容都可能会发生FGC（至于什么时候会，比较复杂，跟几个参数有关）；
- 如果Old区配置CMS垃圾回收，那么扩容引起的FGC也会使用CMS算法进行回收；
- 如果MaxMetaspaceSize设置太小，可能会导致频繁FullGC，甚至OOM；
任何一个JVM参数的默认值可以通过java -XX:+PrintFlagsFinal -version |grep JVMParamName获取，例如：java -XX:+PrintFlagsFinal -version |grep MetaspaceSize
验证
笔者的环境，服务启动后，MU的值稳定在55296k，那么设置-XX:MetaspaceSize=50m -XX:MaxMetaspaceSize=256m，按照上面的推理，会发生一次CMS GC，事实也确实如此，部分gc日志如下所示：
通过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触发的。
建议
- MetaspaceSize和MaxMetaspaceSize设置一样大；
- 具体设置多大，建议稳定运行一段时间后通过jstat -gc pid确认且这个值大一些，对于大部分项目256m即可。
JDK7的PermSize
JDK8+移除了Perm，引入了Metapsace，它们两者的区别是什么呢？Metasace上面已经总结了，无论-XX:MetaspaceSize和-XX:MaxMetaspaceSize两个参数如何设置，随着类加载越来越多不断扩容调整，直到MetaspaceSize(如果没有配置就是默认20.8m)触发FGC，上限是-XX:MaxMetaspaceSize，默认是几乎无穷大。而Perm的话，我们通过配置-XX:PermSize以及-XX:MaxPermSize来控制这块内存的大小，jvm在启动的时候会根据-XX:PermSize初始化分配一块连续的内存块，这样的话，如果-XX:PermSize设置过大，就是一种赤果果的浪费。很明显，Metapsace比Perm好多了^^；
JDK7 Perm 验证如下–设置-XX:PermSize=64m -XX:MaxPermSize=64m，那么PC初始化就是64m：
JDK7 PC&PU By afei
