The Java virtual machine (JVM) contains the bytecode data stored in the memory of the Java virtual machine (JVM) after the class is loaded. How does the Java virtual machine allocate memory for class instances or member variables? Yes, these two questions involve knowledge of JVM memory structure, so this article will answer them.
@[toc]
1. Memory structure or runtime data area?
To answer the questions in this article, we first need to understand the memory structure of the Java virtual machine.
In one sense, the Memory structure of the Java virtual machine is equal to the run-time data area. There is no such thing as a memory structure in the Java Virtual Machine Specification, which uses the term run-time data area. Memory structure just sounds more appropriate and graphic, so it’s good to know that memory structure means run-time data area! There’s no need to dwell on it
2. Runtime data area
The JVM is divided into three main subsystems: the classloader subsystem, the runtime data area, and the execution engine. Today’s article focuses on Runtime Data Areas.
The heap
The stack
By the way, the run-time constant pool also goes into the method area, which means that the method area already contains the constant pool.
Note in particular that the Java heap and method area are shared by threads. Everything else is thread private.
Thread sharing: Java heap, method area
Let’s start by taking a look at the Java heap and method area shared by threads!
3.1, the Java heap
The Java heap is shared by all threads and is created when the virtual machine starts
The Java heap is the largest area of memory that is occupied, and the Java heap is used to hold object instances and arrays, which means that objects in our code are stored there with the new keyword new. This became the main camp for the garbage collector, hence the nickname GC heap, and a single JVM process has one and only one Java heap. According to the rules of the garbage collector, we can further divide the Java heap, as shown in the following figure:
In fact, the Java heap is based on object lifetime
Java heap = old + New generation
Cenozoic = Eden + S0 + S1
Default Eden: from: to = 8:1:1
JVM parameters can be used to dynamically control the size of the Java heap. There are a number of JVM parameters that can be used to dynamically control the size of the Java heap. It’s easy to remember when you use it. Here are some common JVM parameters for a heap:
-Xms: indicates the initial size of the heap capacity (the heap includes the new generation and the old generation). For example, -xms 20m-xmx: indicates the total (maximum) size of the heap. For example: -xmx 30M Note: It is recommended to set -xms and -xmx to the same value to avoid the JVM reallocating memory after each garbage collection is complete! -Xmn: Indicates the capacity of the Cenozoic era. For example, -xmn 10M-XX: SurvivorRatio Sets the ratio of Eden, form, and TO. The default ratio is 8:1:1. For example, -xx: SurvivorRatio=8 indicates the ratio 8:1:1
Although you do not set the old age parameters directly, you can set the heap space size and the new generation space size to indirectly control: old age space size = heap space size – young generation large space size
A common OutOfMemoryError, also known as an OOM exception, will be thrown when there is enough space in the Java heap to complete the instance allocation and the heap cannot expand
3.2 Can other threads continue to work after JVM heap memory runs out?
If the JVM has run out of heap memory, can other threads continue to work?
In fact, this problem requires specific scenario analysis. But in general, the OOM thread will die (unless the code is poorly written), and the heap used by the object held by that thread will be gc, freeing memory. Since gc is performed before OOM occurs, even if other threads are working properly, frequent gc will have a significant impact.
In other words, the thread in OOM will die, which means it will be terminated, and the heap used by the object in the thread will be gc, freeing memory. Since gc is performed before OOM occurs, even if other threads are working properly, frequent gc will have a significant impact.
3.3. Method area
In the case of HotSpot virtual machine, in JDK1.7, the method area was called the permanent generation, and since JDK1.8, Metaspace is what we call the method area!
In other words, if your friend is still talking about perpetual generations, he is talking about the concept of perpetual generations before 1.8, which has been abolished since 1.8.
The Method Area, like the Java heap described above, is shared by each thread. It is used to store information about classes that have been loaded by the virtual machine, constants, static variables, and code compiled by the just-in-time compiler. Although the Java Virtual Machine specification describes the method area as a logical part of the Heap, it has an alias called non-heap, which is supposed to distinguish it from the Java Heap.
A method area is defined in the Java Virtual Machine specification as storing structural information for each class, such as the run-time constant pool, fields, method data, constructors, and bytecode content for common methods, as well as special methods used during class, instance, and interface initialization.
3.4. Method area before JDK1.8
Take, for instance, the HotSpot virtual machine before JDK1.8 method area is also known as the permanent generation, will happen this way area we common Java. Lang. OutOfMemoryError: PermGen space exception: PermGen space exception: PermGen space exception: PermGen space exception
-xx :PermSize Minimum space in the method area -xx :MaxPermSize Maximum space in the method area
In the HotSpot VIRTUAL machine prior to JDK7, strings that were included in the string constant pool were stored in the persistent generation, resulting in a number of performance issues and memory overflow errors. A particularly striking example is the String intern () method
3.5 methods area after JDK1.8
After JDK8, the term “no permanent generation” became a meta space, and the old age was separated from the meta space. The meta-space is placed in local memory, so the maximum size of the meta-space is the system’s memory space, so there are no more memory overflow errors such as permanent generation, or leaked data moved to swap. You can set a maximum available space for the metadata space. If you do not set the maximum available space, the capacity of the metadata space is dynamically increased based on the metadata size of the class. For a 64-bit server-side JVM, the default — XX:MetaspaceSize value is 21MB. This means that the default meta-space size is 21MB.
== As long as the classloader is alive, the metadata of its loaded classes is also alive and will not be recycled! That is, live and die together
3.6. Why has the method area changed so much since JDK1.8?
There are probably two main reasons for making this change:
1, due to the permanent generation (PermGen) memory overflow, often causing annoying Java. Lang. OutOfMemoryError: PermGen, therefore the JVM developers hope this piece of memory would be a more flexible management, don’t often appear such OOM error.
2. Removing PermGen will facilitate fusion between HotSpot JVM and JRockit VM since JRockit does not have PermGen.
It is also important to note that the removal of the permanent generation does not mean that the custom classloader leak problem is solved. Therefore, you also have to monitor your memory consumption, because a leak can take up a lot of your local memory and can make swap swap worse.
Thread private: program counters, Java virtual machine stacks, local method stacks
The Java heap and method area data are shared, but some parts are thread private. The thread private part can be divided into three parts: program counter, Java virtual machine stack, local method stack.
4.1 Java Virtual Machine Stacks
1. Each thread of the Java virtual machine 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.
The Java virtual machine stack describes the memory model for the execution of ==Java methods == : When each method is executed, a stack frame will be created, which is used to store information such as local variable table, operand stack, dynamic link, method exit, etc. == The process of each method from invocation to completion of execution corresponds to the process of a stack frame in the Java virtual machine stack ==.
3. The local variable table stores various basic data types, object references, and returnAddress types known at compile time.
Object reference: the reference type, which is not the same as the object itself. Depending on the virtual machine implementation, it may be a reference pointer to the object’s starting address, a handle to the object, or some other location associated with the object. The returnAddress type refers to the address of a bytecode instruction.
64-bit long and double data occupy two local variable slots, and the rest occupy only one. The memory space required for the local variable table is allocated at compile time. When entering a method, how much local variable space the method needs to allocate in the frame is completely determined, and the size of the local variable table does not change during the method run.
4. The Java virtual machine stack can be implemented as a fixed size, and can be dynamically expanded and shrunk based on computation. With a fixed size, the size of the Java virtual machine stack for each thread can be selected independently at thread creation time. There are two types of exceptions that occur in the Java virtual machine stack, which are specified in the virtual machine specification:
- If a thread request allocates more stack capacity than the maximum allowed by the Java virtual machine stack, the Java virtual machine will throw
StackOverflowErrorThe exception; Aka stack overflow error!Methods the recursiveCall to produceStackOverflowErrorAbnormal results. - If the Java virtual machine stack can be dynamically extended and there is not enough memory to create the corresponding Java virtual machine stack when trying to extend or when creating a new thread, the virtual machine will be thrown
OutOfMemoryErrorThe exception. OOM memory overflow error! (Too many threads started)
Of course, the JVM stack can be resized with the -xss parameter!
4.2 Native Method Stacks
== is similar to the virtual stack, except that it serves the Native method ==, which is thread private. Native method stacks are also used when Java virtual machines implement instruction set interpreters in other languages, such as C. If the Java virtual machine does not support the NatVIE method and does not rely on the traditional stack itself, you do not need to support the native method stack.
Like the Java virtual machine stack, the local method stack area throws StackOverflowError and OutOfMemoryError exceptions.
The HotSpot VIRTUAL machine simply blends the local method stack with the virtual machine stack.
4.3 Program counter
A line number indicator of the bytecode being executed by the current thread, used to record the address of the virtual machine byte instruction being executed, thread private.
It is important to note that the program counter is the only area where the Java Virtual Machine specification does not specify any OutOfMemoryError cases.
5. Summary of JVM memory structure
1. The line number indicator of the bytecode being executed by the current thread. It is used to record the address of the virtual machine byte instruction being executed. 2. Program counters are the only area where the Java Virtual Machine specification does not specify any OutOfMemoryError cases.
Java virtual stack:
1, store basic data types, object references, method exits, etc., thread private. 2. When the stack size exceeds the maximum size of the Java virtual machine stack, a StackOverflowError is raised. Aka stack overflow error! 3. OutOfMemoryError is raised if the Java virtual machine stack can be dynamically extended and not enough memory is allocated, or if there is not enough memory to create the corresponding Java virtual machine stack when a new thread is created. OOM memory overflow error! The -xss parameter adjusts the JVM stack size
Native method stack:
Similar to virtual stack except that it serves Native methods and is thread private. 2. The HotSpot VIRTUAL machine directly combines the local method stack with the virtual machine stack.
The Java heap:
The largest chunk of Java memory, where all object instances, arrays are stored in the Java heap, where GC is collected, and shared by threads.
Java heap = old + New generation
Cenozoic = Eden + S0 + S1
Default Eden: from: to = 8:1:1
Methods area:
In JDK1.7, the permanent generation of the method area is deprecated. In JDK1.8, the permanent generation of the method area is deprecated and replaced by the meta space. In JDK1.8, the permanent generation of the method area is deprecated.
If this article helped you at all, please give it a thumbs up. Thanks
Finally, if there is insufficient or improper place, welcome to criticize, grateful! If you have any questions welcome to leave a message, absolutely the first time reply!
Welcome everyone to pay attention to my public number, discuss technology together, yearning for technology, the pursuit of technology, good come is a friend oh…
