Jvm-parent Delegation Model, jvm-parent Delegation
Interview Questions
Can I write a class called java. lang. System?
Answer: Generally, this is not acceptable, but an alternative method can be used to meet this requirement.
Explanation: in order not to allow us to write System Classes, class loading adopts a delegation mechanism, which ensures that the class members are given priority and the class members can find, so the son will not have the chance to load the class. The System class is loaded by the Bootstrap loader. Even if you rewrite it yourself, you always use the System provided by the Java System. The System class you write has no chance to load it.
However, we can define a class loader to achieve this goal. To avoid parent-parent delegation, this class loader must also be special. Because all the three class loaders in the system load classes under a specific directory, if our own class loaders are placed in a special directory, the system's loaders cannot be loaded, that is to say, it is still loaded by our own loader.
Three types of class loaders predefined by JVM:
Bootstrap: A Class Loader implemented using local code. It is responsible for loading the Class Libraries under <Java_Runtime_Home>/lib to the memory (such as rt. jar ). Since the bootstrap loader involves the local implementation details of the virtual machine, developers cannot directly obtain the reference of the bootstrap loader, so they cannot directly perform operations through the reference.
Standard Extension class loader: Implemented by Sun's ExtClassLoader (sun. misc. Launcher $ ExtClassLoader. It loads <Java_Runtime_Home>/lib/ext or the class library specified by the system variable java. ext. dir to the memory. Developers can directly use the standard extension class loader.
System Class Loader: It is implemented by Sun's AppClassLoader (sun. misc. Launcher $ AppClassLoader. It is responsible for loading the class library specified in the system classpath to the memory. Developers can directly use the system class loader.
In addition to the three types of loaders listed above, there is also a special type-thread context class loader.
Description
When receiving a request to load a class, a specific class loader first delegates the load task to the parent class loader, recursively returning it. If the parent class loader can complete the class loading task, the returned result is successful. Only when the parent class loader cannot complete this loading task can it load it by itself.
Some Thoughts
The first class loader of the Java Virtual Machine is Bootstrap, which is special. It is not a Java class, so it does not need to be loaded by others. It is nested in the Java Virtual Machine kernel, that is, when the JVM is started, Bootstrap is started. It is a binary code written in C ++ (not a bytecode) and can load other classes.
This is why we found System during the test. class. the getClassLoader () result is null, which does not indicate that the System class does not have a class loader, but its loader is special. It is BootstrapClassLoader, because it is not a Java class, therefore, null is returned for obtaining its reference.
Delegation Mechanism
When the Java Virtual Machine loads a class, which class loader is dispatched to load the class?
First, the class loader of the current thread loads the First Class (assuming Class A) in the thread ).
Note: The Class Loader of the current Thread can be obtained through getContextClassLoader () of the Thread class, or you can set the class loader by setContextClassLoader.
If Class A references Class B, the Java virtual machine uses the class loader that loads Class A to load Class B.
You can also directly call the ClassLoader. loadClass () method to specify a class loader to load a class.
Significance of the delegation mechanism-prevent multiple identical bytecode in the memory
For example, both Class A and Class B must load the System class:
If you do not need to delegate but load your own, Class A will load A System bytecode, and Class B will load A System bytecode, in this way, two System bytecode is displayed in the memory.
If the delegate mechanism is used, it recursively searches for the parent class, that is, it is the first choice to use Bootstrap to try loading. If it cannot be found, it will go down. Here, the System can be found in Bootstrap and loaded. If Class B also needs to load the System, it also starts from Bootstrap, at this time, Bootstrap finds that the System has been loaded, so it can directly return the System in the memory without re-loading, so that the memory has only one System bytecode.