Ricky.L的随笔
0%

Class常量池、运行时常量池、字符串常量池

发表于 更新于 分类于 Disqus：

Class常量池

Class常量池在哪，是做什么的？

每个Class文件中都有常量池，位于魔数和主次版本号之后，是Class文件中第一个出现的表类型的数据项，占用空间最大的数据项之一，也是与其他项目关联最多的数据类型。

Class常量池主要存放：

  1. 字面量（Literal）
  2. 符号引用（Symbolic References）

可以理解为Class文件中的资源仓库。

参考《深入理解Java虚拟机（第2版）》168页 6.3.2 常量池。

字面量是什么？

直观的数据值。

1
2
3
int i = 100;
float f = 2.3f;
String s = "abc";

100、2.3f、”abc”是字面量

0x1FB等十六进制、八进制、二进制等直观的数据值也是字面量。

参考：

符号引用是什么？

  1. 类和接口的全限定名
  2. 字段的名称和描述符
  3. 方法的名称和描述符

Java代码在进行Javac编译的时候，并不像C和C++那样有“连接”这一步骤，而是在虚拟机加载Class文件的时候进行动态连接。

也就是说，在Class文件中不会保存各个方法、字段的最终内存布局信息，因此这些字段、方法的符号引用不经过运行期转换的话无法得到真正的内存入口地址，也就无法直接被虚拟机使用。

当虚拟机运行时，需要从常量池获得对应的符号引用，再在类创建时或运行时解析、翻译到具体的内存地址之中。

因为java要支持动态性，所以不能在编译期就确定最终的内存布局。

参考《深入理解Java虚拟机（第2版）》168页 6.3.2 常量池。

字段描述符和方法的描述符是什么？

字段的描述符唯一确定一个字段，方法的描述符唯一确定一个方法。

参考：

Class常量池的实际存储格式是什么样的?

常量池整体上分为两部分：

  • 常量池计数器
  • 常量池数据区

常量池计数器（constant_pool_count）：由于常量的数量不固定，所以需要先放置两个字节来表示常量池容量计数值。

常量池数据区：数据区是由（constant_pool_count-1）个cp_info结构组成，一个cp_info结构对应一个常量。在字节码中共有14种类型的cp_info（如下图6所示），每种类型的结构都是固定的。

具体以CONSTANT_utf8_info为例，它的结构如下图7左侧所示。首先一个字节“tag”，它的值取自上图6中对应项的Tag，由于它的类型是utf8_info，所以值为“01”。接下来两个字节标识该字符串的长度Length，然后Length个字节为这个字符串具体的值。从图2中的字节码摘取一个cp_info结构，如下图7右侧所示。将它翻译过来后，其含义为：该常量类型为utf8字符串，长度为一字节，数据为“a”。

参考

Class常量池一个具体内容的例子？

定义如下的类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class JavaBean{ 
    private int value = 1; 
    public String s = "abc"; 
    public final static int f = 0x101; 

    public void setValue(int v){ 
        final int temp = 3; 
        this.value = temp + v; 
    } 
 
    public int getValue(){ 
        return value; 
    } 
}

生成的class常量池如下： 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Constant pool: 
   #1 = Methodref          #6.#29         // java/lang/Object."<init>":()V 
   #2 = Fieldref           #5.#30         // JavaBasicKnowledge/JavaBean.value:I 
   #3 = String             #31            // abc 
   #4 = Fieldref           #5.#32         // JavaBasicKnowledge/JavaBean.s:Ljava/lang/String; 
   #5 = Class              #33            // JavaBasicKnowledge/JavaBean 
   #6 = Class              #34            // java/lang/Object 
   #7 = Utf8               value 
   #8 = Utf8               I 
   #9 = Utf8               s 
  #10 = Utf8               Ljava/lang/String; 
  #11 = Utf8               f 
  #12 = Utf8               ConstantValue 
  #13 = Integer            257 
  #14 = Utf8               <init> 
  #15 = Utf8               ()V 
  #16 = Utf8               Code 
  #17 = Utf8               LineNumberTable 
  #18 = Utf8               LocalVariableTable 
  #19 = Utf8               this 
  #20 = Utf8               LJavaBasicKnowledge/JavaBean; 
  #21 = Utf8               setValue 
  #22 = Utf8               (I)V 
  #23 = Utf8               v 
  #24 = Utf8               temp 
  #25 = Utf8               getValue 
  #26 = Utf8               ()I 
  #27 = Utf8               SourceFile 
  #28 = Utf8               StringConstantPool.java 
  #29 = NameAndType        #14:#15        // "<init>":()V 
  #30 = NameAndType        #7:#8          // value:I 
  #31 = Utf8               abc 
  #32 = NameAndType        #9:#10         // s:Ljava/lang/String; 
  #33 = Utf8               JavaBasicKnowledge/JavaBean 
  #34 = Utf8               java/lang/Object

