In the previous two blogs, we briefly introduced the basics of the class loader and the basic content of the class lifecycle, today, let's continue to look at the detailed content of the Java class loader. We all know. The class loader is used to load classes to Java virtual machines. Since jdk2.0, the class loading process adopts the parent delegation mechanism. The JVM classloader adopts a tree structure. Apart from the root class loader, each classloader has only one parent class loader, the default parent class loader of the User-Defined classloader is the system class loader. Of course, you can specify a classloader instance by yourself. Let's look at their parent-child relationship:
In the parent class delegation mechanism, when a Java program requests loader1 to load the Hello class, loader1 first delegates its parent loader to load the Hello class. If the parent loader can load the Hello class, the Uploader loads the character. Otherwise, the loader1 loader loads the Hello class. Next, let's take a look at several loaders that come with the Java Virtual Machine:
In addition to the built-in loaders of the Java virtual machine, you can also customize your own class loaders as needed .. Java provides the abstract class java. Lang. classloder. All user-defined class loaders must inherit this classloader class.
Note:The parent-child relationship between loaders actually refers to the packaging relationship between loader objects, rather than the inheritance relationship between classes. A parent-child loader may be two instances of the same loader class, or not. A parent loader object is encapsulated in the sub-loader object. when a custom classloader instance is generated, if its parent loader is not specified, the system classloader will become the parent loader of the class loader. If the parent class loader is specified in the constructor, the parent class loader is the specified loader. The proof is as follows:
Classloader loader1 = new myclassloader (); // The loader1 parameter will be used as the parent loader classloader loader2 = new myclassloader (loader1) of loader2 );
When the Java Virtual Machine loads a class, which class loader should be assigned to load the class? We can see:
Loader1 and loader2 are two class loaders defined by ourselves. loader1 and loader2 are parent-child relationships. Now we want the loader2 class loader to load a sample class we have written: loader2.loadclass ("sample "), let's analyze to see which class loader should be used for loading. When this code is executed, loader2 first goes to its namespace to check whether the sample class has been loaded. If it is loaded, it directly returns the reference of the class object of this class. If the sample class has not been loaded, loader2 first requests loader1 for loading, loader1 requests the system class loader for loading, and the system class loader requests the extended class loader, the extension class loader then requests the root class loader. If neither the root class loader nor the extension class loader can be loaded, the system class loader tries to load the file. If the file can be loaded, then, the reference of the Class Object corresponding to the sample class is returned to loader1, and loader1 returns the reference to loader2, so that the sample class is successfully loaded to the virtual machine. If the system class loader cannot load the sample class, loader1 tries to load the sample. If loader1 cannot be loaded, loader2 tries. If all classes cannot be loaded, A classnotfoundexception exception is thrown.
Define a Class Loader: If a class loader can load a class, the class loader is called the definition Class Loader. The definition class loader and all its subloaders are called:Initial Class Loader
The advantage of the parent delegation mechanism is to improve the security of the software system. Because, under the word mechanism, the user-defined class loader cannot load the reliable class that should be loaded by the parent loader, this prevents unreliable malicious code from replacing the reliable class loaded by the parent class loader, and prevents unreliable or even malicious code from replacing the reliable code loaded by the parent class loader. For example, the Java. Lang. Object Class is always loaded by the root class loader. Other user-defined class loaders cannot load the java. Lang. Object Class containing malicious code.
In fact, the namespace mentioned here is a commonly used package in Java. Each class loader has its own namespace, the namespace consists of the loader and all classes loaded by the parent loader. In the same namespace, there will be no two mines with the same full name of the class (including the package name of the class). In different namespaces, there may be two classes with the same full name (including the package name of the class.
Classes loaded by the same class loader belong to the same package constitute a runtime package. Determine whether the two classes belong to the same runtime package. It depends not only on whether their package names are the same, but also on whether the class loaders are the same. Only the classes that belong to the same runtime package can access each other's visible (default access level) classes and members. Assume that you have customized a Java class. lang. testcase is loaded by a Class Loader for customization. lang. testcase and core class library Java. lang. * loaded by different class loaders, which belong to different runtime packages, so Java. lang. testcase cannot access the core library Java. visible member in the lang package.
Reference materials: free training video for Teacher Zhang Long in Beijing
Bytes ------------------------------------------------------------------------------------------------------------
The electronic book "Java programmers from stupid birds to cainiao" is officially released. You are welcome to download it.
Http://blog.csdn.net/csh624366188/article/details/7999247