Java ClassLoader principle
I have written a brief introduction to the Java ClassLoader principle of Java ClassLoader.
After a few years, look again, think some places appear too pale, so another article:
After completing a Java class, the Javac compiles a class file that contains all the basic information related to this class: attribute fields, methods, and so on. These all belong to the metadata of a class, which is the invariant part. During execution, you need to generate an instance object based on the metadata information of the class, which can have different states depending on the scene. This means that the same class corresponds to different states in the running process. (Note that this is class, not object) after each Java file is compiled, the compiler will give a static field that joins a public called: class. In the program, we can get a class object in a Someobject.class way.
In Java, a class is determined by the package path and class name, and through the Java API we know that a method in class is getClassLoader (), but if a class is loaded by two different ClassLoader, the method returns different results, in which case Although it is the same class, but is loaded by different class loader, the corresponding class object is not the same one.
Why set Environment variables: java_home, CLASSPATH? Java_home corresponds to the Java installation root path, in order to be able to use the system in all the Java to provide us with the command-line tool, so we want to add Java_home/bin path to path. But classpath, why do you need to specify the three jars (Tools.jar, Dt.jar, Rt.jar) in Classpath?
First of all, Tools.jar is mainly some Java tools, you can download the JDK from the OPENJDK source code, find Langtools the path of the file to see, if you want to write some tools, such as Java to parse or compile Java files, You can look at the Javac related Api;dt.jar in tools that are primarily swing-related classes. The Rt.jar is run-time related and is the Java class in the core library of Java.
Let's take a look at Java's proxy mode load order at startup. In Java, there is a parent class loader in addition to the Bootstrap class loader. See Java official for "Understanding Extension Class Loading"Description. It mentions three aspects of the loading content: First, Rt.jar and I18n.jar, such as basic class package, the second is the expansion package, and the third is that we classpath the specified dependency package. For the first part, the Bootstrap class loader is responsible for loading, so class loader in the Java package is bootstrap class loader, and the extension path (typically Jre/lib/ext) is Extension class loader (Extclassloader) is responsible. The third part of the load requires the application of class loader (Appclassloader) to be responsible. In general, when booting directly from Java, a-classpath or-CP is identified to identify the list of dependent packages (note, not a path, but a list of files). The process of initializing the relevant class loader in the code is in the Sun.misc.Launcher class, and the following is the implementation in the constructor method of launcher.
Public Launcher () {
Create the Extension class loader
ClassLoader EXTCL;
try {
EXTCL = Extclassloader.getextclassloader ();
} catch (IOException e) {
throw New Internalerror (
"Could not create extension class loader", E);
}
Now create the class loader to launch the application
try {
Loader = Appclassloader.getappclassloader (EXTCL);
} catch (IOException e) {
throw New Internalerror (
"Could not create application class loader", E);
}
Also Set the context class loader for the primordial thread.
Thread.CurrentThread (). Setcontextclassloader (loader);
.....
}
The related loading paths mentioned above also have relevant code in this class, not listed.
The LoadClass method in the ClassLoader class in the Java API:
Protected class<?> loadclass (String name, Boolean resolve)
Throws ClassNotFoundException
{
Synchronized (Getclassloadinglock (name)) {
First, check if the class has already been loaded
Class C = findloadedclass (name);
if (c = = null) {
Long T0 = System.nanotime ();
try {
if (parent! = NULL) {
c = Parent.loadclass (name, false);
} else {
c = findbootstrapclassornull (name);
}
} catch (ClassNotFoundException e) {
ClassNotFoundException thrown if class not found
From the Non-null parent class loader
}
if (c = = null) {
If still not found, then invoke Findclass in order
To find the class.
Long T1 = System.nanotime ();
c = findclass (name);
This is the defining class loader; Record the stats
Sun.misc.PerfCounter.getParentDelegationTime (). Addtime (T1-T0);
Sun.misc.PerfCounter.getFindClassTime (). Addelapsedtimefrom (t1);
Sun.misc.PerfCounter.getFindClasses (). increment ();
}
}
if (resolve) {
Resolveclass (c);
}
return C;
}
}
When a class is loaded, the current ClassLoader will first delegate the parent class loader attempt to load. This approach, there are several aspects of consideration: first, security issues, if the attacker simulates the implementation of the corresponding class, such as Java.lang.String, when the class is loaded through LoadClass, it will be found in the parent ClassLoader, It is obvious that it can be found in the Bootstrap class loader, so that the most critical code can be protected as much as possible. One is the redundancy problem, in this way can minimize the repeated loading. Each level of ClassLoader is responsible for the class library loading under the corresponding path, and for application implementations it can be centralized in the application system. Here you can consider the implementation of Web container, such as Tomcat. Each JSP page is eventually compiled into a class file and placed in the work path, so each Web container builds a classloader to load the class file from the specified path.
With the instructions above, it is possible to understand that the JVM will only load once when it discovers the same package path (different jar, but same package) in the boot process, and mainly see which package is at the front. Here's a question: Why is the package in front of you working, not behind? Wouldn't it be overwritten if it was loaded by the same classloader? In fact, if it is the implementation of the ClassLoader, that can adjust the strategy, but the Convention in Java is the first load of class will be based on binary name, the class metadata in the permanent region, and then there is the same name of the class, can be found, without having to reload.
Java ClassLoader principle
