Classloader classloader_ Detailed explanation of loading method based on Java class

Basic concepts

Classloader class loader, which is used to load Java classes into the Java virtual machine. Unlike ordinary procedures. Java programs (class files) are not local executable programs. When running a java program, first run the JVM (Java virtual machine), and then load the Java class into the JVM for running. The part responsible for loading the Java class is called class loader.

The JVM itself contains a classloader called bootstrap classloader. Like the JVM, bootstrap classloader is implemented in local code and is responsible for loading core javaclasses (i.e. all classes beginning with Java. *). In addition, the JVM also provides two classloaders, which are written in Java language and loaded by bootstrap classloader; Extension classloader is responsible for loading the extended Java classes (such as all classes beginning with javax. * and classes stored in the EXT directory of JRE), and applicationclassloader is responsible for loading the classes of the application itself.

When running a program, JVM starts, runs bootstrapclassloader, the ClassLoader loads Java core API (ExtClassLoader and AppClassLoader are loaded at this time), and then calls ExtClassLoader loading extended API, and finally AppClassLoader loads the CLASSPATH defined under the CLASSPATH directory, which is the most basic loading process of a program.

Note: learn from classloader to see OSGi applications

When will the JVM use classloader to load a class? When you use java to execute a class, the JVM uses applicationclassloader to load the class; Then, if class a refers to class B, either directly or with class Forname () reference, the JVM will find the classloader that loads class A and use this classloader to load class B. The JVM decides whether to load new classes according to the valid execution statements of the runtime, so as to load as few classes as possible, which is different from compiling classes.

Why use your own ClassLoader?

It seems that the JVM's own classloader is enough. Why do we need to create our own classloader?

Because the JVM's own classloader only knows how to load standard Java class files from the local file system. If you write your own classloader, you can:

1) Automatically validate digital signatures before executing untrusted code

2) Dynamically create customized build classes that meet user specific needs

3) Get Java classes from a specific place, such as in a database

4) Wait

In fact, when you use an applet, you use a specific classloader, because you need to load Java classes from the network and check the relevant security information.

Most application servers use classloader technology. Even if you don't need to create your own classloader, understanding its principle will help you better deploy your own applications.

Important note: in fact, a loaded class cannot be updated. If you try to load the same class again with the same classloader, you will get an exception (java.lang.linkageerror: duplicate classdefinition). We can only re create a new classloader instance to load the new class again. As for the originally loaded class, developers do not have to worry about it, because it may have instances that are being used. As long as the relevant instances are recycled, the JVM will unload the unused class at an appropriate time.

Most Java programs use class loaders provided by three systems

1. Start the class loader (bootstrap classloader) to load the class libraries that exist in < java_home > \ lib directory or in the path specified by the - xbootclasspath parameter and are recognized by the virtual machine into the virtual machine. Note that they are identified according to the file name, such as rt.jar. Class libraries with inconsistent names will not be loaded even if they are placed in the Lib directory.

2. Extension class loader (extclassloader), which is responsible for < Java_ In the home > \ lib \ ext directory, or by Java All class libraries in the path specified by the ext.dirs system variable

3. Application class loader (APP classloader) through cassloader Getsystemclassloader(), which is responsible for loading the class library specified on the user's classpath. Generally, this is the default class loader in the program

Parental delegation mode is a kind of loading implementation recommended by Java designers to developers The working process of the parent delegation model is: if a class loader receives a class loading request, it will not try to load the class itself, but delegate the request to the parent class loader to complete it This is true for class loaders at each level, so all load requests will eventually be sent to the top-level startup class loader. Only when the parent class loader does not find the required class, the child loader will try to load it by itself. The advantage of the parent mode is that Java classes have a hierarchical relationship with priority along with their class loaders. For example, the class object is stored in rt.jar. No matter which class loader loads this class, it is ultimately delegated to the startup class at the top of the model. Therefore, the object class can still be guaranteed to be the same class in the environment where the program uses multiple kinds of loaders. On the contrary, if the parental model is not used, users may write an object class themselves, resulting in multiple different object classes in the system. In this way, the most basic behavior in the Java type system cannot be guaranteed.

The classloader class loader in the above article_ The detailed explanation of loading method based on Java class is all the content shared by Xiaobian. I hope it can give you a reference and support programming tips.