Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "the difference of JVM memory partition, stack area, stack area and method area in java". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Now use a picture to introduce the content stored in each area.

How do you understand the runtime datazone?

The JVM runtime first needs the class loader (classLoader) to load the bytecode file of the desired class. After loading, it is left to the execution engine, and a section of space is needed to store data during execution (analogy CPU to main memory). This process of allocating and freeing memory space is exactly the runtime data area that we need to care about.

Runtime data area

The runtime data area includes program counters, method areas (including constant pools), virtual machine stacks, local method stacks, and heaps. JVM itself is a virtual computer, the purpose is to achieve a compilation everywhere execution.

Program counter

A program counter is a small piece of memory. It can be thought of as a bytecode line number indicator executed by the current thread. The bytecode interpreter's job is to select the next bytecode instruction to be executed by changing the value of the counter. Basic functions such as branches, loops, jumps, exceptions, and thread recovery all rely on this counter.

Because the multithreading of the JVM virtual machine is realized by the thread switching in turn and allocating the processor execution time, at any given moment, a processor (a core for a multi-core processor) will only execute instructions in one thread. When switching to another thread, if you do not save the execution location of the current unfinished thread, the next time the processor executes the thread, it will restart execution. This situation is obviously intolerable. Therefore, in order to restore to the execution position correctly after thread switching, each thread needs to have an independent program counter, which does not affect each other and is stored independently. We call this kind of memory area 'thread private' memory.

If the thread is executing a java method, this counter records the address of the executing virtual machine bytecode instruction, and if the native method is being executed, the counter is (undefined). This memory area is an area that does not specify any OutOfMemoryError conditions in the java virtual machine specification.

Java virtual machine stack

Like the program counter, the java virtual machine is also thread-private, and its life cycle is the same as thread. the virtual machine stack describes the memory model of the execution of the java method: each method creates a stack frame at the same time (Stack Frame, it can be understood that the stack frame, the virtual machine stack contains N stack frames each stack frame contains local variables, Operand stack, dynamic links, method exit and other information). From the call to the completion of the process, each method corresponds to the process from the stack to the unstack of the stack frame in the virtual machine stack.

People often divide java memory into heap memory and stack memory, which is actually very rough, and the division of java memory is much more complicated than this. It can only show that traditional programmers are most concerned about these two memory heaps and stacks that are most closely related to object memory allocation. The stack is now called the virtual machine stack, or the local variable table part of the stack frame in the virtual machine stack.

The local variable table stores various basic data types (boolean,byte,char,short,int,float,long,double) known at compile time, object references (reference types, which are not equivalent to the object itself, and may be a reference pointer to the starting address of the object, or a handle to a representative object or other related location), and the returnAddress type (the address that points to a bytecode instruction).

The 64-bit long and double types occupy two local variable spaces, while the rest of the data types take up only one local variable space. The memory space required by the local variable table is allocated during compilation. When entering a method, how much memory space this method needs to allocate in the frame is completely determined, and the size of the local variable table will not be changed during the operation of the method.

In the java virtual machine specification, two exception states are specified for this area: if the depth of the stack requested by the thread is greater than the depth allowed by the virtual machine, a StackOverFlowError exception (stack overflow) will be thrown, if the virtual machine stack can be dynamically expanded (most java virtual machines can be expanded dynamically now, but the fixed-length java virtual machine stack is also allowed in the java virtual machine specification). If the extension cannot apply for sufficient memory space An OutOfmMemoryError exception is thrown (not enough memory)

Local method stack

The role of the local method stack (Native Method Stacks) is very similar to that of the virtual machine stack, except that the virtual machine stack executes java methods (that is, bytecode) services for the virtual machine, while the local method stack serves the local Native methods used by the virtual machine. The usage, language, and data structures of the local method stack are not mandatory in the virtual machine specification. So the specific virtual machine is free to implement it. Even some virtual machines (such as Sun HotSpot virtual machines) directly combine the local method stack and the virtual machine stack into one. Like the virtual machine stack, the local method stack also throws StackOverFlowError and OutOfmMemoryError exceptions

