metaspace 元空间

为何移除持久代

  • 它的大小是在启动时固定好的, 很难进行调优 -XX:MaxPermSize(默认64M)
  • HotSpot 的内部类型也是Java对象: 它可能会在Full GC中被移动, 同时它对应用不透明, 且是非强类型的, 难以跟踪调试, 还需要存储元数据信息 (meta-metadata)
  • 简化 Full GC: 每一个回收器都有专门的元数据迭代器。
  • 可以在GC不进行暂停的情况下并发地释放类数据。
  • 使得原来受限于持久代的一些改进未来有可能实现。
  • 综上, jdk1.8后, 永久代被移除, 方法区移至Metaspace, 字符串常量移至Java Heap。

移除持久代后, PermGen 空间的状况

  • 这部分内存空间将被全部移除。
  • JVM 参数: PermSize 和 MaxPermSize 会被忽略并给出警告 (如果启用时设置了这两个参数)。

metaspace 的组成

  • Klass Metaspace
    • klass是class文件在jvm里的运行时数据结构, 而Klass Metaspace 就是用来存 klass的。
    • 但X.class(反射)其实是存在heap中的, 是java.lang.Class 的一个对象实例。
    • 这块内存紧挨着的Heap, 可以通过 -XX: CompressedClassSpaceSize参数来控制(默认1G)。
    • 假如开启压缩指针就不会有这块内存, 这种情况下klass都会存在NoKlass Metaspace中
    • 另外如果我们把-Xmx设置设置大于32G的话, 这块内存也会消失, 因为过大的内存会关闭压缩指针开关。
    • 这块内存最多只会存在一块。
  • NoKlass Metaspace
    • 专门用来存klass相关的其他内存, 比如method, constantPool等。
    • 这块内存是由多块内存组合起来的, 所以可以认为是不连续的内存块组成的。
    • 这块内存是必须的, 虽然叫做NoKlass Metaspace, 但是其实也可以存klass的内容。
  • Klass Metaspace 和 NoKlass Metaspace 都是所有classloader共享的
  • 所有类加载器们要分配内存, 但是每个类加载器都有一个SpaceManager, 来管理这个类加载的内存小块。
  • 如果Klass Metaspace 用完了, 就会造成 OOM, 不过一般情况下不会。
  • NoKlass Metaspace是由一块块内存慢慢组合起来的, 在没有达到限制条件的情况下, 会不断加长这条链, 让它可以持续工作。
  • 元空间与永久代之间的最大区别:
    • 元空间不再虚拟机中, 而是使用本地内存。
  • 默认情况下, 元空间大小仅受本地内存限制, 但可以通过以下参数来指定元空间的大小:
    • -XX:MetaspaceSize
    • 初始空间大小, 达到该值就会触发垃圾收集进行类型卸载
    • 同时GC会对该值进行调整: 如果释放了大量空间, 就适当降低该值, 如果释放了很少的空间, 那么在不超过MaxMetaspaceSize时, 适当提高该值。
    • -XX:MaxMetaspaceSize
    • 最大空间, 默认没有限制。
    • -XX:MinMetaspaceFreeRatio
    • 在GC之后, 最小的Metaspace剩余空间容量的百分比, 减少为分配空间所导致的垃圾收集
    • -XX:MaxMetaspaceFreeRatio
    • 在GC之后, 最大的Metaspace剩余容量的百分比, 减少为释放空间所导致的垃圾收集
    • -verbose 参数是为了获取类型加载和卸载的信息

metaspace 的特点

  • 充分利用了Java语言规范中的好处：类及相关的元数据的生命周期与类加载器的一致。
  • 每个加载器有专门的存储空间
  • 只进行线性分配
  • 不会单独回收某个类
  • 省掉了GC扫描及压缩的时间
  • 元空间里的对象的位置是固定的
  • 如果GC发现某个类加载器不再存活了, 会把相关的空间整个回收掉

