Java Virtual Machine (1) runtime data area

Java Virtual Machine (1) runtime data area

1. There is a "high wall" between Java and C ++ that is surrounded by the dynamic memory allocation and garbage collection technology. The people inside the wall want to go in, but they want to come up.

2. Division of runtime data regions

During java program execution, the java Virtual Machine divides the memory it manages into several regions, each of which has its own purpose, Creation Time, and destruction time, some regions exist with the startup of virtual machine processes, and some regions are established and destroyed Based on the startup and termination of user threads. According to the provisions of Java virtual machine specification (Java SE 7, java virtual machines are divided into the following areas.

　　

　　2.1 Program Counter (Program Counter Register)

The program counter is a private thread and a small space. It can be seen as the row number indicator of the bytecode executed by the current thread. When the bytecode interpreter is working, it selects the next bytecode instruction to be executed by changing the value of this counter. Each thread has an independent counter. counters between threads do not affect each other and are stored independently. This memory region is the only region in which the Java Virtual Machine specification does not specify any OutOfMemoryError conditions.

　2.2 Java Virtual Machine Stack (VM Stack)

Similar to program counters, they all belong to the thread and have the same lifecycle as the thread. They describe the Memory Model of java method execution. Each method creates a stack frame for execution, stores information such as local variable tables, Operation stacks, dynamic links, and method exits. Each method is called until the execution is complete, it corresponds to the process of a stack frame in the VM Stack from the inbound stack to the outbound stack. The local variable table stores the basic data types (Boolean, byte, char, short, int, float, long, and double) known during the compilation period, and references of the object.

This area specifies two exceptions: If the stack depth requested by the thread is greater than the depth allowed by the virtual machine, an StackOverflowError exception will be thrown; when the Virtual Machine stack is dynamically expanded, an OutOfMemoryError will be thrown if you cannot apply for sufficient memory.

　2.3 Native Method Stack)

The local method stack and the virtual machine stack play a very similar role. The difference between them is that the virtual machine stack executes the Java method (also known as bytecode) service for the virtual machine, the local method stack is the Native method service used by virtual machines.

Example (StackOverflowError ):

　　

 1 public class TestStackSOF { 2     public long stackLenth = 1; 3      4     public void stackSOF(){ 5         stackLenth++; 6         System.out.println(stackLenth); 7         stackSOF(); 8     } 9     public static void main(String[] args) {10         TestStackSOF tss = new TestStackSOF();11         try{12             tss.stackSOF();13         }catch(Throwable e){14             System.out.println("stackLenth: "+tss.stackLenth);15             try {16                 throw e;17             } catch (Throwable e1) {18                 // TODO Auto-generated catch block19                 e1.printStackTrace();20             }21         }22     }23 }

Execution result:

StackLenth: 326323

Java. lang. StackOverflowError

At com.cn. TestStackSOF. stackSOF (TestStackSOF. java: 9)

At com.cn. TestStackSOF. stackSOF (TestStackSOF. java: 9)

If you adjust-Xss to 50 M, the execution result is:

StackLenth: 1637043

Java. lang. StackOverflowError

At com.cn. TestStackSOF. stackSOF (TestStackSOF. java: 9)

At com.cn. TestStackSOF. stackSOF (TestStackSOF. java: 9)

Conclusion: It is not difficult to see that the-Xss size is different and the execution results are different. If you encounter a java. lang. StackOverflowError exception in the project in the future, you can first check whether the Code has infinite recursion. If not, you can increase the size of-Xss to see the running effect.

　2.4. Java Heap)

Java heap is the largest memory area managed by the java Virtual Machine and shared by all threads. The only purpose of this region is to store object instances, where almost all object instances allocate memory.

Java heap is the main area for managing the Garbage Collector, also known as "GC Heap".

The size of the java heap can be expanded. It is controlled by-Xmx and-Xms. If the heap does not have memory to allocate instances and the heap cannot be expanded, an OutOfMemoryError error will be thrown.

Example (OutOfMemoryError ):

　　

import java.util.ArrayList;import java.util.List;public class TestHeapOOM {    /**     * vm args -Xmn120M -Xmx1024M     */    public static void main(String[] args) {        List<String> list = new ArrayList<String>();        while(true){            list.add("sss");        }    }}

Running result:

Exception in thread "main" java. lang. OutOfMemoryError: Java heap space

At java. util. Arrays. copyOf (Unknown Source)

　　2.5 Method Area)

Same as the Java heap, the method area is used to store data such as class information, constants, static variables, and Code Compiled by the real-time compiler loaded by virtual machines. The method area is also called "permanent generation", not the permanent existence of index data. The memory recovery target in this region is mainly for the collection of constant pools and the uninstallation of types. The recovery results in this region are quite unsatisfactory, especially for Type offloading. The conditions are quite harsh. However, this part of memory recycling is necessary. When the method area cannot meet the memory allocation requirements, an OutOfMemoryError error is thrown.

　2.6 Direct Memory (Direct Area)

Direct Memory is not part of the VM runtime data zone, nor is it the memory zone defined in the Java VM specification. However, this part is frequently used and may cause an OutOfMemoryError error.

Direct Memory is not limited by the Java heap size. NIO (New Input/Output) class is added to JDK1.4. NIO Buffer provides a class that can directly access the physical memory of the system-DirectBuffer. The DirectBuffer class inherits from ByteBuffer, but it is different from the normal ByteBuffer class. The general ByteBuffer still allocates memory on the JVM stack, and its maximum memory is limited by the maximum heap memory. DirectBuffer is directly allocated to the physical memory and does not occupy the heap space. When accessing a common ByteBuffer, the system always uses a "kernel buffer" for operations. The location of DirectBuffer is equivalent to the "kernel buffer ". Therefore, using DirectBuffer is a method closer to the underlying memory, so it is faster than a common ByteBuffer.