"Java Interview Question Series": A long knowledge and very interesting column. In-depth digging, analyzing the source code, summarizing the principles, combining pictures and texts, creating a series of articles on the official account, and raising the level for interviews or not. Welcome to continue to pay attention to [Program New Vision]. This is the fifth one.
[Extras] The core of this article: the functions and storage locations of the runtime constant pool, string constant pool, and static constant pool of the JDK in each version of the JDK.
When writing this series of articles, I found that once the underlying implementation is investigated, some memory structure issues will be involved. One of the more involved is the constant pool. This article summarizes the functions and storage structure of the JDK's runtime constant pool, string constant pool, and static constant pool.
JVM runtime memory structure
Before understanding the constant pool, let's take a picture to understand the entire memory distribution diagram of the JVM. The following figure shows the memory structure of JDK7:
In the above figure, the memory managed by JVM mainly includes the following areas: Program Counter Register, VM Stack, Native Method Stack, Method Area, Heap .
The memory structure of different versions of JVM has different changes, these changes will have an impact on the three concepts we are going to talk about today, we will explain them one by one later.
Knowing the JVM memory structure, what area of the JVM are the runtime constant pool, string constant pool, and static constant pool located in? Let's take a look at their definitions and functions first.
Static constant pool
When a Java program is to be run, a compiler is required to first compile the source code file into a bytecode (.class) file, which is then interpreted and executed by the JVM.
In addition to the description information of the class version, fields, methods, and interfaces in the class file, there is also a constant pool (Constant pool table), which is used to store various literal and symbolic references generated during compilation. This part of the content Will be stored in the runtime constant pool after the class is loaded.
The static constant pool is the constant pool in the class file mentioned above. The class constant pool exists in every class file at compile time. Different symbol information is placed in the constant table of different flags.
The symbol information stored in the constant pool needs to be used when the JVM executes instructions. All items in the constant pool have the following general format:
cp_info {
u1 tag; //表示cp_info的单字节标记位
u1 info[]; //两个或更多的字节表示这个常量的信息，信息格式由tag的值确定
}
The supported type information is as follows:
Taking CONSTANT_Class as an example, it is used to represent a class or interface, and the format is as follows:
CONSTANT_Class_info {
u1 tag; //这个值为CONSTANT_Class (7)
u2 name_index;//一个index，表示一个索引，引用的是CONSTANT_UTF8_info
}
The CONSTANT_Class_info type is composed of a tag and a name_index. The index in name_index indicates that it is an index, which refers to CONSTANT_UTF8_info.
CONSTANT_Utf8_info is used to represent the value of a character constant, the structure is as follows:
CONSTANT_Utf8_info {
u1 tag;
u2 length;
u1 bytes[length];
}
The tag is expressed as: CONSTANT_Utf8 (1); length indicates the length of the bytes[] array; the bytes[] array refers to the previous length as its length. Character constants are represented by an improved UTF-8 encoding.
For the static constant pool, we need to know that it exists in the compiler. If it is related to the runtime, it can be said that the constants in the runtime are allocated after the JVM loads the class file.
Runtime constant pool
The runtime constant pool is to put the compiled class information into the method area, which means that it is part of the method area.
The runtime constant pool is used to dynamically obtain class information, including: class file meta information description, compiled code data, reference type data, class file constant pool, etc.
The runtime constant pool is to dump the symbol reference value in each class constant pool to the runtime constant pool after the class is loaded. Each class has a runtime constant pool. After the class is resolved, the symbolic reference is replaced with a direct reference, which is consistent with the reference value in the global constant pool.
Another feature of the runtime constant pool compared to the class file constant pool is that it is dynamic. The java language does not require constants to be generated only by the compiler, that is, the content of the constant pool is not preset into the class file to enter the method area to run Time constant pool, new constants may also be put into the pool during operation.
String constant pool
The content in the string pool is stored in the string constant pool after the class is loaded, verified and prepared. Regarding the specific implementation of the string constant pool, we will not expand it here, and will explain it in a special article later.
The processing mechanism of the string constant pool has been mentioned in the previous article. Only one copy will be stored and shared by all classes. The basic process is: check whether the string exists in the constant pool before creating the string, if it exists, get its reference, if it does not exist, create and save it, and return the new object reference.
The location of the string constant pool is constantly changing with the evolution of the JDK version. Below we will specifically explain it with a picture.
Constant pool memory location evolution
Before JDK1.7, the runtime constant pool logic included a string constant pool stored in the method area. At this time, the hotspot virtual machine implements the method area as a permanent generation.
In JDK1.7, the string constant pool and static variables are taken from the method area to the heap, and the rest of the runtime constant pool is still in the method area, which is the permanent generation in hotspot.
In the JDK8 hotspot, the permanent surrogate metaspace (Metaspace) was removed and replaced. At this time, the string constant pool is still in the heap, and the runtime constant pool is still in the method area, but the implementation of the method area has changed from permanent generation to metaspace (Metaspace). )
Through the above diagram, we can easily know that the method area and internal components are constantly changing in different versions.
summary
Through this article, we explain the runtime constant pool, string constant pool, and static constant pool of JDK one by one, and illustrate the memory locations of different versions of JVM (hotspot virtual machine).
To summarize, static variables are in the compiler and exist in the class file. You can use the javap verbose command to view the contents of the static constant pool when the string is merged; the string constant pool used to be part of the runtime constant pool, located Method area, but with the evolution of JVM version, the two have been separated. After JDK8, the string constant pool is located in the heap, and the runtime constant pool is located in the method area.
In fact, there are many more about this part, especially the string constant pool, welcome everyone to continue to pay attention. The string constant pool will be analyzed in the future. In the process, it was also found that many articles described without specifying the JDK version, which were all unbiased. This series is for everyone to research, remove the false and keep the truth.
Original link: " Interview Question Series No. 5: JDK runtime constant pool, string constant pool, static constant pool, still stupid and confused? 》
Reference article:
https://blog.csdn.net/qq_31615049/article/details/81611918
https://blog.csdn.net/weixin_43232955/article/details/107411378
