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

This article introduces the relevant knowledge of "what is the principle of Java class loading mechanism". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Preface

Before we introduce the class loading mechanism in detail, let's take a look at the classic topic on the Internet about understanding the class loading mechanism:

Public class Singleton {private static Singleton singleton = new Singleton (); public static int counter1; public static int counter2 = 0; private Singleton () {counter1++; counter2++;} public static Singleton getSingleton () {return singleton;}} / / print the value of the static attribute public class TestSingleton {public static void main (String [] args) {Singleton singleton = Singleton.getSingleton () System.out.println ("counter1=" + singleton.counter1); System.out.println ("counter2=" + singleton.counter2);}} / / output result: > counter1=1 > > counter2=0

I won't explain why counter2=0 is here, but I just want to say that it has assessed a few points:

The sequence of the five stages of the class loading process: the preparation phase is before initialization

What each does in the preparation phase and the initialization phase

Details of static initialization: sequence

What is class loading

To get back to the point, let's start with the definition of class loading, an overview.

The virtual machine loads the binary data stream from the class file into the method area of the JVM runtime data area, and after verifying, preparing, parsing and initializing, the virtual machine creates the java.lang.class object in memory as the access entrance to this kind of data structure in the other method area.

Here are a few points to explain. Class files refer to binary data streams that conform to class file format, which is what we often call bytecode files. It is the format agreement between us and JVM. As long as it is a binary stream that conforms to class file format, it can be loaded by JVM. This is also the cross-platform basis of JVM. In addition, the java.lang.class object is only created in memory and does not specify whether it is in the Java heap or not. For Hotspot virtual machines, it is stored in the method area.

Loading mode

Classes can be loaded in two ways: implicit loading and explicit loading.

Implicit loading

The reality is that instead of our code proactively declaring, JVM automatically loads classes at the right time. For example, when a class is actively referenced, the class loading and initialization phase is automatically triggered.

Explicit loading

It usually refers to explicitly loading the specified class through code, which is common in the following ways:

Load the specified class through Class.forName (). For the forName (String className) method, static initialization is performed by default, but if you use another overloaded function forName (String name, boolean initialize, ClassLoader loader), you can actually control whether static initialization is performed through initialize

Loading the specified class through ClassLoader.loadClass () only loads .class into JVM and does not execute static initialization blocks, which will be emphasized later when it comes to the responsibilities of the classloader

As to whether Class.forName () performs static initialization, it is clear at a glance through the source code:

Public static Class forName (String className) / / performs initialization because initialize is true throws ClassNotFoundException {Class caller = Reflection.getCallerClass (); return forName0 (className, true, ClassLoader.getClassLoader (caller), caller);}. Public static Class forName (String name, boolean initialize, ClassLoader loader) / / controllable, specify whether or not to initialize throws ClassNotFoundException {. Return forName0 (name, initialize, loader, caller);} loading time

The first stage of class loading-when the loading phase begins, is not specified by the virtual machine specification, which is determined by the specific virtual machine implementation, and can be divided into two times: preloading and runtime loading:

Preloading: for the commonly used basic library in JDK-rt.jar under JAVA_HOME/lib, it contains our most commonly used class, such as java.lang.*, java.util.*, etc., which will be loaded in advance when the virtual machine starts, so that loading time is saved and access speed is accelerated.

Runtime loading: most classes, such as user code, are loaded when the class is used for the first time, often referred to as lazy loading, probably because of memory savings.

Loading principle loadClass source code

Code first (JDK1.7 source code):

