Java class loading system and Contextclassloader__java

VA is a very simple and ingenious language, and the basics behind it are simple, with two points in general:

1. Memory management of the JVM, understanding this, the problem of the object can be solved. such as thread safety issues, memory leaks, and so on.

2.JVM class Loading system, understand this, about the jar package configuration problem, including various appserver configuration, the application of the issue can be solved.

The memory management of the JVM, as long as understand the above diagram, basically can understand sorta. This document focuses on the JVM's class loading system, in our common development, most of the use of the default class loader, do not need to understand the class loading principle. But if you are not only satisfied with the usual development, want to understand some of the underlying principles, or want to read some Open-source software source code, such as TOMCAT,JDBC, and so on, it is necessary to delve into the principle of class loading. This document is intended for people who want to be a master of Java.

This article is not prepared to do a lot of description of the basic class loading principle, because this kind of article on the Internet more yaks, do not understand the class loading principle of students please refer to the Java object-oriented Programming book tenth (class declaration cycle) or Java depth adventure. Here are some main diagrams to illustrate the general principle.

Figure 1 is the Java class loading system, with Bootstrap, EXT, app and user-defined loader, when loading classes using the parental delegation mechanism. It is particularly noteworthy that the classloader of the loader is independent of the parent-child relationship and the inheritance relationship, and that the loader is not loaded with the loader, but rather that it is related to the loader that was specified when the loader was created, that is, manually specified. For example, to determine the parent loader for loader A, it is determined only by the parent loader that created object a newsletters, regardless of the type of a, regardless of which loader the A is loaded.

The default rules for loading class are simpler, with two:

1, the parents entrust the mechanism.

2, the same loader: Class A refers to Class B, then the loader of Class A loads class B to ensure that the referenced class is loaded by the same loader.

Figure 2 is the loader, class object, and class form in memory. Loader, class objects are instance objects, all exist in the heap area. And the related information of the class exists the method area, namely the Perm area. (Bty: If the method area is full, it throws an exception java.lang.Out of Memory Perm Gem space error).

Figure 3 is the process of executing a Java program, and you can see that the execution is loaded like an entire class loading system, then load the class we want to execute with this system, and then run the main method.

Figure IV is the three methods of the JVM load class, including implicit new, and explicit Class.forName () and Classloader.loadclass ().

Figure 1

Figure 2

Figure Three

Figure Four

In most cases, this default class loading system for the JVM already satisfies most situations. Then why do we need Contextclassloader? This is because the default rules that load class cannot meet the requirements in some cases. For example, the JDBC API in the JDK and the class loading problem of the implementation class SPI of the specific database vendor. Classes in the JDBC API are loaded by bootstrap, and if the JDBC API needs to use the SPI implementation class, the implementation class will also be loaded by the bootstrap according to default rule 2, but the SPI implementation class cannot be loaded by bootstrap. can only be loaded by ext or app, how to solve this problem. Cows have come up with a Contextclassloader method.

The implementation process is as follows: Define a property ClassLoader in class thread to allow the user to save a ClassLoader (the default is app) and to expose the setter and getter methods, So that any statement of this thread can get this classloader and then use it to load the class to break the default rule 2. To be blunt, Contextclassloader is a property of thread, nothing complicated. But this attribute is closely related to the underlying loading system, which makes many people think there are some advanced principles in it. Understanding this point, Contextclassloader also has no mystery.

So let's see how Contextclassloader solves the problem. In the case of JDBC, when DriverManager needs to load the implementation class in the SPI, you can get Contextclassloader (the default is app), and then use this classloader to load the classes in the SPI. Very simple process. Of course do not use Contextclassloader, find a place to save ClassLoader, in other places can get this classloader. That's what Tomcat does. For example, Standardcontext is loaded by common, and standardcontext to use the project under the class, how to do, obviously can not use common to load, and can only be loaded with WebappClassLoader, how to do. Of course, it can be solved in a contextclassloader way, but Tomcat does not solve it, but instead creates a loader for each app that holds the classloader of the WebApp. When you need to load a class under WebApp, you remove ClassLoader to use it, and the principle is the same as Contextclassloader. As for Tomcat, why would you do that? Because the problem with class loading in Tomcat is handled by a main thread, instead of creating a separate thread for each webapp, there is no way to solve it by Contextclassloader, but with its own properties.

TOMCAT6 class loader system, from: http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html

Now that Rule 2 has been broken, Rule 1: Can parents ' entrustment mechanisms be broken? Rule 1 is set because of security issues, and if I can control the security issues of class loading, can I violate rule 1? The answer is yes. The same Tomcat also broke the rule. When WebappClassLoader loads a project's class in Tomcat, you can decide whether to look up a class file in the local path of the project first. Instead of automatically using the parent loader common under Tomcat common directory lookup. How is this achieved?

To answer this question, we must first understand how the parental delegation mechanism is implemented. Only by understanding how to achieve, can we change it. The parental delegation mechanism is implemented in the loadclass of the class ClassLoader. Then inherit ClassLoader's WebappClassLoader, as long as covers LoadClass method, realizes own loading strategy, can avoid the parents entrust the mechanism.