Understanding of Java Foundation-classloader

Default Three class Loaders

Java has three ClassLoader by default, hierarchically from top to bottom:

• Bootstrap ClassLoader
• Ext ClassLoader
• System ClassLoader

Bootstrap ClassLoader is the topmost classloader, it is very special, is written in C + + in the JVM, is the JVM when it is launched to load some core classes, such as:,, rt.jar resources.jar ,, charsets.jar jce.jar etc., You can run the following code to see what you have:

2. url[] URLs = Sun.. Launcher. Getbootstrapclasspath (). Geturls
4. for (int i = 0; i < urls.length; i++) {
6. System.out.println(urls[i].toExternalForm());
8. }

file:/c:/program%20files/java/jre6/lib/resources.jarfile:/c:/program%20files/java/jre6/lib/  Rt.jarfile:/c:/program%20files/java/jre6/lib/sunrsasign.jarfile:/c:/program%20files/java/jre6/ lib/jsse.jarfile:/c:/program%20files/java/jre6/lib/jce.jarfile:/c:/program%20files/java/jre6 /lib/charsets.jarfile:/c:/program%20files/java/jre6/lib/modules/jdk.boot.jarfile:/c:/program %20files/java/jre6/classes

The rest of the two ClassLoader are inherited from ClassLoader this class. Java class loading takes a way called "parental delegation" (explained later), so Bootstrap ClassLoader there is a "parent" classloader, in addition to the rest of the ClassLoader, not through integration, but a contained relationship.

2. //ClassLoader.java
4. public abstract class ClassLoader {
6. ...
8. // The parent class loader for delegation
10. private ClassLoader parent;
12. ...

"Parental delegation"

The so-called "parental delegation" is when loading a class will be delegated to the parent class loader to load, when the parent class loader can not load and then try to load themselves, so the entire class load is "top-down", if not loaded to throw an ClassNotFoundException exception.

The above mentioned bootstrap ClassLoader is the topmost class loader, and actually the Ext ClassLoader and system ClassLoader are the first to be loaded.

Ext ClassLoader, called the extension ClassLoader, is responsible for loading the Java Extension Class library, which loads all the jars in the java_home/jre/lib/ext/directory by default (including the jar packages that you manually put in).

System ClassLoader is called the systems ClassLoader and is responsible for loading all the jar and class files in the application Classpath directory, including the jar packages that we normally run under the CP parameter specified by the jar package.

Run the following code to verify the above content:

2. ClassLoader loader = Debug.class.getClassLoader();
4. while(loader != null) {
6. System.out.println(loader);
8. loader = loader.getParent();
10. }
12. System.out.println(loader);

[email protected][email protected] NULL

The role of "parental delegation"

The use of "parental delegation" is primarily for security purposes, to avoid the user-written classes dynamically replace some of Java's core classes, such as String, but also avoid repeated loading, because the JVM distinguishes between different classes, not only according to the class name, The same class files are loaded by different classloader, which are different two classes, and if they are transformed, they will be thrown java.lang.ClassCaseException .

Custom Class Loaders

In addition to the three default class loaders mentioned above, users can ClassLoader create custom class loaders by inheriting classes, because there are times when we need to create classes in special ways, such as networks.

As for how the custom class loader works, the ClassLoader LoadClass method of the class has defined the algorithm:

2. protected synchronized Class<?> loadClass(String name, boolean resolve)
4. throws ClassNotFoundException
6. {
8. // First, check if the class has already been loaded
10. Class c = findLoadedClass(name);
12. if (c == null) {
14. try {
16. if (parent != null) {
18. c = parent.loadClass(name, false);
20. } else {
22. c = findBootstrapClassOrNull(name);
24. }
26. } catch (ClassNotFoundException e) {
28. // ClassNotFoundException thrown if class not found
30. // from the non-null parent class loader
32. }
34. if (c == null) {
36. // If still not found, then invoke findClass in order
38. // to find the class.
40. c = findClass(name);
42. }
44. }
46. if (resolve) {
48. resolveClass(c);
50. }
52. return c;
54. }

>1. Invoke to findLoadedClass(String) Check if the class has already been loaded.

>2. Invoke the LoadClass method on the parent class loader. If The parent is null for the class loader built-in to the Vsan is used, instead.

>3. Invoke the findClass(String) method to find the class.

As you can see from the Javadoc above, the custom ClassLoader is as good as overloading findClass .

Context ClassLoader

First of all, Java in ClassLoader on the above mentioned four,, Bootstrap ClassLoader Ext ClassLoader System ClassLoader as well as user-defined, so is Context ClassLoader not a new class loader, is certainly one of these four kinds.

The first thing to add to the class is that if Class A is loaded by a loader, the B referenced in Class A is also loaded by the loader (if B is not loaded), typically class B must be under the classpath of Class A.

But considering that different objects in a multithreaded environment might be loaded by different classloader, when an object a loaded by Classloaderc is passed from one thread to another threadb, and threadb is loaded by Classloaderd, At this time if a wants to get other than its own classpath resources, it can Thread.currentThread().getContextClassLoader() get the thread context of the ClassLoader, is generally classloaderd, can be displayed by Thread.currentThread().setContextClassLoader(ClassLoader) the settings.

Why should there be Contex ClassLoader

There is a context classloader because this "parental delegation" mechanism in Java is limited:

• An example of the Internet:

> Jndi For example, Jndi classes are loaded by bootstrap ClassLoader from the middle of Rt.jar, but Jndi specific core drivers are provided by formal implementations and are usually under the-CP parameter (note: The default system ClassLoader management), this requires BOOTSTARTP ClassLoader to load only the Systemclassloader visible classes, the normal logic can not be processed. What do we do? The parent can load the class by obtaining the >context Classloder of the calling thread by getting the method that currently calls thread.

• I mentioned above for an example of loading resources.

Contex ClassLoaderProvides a backdoor that breaks through this mechanism.

Context ClassLoader generally in some framework code with more, usually write code when the class of ClassLoader can be.

Reference links

Http://stackoverflow.com/questions/1771679/difference-between-threads-context-class-loader-and-normal-classloader

Http://www.cnblogs.com/magialmoon/p/3952445.html

Understanding of Java Foundation-classloader (RPM)