The necessity of learning JVM knowledge
The Java language implements an automatic management mechanism for memory, and does not require programmers to write code to release memory and garbage collection in the code. JVM helps you achieve these functions. Although Java has a garbage collection mechanism, some garbage can't be collected, which can still cause errors such as memory leaks and memory overflows. If you don't understand the JVM memory model and operating mechanism, you will be at a loss when the project has problems.
How does the JVM work after the project is launched
1. When the server starts, the source code is compiled into a bytecode file (.class) by the Java compiler.
2. The class loader in the JVM loads all bytecode files into the JVM space.
3. The JVM execution engine executes these bytecode files.
4. During the execution process, a lot of data is generated, and these data are fixed in a certain space, which is the JVM memory we often mention.
JVM memory division
JVM is divided into five parts, namely stack, heap, method area, program counter, and local method stack. Every project we run is a process, and a process contains multiple threads.
Stack
Thread private.
The stack solves the running problem of the program, that is, how the program is executed, or how to process the data.
All threads running in the virtual machine, each thread, has its own thread stack, this stack is private, and others cannot access your things. The thread stack includes the method currently executed by this thread and the node's Related Information.
Each thread stack is composed of stack frames, and each stack frame corresponds to a method called.
In short, the stack executes java methods in bytecode files.
heap
Thread sharing.
The heap is the largest area of memory. It solves the problem of data storage and stores object instances.
The memory errors that we often encounter are basically all made here. For example, you create too many instance objects, and the heap space is full.
The interior of the heap is divided into two spaces, the new generation and the old generation.
The newly created objects are all in the young generation. If they are still alive after multiple GCs, they will be transferred to the old generation.
In short, when something goes wrong, it's basically a pot of heap memory allocation.
Method area
The method area has three names, method area, non-heap, and permanent generation.
It is similar to the heap, shared by threads, but it stores different things, and GC generally does not come here. The main storage type information, constants, static variables and other data.
In short, don't care what the method area is.
Program counter
Thread private, bytecode line number indicator. The program counter is the only area in the JVM specification that does not have any OutOfMemoryError.
In short, this thing, basically, you will not have time to deal with it.
Native method stack
The thread is private, storing literals and symbol references.
In short, the native method stack executes Native methods. Native method refers to the method of calling other programming languages in Java. If you are useless, then this thing is basically nothing to you.
to sum up
Of the five areas, only the heap and method areas are shared by threads, and the others are private to threads.
Does Java cause memory leaks?
Conceptually, Java's garbage collection mechanism will not cause memory leaks.
In reality, every community has cleaning up the trash cans, and occasionally one or two forget to clean up.
That is, GC belongs to GC, there is always some place to hide dirt.
In actual development, there are some useless objects. These objects are not reclaimed by GC, which will cause memory leaks.
For example: The objects in Hibernate's Session (first level cache) are in a persistent state, and the garbage collector will not reclaim these objects. However, there may be useless garbage objects in these objects. If they are not closed or flushed in time, ) Level 1 cache may cause memory leaks.