Java reactor

For most applications, the java heap (java Heap) is the largest piece of java virtual machine management memory. The java heap is a memory management area shared by all threads and is created when the virtual machine starts. The sole purpose of this memory area is to hold an instance of the object. Almost all object instances allocate memory in the heap. This is described in the java virtual machine specification: all object instances and arrays should be allocated on the heap, but with the development of JIT compiler and escape technology gradually mature, on-stack allocation, scalar replacement optimization technology will lead to some subtle changes, all objects allocated on the heap is not so "absolute".

The java heap is the main area managed by the garbage collector, so it is often called the GC heap (Garbage Collected Heap). From the perspective of memory recovery, because the current collectors basically use generation-by-generation collection algorithm, the java heap can also be subdivided into: new generation and old generation: in a more detailed division can be divided into: Eden space, From Survivor space, To Survivor space and so on. From the perspective of memory allocation, the thread-shared java heap may be divided into multiple thread-private allocation buffers, but no matter how the partition has nothing to do with the storage content, no matter which area is stored in the object instance. The purpose of further partitioning is to better reclaim memory, or to allocate memory faster.

According to the java virtual machine specification, the java heap can be in physically discontiguous memory space, as long as it is logically continuous, just like our disk space. The implementation can be either fixed size or scalable size, but the current mainstream virtual machines are implemented according to extensibility (controlled by-Xmx and-Xms). If there are no memory instances in the heap to complete the allocation, and the heap cannot be extended, an OutOfMemoryError will be thrown.

Method area

The method area, like the java heap, is a memory area shared by each thread. It is used to store class information, constants, static variables, compiled code and other data that have been loaded by the virtual machine. Although the java virtual machine specification describes the method area as part of the heap, it also has an individual called Non-heap (non-heap), which is supposed to distinguish it from the java heap.

The java virtual machine specification has very loose restrictions on the normal zone, and you can choose not to implement garbage collection except that you don't need contiguous memory and can choose to be fixed or scalable like the java heap. Garbage collection is relatively rare in this area, but it is not as permanent as the name of the permanent generation when the data enters the method area. The important goal of memory recovery in this area is to reclaim constant pools and unload types. Generally speaking, the 'results' of memory recovery in this area are not satisfactory. In particular, the unloading conditions of the type are very stringent, but this part of the recycling is indeed necessary. Several serious bug that have appeared in sun's bug list are memory spills caused by unfinished recycling of this area by an earlier version of the HotSpot virtual machine.

Here are three concepts to be clear about.

1 constant pool (Constant Pool): the constant pool data compiler is identified as part of the class file, storing constants in classes, methods, interfaces, etc., including string constants, of course.

Constant pool: can be understood as the resource repository in the Class file, which is the data type most associated with other project resources in the Class file structure.

There are two main types of constants stored in the constant pool: literal quantities (Literal) and symbolic references (Symbolic Reference).

Literals: text strings, constant values declared as final, etc.

Symbolic references: fully qualified names of classes and interfaces (Fully Qualified Name), field names and descriptors (Descriptor), method names and descriptors

2 string pool / string constant pool (String Pool/String Constant Pool): part of the constant pool that stores string type data generated by the compiler

3 run time pool (Runtime Constant Pool): part of the method area, shared by all threads. After loading the class file, the virtual machine stores the data in the constant pool to the runtime constant pool.

It is important to note that before JDK1.6, string constant pools existed in the method area, and in JDK1.7 and above string constant pools existed in the heap.

In JDK 7, interned strings are no longer allocated in the permanent generation of the Java heap, but in the main parts of the Java heap (called young and old generation), as well as other objects created by the application. This change will cause more data to reside in the primary Java heap and less data in a permanent build, so you may need to resize the heap. As a result of this change, most applications see relatively small differences in heap usage, but larger applications load many classes or use string. The intern () method will see a more significant difference. If you have any questions, please refer to http://blog.csdn.net/u014039577/article/details/50377805 for testing.

