We first understand the loading process of the class, there are five main stages:
loading-verification-preparation-analysis-initialization.
So what is a class loader?
Class loader : First, the .java file we wrote will be compiled to form a .class bytecode file, and then the class loader will load the .class file as a class template, and can create instance objects through the new keyword. The instance objects can be The class template is obtained through the getClass method, and the class template can obtain the class loader through the getClassLoader method.
Class loader:
There are four main types: startup class loader, extended class loader, application class loader, custom class loader
The relationship of these four types of class loading is:
When loading an object, it will look up from the application class loader, find the extended class loader, and then look up again to find the root loader. If the root loader cannot be loaded, then it will look. Whether the extension class loader can be loaded, if not, then check whether the application class loader can be loaded, if not, an error will be reported.
This process is the parent delegation mechanism.
In-depth understanding of the Java virtual machine's workflow is defined in this way:
the advantages of using the parent delegation model:
defects:
can not meet the flexible way of class loading.
Solution:
Rewrite some methods yourself to break the parental delegation model.
SPI mechanism :
A typical example is JNDI service. The purpose of JNDI is to find and centrally manage resources. It needs to call the code of the JNDI Service Provider Interface (SPI) implemented by other vendors and deployed under the ClassPath of the application . Now the problem comes, start It is impossible for a class loader to recognize and load these codes, so what should I do?
Solution: Thread Context ClassLoader (Thread Context ClassLoader) .
The JNDI service uses this thread context class loader to load the required SPI service code. This is a behavior in which the parent class loader requests the child class loader to complete the class loading. This behavior actually opens up the parent delegation model. Hierarchical structure to reverse the use of class loader has violated the general principle of the parent delegation model, but it is also helpless. The loading involving SPI in Java is basically done in this way, such as JNDI, JDBC, JCE, JAXB and JBI. However, when there is more than one SPI service provider, the code can only be hard-coded and judged based on the type of the specific provider. In order to eliminate this extremely inelegant implementation, in JDK 6, the JDK provides java. The util.ServiceLoader class, with
the configuration information in META-INF/services , supplemented by the chain of responsibility mode, provides a relatively reasonable solution for the loading of SPI.