面试题系列第5篇：JDK的运行时常量池、字符串常量池、静态常量池，还傻傻分不清？

《Java面试题系列》：一个长知识又很有意思的专栏。深入挖掘、分析源码、汇总原理、图文结合，打造公众号系列文章，面试与否均可提升Level。欢迎持续关注【程序新视界】。本篇为第5篇。

【番外篇】本篇核心：JDK各个版本中JDK的运行时常量池、字符串常量池、静态常量池的功能及存储位置。

在写本系列文章时，发现一旦追究起底层实现都会涉及到一些内存结构的问题。其中涉及比较多的便是常量池，本篇文章汇总一下JDK的运行时常量池、字符串常量池、静态常量池的功能及存储结构。

在了解常量池之前我们先通过一张图了解一下JVM的整个内存分布图。下图为JDK7的内存结构：

在上图中JVM所管理的内存主要包括以下区域：程序计数器(Program Counter Register)、虚拟机栈(VM Stack)、本地方法栈(Native Method Stack)、方法区(Method Area)、堆(Heap)。

不同版本的JVM的内存结构有不同的变化，这些变化对我们今天要讲的三个概念会有所影响，后面我们会逐一讲解。

了解了JVM内存结构，那么运行时常量池、字符串常量池、静态常量池对于的都位于JVM的什么区域呢？先来看看它们的定义及功能。

Java程序要运行时，需要编译器先将源代码文件编译成字节码（.class)文件，然后在由JVM解释执行。

class文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池(Constant pool table)，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入运行时常量池中存放。

静态常量池就是上面说的class文件中的常量池。class常量池是在编译时每个class文件中都存在。不同的符号信息放置在不同标志的常量表中。

常量池中存放的符号信息，在JVM执行指令时需要依赖使用。常量池中的所有项都具有如下通用格式：

cp_info {
    u1 tag;     //表示cp_info的单字节标记位
    u1 info[];  //两个或更多的字节表示这个常量的信息，信息格式由tag的值确定
}

支持的类型信息如下：

以CONSTANT_Class为例，它用于表示类或者接口，格式如下：

CONSTANT_Class_info {
 u1 tag;       //这个值为CONSTANT_Class (7)
 u2 name_index;//一个index，表示一个索引，引用的是CONSTANT_UTF8_info
}

CONSTANT_Class_info类型是由一个tag和一个name_index组成。name_index中的index表示它是一个索引，引用的是CONSTANT_UTF8_info。

CONSTANT_Utf8_info用于表示字符常量的值，结构如下所示：

CONSTANT_Utf8_info {
 u1 tag;
 u2 length;
 u1 bytes[length];
}

tag表示为：CONSTANT_Utf8（1）；length指明了bytes[]数组的长度；bytes[]数组引用了上一个length作为其长度。字符常量采用改进过的UTF-8编码表示。

对于静态常量池我们需要知道它存在于编译器，如果说与运行时有关的话，可以说运行时中的常量是JVM加载class文件之后进行分配的。

运行时常量池就是将编译后的类信息放入方法区中，也就是说它是方法区的一部分。

运行时常量池用来动态获取类信息，包括：class文件元信息描述、编译后的代码数据、引用类型数据、类文件常量池等。

运行时常量池是在类加载完成之后，将每个class常量池中的符号引用值转存到运行时常量池中。每个class都有一个运行时常量池，类在解析之后将符号引用替换成直接引用，与全局常量池中的引用值保持一致。

运行时常量池相对于class文件常量池的另外一个特性是具备动态性，java语言并不要求常量一定只有编译器才产生，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。

字符串池里的内容是在类加载完成，经过验证、准备阶段之后存放在字符串常量池中。关于字符串常量池的具体实现我们这里先不展开，后面用专门的文章来进行讲解。

字符串常量池的处理机制我们前面文章已经讲到，只会存储一份，被所有的类共享。基本流程是：创建字符串之前检查常量池中是否存在，如果存在则获取其引用，如果不存在则创建并存入，返回新对象引用。

字符串常量池随着JDK版本的演化所在的位置也在不断的变化，下面我们会专门用图讲解一下。

在JDK1.7之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时hotspot虚拟机对方法区的实现为永久代。

在JDK1.7字符串常量池和静态变量被从方法区拿到了堆中，运行时常量池剩下的还在方法区, 也就是hotspot中的永久代。

在JDK8 hotspot移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆，运行时常量池还在方法区，只不过方法区的实现从永久代变成了元空间(Metaspace)

通过上面的图解，我们可以轻易得知在不同的版本中方法区及内部组成部分是在不断变化的。

通过本篇文章我们针对JDK的运行时常量池、字符串常量池、静态常量池进行逐一讲解，同时针对不同版本的JVM（hotspot虚拟机）中它们所处的内存位置进行了图解。

总结一下就是：静态变量处于编译器，存在于class文件内，可通过javap verbose命令查看字符串合并时查看的是静态常量池里面的内容；字符串常量池曾经属于运行时常量池的一部分，位于方法区，但随着JVM版本的演变，二者已经分开。在JDK8以后字符串常量池位于堆中，而运行时常量池位于方法区。

其实关于此部分的内容还有很多，特别是字符串常量池，欢迎大家持续关注。后续会对字符串常量池再进行针对性的分析。在此过程中也发现很多文章在没有指定JDK版本的情况下进行描述，都有失偏驳。本系列为大家考证，去伪存真。

参考文章：
https://blog.csdn.net/qq_31615049/article/details/81611918
https://blog.csdn.net/weixin_43232955/article/details/107411378

面试题系列第5篇：JDK的运行时常量池、字符串常量池、静态常量池，还傻傻分不清？插图6

关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台

除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接

程序新视界，一个软实力、硬知识同时提升的平台