For Java programmers, with the help of the automatic memory management mechanism of the virtual machine, it is no longer necessary to write paired delete/free code for each new operation, and it is not prone to memory leaks and memory overflow problems. It seems that Everything is fine with virtual machine management memory. However, it is precisely because Java programmers give the power of memory control to the Java virtual machine. Once memory leaks and overflows occur, if you don’t understand how the virtual machine uses memory, troubleshooting will become an issue. Very hard work.
During the execution of the Java program, the Java virtual machine divides the memory it manages into thousands of different data areas. These areas have their own purposes, as well as the time of creation and destruction. Some areas
exist as the virtual machine process starts, and some areas are created and destroyed depending on the start and end of the user thread.
Let's start with the JVM overall architecture diagram to explore
1. Runtime data area
1. Program Counter
The line number indicator of the bytecode executed by the current thread.
- If the current method is native, then the value of the program counter is undefined.
- Thread private, the only area in the Java memory area where the Java virtual machine specification does not specify that OOM or StackOverflow will occur
Pay attention to questions
- Why is the program counter private to the thread?