The main components of JVM
- Class Loader
- Runtime Data Area
- Execution Engine
- Native Interface
Composition of data area in JVM runtime
Method area is mainly used to store class information (constructor, interface definition), constants, static variables and running time constant pool which have been loaded by virtual machine.
(2) This area is shared by threads.
(3) There is a pool of runtime constants in the method area for storing literal and symbolic references generated by static compilation. This constant pool is dynamic, that is to say, constants are not always determined at compile time, and constants generated at run time also exist in this constant pool.
Virtual machine stack:
Virtual machine stack is also called stack memory, which is responsible for the running of Java programs. It is created when the thread is created. Its lifetime follows the lifetime of the thread, and the end of the thread releases the stack memory. There is no garbage collection problem for the stack. As long as the thread terminates the stack, it will be over. The lifetime is consistent with that of the thread, and it is thread-private. 。
Eight basic types of variables + object reference variables + instance methods are allocated in the stack memory of functions.
When each method is executed, a stack frame is created to store information such as local variable table, operand stack, dynamic link and method exit.
(2) The virtual machine stack is thread-private, and its lifecycle is the same as that of threads.
(3) The local variable table stores the basic data type, the return Address type (the address of a bytecode instruction) and the object reference, which may be a pointer to the starting address of the object, a handle representing the object or a position associated with the object. 4. The memory space required for local variables is determined between compilers.
(4) The function of the operand stack is mainly used to store the result of operation and the operand of operation. It is different from the way that the table of local variables is accessed by index, but it is the way of stacking and stacking.
Each stack frame contains a reference to the method to which the stack frame belongs in the run-time constant pool, which is held to support dynamic connection during method invocation. Dynamic link is to convert symbol references in the constant pool into direct references at run-time.
Native Method Stack
The local method stack is similar to the virtual machine stack, except that the local method stack serves the Native method.
The Java heap is a piece of memory shared by all threads. It is created at the start of the virtual machine. Almost all object instances are created here. Therefore, garbage collection often occurs in this area.
Because of the small memory space, bytecode interpreter can select the next bytecode instruction to be executed by changing this count value. The functions of branch, loop, jump, exception handling and thread recovery all depend on this counter. This memory area is the only area where the Java virtual machine specification does not specify any OOM (application memory is too large for the virtual machine to satisfy us, and then commits suicide).
The execution process of program in virtual machine
First, the class loader loads the class file to get the class template, and puts it into the method area (class information (constructor, interface definition), constant, static variable and run-time constant pool, etc.). When instantiating the object according to the class template, the object will be placed in the heap (can refer to heap generation, garbage collection). Policy, garbage collection algorithm, cause of memory leak. According to the object invocation method, the method will be pushed into the stack (8 basic types of variables + object reference variables + instance methods). The native method will be pushed into the local method stack. The JVM will send instructions to the operating system, and the execution engine will interpret the commands to send to the local method stack. Operating system, the operating system will call the local method interface, using the local method library, to execute the local method. The method in the stack goes out of the stack in the order of last-in-first-out, and the program counter points to the next method out of the stack. There is no garbage collection in the stack, and they are released as the thread is executed.
Parent Delegation Model for Class Loading
Before introducing the Parent Delegation Model, let’s talk about the next class loader. For any class, the uniqueness in the JVM is established by the class loader that loads it and the class itself. Each class loader has a separate class namespace. Class loader loads class files into JVM memory according to the specified fully qualified name, and then converts them into class objects.
Class loader classification:
Start Class LoaderBootstrap Class Loader is a part of the virtual machine itself, which is used to load the class libraries in the Java_HOME/lib/directory or in the path specified by the – Xboot classpath parameter and recognized by the virtual machine.
extensions class loader(Extension Class Loader): responsible for loading <java_home style=”box-sizing: border-box;-webkit-tap-highlight-color: transparent; text-size-adjustment: none; -webkit-font-smoothing: antialiased; outline: 0px! Important; >\ lib ext directory or all class libraries in the path specified by Java. ext. dirs system variables; </java _home>
Application ClassLoader(Application Class Loader). It is responsible for loading the specified class libraries on the user classpath. We can use this class loader directly. In general, if we don’t have a custom class loader, we use it by default.
Custom Class Loader
The relationship between them is top-down as shown in the figure.
If a class loader receives a class loading request, it will not load the class itself first, but delegate the request to the parent class loader to complete. This is true for each class loader, so that all loading requests will be sent to the top-level startup class loader, only when the parent load cannot complete. When a load request (the required class is not found in its search range), let the subloader try to load the class from top to bottom.
So how do we verify this statement?
Let’s write a simple little program:
Then compile the java file and generate the class file.
We put this file where the boot class loader can load and create a new directory classes: D: Program Files Java jdk1.8.0_161 jre classes
Then modify the program:
Compile again and place the generated classes file where the extension class starter can load. Create a new folder classes: D: Program Files Java jdk1.8.0_161 jre lib ext classes
Finally, let’s revise it again.
The generated class file is placed in the current directory.
So what happens when we execute this class file?
This means that instead of loading the class file in our current directory, we used the boot class loader to scan the file in the scope.
Further validation, we delete the files under D: Program Files Java jdk1.8.0_161 jre classes
The result changed to bbb, indicating that when the boot class loader did not find the class file, it was loaded by the extended class loader.
Does the file in the scope of the Extended Class Loader also be deleted?
Finally, the class file is loaded into the current folder
Can you create a java. lang. String object in your own code? If so, can this object be loaded by the class loader?
It can be created, but it cannot be loaded.
Because the parent delegation mode ensures that the parent loader loads the class first, that is, the BootStrap loader loads the java. lang. String class in jdk, while the custom java. lang. String class will never be loaded.
The above is the whole content of this article. I hope it will be helpful to everyone’s study, and I hope you will support developpaer more.