Shulou(Shulou.com)06/02 Report--

How to analyze the JDK source code in the ClassLoader analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

ClassLoader class as a JDK source code for our program to provide some help, programming generally need to edit, compile, connect, load and run several steps. In our application, there is some common code that needs to be used repeatedly, so the code is compiled into a "library" file; in the connection step, the connector will take the required code from the library file and copy it into the generated executable file. This library is called a static library, and its characteristic is that the executable file contains a complete copy of the library code; the disadvantage is that there will be multiple redundant copies if it is used multiple times.

In order to overcome this disadvantage, dynamic link library can be used. At this time, the connector simply marks the executable file to indicate which dynamic link libraries need to be used; when the program is running, the loader loads the required dynamic link libraries into memory according to these flags.

In addition, in the current programming environment, it generally provides ways for programs to load and run a specific dynamic link library at run time, or unload it (for example, LoadLibrary () & FreeLibrary () of Win32 and dlopen () & dlclose () of Posix). This feature is widely used to update certain functional modules or program appearance while the program is running.

What is the meaning of ClassLoader in JDK source code?

Unlike ordinary programs, Java programs (class files) are not local executable programs. When you run the Java program, you first run the JVM (Java Virtual Machine), and then load the Java class into the JVM to run. The part responsible for loading the Java class is called Class Loader.

JVM itself contains a ClassLoader called Bootstrap ClassLoader, and like JVM, Bootstrap ClassLoader is implemented in native code and is responsible for loading the core Java Class (that is, all classes at the beginning of java.*). In addition, JVM provides two ClassLoader, both of which are written in Java and loaded by Bootstrap ClassLoader; Extension ClassLoader is responsible for loading extended Java class (such as all classes at the beginning of javax.* and classes stored in JRE's ext directory), and Application ClassLoader is responsible for loading the application's own classes.

When does the JDK source code load a class?

When will JVM use ClassLoader to load a class? When you use java to execute a class, JVM uses Application ClassLoader to load the class; then if class A references class B, either directly or with Class.forName (), JVM will find the ClassLoader that loads class An and use this ClassLoader to load class B.

Why use your own ClassLoader?

It seems that JVM's own ClassLoader is enough, so why do we need to create our own ClassLoader?

Because JVM's native ClassLoader only knows how to load standard java class files from the local file system, if you write your own ClassLoader, you can do this:

◆ automatically verifies digital signatures before executing unbelievable code

◆ dynamically creates customized build classes that meet the specific needs of users

◆ fetches java class from a specific place, such as in a database, etc.

In fact, when using Applet, you use a specific ClassLoader because you need to load java class from the network and check the relevant security information.

Most of the current application servers use ClassLoader technology, even if you do not need to create your own ClassLoader, understanding its principle will help to better deploy your own applications.

ClassLoader Tree & Delegation Model

When you decide to create your own ClassLoader, you need to inherit java.lang.ClassLoader or its subclasses. When you instantiate each ClassLoader object, you need to specify a parent; if not, the system automatically assigns ClassLoader.getSystemClassLoader () as the parent. As shown below:

After Java 1.2, java class loads in the so-called delegate mode (Delegation Modle), and when a ClassLoader.loadClass () is called to load a class, the following steps are followed:

1) check whether the class has been loaded.

2) if it is not already loaded, call the parent object to load the class

3) if the parent object cannot be loaded, call the object's findClass () to get the class.

So when you create your own Class Loader, you only need to overload the findClass () method.

Unloading? Reloading?

When a java class is loaded into JVM, is it possible to unload it? We know that Win32 has a FreeLibrary () function, and Posix has a dlclose () function that can be called to unload the specified dynamic link library, but Java does not provide a UnloadClass () method to unload the specified class.

In Java, the uninstall of java class is only an optimization of the system, which helps to reduce the memory footprint of applications. Since it is an optimization method, it is entirely up to JVM to decide how to implement it, which is completely transparent to Java developers.

In the programs provided by the JDK source code, when will a java class/interface be uninstalled? The exact words of Sun are: "class or interface may be unloaded if and only if its class loader is unreachable. Classes loaded by the bootstrap loader may not be unloaded."

In fact, what we care about is not how to unload the class, what we care about is how to update the loaded class to update the functionality of the application. JSP is a typical example. If a JSP file is changed, the application server needs to recompile the changed JSP and then load the newly generated class to respond to subsequent requests.

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 class definition). We can only recreate a new ClassLoader instance to load the new class again. Developers don't have to worry about classes that have already been loaded, because there may be instances in use, and as long as the relevant instances are reclaimed in memory, JVM will unload classes that will no longer be used at the appropriate time.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.