metaspace 元空间

zoukankan html css js c++ java

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是如何给元数据分配虚拟内存的空间?
- 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对象的内存布局
  
  类指针压缩空间 (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引用。
- 元空间虚拟机负责元空间的分配，其采用的形式为组块分配。组块的大小因类加载器的类型而异。
- 在元空间虚拟机中存在一个全局的空闲组块列表。当一个类加载器需要组块时，它就会从这个全局的组块列表中获取并维持一个自己的组块列表。
- 当一个类加载器不再存活，那么其持有的组块将会被释放，并返回给全局组块列表。
- 类加载器持有的组块又会被分成多个块，每一个块存储一个单元的元信息。组块中的块是线性分配（指针碰撞分配形式）。
- 组块分配自内存映射区域。这些全局的虚拟内存映射区域以链表形式连接，一旦某个虚拟内存映射区域清空，这部分内存就会返回给操作系统。
metaspace 调优
- MaxMetaspaceSize调优
  
  -XX:MaxMetaspaceSize={unlimited}
  
  元空间的大小受限于机器的内存
  
  限制类的元数据使用的内存大小, 以免出现虚拟切换以及本地内存分配失败。
  
  如果怀疑有类加载器出现泄露，应当使用这个参数。
  
  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 的问题
- 元空间虚拟机采用了组块分配的形式，同时区块的大小由类加载器类型决定。
- 类信息并不是固定大小，因此有可能分配的空闲区块和类需要的区块大小不同，这种情况下可能导致碎片存在。
- 元空间虚拟机目前并不支持压缩操作，所以碎片化是目前最大的问题。
查看全文

相关阅读:
玩儿了一下django User authentication
python装饰器方法
 django session
采用asyncore进行实时同步
 django internal search
素质拓展
 框架，公共模块，unified思想
 Linux操作系统分析__破解操作系统的奥秘
 ASP.NET]ASP.NET C# 用 Print2Flash 实现在线预览 Word、PPT、PDF 等
 [Asp.net]常见word，excel，ppt，pdf在线预览方案，有图有真相，总有一款适合你！

原文地址：https://www.cnblogs.com/ronnieyuan/p/11837789.html

metaspace 元空间

为何移除持久代

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

metaspace 的组成

metaspace 的特点

metaspace 的内存分配模型

metaspace 内存管理

metaspace 调优

metaspace 可以使用的工具

提高 GC 的性能

metaspace 的问题