java from space to space_Java 8 - From PermGen to Metaspace

Java 8 - From PermGen to Metaspace

随着JDK8的到来,JVM不再有PermGen。但类的元数据信息(metadata)还在,只不过不再是存储在连续的堆空间上,而是移动到叫做“Metaspace”的本地内存(Native memory)中。

类的元数据信息转移到Metaspace的原因是PermGen很难调整。PermGen中类的元数据信息在每次FullGC的时候可能会被收集,但成绩很难令人满意。而且应该为PermGen分配多大的空间很难确定,因为PermSize的大小依赖于很多因素,比如JVM加载的class的总数,常量池的大小,方法的大小等。

此外,在HotSpot中的每个垃圾收集器需要专门的代码来处理存储在PermGen中的类的元数据信息。从PermGen分离类的元数据信息到Metaspace,由于Metaspace的分配具有和Java Heap相同的地址空间,因此Metaspace和Java Heap可以无缝的管理,而且简化了FullGC的过程,以至将来可以并行的对元数据信息进行垃圾收集,而没有GC暂停。

JDK 7: PermGen

Permanent Generation still exists in JDK 7 and its updates,and is used by all the garbage collectors. In JDK7, the effort to remove the permanent generation was started and some parts of the data residing in the permanent generation were moved to either the Java Heap or to the native heap.Permanent generation was not completely removed and it still exists in JDK 7 and its updates. Here's the list of things that were moved out of the permanent generation in JDK7:

Symbols were moved to the native heap

Interned strings were moved to the Java Heap

Class statics were moved to the Java Heap

JDK7: G1 and PermGen

With G1 collector, PermGen is collected only at a Full GC which is a stop-the-world (STW) GC. If

G1 is running optimally then it does not do Full GCs. G1 invokes the Full GCs only when the PermGen is full or when the application does allocations faster than G1 can concurrently collect garbage.

With CMS garbage collector, we can use option -XX:+CMSClassUnloadingEnabled to collect PermGen space in the CMS concurrent cycle. There is no equivalent option for G1. G1 only collects PermGen during the Full stop-the-world GCs.

We can use options PermSize and MaxPermSize to tune the PermGen space size according to the application needs.

JDK8: Metaspace

In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace.There are some new flags added for Metaspace in JDK 8:

-XX:MetaspaceSize=

where is the initial amount of space(the initial

high-water-mark) allocated for class metadata (in bytes) that may induce a

garbage collection to unload classes. The amount is approximate. After the

high-water-mark is first reached, the next high-water-mark is managed by

the garbage collector

-XX:MaxMetaspaceSize=

where is the maximum amount of space to be allocated for class

metadata (in bytes). This flag can be used to limit the amount of space

allocated for class metadata. This value is approximate. By default there

is no limit set.

-XX:MinMetaspaceFreeRatio=

where is the minimum percentage of class metadata capacity

free after a GC to avoid an increase in the amount of space

(high-water-mark) allocated for class metadata that will induce a garbage

collection.

-XX:MaxMetaspaceFreeRatio=

where is the maximum percentage of class metadata capacity

free after a GC to avoid a reduction in the amount of space

(high-water-mark) allocated for class metadata that will induce a garbage

collection.

By default class metadata allocation is only limited by the amount of available native memory. We can use the new option MaxMetaspaceSize to limit the amount of native memory used for the class metadata. It is analogous to MaxPermSize. A garbage collection is induced to collect the dead classloaders and classes when the class metadata usage reaches MetaspaceSize (12Mbytes on the 32bit client VM and 16Mbytes on the 32bit server VM with larger sizes on the 64bit VMs). Set MetaspaceSize to a higher value to delay the induced garbage collections. After an induced garbage collection, the class metadata usage needed to induce the next garbage collection may be increased.

Metaspace garbage collection

‍Garbage collection of the dead classes and classloaders is triggered(触发的) once the class metadata usage reaches the “MaxMetaspaceSize”.‍

Proper monitoring & tuning of the Metaspace will obviously be required in order to limit the frequency or delay of such garbage collections. Excessive Metaspace garbage collections may be a symptom of classes, classloaders memory leak or inadequate sizing for your application.

===================END===================

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值