一、JVM空间说明
在JDK1.7及以前，HotSpot虚拟机将java类信息、常量池、静态变量、即时编译器编译后的代码等数据，存储在Perm（永久带）里（对于其他虚拟机如BEA JRockit、IBM J9等是不存在永久带概念的），类的元数据和静态变量在类加载的时候被分配到Perm里，当常量池回收或者类被卸载的时候，垃圾收集器会回收这一部分内存，但效果不太理想。
JDK1.8时，HotSpot虚拟机对JVM模型进行了改造，将类元数据放到了本地内存中，将常量池和静态变量放到了Java堆里，HotSpot VM 将会为类的元数据明确的分配与释放本地内存。
在这种架构下，类元数据就突破了-XX:MaxPermSize的限制，所以此配置已经失效，现在可以使用更多的本地内存。这样一定程度上解决了原来在运行时生成大量的类，从而经常Full GC的问题——如运行时使用反射、代理等。
总结：可以发现最明显的一个变化是元数据空间从虚拟机转移到了本地内存。
默认情况下，元数据空间大小仅受限于本地内存， 这意味着以后不会因为永久代大小不够而抛出OOM异常了。
JDK1.8以前，HotSpot VM将class和类的jar包数据存储在PermGen里， PermGen大小是固定的，而且项目之间无法公用公有的class，所以很容易碰到OOM异常。
改成MateSpace后， 各个项目会共享同样的class空间。比如多个项目都引用了apache-common包， 在MateSpace中只会存储一份的apache-common的class，提高了内存的利用率，垃圾回收更有效。
二、GC（Garbage Collection）算法
在JVM里的内存空间，从大的层面划分，主要有新生代空间（Young）和老年代空间（Old），其中Young空间，又被分为2个部分和3个板块，分别是1个Egen区，和2个Survivor区，看下图：
OK,下面来具体看下，每部分都是干啥的
（1）Eden区域是用来存放使用new或者newInstance等方式创建的对象，默认都是存放在Eden区，除非这个对象太大，或者超过了设定的阈值-XX:PretenureSizeThresold,这样的对象会被直接分配到Old区域。
（2）2个Survivor（幸存）区，一般称S0，S1，理论上他们是一样大的，解释一下，他们是如何工作的：
<1> 在不断创建对象的过程中，Eden区会满，这时候会开始做Young G也叫Minor GC。过程：找出Eden区中，幸存活着的对象，然后将这些对象，放到S0，或S1区中的其中一个， 假设第一次选择了S0，它会逐步将活着的对象拷贝到S0区域，但是如果S0区域满了，剩下活着的对象只能放old区域了，然后将Eden区域 清空，此时S1区域是空的。
<2> 当第二次Eden区域满的时候，就将Eden区域中活着的对象 + S0区域中活着的对象，迁移到S1中，如果S1放不下，就会将剩下的部分，放到Old区域中，只是这次对象来源区域增加了S0，最后会将Eden区+S0区域，清空。
<3> 第三次和第四次依次类推，始终保证S0和S1有一个是空的，用来存储临时对象，用于交换空间的目的。除了放不下放到old区域的，反复多次没有被淘汰的对象，将会放入old区域中，默认是15次。具体的交换过程就和上图中的信息相似。
<4> 直到Old区也快满的时候，Eden区也快满的时候，会对整个这一块内存区域进行一次大清洗（FullGC），腾出内存，为之后的对象创建，程序运行腾地方。
注：
新生代GC（Minor GC）:指发生在新生代的垃圾回收动作，因为java对象大多具备朝生夕灭的特征，所以Minor GC发生的特别频繁， 一般回收速度也很快。 老年代GC（Major GC/Full GC）:指发生在老年代的GC，出现了Major GC，至少会伴随一次的MinorGC（但非绝对， 在Parallel Scavenge收集器的收集策略里就有直接进行Minor GC的策略选择过程）。Major GC的速度一般比Minor GC慢。
三、JVM参数配置
在jdk1.8以前，生产环境一般有如下配置
-XX:PermSize=512M -XX:MaxPermSize=1024M
表示在JVM里存储Java类信息，常量池和静态变量的永久代区域初始大小为512M，最大为1024M。在项目启动后，这个值是固定的，如果项目class过多，很可能遇到OutOfMemoryError: PermGen异常。
-XX:MetaspaceSize=512M XX:MaxMetaspaceSize=1024M
MetaspaceSize如果不做配置，通过jinfo查看默认MetaspaceSize大小（约21M）,MaxMetaspaceSize很大很大，前面说过MetaSpace只受本地内存大小限制。
jinfo -flag MetaspaceSize 1234 #结果为：-XX:MetaspaceSize=21807104
jinfo -flag MaxMetaspaceSize 1234 #结果为：-XX:MaxMetaspaceSize=18446744073709547520
总结： MetaspaceSize为触发FullGC的阈值，默认约为21M，如做了配置，最小阈值为自定义配置大小。空间使用达到阈值，触发FullGC，同时对该值扩大。当然如果元空间实际使用小于阈值，在GC的时候也会对该值缩小。
MaxMetaspaceSize为元空间的最大值，如果设置太小，可能会导致频繁FullGC，甚至OOM。
四. JVM参数配置指南
前面三个部分对JVM进行了整体的了解，接下来是本文的重点。
-XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256M -Xms256m -Xmx256m
文章看下来上面这段配置的意思很简单，设置元空间的初始值和最大值，设置堆空间的初始值和最大值。
为什么MetaspaceSize要设置为128M？为什么堆内存初始值Xms设置为256M而不是512M？
按照Java官方的指导
Java堆大小设置，Xms 和 Xmx设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍
- MaxPermSize(元空间)设置为老年代存活对象的1.2-1.5倍。
- 年轻代Xmn的设置为老年代存活对象的1-1.5倍。
- 老年代的内存大小设置为老年代存活对象的2-3倍。
可以让系统运行一段时间后查看系统的各个指标，然后在进行配置。如下用jstat工具查看jvm的情况：
jstat -gc 12345
###
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
13824.0 22528.0 13377.0 0.0 548864.0 535257.2 113152.0 46189.3 73984.0 71119.8 9728.0 9196.2 14 0.259 3 0.287 0.546
OU表示老年代所占用的内存为 46189.3 K（大约45M）；那么jvm相应的配置参数应该做如下修改：
堆内存是老年代的3~4倍：45*3=135，45*4=180
元数据空间是老年代的1.2~1.5倍：45*1.2=54，45*1.5=67.5
配置如下：
-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M -Xms180m -Xmx180m