One of the secrets of JVM helps you understand JVM

Today, I just received an insite letter from csdn, explaining the reason why my previous article was removed from the blog homepage. In fact, I did not care much about the withdrawal of the article, however, I was a little frustrated when I was removed three or four times in a row, so I didn't post any more articles in those days, and I couldn't open the homepage of my blog after I debugged the network environment of my school. I finally got better recently. Suddenly I want to say that I have come back again. Return to the topic and start a new JVM journey. Java Virtual Machine (VM) is something that every good java programmer needs to know. Some problems cannot be solved at the code level. Only by studying jvm can we find out the real source. In short, learning jvm allows us to stand up and look at the problem.

For more information, see [author's Idlear blog http://blog.csdn.net/idlear/article/details/21414143]

This figure will start our JVM journey. There are some omissions in the poor drawing tools. However, this figure shows a jvm snapshot model when a java program is running. Since jvm is just a specification and its definition is very abstract, developers have a lot of free space to design the jvm. For example, some jvm method zones are the permanent generation in the java heap memory, this will also facilitate gc recovery. But even so, this will not affect our understanding of jvm. The java source code is compiled by the javac compiler into a familiar java class file. The java class file is designed around the constant pool, but the constant pool here is not a constant pool in our jvm, the runtime Constant Volume pool is a data structure of class files. When we run java class, we will tell the jvm class that contains the main method. The main method is the program entry, which is started by the jvm instance. When we actually load the class file, the class file must be checked by the class file examiner. The three checks are performed in the method area. That is to say, after the check, the class file has been loaded into the memory, the class loading mechanism is the parent-parent delegation that we are familiar with, and starts the class loader to load the java api class. Jvm will produce a class instance for each loaded class and store it in the java heap memory. The heap memory stores all class instances, which is also the main memory area for gc collection, in jvm, a java stack and pc program counter are generated for each thread. The program counter always stores the next execution command. Stack frames are stored in the java stack. Each java stack frame includes the local variable region, the Operation stack, and the frame data zone. The operation stack is the working platform of the execution engine, it is also a work platform for method execution. The operation stack always copies local variables from local variables to the operation stack, and performs corresponding operations according to the method bytecode operation.