字面量：

这里需要说明的一点，上面说的存在于常量池的字面量，指的是数据的值，也就是abc和0x101(257),通过上面对常量池的观察可知这两个字面量是确实存在于常量池的。

而对于基本类型数据(甚至是方法中的局部变量)，也就是上面的private int value = 1;常量池中只保留了他的的字段描述符I和字段的名称value，他们的字面量不会存在于常量池。

符号引用：

对于方法中的局部变量名，class文件的常量池仅仅保存字段名。

参考：

一个方法名最多可以有多长？

在HotSpot VM中，运行时常量池里，CONSTANT_Utf8_info可以表示Class文件的方法、字段等等，其结构如下：

首先是1个字节的tag,表示这是一个CONSTANT_Utf8_info结构的常量，然后是两个字节的length，表示要储存字节的长度，之后是一个字节的byte数组，表示真正的储存的length个长度的字符串。这里需要注意的是，一个字节只是代表这里有一个byte类型的数组，而这个数组的长度当然可以远远大于一个字节。当然，由于CONSTANT_Utf8_info结构只能用u2即两个字节来表示长度，因此长度的最大值为2byte，也就是65535。

Android虚拟机的Class常量池跟JVM的有什么不同？

Java从设计之初就非要支持分离编译（separate compilation）与按需动态类加载（on-demand dynamic class loading），导致Java的Class文件必须独立的（self-contained）——每个Class文件必须自己携带自己的常量池，其主要信息是字符串与若干其它常量的值，以及用于符号链接的符号引用信息（symbolic reference）。

如果大家关注过Class文件的内容的话，会知道其实通常Class文件里表示程序逻辑的代码部分——“字节码”——只占Class文件大小的小头；而大头都被常量池占了。而且多个Class文件的常量池内容之间常常有重叠，所以当程序涉及多个Class文件时，就容易有冗余信息，不利于减少传输/存储代码的大小。

大家或许还记得Google在Google I/O 2008的Dalvik VM Internals演讲里，Dan得意的介绍到Dalvik的Dex格式在未压缩的情况下都比压缩了的JAR文件还小么？

Dan准确的介绍了Dex体积更小的原因：一个Dex相当于一个或多个JAR包，里面可以包含多个Class文件对应的内容。一个Dex文件里的所有Class都共享同一个常量池，因而不会像Class文件那样在多个常量池之间有冗余。这样Dex文件就等同于在元数据层面上对JAR文件做了压缩，所以前者比后者更小。

参考：

字符串常量池

字符串常量池在内存区域中的哪一块？

方法区实际上是在一块叫“非堆”的区域包含——可以简单粗略的理解为非堆中包含了永生代，而永生代中又包含了方法区和字符串常量池。

其中的Interned String就是全局共享的“字符串常量池（String Pool）”，和运行时常量池不是一个概念。但我们在代码中申明String s1 = “Hello”;这句代码后，在类加载的过程中，类的class文件的信息会被解析到内存的方法区里。

全局字符串池里的内容是在类加载完成，经过验证，准备阶段之后在堆中生成字符串对象实例，然后将该字符串对象实例的引用值存到string pool中（记住：string pool中存的是引用值而不是具体的实例对象，具体的实例对象是在堆中开辟的一块空间存放的。）。

在HotSpot VM里实现的string pool功能的是一个StringTable类，它是一个哈希表，里面存的是驻留字符串(也就是我们常说的用双引号括起来的)的引用（而不是驻留字符串实例本身），也就是说在堆中的某些字符串实例被这个StringTable引用之后就等同被赋予了”驻留字符串”的身份。这个StringTable在每个HotSpot VM的实例只有一份，被所有的类共享。

