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

Today, I will talk to you about the knowledge related to the memory structure of JVM, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

JVM memory structure means that the Java virtual machine defines several runtime data areas that will be used during the running of the program, some of which will be created as the virtual machine starts and destroyed as the virtual machine exits, while others correspond to the thread one by one, created with the beginning of the thread and destroyed with the end of the thread. The specific runtime data area is shown in the following figure:

In the Java virtual machine specification, five kinds of runtime data zones are defined, which are Java heap, method area, virtual machine stack, local method area and program counter, in which Java heap and method area are shared by threads. Let's take a look at these five runtime data areas in detail.

Java heap (Heap)

The Java heap is an area of memory shared by all threads, it is created when the virtual machine starts, and a single JVM process has one and only one Java heap. The Java heap is used to store object instances and arrays, which means that all the objects in our code that are new through the new keyword are stored here. So here is the main activity camp for the garbage collector, so it has an alias called GC heap. According to the rules of garbage collector, we can further divide the Java heap. The specific Java heap memory structure is shown in the following figure:

We can divide the Java heap into two large modules: the new generation and the old age. In the new generation, we can be further divided into Eden space, From Survivor space (s0) and To Survivor space (S1). One of the Survivor space is empty, which is used to store living objects when GC occurs. In the old era, objects that are still alive after many times of Minor GC or some large objects are stored, and FGC occurs in the old era.

The above is the specific structure of the Java heap. We also know that the size of each space in the Java heap can be dynamically controlled. I also briefly marked this in the figure. Let's take a detailed look at these three parameters:

The initial heap value applied for when Xms:JVM starts, defaults to 1x64 of the operating system physical memory, for example, the maximum heap value that can be applied for by-Xms20m-Xmx:JVM, and the default value is 1x4 of physical memory. For example,-Xmx20m, we'd better set-Xms and-Xmx to the same value to avoid JVM redistributing memory after each garbage collection. -Xmn: set the memory size of the new generation.-Xmn sets NewSize and MaxNewSize to the same size. We can also set these two parameters separately.

An OOM exception occurs in the Java heap. When there is enough space in our Java heap to complete instance allocation, and the heap cannot be expanded, our common OutOfMemoryError exception will be thrown, as shown in the following figure:

With regard to the OOM exception, I still want to say that there is a very popular interview question on the Internet: after the JVM heap memory overflow, can other threads continue to work? Personally, I think many of the answers are wrong. Those who are interested can study them.

Method area (Method Area)

Like the Java heap, the method area (Method Area) is the memory area shared by each thread and the only two memory sharing area in the Java virtual machine. In the Java virtual machine specification, the method area is defined in this way: it stores the structural information of each class, such as the bytecode contents of runtime constant pools, fields, method data, constructors, and common methods, as well as special methods used in class, instance, and interface initialization.

The method area is created when the virtual machine starts. Although the method area is a logical part of the heap, a simple virtual machine implementation can choose not to implement garbage collection and compression in this area. The method area may not be continuous in the actual memory space. For the capacity of the method area, you can be fixed, or you can dynamically expand as the program executes, and automatically shrink when you do not need too much space.

The above are all the specifications in the Java virtual machine. Let's take a look at the specific implementation. Take our commonly used HotSpot virtual machine. Before JDK1.8, the method area was also called permanent generation. This method area will have our common java.lang.OutOfMemoryError: PermGen space exception. We can also control the size of the method area through startup parameters:

-XX:PermSize sets the minimum space-XX:MaxPermSize sets the maximum space

After JDK1.8, the HotSpot virtual machine has made a lot of changes to the normal area, removing the permanent generation completely, migrating the data originally stored in the permanent generation to the Java heap or Metaspace, the method area has been moved to Metaspace, and the string constant has been moved to Java Heap, in other words, starting with JDK1.8, Metaspace is what we call the method zone, why do we have to make this change? It may be for two reasons:

Because PermGen memory often overflows, leading to the annoying java.lang.OutOfMemoryError: PermGen, JVM developers hope that this piece of memory can be managed more flexibly, and that removing PermGen from OOM will promote the integration of HotSpot JVM and JRockit VM, because JRockit does not have a permanent generation.

