1The JVM runs the main function of a class as follows

LoadClass can be divided into several steps

Load -> Verify -> Prepare -> Parse -> Initialize ->Use -> Uninstall

1. Loading: the byte code file is read through IO in the hard disk search, and will be loaded only when the class is used, including main, new.. In the loading phase, an Object java.lang.Object representing the class is generated in memory as an entry point to access the class

2. Verification: Verify the accuracy of the bytecode file

3. Preparation: Static variables allocate memory and assign default values

4. To replace symbolic references with direct references is to replace some static methods with Pointers to the corresponding memory data. This is called static join

5. Initialization: Assign an initial value to a static variable and execute a static code block

Class loaders fall into several categories

  • The bootloader is responsible for loading the core libraries that support the JVM. The core libraries in the JRE lib, such as Charsets, etc.
  • Extension classloader: jar package of ext extension in lib directory of JRE
  • Application class loaders: things in the class directory that you write yourself
  • Custom class loader: loads the class package in the user-defined directory

The class loader initializes the client

Sun.misc.Launcher initialization uses a single-column mode to ensure that there is only one sun.misc.Launcher field in the JVM. Two classloaders are created in the Launcher constructor: ExtClassLoader, the default classLoader for the AppClassLoader Launcher is AppClassLoader, So this is the AppClassLoader that gets returned by getClassLoader, which is the default AppClassLoader to load our application and when we create the AppClassLoader we pass var1, The parent property of the AppClassLoader will eventually be set to ExtClassLoaderCopy the code

Parent delegation mechanism

Look at the loadClass method of AppClassLoader and finally call the loadClass of ClassLoader

    protectedClass<? > loadClass(String name,boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            
            Parent.loadclass (name, false); parent.loadClass(name, false);
            // see if the class is loadedClass<? > c = findLoadedClass(name);if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if(parent ! =null) {
                        // Call the parent class load when parent is present
                        c = parent.loadClass(name, false);
                    } else {
                        // Call the bootstrap classloader without itc = findBootstrapClassOrNull(name); }}catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    // findCalss() of UrlClassLoader is called when the parent loader is not loaded.
                    c = findClass(name);

                    // this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0); sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); sun.misc.PerfCounter.getFindClasses().increment(); }}if (resolve) {
                resolveClass(c);
            }
            returnc; }}Copy the code

Why design parental delegation

  • Sandbox security: Prevents core libraries from being String modified, and self-written java.lang.String cannot be loaded back into the wrong stack
  • Avoid Class reloading: If the parent loader is loaded, there is no need for child loading to ensure the uniqueness of the loaded Class
  • Fully responsible delegate mechanism: When a ClassLoader loads a class, unless another ClassLoader is displayed, the classes that the class depends on are also loaded by that ClassLoader

Custom class loaders

A custom class loader inherits the ClassLoader. There are two important methods: loadClass implements the parent delegate mechanism, and findClass reads the class according to the path and overrides findClass

Break the parent delegate mechanism

The logic is basically a loadClass method, and you override the loadClass method depending on your needs which classes go to the parent delegate and which classes don’t go to the parent loader