你好,我叫sharkchili,目前还是在一线奋斗的Java开发,经历过很多有意思的项目,也写过很多有意思的文章,是CSDN Java领域的博客专家,也是Java Guide的维护者之一,非常欢迎你关注我的公众号:写代码的SharkChili,这里面会有笔者精心挑选的并发、JVM、MySQL数据库专栏,也有笔者日常分享的硬核技术小文。
经常看到初学JVM的读者会因为方法区这一概念提出下面这些混淆的问题和概念:
所以,笔者这里就以这篇文章来帮助读者梳理一下JVM中方法区的概念:
方法区其实是一个**《Java虚拟机规范》一个逻辑上的概念,对于不同版本的JVM都有不同的实现,就以我们常用的HotSpotJVM而言,方法区还有一个别名叫Non-Heap**,即非堆内存,这么定义的目的自然是要让Java开发者明白方法区和堆是一块独立于Java堆的内存空间,而这里笔者也列出方法区几个通用的概念:
这里我们补充说明一下,后文所涉及的不同版本的JVM版本都是以HotSpot虚拟机展开探讨。
先来在JDK7之前的版本内存结构图,在这些版本上逻辑上方法区和堆区在逻辑上是连续的,实际上在物理内存上来说,它们却可是一块连续的内存。在JDK7之前的版本,它们都用的是一个名为PermGen(永久代)的虚作为方法区的实现。
这也是为什么很多读者会把永久代和老年代混淆,实际上这两个完全不是一个概念,在JDK7之前的版本,永久代仅仅是作为方法区的实现以及和老年代捆绑在一起,当老年代或者永久代任何一个内存空间满了的时候,都会触发一次垃圾收集,仅此而已。
在这些个版本的JVM,方法区即永久代存储的是:
JDK7则是基于原有的内存结构的基础上将部分数据进行转移:
最后我们再来说说现主流的JDK8版本,它基于JDK7的存储方式,将**永久代(Perm Gen)**改为 元空间(Metaspace) 作为方法区的实现,同时元空间不再与堆内存连续,是一个划分在 本地内存(Native memory) 的一块内存区域,这也就意味着JDK8版本实现的方法区即使内存空间满了也不会触发GC。
所以JDK8版本的内存结构最终如下图所示,这也就意味着JDK7版本对永久代的设置参数
(-XX:MaxPermSize) 变为无效参数,取而代之的是对元空间空间大小设置的参数
(-XX:MetaspaceSize)。
接下来我们通过几段代码来印证笔者的观点,来看看这段代码,笔者这里直接声明了一段最大长度的静态数组,这个数组长度为Integer.MAX_VALUE,粗略估算这个数组大致需要占用4G左右的内存空间。
//声明一个静态数组
public static int[] arr=new int[Integer.MAX_VALUE];
public void test(){
for (int i = 0; i < arr.length; i++) {
System.out.println(arr[i]);
}
}
public static void main(String[] args) {
new Main().test();
}
输出结果如下,可以看到直接抛出了OOM异常,这也就意味着静态变量在JDK8版本的堆内存中。
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at com.sharkChili.webTemplate.Main.<clinit>(Main.java:16)
Exception in thread "main"
同理的再来看看这段代码。笔者声明了一个常量数组,如果它也存在于堆内存中的话,那么它的运行结果也是OOM:
//常量全局数组
final int[] arr = new int[Integer.MAX_VALUE];
public void test() {
for (int i = 0; i < arr.length; i++) {
System.out.println(arr[i]);
}
}
public static void main(String[] args) {
new Main().test();
}
意料之内,在JDK8版本常量也是分配于堆内存中:
Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at com.sharkChili.webTemplate.Main.<init>(Main.java:15)
at com.sharkChili.webTemplate.Main.main(Main.java:25)
接下来这个实验比较特殊,我们都知道CGLIB是一个强大且高性能的字节码生成库,它支持运行时扩展Java类或接口实现,本质上就是动态生成一个子类并覆盖要代理的类。所以为了验证JDK8版本的类信息是否是存于堆区还是方法区,我们就基于一个CGLIB通过无限循环去创建无数的代理类,让JVM去存储这些类定义的信息,看看最终抛出的是OOM还是元空间不足。
为了能够更快看到效果,笔者手动调整了一下元空间的大小:
-XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m
示例代码如下,通过无限循环生成代理类并创建EmptyObject的代理对象:
public static void main(String[] args) {
while (true){
Enhancer enhancer = new Enhancer();
//设置代理目标
enhancer.setSuperclass(EmptyObject.class);
//不生成同属性类的静态缓存
enhancer.setUseCache(false);
//设置单一回调对象,在调用中拦截对目标方法的调用
enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> methodProxy.invokeSuper(objects, args));
//如有必要,生成一个新类,并使用指定的回调(如果有的话)创建一个新的对象实例。
enhancer.create();
}
}
启动后我们使用jvisualvm查看当前程序的GC情况,可以看到Java Heap运行正常,即时创建的无用代理对象都会被回收掉:
再来看看元空间,可以看到随着实践的推移,无数个全新的代理类的信息存到元空间,因为元空间不受GC管理,所以使用内存不断增加:
最终如预期所说出现java.lang.OutOfMemoryError: Metaspace:
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
at net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:345)
at net.sf.cglib.proxy.Enhancer.generate(Enhancer.java:492)
at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:114)
at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:480)
at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:305)
at com.sharkChili.webTemplate.Main.main(Main.java:39)
大体来说取消永久代有以下两个原因:
我是sharkchili,CSDN Java 领域博客专家,开源项目—JavaGuide contributor,我想写一些有意思的东西,希望对你有帮助,如果你想实时收到我写的硬核的文章也欢迎你关注我的公众号:
写代码的SharkChili,同时我的公众号也有我精心整理的并发编程、JVM、MySQL数据库个人专栏导航。
类静态成员变量的存储位置及JVM的内存划分:https://blog.csdn.net/edmond999/article/details/116274263
面试官 | JVM 为什么使用元空间替换了永久代?
:https://zhuanlan.zhihu.com/p/111809384
jdk8之后,静态成员变量存储在哪?有说存在元数据区,有说迁移到堆中?希望大佬能给个详细的解答,多谢? - 红尘修行的回答 - 知乎
:https://www.zhihu.com/question/324306038/answer/688264413
类的元数据是啥意思
:https://blog.csdn.net/Fyfdf/article/details/132545463
JVM 运行时内存空间详解——方法区:https://blog.csdn.net/u012660464/article/details/120050562
你知道 JVM 的方法区是干什么用的吗?:https://zhuanlan.zhihu.com/p/166190558
JVM 运行时内存空间详解——方法区:https://blog.csdn.net/u012660464/article/details/120050562