String s1 = “Hello”，到底有没有在堆中创建对象？

class文件里常量池里大部分数据会被加载到“运行时常量池”，包括String的字面量；但同时“Hello”字符串的一个引用会被存到同样在“非堆”区域的“字符串常量池”中，而”Hello”本体还是和所有对象一样，创建在Java堆中。

当主线程开始创建s1时，虚拟机会先去字符串池中找是否有equals(“Hello”)的String，如果相等就把在字符串池中“Hello”的引用复制给s1；如果找不到相等的字符串，就会在堆中新建一个对象，同时把引用驻留在字符串池，再把引用赋给str。

当用字面量赋值的方法创建字符串时，无论创建多少次，只要字符串的值相同，它们所指向的都是堆中的同一个对象。

字符串常量池本质是个什么东西？

字符串常量池是JVM所维护的一个字符串实例的引用表。

在HotSpot VM中，它是一个叫做StringTable的全局表。在字符串常量池中维护的是字符串实例的引用，底层C++实现就是一个Hashtable。这些被维护的引用所指的字符串实例，被称作”被驻留的字符串”或”interned string”或通常所说的”进入了字符串常量池的字符串”。

String”字面量” 是何时进入字符串常量池的？如何决定是否要复用字符串常量池中的驻留字符串？

在执行ldc指令时，该指令表示int、float或String型常量从常量池推送至栈顶。

ldc全称：load constant

就HotSpot VM的实现来说，加载类的时候，那些字符串字面量会进入到当前类的运行时常量池，不会进入全局的字符串常量池（即在StringTable中并没有相应的引用，在堆中也没有对应的对象产生），在执行ldc指令时，触发lazy resolution这个动作。

ldc字节码在这里的执行语义是：到当前类的运行时常量池（runtime constant pool，HotSpot VM里是ConstantPool + ConstantPoolCache）去查找该index对应的项，如果该项尚未resolve则resolve之，并返回resolve后的内容。

在遇到String类型常量时，resolve的过程如果发现StringTable已经有了内容匹配的java.lang.String的引用，则直接返回这个引用，反之，如果StringTable里尚未有内容匹配的String实例的引用，则会在Java堆里创建一个对应内容的String对象，然后在StringTable记录下这个引用，并返回这个引用出去。

可见，ldc指令是否需要创建新的String实例，全看在第一次执行这一条ldc指令时，StringTable是否已经记录了一个对应内容的String的引用。

String.intern()用法和规则是什么？

1
2
3
4
5
6
7
8
public class Demo {
	public static void main(String[] args) {
		String str1 = new StringBuilder("计算机").append("软件").toString();
		System.out.println(str1.intern() == str1);
		String str2 = new StringBuilder("ja").append("va").toString();
		System.out.println(str2.intern() == str2);
	}
}

以上代码，在 JDK6 下执行结果为 false、false，在 JDK7 以上执行结果为 true、false。

首先我们调用StringBuilder创建了一个”计算机软件”String对象，因为调用了new关键字，因此是在运行时创建，之前JVM中是没有这个字符串的。

在 JDK6 下，intern()会把首次遇到的字符串实例复制到永久代中，返回的也是这个永久代中字符串实例的引用；而在JDK1.7开始，intern()方法不再复制字符串实例，String 的 intern 方法首先将尝试在常量池中查找该对象的引用，如果找到则直接返回该对象在常量池中的引用地址。

因此在1.7中，“计算机软件”这个字符串实例只存在一份，存在于java堆中！通过3中的分析，我们知道当String str1 = new StringBuilder(“计算机”).append(“软件”).toString();这句代码执行完之后，已经在堆中创建了一个字符串对象，并且在全局字符串常量池中保留了这个字符串的引用，那么str1.intern()直接返回这个引用，这当然满足str1.intern() == str1——都是他自己嘛；对于引用str2，因为JVM中已经有“java”这个字符串了，因此new StringBuilder(“ja”).append(“va”).toString()会重新创建一个新的“java”字符串对象，而intern()会返回首次遇到的常量的实例引用，因此他返回的是系统中的那个”java”字符串对象引用(首次)，因此会返回false。