Direct memory

Direct memory is not part of the running memory of a virtual machine, nor is it a memory area defined in the java virtual machine specification. However, this part of the memory area is also frequently used, which may also lead to OutOfMemoryError exceptions.

A new NIO (New Input/Output) class is added to jdk1.4, which introduces an Ijdk1.4 O method based on Channel and Buffer, which can directly allocate out-of-heap memory using a local function library and then operate as a reference to this memory through a DirectByteBuffer object stored in the java heap, which can significantly improve performance in some scenarios because it avoids copying data back and forth between the java heap and the Native heap.

Obviously the allocation of native direct memory is not limited by the java heap size, but since it is memory. It will certainly be limited by the total memory of the machine. The server administrator will configure the virtual machine memory parameters according to the actual memory setting-Xmx and other parameter information. However, direct memory is often ignored, so that the sum of each memory area is greater than the physical memory limit (including physical and operating system-level limits), resulting in OutOfMemoryError exceptions during dynamic expansion.

=

Case demonstration:

Demo1

Data preparation

Main class

/ / at run time, jvm puts all the AppMain information into the method area public class AppMain {/ / main method itself into the method area public static void main (String [] args) {Sample test1 = new Sample ("Test 1"); test1.printName ();}}

Sample class

After the public class Sample {private String name; / / new Sample instance, the reference is put into the stack area, and the object is put into the heap public Sample (String name) {this.name = name;} / / printName method itself into the method area public void printName () {System.out.println (name);}}

Interaction of stacks, heaps, and method areas in JVM

=

Demo2public class baseTest {public static void main (String [] args) {/ / create an instance of the Car class and start loading Car car1 = new Car (4, "red") into memory through JVM; car1.show (); Car car2 = new Car (2, "black"); car2.show ();} class Car {private int wheelNum;// member variable (heap) private String color / / member variable (heap) public Car () {} public Car (int w, String c) {/ / formal parameter wjournal c is a local variable (stack) this.wheelNum = w; this.color = c;} public void show () {/ / method name show is put in the method area System.out.println ("car:wheelNum-" + wheelNum+ "color-" + color);}}

=

Next, use a small example to learn more about the stack.

String str = "a"

String strr = "bc"

String str1 = "abc"; / / define the string variable str1

String str2 = "abc"; / / define the string variable str2

String str3 = new String ("abc"); / / define the string variable str3 as new

String str4 = new String ("abc"); / / define the string variable str4 as new

String str5 = str + strr

String str6 = "a" + "bc"

Results:

* str1 = = str2 true; ①

* str2 = = str3 false; ②

* str3 = = str4 false; ③

* str1 = = str5 false; ④

* str1.equals (str5) true; ⑤

* str1==str6 true; ⑥

Explanation:

'=' compares the address

Str1 and str2 obviously point to an address in the constant pool in String. (two ways to create String sent by he Linghong last time)

Equals compares content.

① true because the address is the same

Because of the new used by str3, ② is equivalent to creating a heap address in the String class heap. The address of str2 is in the constant pool. The address does not match, so false

The principle of ③ and ② is the same, which means that new has two objects, that is, each has its own address. So false.

④ str5 uses the addition of string variables. When you look at the source code of String, you will find the str.append () method. Essentially, you new a Stringbuilder object, then use it for append, and finally the Builder object toStirng returns to the String type. That is, the address has changed.

Results:

⑤ compares content, so it is true

⑥ may be confused when he sees this, but I was confused at first. When you think about it later, str6 in this case is stitching in the constant pool (point to it directly if it exists; create stitching if it doesn't exist)

This is the content of "the difference of JVM memory partition, stack area, stack area and method area in java". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.