Java virtual machine type loading: principle, implementation and application
Author: Liu Chao
I. Introduction
The class-load load of the Java Virtual Machine (JVM) means that the bytecode included in the class file is loaded into the JVM and makes it a part of the JVM. JVM's dynamic loading technology can dynamically load or replace certain functional modules of the system during runtime, without affecting the normal operation of other functional modules of the system. This article will analyze the type load systems in the JVM to explore the principles, implementations, and applications of the Kum-loaded load in JVM.
Second, Java virtual machine class loading implementation and application
2.1 Loading Process Introduction
The so-called load is to find a class or an interface to construct the process of representing this class or the Class object of this interface, where the name or interface is given. Of course, the name can also be calculated, but more common is to construct through search source code after compiling the compiler.
In Java, the class loader puts a class into a Java virtual machine, and has completed three steps: loading, link, and initialization, where the link can be divided into check, prepare, and resolve three steps, except for the analysis, others The step is to complete according to the order, and the main steps of each step are as follows:
Loading: Finding and importing binary data for class or interface; link: Perform the following check, preparation, and resolution step, where the parsing step is to select; check: Check the correctness of the binary data of the import class or interface; Preparation: Assign the static variables to the class and initialize the storage space; resolution: Trimming the symbol reference to direct reference; initialize: the initialization Java code and static Java code blocks for activation of the static variables.
As for the specific details of the type load and virtual machine, please see "Java Virtual Machine Specification" and "In-Java Virtual Machine", and the resource address above the network is: http: / /java.sun.com/docs/books/vmspec/2nd-edition/html/preface.doc.html and http://www.Artima.com/insidejvm/ed2/index.html. Due to the discussion of this article, it will not be described much more.
2.2 Delivery
The loading of the JVM is implemented by ClassLoader and its subclass, and Java ClassLoader is an important Java runtime system component. It is responsible for finding and putting a class file at runtime.
In Java, ClassLoader is an abstract class, which can be said in the package java.lang, which can say that as long as you understand some of the important methods in ClassLoader, combine the specific processes loaded in the JVM described above. Dynamic loading class This technology has a relatively probably mastered, including the following:
1LoadCass method loadClass (String name, boolean resolve) where the Name parameter specifies the name of the class required by the JVM, which is represented by a package representation, such as java.lang.Object; resolve parameter tells the method, if you need to parse classes, before initialization It should be parsed by all classes, if all classes need to be parsed, if the JVM only needs to know if the class exists or finds the superclass of the class, then it is necessary to resolve. This method is the entry point of ClassLoader.
2DefineClass method This method accepts the array of class files and converts it into a Class object. The byte array can be data loaded from a local file system or network. It analyzes the bytecode code into runtime data structure, check validity, and more.
3FindsystemClass method FindsystemClass method is loaded from the local file system. It looks for class files in the local file system. If there is, use DefineClass to convert the byte array into a Class object to convert the file into classes. This is the default mechanism for JVM normally loaded when running a Java application.
4ResolVeclass method resolveclass (class c) method parsed the loaded class, if the class has been parsed, then it will not be processed. When the loadclass method is called, it is determined whether or not the resolve parameter is determined.
5FindLoadedClass method When the loadClass method is called, the FindLoadedClass method is called to see if the ClassLoad is loaded. If it is loaded, then the Class object is returned, otherwise the NULL is returned. If you are forcing an existing class, a link error will be thrown.
2.3 loading application
In general, we need to inherit the abstract class java.lang.classloader when loading the virtual machine, where the method you must implement is loadClass (), and the following is required to implement the following: (1) Acknowledgment class; (2) Check that the category that requests to be loaded is already loaded; (3) Check if the request loaded is a system class; (4) Try to get the requested class from the storage area of the class load; (5) Defining in the virtual machine The requested class; (6) parsing the requested class; (7) returns the requested class.
All Java virtual machines include a built-in class loader, which is called Bootstrap ClassLoader. The particularity of the root loader is that it can only be loaded in the design time known times, so the virtual machine assumes that the categories loaded by the root carrier are safe, trustworthy, can run directly without safety certification. When the application needs to be loaded and not designed, you must use a user-defined ClassLoader. Let us exemplify its application.
Public Abstract Class MulticlassLoader Extends ClassLoader {
...
Public Synchronized Class LoadClass (String S, Boolean Flag)
Throws ClassNotFoundException
{
/ * Check if the class S is already in local memory * /
Class Class1 = (Class) classes.get (s);
/ * Class S is already in local memory * /
IF (Class1! = NULL) RETURN CLASS1;
TRY / * Load the class with the default ClassLoader * / {
Class1 = super.findsystemclass (s);
Return class1;
}
Catch (classnotfoundexception _ex) {
System.out.println (">> NOT A System Class.");
}
/ * Number of bytes of class S * /
Byte Abyte0 [] = loadingClassBytes (s);
IF (ABYTE0 == Null) throw new classnotfoundexception ();
/ * Convert the class byte array to class * /
Class1 = defineclass (null, abyte0, 0, abyte0.length);
IF (Class1 == Null) throw new classformaterror ();
IF (flag) resolveclass (class1); / * Analysis class * /
/ * Add newly loaded classes into local memory * /
Classes.put (s, class1);
System.out.println (">> Returning Newly Loaded Class.");
/ * Return to loading, parsing class * /
Return class1;
}
...
}
Third, the principle of the Java virtual machine
As we have known, a Java application uses two types of type-loaded loaders: RootsTrap and user-defined loaders (User-Defined). The root loader is part of the Java virtual machine implementation, for example, if a Java virtual machine is implemented in the top of the operating system that has already existed and is being used with a C program, then the root loader will be those Part of the C program. The root loader is loaded in a certain manner, including the class of the Java API. A Java program can install the typeload loader you defined by the user during the run. The root loader is part of the virtual machine, and the user-defined class-loader is not, it is written in the Java language, after being compiled into a Class file and then loaded into the virtual machine, and like any other object Can be instantiated. The architecture of the Java class loader is as follows: Figure 1 Java class loading architecture
Java's class load model is a delegation model. When the JVM requires a class loader CL (ClassLoader), the Cl is first forwarded to his parent carrier. CL acquires the opportunity to load this class when the parent loader is not loaded and cannot load this class. Thus, all the agency relationships of all types of loaders constitute a tree relationship. The root of the tree is a Bootstrap ClassLoader, which is represented in JVM. There is only one parent loader other than the root loader. When creating a loader, if there is no explicitly give the parent loader, JVM will default the system loader for its parent loader. Java's basic class loader agent structure is shown in Figure 2:
Figure 2 Agent structure loaded by Java class
The following detailed description is performed for various types of loaders.
Bootstrap loader: This loader does not have a parental loading, which is part of the JVM implementation, loads the core code of the running time library from sun.boot.class.path.
Extension loader: Inherited parental loading is the root loader, unlike the root-loading machine may be related to the operating system, this class loader is implemented with a pure Java code, it from java.ext.dirs (Extended Directory) loading code.
System or Application loader: The loader is an extension loader, we all know that you want to set the environment variable (ClassPath) when installing JDK, this class loader is loaded from java.class.path (ClassPath environment variable) The code is also implemented with a pure Java code, or the user-default parent loader of the user-defined type loader.
Small Application (Applet) loader: loader is a system loader that loads a small application code from a specific directory on the user specified by the user.
When you design a class loader, you should meet the following two conditions:
For the same class name, the object returned by the class load should be the same class object if the class loader CL1 will transfer the request to the class C to the class loader CL2, then the following class or interface, CL1 and CL2 should return The same class object: a) S is the direct superclass of C; b) S is the direct overhead of C) C) S is the type of C's member variable; D) S is a member method of C, parameter type of the builder ; e) return type of the member method of C.
Each class already loaded into the JVM implicitly contains information on the loader loaded. Class Method GetClassLoader can get a class loader loaded with this class. One class loader knows the class of the parent loader understands the class and its own load, the class that the visible loader knows is the supercoming of the class itself loaded. Note that we can get information about the class loader, but the classes that have been loaded into the JVM are unable to change its class loader.
The loading process of the classes in Java is also the process of agents loading. For example, the JVM in the web browser needs to load a small application TestApplet. JVM calls the small application loader ACL (Applet ClassLoader) to complete the load. ACL first requests its parent-loader, that is, the system loader loads the TestApplet whether it is loaded with this class. Since the TestApplet is not in the loading path of the system loader, the system loader does not find this class, and there is no load success. The ACL is then loaded with Testapplet. ACL successfully found TestApplet.class files through the network and imported it into JVM. During the loading process, the JVM discovers that TestAppPet is inherited from the super class java.applet.applet. So JVM calls the ACL again to load the java.applet.applet class. The ACL is loaded again in the order of the above, and the result ACL discovers that his parent-loader has already loaded this class, so the ACL returns this already loaded class to JVM, complete the loading of the Applet class. Next, the superclass of the Applet class is also processed. Finally, TestApplets and all related classes are loaded into the JVM. Fourth, conclusion
The dynamic load mechanism of the class is a core technology of JVM, which is also easy to overlook a lot of misunderstandings. This article describes the principles, implementations, and applications of JVM, especially analyzes the structure, use of ClassLoader, and how to load and execute the Java class with custom ClassLoader. I hope that the reader can load the classes in the JVM have a more in-depth. understanding.