在 JDK6 下 str1、str2 指向的是新创建的对象，该对象将在 Java Heap 中创建，所以 str1、str2 指向的是 Java Heap 中的内存地址；调用 intern 方法后将尝试在常量池中查找该对象，没找到后将其放入常量池并返回，所以此时 str1/str2.intern() 指向的是常量池中的地址，JDK6常量池在永久代，与堆隔离，所以 s1.intern()和s1 的地址当然不同了。

运行时常量池

运行时常量池是什么？

运行时常量池是方法区的一部分，所以也是全局贡献的，我们知道，jvm在执行某个类的时候，必须经过加载、链接（验证、准备、解析）、初始化，在第一步加载的时候需要完成：

  1. 通过一个类的全限定名来获取此类的二进制字节流
  2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
  3. 在内存中生成一个类对象，代表加载的这个类，这个对象是java.lang.Class，它作为方法区这个类的各种数据访问的入口。

上面的第二条，将class字节流代表的静态存储结构转化为方法区的运行时数据结构，其中就包含了class文件常量池进入运行时常量池的过程，这里需要强调一下不同的类共用一个运行时常量池，同时在进入运行时常量池的过程中，多个class文件中常量池相同的字符串，多个class文件中常量池中相同的字符串只会存在一份在运行时常量池，这也是一种优化。

运行时常量池的作用是存储java class文件常量池中的符号信息，运行时常量池中保存着一些class文件中描述的符号引用，同时在类的解析阶段还会将这些符号引用翻译出直接引用（直接指向实例对象的指针，内存地址），翻译出来的直接引用也是存储在运行时常量池中。

运行时常量池 和 驻留字符串常量池 有什么联系？

jvm在执行某个类的时候，必须经过加载、连接、初始化，而连接又包括验证、准备、解析三个阶段。而当类加载到内存中后，jvm就会将class常量池中的内容存放到运行时常量池中，由此可知，运行时常量池也是每个类都有一个。在上面我也说了，class常量池中存的是字面量和符号引用，也就是说他们存的并不是对象的实例，而是对象的符号引用值。而经过解析（resolve）之后，也就是把符号引用替换为直接引用，解析的过程会去查询全局字符串池，也就是我们上面所说的StringTable，以保证运行时常量池所引用的字符串与全局字符串池中所引用的是一致的。

1
2
3
4
5
6
7
8
String str1 = "abc";
String str2 = new String("def");
String str3 = "abc";
String str4 = str2.intern();
String str5 = "def";
System.out.println(str1 == str3); // true
System.out.println(str2 == str4); // false
System.out.println(str4 == str5); // true

上面程序的首先经过编译之后，在该类的class常量池中存放一些符号引用，然后类加载之后，将class常量池中存放的符号引用转存到运行时常量池中，然后经过验证，准备阶段之后，在堆中生成驻留字符串的实例对象（也就是上例中str1所指向的”abc”实例对象），然后将这个对象的引用存到全局String Pool中，也就是StringTable中，最后在解析阶段，要把运行时常量池中的符号引用替换成直接引用，那么就直接查询StringTable，保证StringTable里的引用值与运行时常量池中的引用值一致，大概整个过程就是这样了。

回到上面的那个程序，现在就很容易解释整个程序的内存分配过程了，首先，在堆中会有一个”abc”实例，全局StringTable中存放着”abc”的一个引用值，然后在运行第二句的时候会生成两个实例，一个是”def”的实例对象，并且StringTable中存储一个”def”的引用值，还有一个是new出来的一个”def”的实例对象，与上面那个是不同的实例，当在解析str3的时候查找StringTable，里面有”abc”的全局驻留字符串引用，所以str3的引用地址与之前的那个已存在的相同，str4是在运行的时候调用intern()函数，返回StringTable中”def”的引用值，如果没有就将str2的引用值添加进去，在这里，StringTable中已经有了”def”的引用值了，所以返回上面在new str2的时候添加到StringTable中的 “def”引用值，最后str5在解析的时候就也是指向存在于StringTable中的”def”的引用值，那么这样一分析之后，下面三个打印的值就容易理解了。

“abc”的常量会被ldc指令从常量池推送到栈顶，ldc会触发动态解析。

参考资料