Protected Class loadClass (String name, boolean resolve) throws ClassNotFoundException {synchronized (getClassLoadingLock (name)) {/ / First, check if the class has already been loaded Class c = findLoadedClass (name); if (c = = null) {long t0 = System.nanoTime () Try {if (parent! = null) {c = parent.loadClass (name, false);} else {c = 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 (); c = findClass (name); / / this is the defining class loader; record the stats sun.misc.PerfCounter.getParentDelegationTime (). AddTime (T1-T0); sun.misc.PerfCounter.getFindClassTime (). AddElapsedTimeFrom (T1); sun.misc.PerfCounter.getFindClasses (). Increment () }} if (resolve) {resolveClass (c);} return c;}}

LoadClass is the core code in the class loading mechanism, and this code basically illustrates the following two core points:

Caching mechanism

FindLoadedClass (name), the first step is to check whether the class represented by the name has been loaded by a class loader instance, and if so, directly return the loaded c, otherwise continue the following logic such as delegation. That is, the JVM layer caches loaded classes, so how exactly is it cached? In the JVM implementation, there is a data structure similar to HashTable called SystemDictionary, which caches the loaded class information. The cached key is the fully qualified name of the class loader instance + class, and value is the klass data structure that points to the class information. This is why we often say that the class loader instance that loads the class in JVM plus the fully qualified name of the class, together, the two can uniquely determine a class. Each class loader instance is equivalent to a separate class namespace, and classes loaded by two different loader instances are two completely different classes, even if they have the same name.

Parental appointment

For newly loaded classes, the cache misses and follows the parent delegation logic-when parent exists, it is first delegated to parent for loadClass, and then the same upward delegation is made within parent.loadClass until parent is null and delegated to the root loader. In other words, the delegation request is passed all the way up to the top-level boot class loader, and then uniformly passes it down layer by layer in the way of ClassNotFoundException exception, until a certain layer classLoader finds and loads the class within its search scope; when parent does not exist, there is no parent class loader, so it is directly delegated to the top-level loader-BootstrapClassLoader.

From this we can see that in the parent delegation structure, the parent-child hierarchical relationship between class loaders is not achieved by inheritance, but by combination, that is, the child class loader holds the parent proxy to point to the parent class loader.

Keystone

Because delegates are one-way, classes at the subclass loader level can access classes at the parent loader level, but not vice versa

Each has its own responsibility, and the class loaders at each level are only responsible for loading classes at this level. Implementation: each level of class loader has its own loading path, which is isolated and invisible to each other. Learn about the ucp attribute of URLClassLoader ~

The protocol between ClassNotFoundException-- parent and child class loaders. Only when the parent class loader throws this exception, the load request is passed to the lower layer, and the other exceptions are not recognized!

This priority of the upper and lower layers further ensures the stability of the Java program, and the core classes in the JDK library will not be overwritten because of the user's misdefined class of the same name.

Class loader

Let's give a definition:

Get the code module that describes the binary byte stream of a class through the fully qualified name of a class

Classic three-layer loader structure:

1. Boot class loader (or boot class loader): only responsible for loading the specific name class library in the / lib directory or in the path specified by the startup parameter-Xbootclasspath. The loader is implemented by C++ and is not visible to the Java program. For a custom loader, if no parent is specified, the loader will be delegated to load.

2, extended class loader: responsible for loading all class libraries in the / lib/ext directory or under the path specified by the java.ext.dirs system variable. The loader is implemented by sum.misc.Launcher$ExtClassLoader and can be used directly.

3. Application class loader (or system class loader): responsible for loading all class libraries in the user classpath ClassPath. The loader is implemented by sum.misc.Launcher$AppClassLoader and can be obtained by the ClassLoader.getSystemClassLoader () method.

Keystone

ExtClassLoader and AppClassLoader are both inherited from URLClassLoader, and their respective load paths are saved in the ucp attribute, which can be seen by the source code.

Three times "sabotage"

Parental delegation is not a mandatory constraint model, after all, it has its own limitations. Whether at the historical code level, SPI design issues, or new hot deployment requirements, it will inevitably violate this principle, with a cumulative total of three "breaks".

Coverable loadClass method

According to the source code of ClassLoader, the implementation details of parent delegation are in the loadClass method, which is a protected, meaning that subclasses can override the method, thus bypassing parent delegation logic. The parental delegation model was introduced after JDK1.2. Before that, some users of JDK1.0 have rewritten loadClass logic by inheriting ClassLoader, which makes the parental delegation logic introduced later do not work in these user programs.

For forward compatibility, ClassLoader adds a new findClass method that encourages users to put their own class loading logic into findClass instead of overriding the loadClass method.

Its own defect, unable to support SPI

The hierarchical priority of parental delegation determines the inequality between the user code and the JDK base class, that is, only the user code can call the base class, and vice versa. For designs such as SPI, such as JNDI, which has become a standard service of Java, the interface code is in the basic class, while the specific implementation code is that under the user Classpath and under the restrictions of parental delegation, JNDI cannot call the implementation layer code.

Open a back door-introduce thread context class loader (Thread ContextClassLoader), which can be set through java.lang.Thread.setContextClassLoader (). If it is not set when creating a thread, it inherits from the parent thread; if the global scope of the application is not set, it is set to the application class loader by default, which can be found in the source code of Launcher.

With this, the JNDI service can use the loader to load the required SPI code. Other similar SPI designs are in this way, such as JDBC, JCE, JAXB, JBI, and so on.

Dynamic requirements of the program, that is, hot deployment

Modular hot deployment is particularly attractive in the production environment, just like our computer peripherals, which can be replaced at any time, such as mouse, USB disk, etc., without reboot. OSGi has become the de facto Java modularization standard in the industry, at this time the classloader is no longer a tree hierarchy in parent delegation, but a complex mesh structure.

Class Loader instance Analysis of Best Practitioners assigned by Tomcat-- parents

There are usually several basic issues that Web servers need to solve:

Deploy two or more Web applications on the same server, each using Java class libraries that can be isolated from each other.

Multiple Web applications, sharing some of the Java class libraries used. For example, using the same version of spring, sharing a share, whether it is the local disk or Web server memory (mainly method area), is a good savings.

Ensuring the security of the server itself is not affected by the deployed Web application, which is the same as the parental delegation mentioned earlier to ensure the stability of the Java program.

If you support JSP, you need to support HotSwap.

In order to deal with the above basic problems, mainstream Java Web servers will provide multiple Classpath storage class libraries. For Tomcat, the directory structure is divided into the following four groups:

/ common directory, where the class libraries are shared by Tomcat and all Web applications.

The / server directory, which is only used by Tomcat, is not visible to other Web applications.

The / shared directory, which can be shared by all Web applications, but not visible to Tomcat.

The / WebApp/WEB-INF directory, which is used only by the Web application to which it belongs, is not visible to Tomcat and other Web applications.

Corresponding to the above directory is Tomcat's classic parent delegate class loader architecture:

In the figure above, CommonClassLoader, CatalinaClassLoader, SharedClassLoader and WebAppClassLoader are responsible for loading Java class libraries in the / common/*, / server/*, / shared/* and / WebApp/WEB-INF/* directories, respectively. There are usually multiple instances of Jsp class loaders and Jsp class loaders, with one WebAppClassLoader for each Web application and one Jsp class loader for each JSP file.

OSGi-- dares to break through

OSGi (Open Service Gateway Initiative) is a dynamic modular specification based on Java language developed by OSGi Alliance. Its most famous application case is Eclipse IDE, which is the basis of the powerful plug-in system of Eclipse.

Each module in OSGi is called Bundle, and a Bundle can declare the Java Package it depends on (described by Import-Package) or it can declare that it allows the export of published Java Package (described by Export-Package). The dependency relationship between Bundle is horizontal dependency, and there are only rules and no fixed delegation relationship between Bundle class loaders. Suppose there are BundleA, BundleB, and BundleC

BundleA: declare that packageA has been released and rely on java.* 's package BundleB: declare that it depends on packageA and packageC, but also rely on java.* 's package BundleC: declare that packageC has been released and rely on packageA

An example of a simple OSGi classloader architecture is as follows:

This mesh structure in the figure above brings more flexibility, but it may also give rise to many new pitfalls. For example, circular dependencies between Bundle lead to loading deadlocks in high concurrency scenarios.

Summary

Taking a programming question about class loading as a starting point, this paper expounds the specific details of the class loading stage, including loading mode, loading timing, loading principle, and the advantages and disadvantages of parent delegation. Taking the concrete examples of class loader Tomcat and OSGi as examples, this paper simply analyzes the various choices of class loader in practice.

This is the end of the content of "what is the principle of Java class loading mechanism". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.