Research on class loading sequence of Java Virtual Machine

Original post address: http://www.roboticfan.com/blog/user_2005/104/20101218232353.shtml

 

When the JVM (Java Virtual Machine) is started, an initial class loader hierarchy consisting of three class loaders is formed:

Bootstrap classloader
|
Extension classloader
|
System classloader

1. bootstrap classloader-Bootstrap (also called the original) Class Loader. This loader is very special and is not actually Java. lang. classloader subclass, but implemented by JVM itself

It loads the following resources:

D:/program files/Java/jre6/lib/resources. Jar
D:/program files/Java/jre6/lib/RT. Jar
D:/program files/Java/jre6/lib/sunrsasign. Jar
D:/program files/Java/jre6/lib/JSSE. Jar
D:/program files/Java/jre6/lib/JCE. Jar
D:/program files/Java/jre6/lib/charsets. Jar
D:/program files/Java/jre6/classes

Now we know why we don't need to specify these class libraries in the system attribute classpath, because the JVM automatically loads them at startup.

2. extension classloader-extended Class Loader extclassloader, which is responsible for loading the extension directory of JRE (java_home/JRE/lib/EXT or by Java. ext. jar class package specified by the dirs system attribute. It already belongs to the top loader. It loads the following resources:

D:/program files/Java/jre6/lib/EXT; C:/Windows/Sun/Java/lib/EXT

3. system classloader-the system (also called an application) Class Loader appclassloader loads data from the-classpath or Java. class. the jar package and path specified by the path system attribute or the classpath operating system attribute. This is the third-party package used by the add-on consumer and the class in the project. Its Parent loader is extclassloader.

It loads the following resources:

E:/Works/encoder/lib/antlr-2.7.6.jar
E:/Works/encoder/lib/cglib-2.2.jar
E:/Works/encoder/lib/cglib-nodep-2.1_3.jar
E:/Works/encoder/lib/commons-codec-1.1.jar
E:/Works/encoder/lib/commons-collections-3.2.jar
E:/Works/encoder/lib/commons-lang-2.1.jar
E:/Works/encoder/lib/commons-logging-1.0.4.jar
E:/Works/encoder/lib/commons-logging.jar
E:/Works/encoder/lib/dom4j-1.4.jar
E:/Works/encoder/lib/ehcache-0.9.jar
E:/Works/encoder/lib/gameserver_core_1.0.1.jar
E:/Works/encoder/lib/hibernate-annotations.jar
E:/Works/encoder/lib/hibernate-commons-annotations.jar
E:/Works/encoder/lib/hibernate-entitymanager.jar
E:/Works/encoder/lib/hibernate-tools.jar
E:/Works/encoder/lib/hibernate2.jar
E:/Works/encoder/lib/hibernate3.jar
E:/Works/encoder/lib/jakarta-oro.jar
E:/Works/encoder/lib/jasypt-1.5.jar
E:/Works/encoder/lib/javassist-3.9.0.GA.jar
E:/Works/encoder/lib/JTA. Jar
E:/Works/encoder/lib/jzlib-1.0.7.jar
E:/Works/encoder/lib/libthrift. Jar
E:/Works/encoder/lib/log4j-1.2.15.jar
E:/Works/encoder/lib/mina-integration-beans-2.0.0-M4.jar
E:/Works/encoder/lib/mysql-connector-java-5.0.8-bin.jar
E:/Works/encoder/lib/persistence. Jar
E:/Works/encoder/lib/proxool-0.9.1.jar
E:/Works/encoder/lib/proxool-cglib.jar
E:/Works/encoder/lib/slf4j-api-1.5.6.jar
E:/Works/encoder/lib/slf4j-log4j12-1.5.6.jar
E:/Works/encoder/lib/spring. Jar
E:/Works/encoder/lib/springside3-core-3.1.4.jar
E:/Works/encoder/lib/xerces-2.6.2.jar
E:/Works/encoder/lib/xml-apis.jar

Classloader is used to load classes and is fully responsible for delegation. The so-called full responsibility means that when a classloader loads a class, the classloader is responsible for loading all the classes that this class depends on and references, unless it is explicitly loaded using another classloader, the delegate mechanism is to first look for the parent (parent) Class Loader (instead of super, it is not an inheritance relationship with the parent classloader class, you can only search for it from your own class path when the parent cannot be found. In addition, the cache mechanism is used for class loading, that is, if the class is saved in the cache, it is directly returned. If the class is not saved, it is read from the file and converted to the class, and saved to the cache, this is why we modified the class but had to restart JVM to take effect.
The sequence of class loaders is:
Bootstrap classloader, extension classloader, and system classloader. You will find that the more important the loaded class is, the more important it is. This is because of security considerations. Imagine the consequence of loading a destructive "Java. Lang. System" class by system classloader. This delegate mechanism ensures that even if you have such a class, you can add it to the class path, but it will never be loaded, because this class is always loaded by bootstrap classloader.

System. Out. println ("Bootstrap classloader-pilot (also called the original) Class Loader ");
URL [] URLs = sun. Misc. launcher. getbootstrapclasspath (). geturls ();
For (INT I = 0; I <URLs. length; I ++ ){
System. Out. println (URLs [I]. toexternalform ());
}
System. Out. println ("extension classloader-extension class loader ");
System. Out. println (system. getproperty ("Java. Ext. dirs "));
System. Out. println ("system classloader-system (also called Application) classloader ");
System. Out. println (system. getproperty ("Java. Class. Path"). Replace (";", "/N "));

==========================================================

Every class in Java is loaded to the memory through the class loader. The workflow for the class loader is as follows:
1. searchfile ()
Find the class file that I want to load. (The concept of dropping the jar package is to load a. Class file)
2. loaddataclass ()
The bytecode used to read this type of file.
3. defineclass ()
Load class files. (The loading process is actually very complicated. We will not study it now .)
From this process, we can clearly find that custom class loading can easily control the loading process of each class file. In this way, we can flexibly control the process between Step 2 (loaddataclass) and step 3 (difineclass.
The encryption and decryption technology is applied here.

Classloader
1. What is classloader?
A Java program is not an executable file. It is loaded into the JVM only when necessary. Classloader is used to load classes into the memory in JVM. Moreover, Java classloader is written in Java. This means you can create your own classloader
The basic goal of classloader is to provide services for class requests. When the JVM needs to use a class, it requests this class from classloader according to the name, and then classloader tries to return a class object that represents this class. You can create a custom classloader by overwriting methods corresponding to different stages of the process.
2. Some important methods
A) method loadclass
Classloader. loadclass () is the entry point of classloader. The method is defined as follows:
Class loadclass (string name, Boolean resolve;
Name the name of the class required by JVM, such as Foo or Java. Lang. object.
The resolve parameter indicates whether the method needs to parse the class. Before preparing the execution class, consider class resolution. Resolution is not always required. If the JVM only needs to know whether the class exists or find out the super class of the class, it does not need to be parsed.

B) method defineclass
The defineclass method is the main tool of classloader. This method accepts an array composed of the original bytes and converts it to a class object. The original array contains data loaded from a file system or network. Defineclass manages many of the complex, mysterious, and implementation-dependent aspects of JVM-It analyzes bytecode into runtime data structures, verifies validity, and so on. Don't worry, you don't need to write it yourself. In fact, even if you want to do so, you cannot overwrite it because it has been marked as final.

C) Method findsystemclass
The findsystemclass method Loads files from the local file system. It looks for a class file in the local file system. If it exists, it will use defineclass to convert the original byte to a class object to convert the file to a class. When running a Java application, this is the default mechanism for JVM to load classes normally. (Classloader changes in Java 2 provide detailed information about the process changes in Java 1.2 .) For a custom classloader, you can use findsystemclass only after you try other methods to load the class. The reason is simple: classloader is responsible for executing the special steps for loading classes, not for all classes. For example, even if the classloader loads some classes from a remote web site, a large number of basic java libraries need to be installed on the local machine. These classes are not of our concern, so JVM should load them by default: from the local file system. This is the use of findsystemclass.

D) method resolveclass
As mentioned above, classes can be loaded not completely (without resolution), or completely (with resolution. When writing our own loadclass, you can call resolveclass, depending on the resolve parameter value of loadclass.

E) method findloadedclass
Findloadedclass acts as a cache: When loadclass is requested to load the class, it calls this method to check whether the class has been loaded, which can avoid the trouble of re-loading the existing class. Call this method first.

