Small knowledge, big challenge! This paper is participating in theEssentials for programmers”Creative activities

Now that we know the parent delegate mechanism of class loaders and how it works, it’s time to check if we have a solid foundation in defining a class loader

Review the principles of class loaders

Again, the entry point for the classloader is that c++ calls Java code to create JVM initiators, one of which is the sun.misc.Launcher Launcher. This initiator starts and loads AppClassLoader and ExtClassLoader. The launcher. GetClassLoader () method is called to get the loader object, which is essentially a ClassLoader, and the loadClass(“…”) of the ClassLoader is called. The) method loads the class. Also in loadClass (“…” The parent delegate mechanism is implemented in the) method.

Detailed principles refer to the article: www.cnblogs.com/ITPower/p/1…

Analysis of custom class loaders

For the classloader, we know that its focus is loadClass(…). The parent delegate mechanism is implemented in the loadClass method. The findClass() method actually loads the class. There are two things we need to do for our custom classloader

  1. This custom ClassLoader inherits from the ClassLoader
  1. This ClassLoader overrides the findClass() method in the ClassLoader class

In addition, we can refer to AppClassLoader and ExtClassLoader to write.

Third, custom class loader implementation

Below I define a class loader of my own

Step 1: Define a custom ClassLoader that inherits from the ClassLoader abstract class, and then define a constructor that accepts the name of the class to be loaded

Step 2: Rewrite the core method findClass(String name)

There are two steps here,

The first is: from the classpath to load the contents of the file, custom

The second is to call the method that constructed the class, calling the system defineClass

How is a custom loadByte implemented

The implementation here is to find the class, read the contents of the class, convert them into binary bytecode, and return

The last part is how to call it.

The class is loaded with a class loader, then instantiated, using reflection to call User1’s method sout

package com.lxl.jvm; Public class User1 {public void sout() {system.out.println (" enter User1"); }}Copy the code

Inside this System. The out. Println (clazz getClassLoader () getClass (). The getName ()); Get the classloader for the current class, and guess who will be printed here?

See? AppClassLoader. Why?

The reason is that I already have a class User1 in my project

The parent class of our custom class loader is AppClassLoader. User1 in the program code happens to be loaded by AppClassLoader, so it won’t look up in the folder we specified

This is the nature of the parent delegate mechanism of a class.

So if we remove the User1 class from the project, who is this classloader? Our custom class loader, of course.

Why is the parent of a custom classloader AppClassLoader?

Why is the parent of a custom class loaded by appClassLoader?

Let’s look at the source code

Our custom ClassLoader inherits from the ClassLoader, so before calling the constructor of the custom ClassLoader, we should first load the constructor of the parent class ClassLoader without arguments.

The ClassLoader’s no-argument constructor is executed first.

A constructor with no arguments calls its own constructor

There’s a parent in there, and we’re just going to see who that parent is. Take a look at the getSystemClassLoader() method

We’ve looked at getClassLoader(). What loadClass is defined in this method? Is AppClassLoader.

This is why the parent of the custom class loader is AppClassLoader.