Java 8的元空间（metaspace）
很多开发者都在其系统中见过“java.lang.OutOfMemoryError:PermGenspace”这一问题。这往往是由类加载器相关的内存泄漏以及新类加载器的创建导致的，通常出现于代码热部署时。相对于正式产品，该问题在开发机上出现的频率更高，在产品中最常见的“问题”是默认值太低了。常用的解决方法是将其设置为256MB或更高。
持久代
PermGenspace的全称是Permanent Generationspace,是指内存的永久保存区域，说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGenspace区域，它和和存放Instance的Heap区域不同,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGenspace错误。这种错误常见在web服务器对JSP进行pre compile的时候。
JVM种类有很多，比如 Oralce-Sun Hotspot, Oralce JRockit, IBM J9, TaobaoJVM（淘宝好样的！）等等。当然武林盟主是Hotspot了，这个毫无争议。需要注意的是，PermGen space是Oracle-Sun Hotspot才有，JRockit以及J9是没有这个区域。
持久代中包含了虚拟机中所有可通过反射获取到的数据，比如Class和Method对象。不同的Java虚拟机之间可能会进行类共享，因此持久代又分为只读区和读写区。
JVM用于描述应用程序中用到的类和方法的元数据也存储在持久代中。JVM运行时会用到多少持久代的空间取决于应用程序用到了多少类。除此之外，Java SE库中的类和方法也都存储在这里。
如果JVM发现有的类已经不再需要了，它会去回收（卸载）这些类，将它们的空间释放出来给其它类使用。Full GC会进行持久代的回收。
- JVM中类的元数据在Java堆中的存储区域。
- Java类对应的HotSpot虚拟机中的内部表示也存储在这里。
- 类的层级信息，字段，名字。
- 方法的编译信息及字节码。
- 变量
- 常量池和符号解析
持久代的大小
- 它的上限是MaxPermSize，默认是64M
- Java堆中的连续区域 : 如果存储在非连续的堆空间中的话，要定位出持久代到新对象的引用非常复杂并且耗时。卡表（card table），是一种记忆集（Remembered Set），它用来记录某个内存代中普通对象指针（oops）的修改。
- 持久代用完后，会抛出OutOfMemoryError "PermGen space"异常。解决方案：应用程序清理引用来触发类卸载；增加MaxPermSize的大小。
- 需要多大的持久代空间取决于类的数量，方法的大小，以及常量池的大小。
为什么移除持久代
- 它的大小是在启动时固定好的——很难进行调优。-XX:MaxPermSize，设置成多少好呢？
- HotSpot的内部类型也是Java对象：它可能会在Full GC中被移动，同时它对应用不透明，且是非强类型的，难以跟踪调试，还需要存储元数据的元数据信息（meta-metadata）。
- 简化Full GC：每一个回收器有专门的元数据迭代器。
- 可以在GC不进行暂停的情况下并发地释放类数据。
- 使得原来受限于持久代的一些改进未来有可能实现
那么JVM的元数据都去哪儿了？
元空间(metaspace)
持久代的空间被彻底地删除了，它被一个叫元空间的区域所替代了。持久代删除了之后，很明显，JVM会忽略PermSize和MaxPermSize这两个参数，还有就是你再也看不到java.lang.OutOfMemoryError: PermGen error的异常了。
JDK 8的HotSpot JVM现在使用的是本地内存来表示类的元数据，这个区域就叫做元空间。
元空间的特点：
- 充分利用了Java语言规范中的好处：类及相关的元数据的生命周期与类加载器的一致。
- 每个加载器有专门的存储空间
- 只进行线性分配
- 不会单独回收某个类
- 省掉了GC扫描及压缩的时间
- 元空间里的对象的位置是固定的
- 如果GC发现某个类加载器不再存活了，会把相关的空间整个回收掉
元空间的内存分配模型
- 绝大多数的类元数据的空间都从本地内存中分配
- 用来描述类元数据的类也被删除了
- 分元数据分配了多个虚拟内存空间
- 给每个类加载器分配一个内存块的列表。块的大小取决于类加载器的类型; sun/反射/代理对应的类加载器的块会小一些
- 归还内存块，释放内存块列表
- 一旦元空间的数据被清空了，虚拟内存的空间会被回收掉
- 减少碎片的策略
我们来看下JVM是如何给元数据分配虚拟内存的空间的
你可以看到虚拟内存空间是如何分配的(vs1,vs2,vs3) ，以及类加载器的内存块是如何分配的。CL是Class Loader的缩写。
理解_mark和_klass指针
要想理解下面这张图，你得搞清楚这些指针都是什么东西。
JVM中，每个对象都有一个指向它自身类的指针，不过这个指针只是指向具体的实现类，而不是接口或者抽象类。
对于32位的JVM:
_mark : 4字节常量
_klass: 指向类的4字节指针对象的内存布局中的第二个字段( _klass，在32位JVM中，相对对象在内存中的位置的偏移量是4，64位的是8)指向的是内存中对象的类定义。
64位的JVM：
_mark : 8字节常量
_klass: 指向类的8字节的指针
开启了指针压缩的64位JVM： _mark : 8字节常量
_klass: 指向类的4字节的指针
Java对象的内存布局
类指针压缩空间（Compressed Class Pointer Space）
只有是64位平台上启用了类指针压缩才会存在这个区域。对于64位平台，为了压缩JVM对象中的_klass指针的大小，引入了类指针压缩空间（Compressed Class Pointer Space）。
压缩指针后的内存布局
指针压缩概要
- 64位平台上默认打开
- 使用-XX:+UseCompressedOops压缩对象指针 "oops"指的是普通对象指针("ordinary" object pointers)。 Java堆中对象指针会被压缩成32位。 使用堆基地址（如果堆在低26G内存中的话，基地址为0）
- 使用-XX:+UseCompressedClassPointers选项来压缩类指针
- 对象中指向类元数据的指针会被压缩成32位
- 类指针压缩空间会有一个基地址
元空间和类指针压缩空间的区别
- 类指针压缩空间只包含类的元数据，比如InstanceKlass, ArrayKlass 仅当打开了UseCompressedClassPointers选项才生效 为了提高性能，Java中的虚方法表也存放到这里 这里到底存放哪些元数据的类型，目前仍在减少
- 元空间包含类的其它比较大的元数据，比如方法，字节码，常量池等。
元空间的调优
使用-XX:MaxMetaspaceSize参数可以设置元空间的最大值，默认是没有上限的，也就是说你的系统内存上限是多少它就是多少。-XX:MetaspaceSize选项指定的是元空间的初始大小，如果没有指定的话，元空间会根据应用程序运行时的需要动态地调整大小。
MaxMetaspaceSize的调优
- -XX:MaxMetaspaceSize={unlimited}
- 元空间的大小受限于你机器的内存
- 限制类的元数据使用的内存大小，以免出现虚拟内存切换以及本地内存分配失败。如果怀疑有类加载器出现泄露，应当使用这个参数；32位机器上，如果地址空间可能会被耗尽，也应当设置这个参数。
- 元空间的初始大小是21M——这是GC的初始的高水位线，超过这个大小会进行Full GC来进行类的回收。
- 如果启动后GC过于频繁，请将该值设置得大一些
- 可以设置成和持久代一样的大小，以便推迟GC的执行时间
CompressedClassSpaceSize的调优
- 只有当-XX:+UseCompressedClassPointers开启了才有效
- -XX:CompressedClassSpaceSize=1G
- 由于这个大小在启动的时候就固定了的，因此最好设置得大点。
- 没有使用到的话不要进行设置
- JVM后续可能会让这个区可以动态的增长。不需要是连续的区域，只要从基地址可达就行；可能会将更多的类元信息放回到元空间中；未来会基于PredictedLoadedClassCount的值来自动的设置该空间的大小
元空间的一些工具
- jmap -permstat改成了jmap -clstats。它用来打印Java堆的类加载器的统计数据。对每一个类加载器，会输出它的名字，是否存活，地址，父类加载器，以及它已经加载的类的数量及大小。除此之外，驻留的字符串（intern）的数量及大小也会打印出来。
- jstat -gc，这个命令输出的是元空间的信息而非持久代的
- jcmd GC.class_stats提供类元数据大小的详细信息。使用这个功能启动程序时需要加上-XX:+UnlockDiagnosticVMOptions选项。
提高GC的性能
如果你理解了元空间的概念，很容易发现GC的性能得到了提升。
- Full GC中，元数据指向元数据的那些指针都不用再扫描了。很多复杂的元数据扫描的代码（尤其是CMS里面的那些）都删除了。
- 元空间只有少量的指针指向Java堆。这包括：类的元数据中指向java/lang/Class实例的指针;数组类的元数据中，指向java/lang/Class集合的指针。
- 没有元数据压缩的开销
- 减少了根对象的扫描（不再扫描虚拟机里面的已加载类的字典以及其它的内部哈希表）
- 减少了Full GC的时间
- G1回收器中，并发标记阶段完成后可以进行类的卸载
java8中metaspace总结如下：
PermGen空间的状况
这部分内存空间将全部移除。
JVM的参数：PermSize和 MaxPermSize 会被忽略并给出警告（如果在启用时设置了这两个参数）。
Metaspace内存分配模型
大部分类元数据都在本地内存中分配。
用于描述类元数据的“klasses”已经被移除。
Metaspace容量
默认情况下，类元数据只受可用的本地内存限制（容量取决于是32位或是64位操作系统的可用虚拟内存大小）。
新参数（MaxMetaspaceSize）用于限制本地内存分配给类元数据的大小。如果没有指定这个参数，元空间会在运行时根据需要动态调整。
Metaspace垃圾回收
对于僵死的类及类加载器的垃圾回收将在元数据使用达到“MaxMetaspaceSize”参数的设定值时进行。
适时地监控和调整元空间对于减小垃圾回收频率和减少延时是很有必要的。持续的元空间垃圾回收说明，可能存在类、类加载器导致的内存泄漏或是大小设置不合适。
Java堆内存的影响
一些杂项数据已经移到Java堆空间中。升级到JDK8之后，会发现Java堆空间有所增长。
Metaspace监控
元空间的使用情况可以从HotSpot1.8的详细GC日志输出中得到。
Jstat和 JVisualVM两个工具，在使用b75版本进行测试时，已经更新了，但是还是能看到老的PermGen空间的出现。
前面已经从理论上充分说明，下面让我们通过“泄漏”程序进行新内存空间的观察……
PermGenvs. Metaspace 运行时比较
为了更好地理解Metaspace内存空间的运行时行为，
将进行以下几种场景的测试：
- 使用JDK1.7运行Java程序，监控并耗尽默认设定的85MB大小的PermGen内存空间。
- 使用JDK1.8运行Java程序，监控新Metaspace内存空间的动态增长和垃圾回收过程。
- 使用JDK1.8运行Java程序，模拟耗尽通过“MaxMetaspaceSize”参数设定的128MB大小的Metaspace内存空间。
首先建立了一个模拟PermGenOOM的代码
- public class ClassA {
- public void method(String name) {
- // do nothing
- }
- }
上面是一个简单的ClassA，把他编译成class字节码放到D：/classes下面，测试代码中用URLClassLoader来加载此类型上面类编译成class
- /**
- * 模拟PermGen OOM
- * @author benhail
- */
- public class OOMTest {
- public static void main(String[] args) {
- try {
- //准备url
- URL url = new File("D:/classes").toURI().toURL();
- URL[] urls = {url};
- //获取有关类型加载的JMX接口
- ClassLoadingMXBean loadingBean = ManagementFactory.getClassLoadingMXBean();
- //用于缓存类加载器
- List
classLoaders = new ArrayList(); - while (true) {
- //加载类型并缓存类加载器实例
- ClassLoader classLoader = new URLClassLoader(urls);
- classLoaders.add(classLoader);
- classLoader.loadClass("ClassA");
- //显示数量信息（共加载过的类型数目，当前还有效的类型数目，已经被卸载的类型数目）
- System.out.println("total: " + loadingBean.getTotalLoadedClassCount());
- System.out.println("active: " + loadingBean.getLoadedClassCount());
- System.out.println("unloaded: " + loadingBean.getUnloadedClassCount());
- }
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }
虚拟机器参数设置如下：-verbose -verbose:gc
设置-verbose参数是为了获取类型加载和卸载的信息
设置-verbose:gc是为了获取垃圾收集的相关信息
JDK1.7 @64-bit – PermGen 耗尽测试
Java1.7的PermGen默认空间为85MB（或者可以通过-XX:MaxPermSize=XXXm指定）
可以从上面的JVisualVM的截图看出：当加载超过6万个类之后，PermGen被耗尽。我们也能通过程序和GC的输出观察耗尽的过程。
程序输出(摘取了部分)
- ......
- [Loaded ClassA from file:/D:/classes/]
- total: 64887
- active: 64887
- unloaded: 0
- [GC 245041K->213978K(536768K), 0.0597188 secs]
- [Full GC 213978K->211425K(644992K), 0.6456638 secs]
- [GC 211425K->211425K(656448K), 0.0086696 secs]
- [Full GC 211425K->211411K(731008K), 0.6924754 secs]
- [GC 211411K->211411K(726528K), 0.0088992 secs]
- ...............
- java.lang.OutOfMemoryError: PermGen space
JDK1.8 @64-bit – Metaspace大小动态调整测试
Java的Metaspace空间：不受限制（默认）
从上面的截图可以看到，JVMMetaspace进行了动态扩展，本地内存的使用由20MB增长到646MB，以满足程序中不断增长的类数据内存占用需求。我们也能观察到JVM的垃圾回收事件—试图销毁僵死的类或类加载器对象。但是，由于我们程序的泄漏，JVM别无选择只能动态扩展Metaspace内存空间。程序加载超过10万个类，而没有出现OOM事件。
JDK1.8 @64-bit – Metaspace 受限测试
Java的Metaspace空间：128MB（-XX:MaxMetaspaceSize=128m）
可以从上面的JVisualVM的截图看出：当加载超过2万个类之后，Metaspace被耗尽；与JDK1.7运行时非常相似。我们也能通过程序和GC的输出观察耗尽的过程。另一个有趣的现象是，保留的原生内存占用量是设定的最大大小两倍之多。这可能表明，如果可能的话，可微调元空间容量大小策略，来避免本地内存的浪费。
从Java程序的输出中看到如下异常。
- [Loaded ClassA from file:/D:/classes/]
- total: 21393
- active: 21393
- unloaded: 0
- [GC (Metadata GC Threshold) 64306K->57010K(111616K), 0.0145502 secs]
- [Full GC (Metadata GC Threshold) 57010K->56810K(122368K), 0.1068084 secs]
- java.lang.OutOfMemoryError: Metaspace
在设置了MaxMetaspaceSize的情况下，该空间的内存仍然会耗尽，进而引发“java.lang.OutOfMemoryError:Metadataspace”错误。因为类加载器的泄漏仍然存在，而通常Java又不希望无限制地消耗本机内存，因此设置一个类似于MaxPermSize的限制看起来也是合理的。
总结
- 之前不管是不是需要，JVM都会吃掉那块空间……如果设置得太小，JVM会死掉；如果设置得太大，这块内存就被JVM浪费了。理论上说，现在你完全可以不关注这个，因为JVM会在运行时自动调校为“合适的大小”；
- 提高Full GC的性能，在Full GC期间，Metadata到Metadata pointers之间不需要扫描了，别小看这几纳秒时间；
- 隐患就是如果程序存在内存泄露，像OOMTest那样，不停的扩展metaspace的空间，会导致机器的内存不足，所以还是要有必要的调试和监控。
总结
- Hotspot中的元数据现在存储到了元空间里。mmap中的内存块的生命周期与类加载器的一致。
- 类指针压缩空间（Compressed class pointer space）目前仍然是固定大小的，但它的空间较大
- 可以进行参数的调优，不过这不是必需的。
- 未来可能会增加其它的优化及新特性。比如， 应用程序类数据共享；新生代GC优化，G1回收器进行类的回收；减少元数据的大小，以及JVM内部对象的内存占用量。
来自 <http://aoyouzi.iteye.com/blog/2243929>