关于 G1垃圾收集器、永久代和元空间(About G1 Garbage Collector, Permanent Generation and Metaspace)
Note
内容复制自 Oracle - Poonam Bajaj的博客,About G1 Garbage Collector, Permanent Generation and Metaspace. 目前此链接已无法访问,且无法从Oracle上查询到此篇文章。
以下为文章内容。内容为英文+翻译,翻译大部分内容为机翻,已通过人工校对对机翻不准确的内容做了修改。但限于本人翻译水平有限,不能保证翻译内容百分比正确,如有错误欢迎指正。
We received some questions around the G1 garbage collector and the use of Permanent Generation with it. There seems to be some confusion that the Hotspot JVM does not use permanent generation when G1 is used as the garbage collector. Here’s some clarification:
我们收到了一些关于 G1 垃圾收集器及其永久代使用的问题。当 G1 用作垃圾回收器时,Hotspot JVM 不使用永久代,这似乎有些混淆。以下是一些说明:
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:
永久代仍然存在于 JDK 7 及其更新中,并被所有垃圾回收器使用。在 JDK7 中,尝试删除永久代,并且驻留在永久代中的某些部分数据被移动到 Java 堆或本机堆中。永久代并未完全删除,它仍然存在于 JDK 7 及其更新中。以下是在 JDK7 中从永久代中移出的内容列表:
- Symbols were moved to the native heap
- Interned strings were moved to the Java Heap
- Class statics were moved to the Java Heap
- 符号已移动到本机堆
intern()
字符串移动到 Java 堆中- 类中的静态内容移至 Java 堆
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.
使用 G1 收集器时,PermGen 仅在 Full GC 时收集,该 GC 是 stop-the-world(STW) GC。如果 G1 以最佳方式运行,则它不会执行 Full GC。 G1 仅在 PermGen 已满或应用程序执行分配速度快于 G1 可以同时收集垃圾时调用 Full GC。
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.
使用 CMS 垃圾回收器,我们可以使用选项
-XX:+CMSClassUnloadingEnabled
在 CMS 并发周期中收集 PermGen 空间。G1 没有等效选项。G1 仅在 Full stop-the-world GC 期间收集 PermGen。
We can use options PermSize
and MaxPermSize
to tune the PermGen space size according to the application needs.
我们可以使用选项
PermSize
并MaxPermSize
根据应用需求调整 PermGen 空间大小。
JDK8: PermGen
Permanent generation has been completely removed in JDK 8. This work has been done under the bug https://bugs.openjdk.java.net/browse/JDK-6964458. Options PermSize
and MaxPermSize
have also been removed in JDK 8.
永久代已在 JDK 8 中完全删除。这项工作是在 BUG https://bugs.openjdk.java.net/browse/JDK-6964458 下完成的。选项
PermSize
,MaxPermSize
也已在 JDK 8 中删除。
Email to openjdk alias regarding the PermGen elimination
project: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006679.html
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:
在 JDK 8 中,类元数据现在存储在本地堆中,这个空间称为元空间。JDK 8 中为 Metaspace 添加了一些新标志:
-XX:MetaspaceSize=<NNN>
where<NNN>
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=<NNN>
where<NNN>
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=<NNN>
where<NNN>
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=<NNN>
where<NNN>
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.
-XX:MetaspaceSize=<NNN>
其中<NNN>
是要为类元数据分配的最大空间量(以字节为单位)。此标志可用于限制为类元数据分配的空间量。此值是近似值。默认情况下,没有设置限制。-XX:MaxMetaspaceSize=<NNN>
其中<NNN>
是要为类元数据分配的最大空间量(以字节为单位)。此标志可用于限制为类元数据分配的空间量。此值是近似值。默认情况下,没有设置限制。-XX:MinMetaspaceFreeRatio=<NNN>
其中<NNN>
是 GC 后可用类元数据容量的最小百分比,以避免为类元数据分配的空间量(高水位线)增加,从而导致垃圾回收。-XX:MaxMetaspaceFreeRatio=<NNN>
其中<NNN>
是 GC 后可用类元数据容量的最大百分比,以避免为类元数据分配的空间量(高水位线)减少,从而导致垃圾回收。
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.
默认情况下,类元数据分配仅受可用本机内存量的限制。我们可以使用新选项
MaxMetaspaceSize
来限制用于类元数据的本机内存量。它类似于 MaxPermSize。当类元数据使用量达到 MetaspaceSize(32 位客户端 VM 为 12MB,32 位服务器 VM 为 16MB,64 位 VM 上较大)时,将诱导垃圾回收以收集失效的类装载器和类。将 MetaspaceSize 设置为更高的值以延迟诱导的垃圾回收。在诱导垃圾回收之后,可能会增加诱导下一个垃圾回收所需的类元数据使用量。
关于 G1垃圾收集器、永久代和元空间(About G1 Garbage Collector, Permanent Generation and Metaspace)
http://jaune162.blog/2024/05/16/about-g1-garbage-collector,-permanent-generation-and-metaspace.html