Welcome to other blogs on this topic:
Deep Dive into Java Virtual Machine (I)-detailed explanation of the underlying structure of Java Virtual Machine
Deep Dive into Java Virtual Machine (II)-class lifecycle (I) class loading and Connection
In-depth Java Virtual Machine (III)-class lifecycle (ii) class initialization
Go deep into Java Virtual Machine (4)-garbage collection mechanism of Java Virtual Machine
In-depth explanation of Java Virtual Machine (V)-Java Local interface JNI
In-depth Java Virtual Machine (6)-parent delegation mechanism for class loading
The classloader class loader is the object responsible for loading classes. The classloader class is an abstract class. If the binary name of a given class (that is, the full name of the package name and class name) is specified, the Class Loader attempts to find or generate data that constitutes the class definition. The general policy is to convert the name to a file name, and then read the "class file" of the name from the file system ". Java. lang. the basic function of the classloader class is to find or generate the corresponding byte code based on the name of a specified class, and then define a Java class from these byte code, that is, Java. lang. an instance of the class. In addition, classloader is responsible for loading resources required for Java applications, such as files and configuration files. As the base class of all class loaders, the internal implementation mechanism of classloader is worth studying in detail. So today, let's take a look at the internal implementation source code of classloader.
First, let's take a look at the two constructor methods of the classloader class.
From the help document above, we can find that when creating a classloader instance, we can indicate its parent loader or not, if this parameter is not specified, its default parent loader is the system loader. Let's take a look at the implementation of the source code:
/** * Creates a new class loader using the <tt>ClassLoader</tt> returned by * the method {@link #getSystemClassLoader() * <tt>getSystemClassLoader()</tt>} as the parent class loader. */ protected ClassLoader() {SecurityManager security = System.getSecurityManager();if (security != null) { security.checkCreateClassLoader();}this.parent = getSystemClassLoader();initialized = true;}
/** * Creates a new class loader using the specified parent class loader for */ protected ClassLoader(ClassLoader parent) {SecurityManager security = System.getSecurityManager();if (security != null) { security.checkCreateClassLoader();}this.parent = parent;initialized = true; }
From the source code above, we can find that the classloader must have a parent attribute to specify the append of the current loader. The source code also proves the above statement.
After reading the implementation of the constructor method, let's take a look at the loadclass method, a particularly important method in classloader. This method is used to load classes. This method has an overloaded method in JDK, but it is actually a sample. A Method with or without a link class. Let's take a look at the source code of this method:
public Class<?> loadClass(String name) throws ClassNotFoundException {return loadClass(name, false); } /** * Loads the class with the specified <a href="#name">binary name</a>. The * default implementation of this method searches for classes in the * @throws ClassNotFoundException * If the class could not be found */ protected synchronized Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException {// First, check if the class has already been loadedClass c = findLoadedClass(name);if (c == null) { try {if (parent != null) { c = parent.loadClass(name, false);} else { c = findBootstrapClass0(name);} } catch (ClassNotFoundException e) { // If still not found, then invoke findClass in order // to find the class. c = findClass(name); }}if (resolve) { resolveClass(c);}return c; }
I feel that I have no need to explain the source code of this method, because the API has already explained it in detail. I certainly cannot explain it as well, so let's take a look at how the API is explained:
Although the JDK has already been explained clearly, I still need to add one thing. From the source code above, we can see that the loadclass method is a recursive method, which is always searched up until the root class loader is found, and then let the Class Loader load the class. We don't know how to implement it with the loader. This is because a local method is used to load classes with classes. It is written in C ++. We cannot see its source code. This verifies the parent class delegation mechanism of the Class Loader we mentioned earlier.
Next let's take a look at the findclass method, which we found in the above Code. In the loadclass method, the findclass method is called. Next, let's take a look at the API's introduction to this method:
From the above introduction, we can see that this method is mainly used to find our class files. We should rewrite this method when customizing our own class loaders, because this method is basically not implemented in JDK, and we need to rewrite this method ourselves, use our own defined methods to find class files. Do not believe it. You can take a look at its source code implementation:
protected Class<?> findClass(String name) throws ClassNotFoundException {throw new ClassNotFoundException(name); }
Let's introduce this for the time being. Other methods are similar. Recently, it seems that blogs are getting harder and harder to write. The lack of underlying theories is becoming increasingly apparent. We hope that through our own efforts, we can slowly change this situation.
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