Java memory distribution summary and detail

Java Memory distribution: During the execution of Java programs, the Java virtual machine divides the memory it manages into several different data areas: method area, virtual machine stack, local method stack, heap, program counter.

1. Program counter

The program counter is a small memory space that can be thought of as a line number indicator of the bytecode being executed by the current thread. In the conceptual model of a virtual machine, the bytecode interpreter works by changing the value of this counter to select one bytecode instruction that needs to be executed.

Basic functions such as branching, looping, jumping, exception handling, and thread recovery all depend on this counter.

In order to restore to the correct execution position after the thread switch, each thread needs to have an independent program counter, each thread counters do not affect each other, independent storage, so this kind of memory area is "thread private" memory.

If the thread is executing an Java method, this counter records the address of the virtual machine bytecode instruction being executed. If the Native method is being executed, the counter value is empty, and this memory area is the only area with 11 children that is not specified in the Java virtual machine specification for OutOfMemoryError.

Java virtual machine stack

Like program counter 1, the Java virtual machine stack is also thread private and has the same lifetime as the thread. The virtual machine stack describes the memory model executed by the Java method. Each method creates a stack frame to store information such as local variables, operands, dynamic links, method exits, etc.

Each method from the call to the completion of execution corresponds to a stack frame in the virtual machine stack to stack out of the process.

The local variational scale contains various basic data types known at compile time, object references (which are not equivalent to objects but refer to objects), and returnAddress types. An StackOverflowError exception is thrown if the thread requests more stack depth than the virtual machine allows, and an OutOfMemory exception is thrown if sufficient memory cannot be requested.

3. Local method stack

The difference between the local method stack and the virtual machine stack is that the virtual machine stack serves the Java(bytecode) methods executed by the virtual machine, while the local method stack serves the Native methods used by the virtual machine.

4. Java heap

The Java heap is a 1 block of memory Shared by all threads and created at virtual machine startup. The only purpose of this memory area is to hold object instances, and the Java heap is the primary area managed by the garbage collector

5. Methods area

The method area, like Java heap 1, is the memory area Shared by each thread, used to store the class information loaded by the virtual machine, constants, static variables, real-time compiler compiled code and other data.

6. Run-time constant pool

The runtime constant pool is part of the method area. In the Class file, in addition to the description information of the class version, fields, methods, interfaces, etc., there is also one piece of information that is the constant pool, which is used to store various literal and symbolic references generated at compile time. This part of information will be stored in the runtime constant pool of the method area after the class is loaded.

Many explanatory constant pools on the web use strings as an example:

Such as

String s1 = "Hello";
String s2 = "Hello";
String s3 = "Hel" + "lo";
String s4 = "Hel" + new String("lo");
String s5 = new String("Hello");
String s6 = s5.intern();
String s7 = "H";
String s8 = "ello";
String s9 = s7 + s8;
 
System.out.println(s1 == s2); // true
System.out.println(s1 == s3); // true
System.out.println(s1 == s4); // false
System.out.println(s1 == s9); // false
System.out.println(s4 == s5); // false
System.out.println(s1 == s6); // true

s1==s2 is true and points to the memory address of the same constant pool.

s1==s3 = true: for s3, the compiler optimizes because the splicing is literal, which means s3="Hello"

s1==s4 is false: since new String("lo") is not a literal, but a variable, the compiler will not optimize because the variable may change.

s1==s9.

s4==s5: References to two different objects are of course different.

s1==s6: Since the String.intern () method is: returns a string in the pool if the constant pool already contains a string equal to the String object, as determined by the equals(Object) method. Otherwise, add this String object to the pool and return a reference to this String object. It follows for any two strings s and t, s.intern () == t.intern () if and only if s.equals (t) is true.

I hope you found this article helpful