We can also control the space size of Metaspace by setting parameters, mainly with the following commands:

-XX:MetaspaceSize: the initial size allocated to the class metadata space in bytes. The value of MetaspaceSize is set too much to extend the garbage collection time. After garbage collection, the size of the class metadata space that causes the next garbage collection may become larger. -XX:MaxMetaspaceSize: the maximum value allocated to the class metadata space, beyond which Full GC is triggered. This value is unlimited by default, but depends on the size of the system memory. JVM changes this value dynamically. -XX:MinMetaspaceFreeRatio: indicates that after a GC, in order to avoid increasing the size of metadata space, the minimum proportion of free class metadata capacity will lead to garbage collection if not enough. -XX:MaxMetaspaceFreeRatio: indicates that after a GC, in order to avoid increasing the size of metadata space, the maximum proportion of free class metadata capacity will lead to garbage collection if not enough.

Java virtual machine stack (JVM Stacks)

Each Java virtual machine thread has its own private Java virtual machine stack, which is created at the same time as the thread, so it has the same life cycle as the thread. Java virtual machine stack describes the memory model of Java method execution: each method creates a stack frame while executing, which is used to store local variables, Operand stack, dynamic link, method exit and other information. The process of each method from call to execution corresponds to the process of stack frame entering into and out of stack in Java virtual machine stack.

The local variable table stores various basic data types known at compile time (boolean, byte, char, short, int, float, long, double) and object reference (reference type, which is different from the object itself. Depending on the virtual machine implementation, it may be a reference pointer to the starting address of the object. It may also point to a handle or other location associated with the object and the returnAddress type (the address that points to a bytecode instruction).

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

The Java virtual machine stack not only allows it to be implemented to a fixed size, but also allows it to expand and contract according to computational dynamics. If the fixed size is adopted, the Java virtual machine stack capacity of each thread can be independently selected when the thread is created. Two exceptions occur in the Java virtual machine stack, which are indicated in the virtual machine specification:

If the thread requests to allocate more stack capacity than the maximum allowed by the Java virtual machine stack, the Java virtual machine will throw a StackOverflowError exception; if the Java virtual machine stack can be dynamically expanded and cannot apply for enough memory when trying to expand, or if there is not enough memory to create the corresponding Java virtual machine stack when creating a new thread, then the virtual machine will throw an OutOfMemoryError exception.

Program counter (Program Counter Register)

The program counter is also thread private, it only needs a small piece of memory space, you can think of it as a line number indicator of the bytecode executed by the current thread, in the conceptual model of the virtual machine (only the conceptual model, various virtual machines may be implemented in some more efficient ways), the bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to be executed Basic functions such as branching, looping, jumping, exception handling, thread recovery, and so on, all rely on this counter.

We know that in the case of multithreading, it is not one thread that executes all the time, but multiple threads switch in turn, so in order to restore to the correct execution position after the thread switch, we need a program counter to tell the thread which instruction to execute next. If the thread is executing a Java method, the counter records the address of the executing virtual machine bytecode instruction, and if the Natvie method is being executed, the counter value is Undefined.

It is important to note that program counters are the only area where no OutOfMemoryError situation is specified in the Java virtual machine specification.

Local method stack (Native Method Stacks)

The role of the native method stack (Native Method Stacks) is very similar to that of the Java virtual machine stack, except that the Java virtual machine stack performs Java methods (that is, bytecode) services for the virtual machines, while the local method stacks serve the Native methods used by the virtual machines. The language, usage and data structure of the methods in the local method stack are not mandatory in the virtual machine specification, so the specific virtual machine can implement it freely. Some virtual machines (such as the Sun HotSpot virtual machine) directly combine the local method stack and the virtual machine stack into one.

Like the Java virtual machine stack, the local method stack area throws StackOverflowError and OutOfMemoryError exceptions.

After reading the above, do you have any further knowledge about the memory structure of JVM? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.