metaspace 的内存分配模型

  • 绝大多数的类元数据的空间都从本地内存中分配

  • 用来描述类元数据的类(klasses)也被删除了

  • 分元数据分配了多个虚拟内存空间

  • 给每个类加载器分配一个内存块的列表。块的大小取决于类加载器的类型; sun/反射/代理对应的类加载器的块会小一些

  • 归还内存块, 释放内存块列表

  • 一旦元空间的数据被清空了, 虚拟内存的空间会被回收掉

  • 减少碎片的策略

  • JVM是如何给元数据分配虚拟内存的空间?

    “meta chunks in virtual space”的图片搜索结果"

  • Boot CL -> Bootstrap ClassLoader

  • _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对象的内存布局

    img

    • 类指针压缩空间 (Compressed Class Pointer Space)
      • 只有是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中的虚方法表也存放到这里 这里到底存放哪些元数据的类型，目前仍在减少
    • 元空间包含类的其它比较大的元数据，比如方法，字节码，常量池等。

metaspace 内存管理

  • 元空间的内存管理由元空间虚拟机来完成。

  • 先前，对于类的元数据我们需要不同的垃圾回收器进行处理，现在只需要执行元空间虚拟机的C++代码即可完成。

  • 在元空间中，类和其元数据的生命周期和其对应的类加载器是相同的。

  • 话句话说，只要类加载器存活，其加载的类的元数据也是存活的，因而不会被回收掉。

  • 每一个类加载器的存储区域都称作一个元空间，所有的元空间合在一起就是我们一直说的元空间。

  • 当一个类加载器被垃圾回收器标记为不再存活，其对应的元空间会被回收。

  • 在元空间的回收过程中没有重定位和压缩等操作。

  • 但是元空间内的元数据会进行扫描来确定Java引用。

  • 元空间虚拟机负责元空间的分配，其采用的形式为组块分配。组块的大小因类加载器的类型而异。

  • 在元空间虚拟机中存在一个全局的空闲组块列表。当一个类加载器需要组块时，它就会从这个全局的组块列表中获取并维持一个自己的组块列表。

  • 当一个类加载器不再存活，那么其持有的组块将会被释放，并返回给全局组块列表。

  • 类加载器持有的组块又会被分成多个块，每一个块存储一个单元的元信息。组块中的块是线性分配（指针碰撞分配形式）。

  • 组块分配自内存映射区域。这些全局的虚拟内存映射区域以链表形式连接，一旦某个虚拟内存映射区域清空，这部分内存就会返回给操作系统。

    “signifies linked list of virtual spaces”的图片搜索结果"

metaspace 调优

  • MaxMetaspaceSize调优
    • -XX:MaxMetaspaceSize=
    • 元空间的大小受限于机器的内存
    • 限制类的元数据使用的内存大小, 以免出现虚拟切换以及本地内存分配失败。
    • 如果怀疑有类加载器出现泄露，应当使用这个参数。
    • 32位机器上，如果地址空间可能会被耗尽，也应当设置这个参数。
    • 元空间的初始大小是21M——这是GC的初始的高水位线，超过这个大小会进行Full GC来进行类的回收。
    • 如果启动后GC过于频繁，请将该值设置得大一些 。
    • 可以设置成和持久代一样的大小，以便推迟GC的执行时间 。
  • CompressedClassSpaceSize调优
    • 只有当-XX:+UseCompressedClassPointers 开启了才有效
    • -XX:CompressedClassSpaceSize=1G
    • 由于这个大小在启动的时候就是固定了的, 因此最好设置得大点。
    • 没有使用到的话不要进行设置
    • JVM后续可能会让该区可以动态地增长。
    • 不需要是连续的区域, 只要从基地址可达就行。
    • 可能会将更多的类元信息放回元空间中。
    • 未来会基于PredictedLoadedClassCount的值来自动地设置该空间的大小。
    • Metaspace VM管理Metaspace空间的增长。
    • 但有时你会想通过在命令行显示的设置参数-XX:MaxMetaspaceSize来限制Metaspace空间的增长。
    • 默认情况下，-XX:MaxMetaspaceSize并没有限制，因此，在技术上，Metaspace的尺寸可以增长到交换空间，而你的本地内存分配将会失败。
    • 每次垃圾收集之后，Metaspace VM会自动的调整high watermark，推迟下一次对Metaspace的垃圾收集。
    • 这两个参数，-XX：MinMetaspaceFreeRatio和-XX：MaxMetaspaceFreeRatio,类似于GC的FreeRatio参数，可以放在命令行。

