要是没有实践过别人书本上的理论的话,就还是会说常量池在方法区里面,要是知道方法区已经随jdk升级,被逐步干掉的话,额,也不能说被干掉,只是被优化了,这又体现了看书的程度深浅了,就会看到有的文章说常量池移动到heap堆里面了,还有极少的说移动到Metaspace里面了,产生了分歧。这个时候就需要实践出真知了。
/**
* 测试 常量池在分区的位置
*
* @author LiXuekai on 2020/6/9
*/
public class StringConstantPoolTest {
public static void main(String[] args) {
List list = Lists.newArrayList();
while (true) {
list.add(String.valueOf(System.currentTimeMillis()).intern());
}
}
}
代码很简单,那本书上也大致是这个样子。String.intern()会将字符串丢到字符串常量池里面。以此来不断增加常量池的使用部分。
还有你得一直使用着这个字符串,不然就被gc了,你就看不到oom现象了。
他当时测试的时候,出的异常是方法区OOM.
当时的jdk还是1.6,我这就不测试1.6的了。
执行结果说明常量池在方法区。
下面是jdk1.7的测试情况,还是这个代码,就是启动参数设置的不一样。
使用的jvm参数设置:
-XX:+PrintGCDetails -Xms100M -Xmx100M -Xmn10M -XX:SurvivorRatio=8 -XX:PermSize=10m -XX:MaxPermSize=10m
然后这个程序的异常截图如下:
堆空间溢出。
使用jvm看内存分区的使用情况的截图:
可以看到堆里面old区总共90M,已经89M,这个是在报oom之前的截图。方法区总共就分了10m,在oom的时候,也就使用了7m多,说明这个常量池,在jdk1.7的时候,确实被安排到了堆Java heap里面了。
上面的说明加起来,使得下面这个理论得到了验证。
永久代主要存放以下数据:
JVM internal representation of classes and their metadata //类及其元数据的JVM内部表示
Class statics //类的静态
Interned strings //实际字符串,说的就是常量池吧
从 JDK7 开始,JDK 开发者们就有消灭永久代的打算了。有部分数据移到永久代之外了:
Symbols => native memory // 符号引用 >本机内存
Interned strings => Java Heap // Interned string => Java堆
Class statics => Java Heap //类statics => Java堆
使用的jvm参数设置:
-XX:+PrintGCDetails -Xms200M -Xmx200M -Xmn10M -XX:SurvivorRatio=8 -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:CompressedClassSpaceSize=5M
代码执行时候报的异常截图
使用jvm看内存分区的使用情况的截图:
设置堆的大小是200m,元空间就只有10m,测试了几次了,每次堆的old区里面也就残留81m,看元空间的最大是10m,使用了8.4m之后,差不多就oom了。堆还差得远呢。
说明这个常量池就是在元空间里面了吧,不能在Java heap里面了吧。
在看元空间的时候,有个这个图
说是开发jvm的人画的。元空间被分为2部分,类空间 class space 和非类空间 non class space
深入 Class Space:
最大的一部分是 Klass 结构,它是固定大小的。
然后紧跟着两个可变大小的 vtable 和 itable,前者由类中方法的数量决定,后者由这个类所实现接口的方法数量决定。
随后是一个 map,记录了类中引用的 Java 对象的地址,尽管该结构一般都很小,不过也是可变的。
vtable 和 itable 通常也很小,但是对于一些巨大的类,它们也可以很大,一个有 30000 个方法的类,vtable 的大小会达到 240k,如果类派生自一个拥有 30000 个方法的接口,也是同理。但是这些都是测试案例,除了自动生成代码,你从来不会看到这样的类。
深入 Non-Class Space
这个区域有很多的东西,下面这些占用了最多的空间:
每个成员方法的 metadata:ConstMethod 结构,包含了好几个可变大小的内部结构,如方法字节码、局部变量表、异常表、参数信息、方法签名等;
最后,那就按照老外的说法来吧,我的测试也稍微辅助说明一下吧,虽然代码里面报错是Java heap 溢出。这点奇怪了。
姑且最终结论,常量池就是在Metaspace 元空间里面。
参考:
老外原文地址
怎么想怎么都觉得不对,这个常量池怎么能在元空间里面。
后面又调整参数,-xms 和-xmx设置2g,代码运行时间就更久了,说明啥,数据对象分配了那么多,要是这个方法区,早就被撑爆炸了,怎么可能会在元空间呢。这地方就分给他10,这个图上最大也就13m,肯定不可能装下那么多的字符串的。那老外画的图又作何解释呢。老外画错了,或者说老外没画明白。
所以,最终的测试结论:
这个常量池(特指字符串常量池而不是所有的常量池),应该还是在Java heap里面,
上面的测试只能证明:jdk1.8中 字符串常量池是在堆里面。
此外,Java有三种常量池,即字符串常量池(又叫全局字符串池)、class文件常量池、运行时常量池。
1. 字符串常量池(也叫全局字符串池、string pool、string literal pool)
字符串常量池 Interned Strings
2. 运行时常量池(runtime constant pool)
当程序运行到某个类时,class文件中的信息就会被解析到内存的方法区里的运行时常量池中。每个类都有一个运行时常量池
3. class文件常量池(class constant pool)
class常量池是在编译后每个class文件都有的,class文件中除了包含类的版本、字段、方法、接口等描述信息外,还有一项信息就是 常量池*(constant pool table)*,用于存放编译器生成的各种字面量(Literal)和符号引用(Symbolic References)。*字面量就是我们所说的常量概念,如文本字符串、被声明为final的常量值等。
按照这个分析的话,
运行时常量池和静态常量池存放在元空间中,而字符串常量池依然存放在堆中。
这个理论还说的通,但是另外2个常量池就不好测试了。
Java Language and Virtual Machine Specifications
上面这个是jdk的官网链接,里面不管是jdk几,里面都有Method Area方法区
都是这么几个分区,说明这几个名字都是概念。
顺便再上传一下他原文和网页简单翻译的图
Each run-time constant pool is allocated from the Java Virtual Machine's method area (§2.5.4). The run-time constant pool for a class or interface is constructed when the class or interface is created (§5.3) by the Java Virtual Machine.
方法区确实是一个概念,概念,概念。
干掉的是永久代,而不是方法区。
卧槽,接口还在,只是实现类变了。
最开始的实现叫PermGen,后来是PermGen + java heap 一起实现,现在叫Metaspace + Java heap 一起协调工作。
元空间并不是方法区!!!
方法区包括类信息、常量、静态变量等,是JVM规范。 方法区是jvm规范里面的概念。
1.7之前方法区的实现就是永久代。 1.7 把常量池和静态变量放入了堆中,也就是方法区由永久代和堆实现。
1.8 把永久代删除使用元空间,也就是方法区由元空间(类信息)和堆实现(常量池、静态变量)。
堆中包含正常对象和常量池,new String()放入堆中,String::inter会将堆中的String变量放入堆中的常量池中。
这个解释就比较完美了。
Each run-time constant pool is allocated from the Java Virtual Machine's method area (§2.5.4). The run-time constant pool for a class or interface is constructed when the class or interface is created (§5.3) by the Java Virtual Machine.
这句话,可不就是说,所有的运行时常量池都是从jvm的 method area 方法区分配来的。
所以,说常量池在方法区,是对的。因为方法区是个概念的东西。
在jvm里面具体实现还的根据不同的jdk,实现的区的名称也不一样,前有PermGen,后有permGen + Java heap ,后再有metaspace + Java heap。