3. How to assemble these methods
1) Call findloadedclass to check whether a mounted class exists.
2) if not, use the special magic method to obtain the original bytes.
3) if the original bytes exist, call defineclass to convert them into class objects.
4) if no original bytes exist, call findsystemclass to check whether the class is obtained from the local file system.
5) if the resolve parameter is true, call resolveclass to parse the class object.
6) If no class exists, return classnotfoundexception.

4. classloader changes in Java 2
1) default Implementation of loadclass
The customized loadclass method is generally used to load the requested class. If you write many classes, you will find that you write variables on the same and complex methods again and again. In Java 1.2, the implementation of loadclass is embedded with the general methods of most search classes, and you can customize it by overwriting the findclass method. When appropriate, findclass will call loadclass. The advantage of this method is that you may not have to overwrite loadclass; you only need to overwrite findclass, which reduces the workload.

2) New Method: findclass
The default Implementation of loadclass calls this new method. The purpose of findclass includes all the special code of your classloader without the need to copy other Code (for example, when a special method fails, the system classloader is called ).

3) New Method: getsystemclassloader
If you override findclass or loadclass, getsystemclassloader enables you to access the system classloader (instead of calling it from findsystemclass) with the actual classloader object ).

4) New Method: getparent
To delegate a class request to the parent classloader, this new method allows the classloader to obtain its parent classloader. This method can be used when a custom classloader cannot find a category.
The parent classloader is defined as the classloader of the object that creates the Code contained in the classloader.