Java’s memory management uses automatic memory management, because Java programmers don’t need to write code that frees memory and are less prone to memory leaks. However, memory is applied for and released by Java virtual machines (VMS). Once a memory leak or overflow occurs, it is difficult to troubleshoot the problem without understanding the Memory structure and automatic management mechanism of Java VMS. So we need to understand the memory model to optimize it.

1. JVM memory model

1.1 Thread Private

  1. Program counter

The Program Counter Register is a small memory space that can be seen as a line number indicator of the bytecode being executed by the current thread. In simple terms, a private record of where the current thread’s bytecode instructions are executed, and where the last execution can be carried out in a thread context switch.

  1. JVM virtual machine stack

Each thread has its own Java virtual machine stack. For example, the main thread here has its own Java virtual machine stack to store local variables of the methods it executes. If a thread executes a method, it creates a stack frame for that method call, which contains the method’s local variator, operand stack, dynamic linking, method exits, and so on.

  1. Local method stack

The role played by the Native method stack and the virtual machine stack is very similar, except that the virtual machine stack performs Java method (bytecode) services for the virtual machine, while the Native method stack serves the Native methods used by the virtual machine. Sun HotSpot directly blends the local method stack with the virtual machine stack. StackOverflowError and OutOfMemoryError exceptions are also thrown by the local method stack.

1.2 Thread Sharing

  1. Methods area

The method area is also a very important area in the JVM, which, like the heap, is shared by threads. In the method area, the information of each class (including the name of the class, method information, field information), static variables, constants, and the compiled code of the compiler are stored. The method area is a logical part of the Heap, and to distinguish it from the Java Heap, it is also nicknamed non-heap. GC collections for this area are relatively rare. OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements. In Java 7 and before, we also used to call it “Permanent Generation” or, more specifically, “HotSpot implements the method section using Permanent Generation”!

  1. Constant pool
  • The runtime constant pool is part of the method area. The Constant Pool table is used to store various literals and symbolic references generated at compile time. This part of the table will be stored in the runtime Constant pool after the Class is loaded.
  • Another feature of the runtime constant pool over the Class file constant pool is that it is dynamic. The Java language does not require that constants must be generated only by the compiler. That is, constants that are not preset into the class file constant pool can be entered into the method area runtime constant pool, and new constants may be added to the pool at runtime.

3, heap

  • The heap, shared by all threads, is created at virtual machine startup to hold object instances, and almost all object instances are allocated memory here.
  • For most applications, the Java Heap is the largest chunk of memory managed by the Java virtual machine.
  • The Java heap is the primary area managed by the garbage collector and is often referred to as the “GC heap”. From the point of view of memory collection, the Java heap can be subdivided into: new generation and old generation; The New generation has three parts: Eden Space, From Survivor space and To Survivor space.
  • The Java heap does not require contiguous memory, and can be dynamically increased, with an OutOfMemoryError thrown if it fails.