metaspace 可以使用的工具

  • 针对Metaspace，JDK自带的一些工具做了修改来展示Metaspace的信息:

  • jmap -clstats :打印类加载器的统计信息(取代了在JDK8之前打印类加载器信息的permstat)。

  • jstat -gc :Metaspace的信息也会被打印出来。

  • jcmd GC.class_stats:这是一个新的诊断命令，可以使用户连接到存活的JVM，转储Java类元数据的详细统计。

  • 这次就用Zookeeper进程查看一下结果了:

  • jmap -clstats 示例

    root@ronnie01:~# jmap -clstats 1518
Attaching to process ID 1518, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08
finding class loader instances ..done.
computing per loader stat ..done.
please wait.. computing liveness...............liveness analysis may be inaccurate ...
class_loader	classes	bytes	parent_loader	alive?	type

<bootstrap>	1673	2966193	  null  	live	<internal>
0x00000000ec2982c8	1	880	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec2992a8	1	1471	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec298200	1	1474	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec2991e0	1	1471	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec299500	1	773	  null  	dead	javax/management/remote/rmi/NoCallStackClassLoader@0x00000001000c9a90
0x00000000ec288918	546	1001934	0x00000000ec290198	live	sun/misc/Launcher$AppClassLoader@0x000000010000f8d8
0x00000000ec290198	0	0	  null  	live	sun/misc/Launcher$ExtClassLoader@0x000000010000fc80
0x00000000ec298458	1	880	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec299118	1	880	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec299438	1	1471	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec2995d8	1	742	  null  	dead	javax/management/remote/rmi/NoCallStackClassLoader@0x00000001000c9a90
0x00000000ec4706d0	0	0	0x00000000ec288918	live	java/util/ResourceBundle$RBClassLoader@0x00000001001000b8
0x00000000ec298390	1	880	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028
0x00000000ec299370	1	1471	  null  	dead	sun/reflect/DelegatingClassLoader@0x000000010000a028

total = 15	2230	3980520	    N/A    	alive=4, dead=11	    N/A

  • jstat -gc 示例

    root@ronnie01:~# jstat -gc 1518
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
2560.0 2560.0  0.0   2528.0 15872.0  11145.9   42496.0     1918.0   12032.0 11678.5 1536.0 1371.2      1    0.104   0      0.000    0.104

  • jcmd GC.class_stats 示例

- JDK1.8需要指定参数  *XX:+UnlockDiagnosticVMOptions*  进入诊断状态才能执行, 然后jdk9又把该要求移除了......

提高 GC 的性能

  • Full GC中，元数据指向元数据的那些指针都不用再扫描了。很多复杂的元数据扫描的代码（尤其是CMS里面的那些）都删除了。
  • 元空间只有少量的指针指向Java堆。这包括：类的元数据中指向java/lang/Class实例的指针;数组类的元数据中，指向java/lang/Class集合的指针。
  • 没有元数据压缩的开销
  • 减少了根对象的扫描（不再扫描虚拟机里面的已加载类的字典以及其它的内部哈希表）
  • 减少了Full GC的时间
  • G1回收器中，并发标记阶段完成后可以进行类的卸载

metaspace 的问题

  • 元空间虚拟机采用了组块分配的形式，同时区块的大小由类加载器类型决定。
  • 类信息并不是固定大小，因此有可能分配的空闲区块和类需要的区块大小不同，这种情况下可能导致碎片存在。
  • 元空间虚拟机目前并不支持压缩操作，所以碎片化是目前最大的问题。
posted @ 2019-11-11 19:53  wellDoneGaben  阅读(571)  评论(0)  编辑  收藏  举报