JAVA VIRTUAL machine class loading mechanism

The Java virtual machine loads the.class class into memory and verifies, parses, and initializes the data. Form Java objects that can be used directly by the virtual machine. This is the classloading mechanism.

The class loading process is as follows: To support runtime binding, the parsing process can take place when initialization is complete, and the rest of the loading process must follow the process shown above.

Java.lang.Class forName() and Java.lang.ClassLoader loadClass() in Java

  • Contact: the forName() method uses the caller’s class loader loadClass() method to class load the class.
  • Difference: class.forname (String) When loading a Class, the complete process of loading, connecting, validating, preparing, parsing, and initializing is performed. If you call classLoader.loadClass (String) when the class is loaded, the process of loading, connecting, validating, preparing, and parsing will be performed, and the final initialization process will not be performed. This is a static block of the class that has not been executed and needs to be executed when the class is first instantiated. For example, perform the class.newinstance () operation for the first time.

Today’s focus is on the parent delegate mechanism. If you want to learn more about the class loading process, click here

Parent delegation mechanism

  • BootstrapClassLoader: BootstrapClassLoader, which belongs to the JAVA versus top-level classloader. Mainly load classes under the Java core package, such as rt.jar. It is written in C voice and does not belong to a Java class, so it cannot be referenced. When the JVM starts, it loads class files under the Rt. jar package, such as String and Integer, through the BootstrapClassLoader. Since it is the top-level classloader, there is no parent classloader.
  • ExtentionClassLoader: ExtentionClassLoader, which belongs to the second level of classloader. It mainly loads jar packages and class files in the system directory java.ext.dirs. It is the system class loader of the JVM. The parent class is BootstrapClassLoader.
  • AppClassLoader: application class loader. Load all classes in the ClassPath of the current application. The parent class is ExtentionClassLoader.
  • XxxClassLoader: a custom class loader. Load the custom class file. The parent class is AppClassLoader.

Generally, loading a class starts with the AppClassLoader class loader,

  1. When the AppClassLoader searches for resources, it first checks whether the current target class has been loaded. If it has not been loaded, the first thing to do is not to see if the current class exists in your package path, but to delegate directly to the parent classloader ExtentionClassLoader.
  2. When looking for resources, the ExtentionClassLoader does not first check whether there is a target class file in its own package path, but directly delegates it to its parent class loader, BootstrapClassLoader.
  3. The BootstrapClassLoader is the top-level classloader, so it looks for a target class in the rt.jar package. If it is found, it loads the class and returns it. If it is not found, the ExtentionClassLoader will load it.
  4. If the ExtentionClassLoader class loader finds the target class file, it loads the class and returns. If not then it goes back to the AppClassLoader class loader for loading.
  5. Finally, if none of the other class loadings are found, it will return to its own class loadings. If the target class file is found and successfully loaded, it will return directly.
  6. If AppClassLoader also does not find the target class, an exception is run.

The illustration

When a classloader receives a class loading task, it does not first load the class itself. Instead, it delegates the class to the parent class loader. This is true for class loaders at each level. Therefore, all classload requests are passed to the top-level classloader, and only when the parent classloader reports that the loading is not complete (no target class was found) will the child loader attempt to load the class itself.

The parent delegate function can avoid the repeated loading of classes, guarantee security, and prevent the system JAR package from being overwritten and replaced locally.

The interview questions

  1. What is the parent delegate mechanism? The class loading mechanism is divided into startup class loader, extension class loader, application class loader, and custom class loader. When a classloader receives a request to load a class, it does not load the class itself. Instead, a parent classloader loads the class. If the parent classloader cannot find the class that is not loaded, it loads the class itself.
  2. Why is a parent delegation mechanism needed? What’s wrong with not having a parent delegate mechanism? Prevents repeated class loading and ensures security. Without parent delegation, classes in the CORE package of the JDK can be loaded by malicious substitution.
  3. Are parent loaders and child loaders inherited? Instead of inheritance, they duplicate class loaders through a composite pattern
  4. How is the parent delegate mechanism implemented? It is implemented in the loadClass method of the classLoader. If the parent class loader is null, the initiator class loader is used to load the class. If the parent class loader is not loaded, the findClass of the own class loader is called to load the class.
  5. Can I actively disrupt this mechanism? How? You can. The custom class loader overwrites its loadClass method.
  6. Why does reloadClass () break the parent delegation mechanism and how is this method different from findClass and defineClass? The loadClass method does the class loading. The default parent delegate loading is implemented in this method. The findClass method loads the class by name or location. The defineClass method converts bytecode to class EG: a custom class loader overwrites loadClass to break the parent delegation mechanism. If you need to customize a classloader without breaking the parent delegate, override findClass by inheriting the Classloader. If the parent class loader fails to load after JDK1.2, it will call the findClass method of its own class to load.
  7. What are some examples you know of that break parental delegation? The parent delegate was created after JDK1.2, so previous class loaders did not have a parent delegate; JDBC, Tomact, tools for hot swap and hot deployment, modular technology applications, etc., all break the parent delegation mechanism;
  8. Why does JDBC need to break the parent delegation mechanism? JDBC breaks the parent delegation mechanism by introducing a ThreadContextClassLoader (thread context loader);
  9. Why does Tomcat need to break the parent delegation mechanism? Tomcat breaks the parent delegation mechanism to provide isolation by providing a separate webAppClassLoader for each Web container;
  10. Understanding of modular technology? In JDK1.9, the entire JDK is built based on modularity. Previously, Rt. jar,tool.jar, etc., were split into dozens of modules. When compiling, only the loaded module was compiled, and each class loader was responsible for loading its own module.
  • Finally, learn with an open mind and make progress together. -_ –