Comparison of the Tomcat class loading mechanism and Java class loading mechanism

 

When it comes to the Tomcat class loading mechanism, we have to say that translation learns Tomcat's original purpose.

Before the internship time to learn javamelody source, but it is a MAVEN project, and our own Web project integration can not be directly debugging breakpoints. Later colleague guidance, said that the Java class is directly copied to the SRC can be. I was wondering .... Why would a Java file under SRC (compiled Class) be loaded first instead of the class in the jar package?

Now that you understand Tomcat's class loading mechanism, everything is so simple.

Class loading

In the JVM it is not a one-time load of all the files, but a step-by-step, as needed to load.

For example, when the JVM starts, different classes are loaded with different classloader. When the user needs some extra class in their own code, it is loaded into the JVM and stored for a period of time for frequent use.

So what kind of loader to use and where to load the class is an important knowledge in the JVM.

JVM class Loading

The JVM class load takes the parent class delegate mechanism, as shown in:

The JVM includes a centralized class loader:

1 Bootstrapclassloader Boot class loader

2 Extclassloader Extension Class loader

3 Appclassloader Application Class Loader

4 CustomClassLoader User custom class Loader

Their differences are also explained above. It is important to note that the classes loaded by different classloader are different, so if a user loader 1 loads a class, other users are not able to use it.

When the JVM is running and the user needs to load some classes, the following steps (the parent class delegation mechanism) are followed:

1 The user's own class loader, passing the load request to the parent loader, and the parent loader to its parent loader, until the top of the loader tree.

2 The topmost class loader is loaded first for its specific location, and is forwarded to the subclass if it is not loaded.

3 If the class load is not loaded until the bottom, the exception classnotfoundexception is thrown.

Therefore, it can be thought that, if the same class is stored in the directory specified by Classpath and in its own working directory, the files in the Classpath directory will be loaded preferentially.

Tomcat class loading

Classes are loaded slightly differently in Tomcat, such as:

When Tomcat starts, several kinds of loaders are created:

1 Bootstrap Boot class loader

Classes required to load the JVM startup, and standard extension classes (under Jre/lib/ext)

2 System Class Loader

Classes loaded with Tomcat startup, such as Bootstrap.jar, are typically specified in Catalina.bat or catalina.sh. Located under Catalina_home/bin.

3 Common Universal Class Loader

Some classes that load tomcat use and apply common, are located under Catalina_home/lib, such as Servlet-api.jar

4 WebApp Application Class Loader

After each app is deployed, a unique classloader will be created. The ClassLoader loads the class file under Class and web-inf/classes in the jar file under Web-inf/lib.

When an application needs to go to a class, the class is loaded in the following order:

1 Loading with Bootstrap boot class loader

2 Loading using the System class loader

3 loading in web-inf/classes using the Application class loader

4 loading in Web-inf/lib using the Application class loader

5 loading in Catalina_home/lib using the common class loader

Problem extension

By understanding the above Tomcat class loading mechanism, it is not difficult to understand why Java files placed in the SRC folder in eclipse will prioritize the class in the jar package.

This is because the files in the SRC folder in Eclipse Java and the JSP in WebContent are compiled into a class file in Web-inf/class when Tomcat starts.

The jar packages referenced externally by Eclipse are equivalent to being placed in Web-inf/lib.

So it must be a Java file or a JSP file compiled by the class-first load.

In this way, we can simply put the Java file in the Src folder, through the modification of the Java file and debugging, easy to learn to have the source Java files, but not packaged into Xxx-source jar package.

In addition, developers will be careless and make the following mistakes.

Different versions of Jar packages are placed in Catalina_home/lib and web-inf/lib, which can cause errors in some cases to be reported without the class being loaded.

Also, if multiple applications use the same jar file, when more than one is placed, it can cause errors that cannot be loaded by the class between multiple applications.

Comparison of the Tomcat class loading mechanism and Java class loading mechanism