Class life cycle

From loading into memory to unloading out of memory, the class has gone through four stages: loading, connecting, initializing and using, among which connecting includes three steps: verification, preparation and parsing. These steps generally follow the sequence shown in the figure, but the Java language itself supports runtime binding, so the parsing phase can also occur after initialization. The above order is just to say the beginning of the order, the actual process is cross-carried out, the loading process may have started to verify.

Class loading process

1, load,

The class loading process is more, the load is one of the first step, is responsible for. The class file loaded into memory, but it can not only from the local. The class file to load a class or interface, also can from the jars, WAR file, remote access to network resources and loaded into the virtual machine, through dynamic proxy technology can be generated dynamically at runtime. JSP files, for example, can also generate corresponding Class classes.

2, validation,

The loaded Class information must be verified to check whether the file format, metadata, and bytecode meet the minimum REQUIREMENTS of VMS, and whether the file is harmful to VMS.

File format verification: verify class file structure metadata verification: verify whether this has a parent class, whether the parent class inherits classes that are not allowed to be inherited, etc. Bytecode verification: In JDK1.6, we only need to check whether the records in the StackMapTable attribute are valid. In JDK1.7, we need to use type checking to verify the symbol reference of the data flow analysis for Class files whose major version is greater than 50. Whether the corresponding class can be found for the fully qualified name, whether there is a field description in the specified class that matches the method, and methods and fields described by simple names. Whether the accessibility is correct. Verification is not successful throws Java. Lang. IncompatibleClassChangeError exception subclasses.

3, preparation,

The amount of memory required for variables is determined at compile time, and the preparation stage for class loading is to allocate memory for class variables and set their initial values (as opposed to user-specified values) in the Method Area shared by the thread.

4, parsing,

The virtual machine replaces the symbol used to identify the reference with the address of the reference it actually points to. A symbol or symbol reference is nothing more than an identifier (descriptor), and the actual address is the true destination memory location.

The resolution action is mainly for references to classes or interfaces, fields (class member variables), class methods, and interface methods.

Class or interface resolution: Determines whether the direct reference to be converted is a reference to an array type or a common object type, and resolves differently.

Field analytical: When parsing a field, the class will first check whether it contains a field whose simple name and field descriptor match the target. If so, the search ends. If not, each interface implemented by the class and its parent interface will be recursively searched from top to bottom according to the inheritance relationship. If not, the parent class will be recursively searched from top to bottom according to the inheritance relationship until the search ends. The search process is as shown in the figure below:



One final note: in theory, search parsing is done in this order, but in practice, the virtual machine compiler implementation may be stricter than the specification requires. The compiler may reject compilation if a field with the same name appears in both the class’s interface and its parent, or in its own or its parent’s interface.

Class method resolution: The resolution of class methods is similar to the search steps for field resolution, but there are more steps to determine whether the method is in a class or an interface, and the matching search of class methods is to search the parent class first, and then search the interface. Interface method resolution: Similar to the class method resolution step, since the interface does not have a parent class, you simply recursively search up the parent interface.

5. Initialization

Initialize the value of the static variable of the class, which is assigned with a value for customization, as opposed to the preparation phase.

Parental delegation model

Bootstrap Class Loader: a built-in Class Loader used to load internal classes of the JDK. The Bootstrap class loader is used to load classes under $JAVA_HOME/jre/lib in the JDK, such as those in the rt.jar package.

(2) Extension Class Loader is mainly used to load JDK Extension classes. Typically, packages under $JAVA_HOME/lib/ext are loaded through this class loader, and the classes under this package basically start with Javax.

(3) Application Class Loader

Why is it called the parental delegation model?

This is a painful translation problem. In fact, in the official Oracle documentation, it is described as follows:

The Java platform uses a delegation model for loading classes. The basic idea is that every class loader has a "parent". class loader. When loading a class, A class loader first "delegates" the search for the class to its parent class loader before attempting to find the class  itself.Copy the code

The Java platform loads classes by delegating models. Each class loader has a parent loader. When a class needs to be loaded, it preferentially delegates the parent loader of the current class to load the class. If the parent loader cannot load the class, try loading the class in the loader of the current class.

So Java’s class-loading mechanism should be called the “parent delegate model”, not the “parent delegate mechanism”, which is too misleading. The person named this may have a deep conception of gender equality.

Advantages of the parental delegation model

Java class loading uses the parent delegate model, in which a class loader delegates the request to its parent class loader when it loads a class. If the parent class loader still has a parent class loader, it continues delegating until the top-level class loader starts. If the parent class loader is able to complete the class load, it returns successfully, and if the parent class loader is unable to complete the load, the child loader will attempt to load itself.

One benefit of this parent delegate pattern is that it avoids reloading classes and also prevents the Java core API from being tampered with.

Classes that have already been loaded by the parent class loader do not need to be loaded again, and for some system classes, user – defined classes do not work, there is a certain security guarantee.

The working mechanism of parental delegation

How does the Parent delegation model work? For example, if you have a test. class and need to load the java.lang.String in rt.jar, the loading process is as shown in the following figure. The overall loading process is completed by delegating the parent loader.

If the parent loader does not load the class in the entire link and the class cannot be loaded, the loader of the test. class will load the class (for example, you want to load the developer-defined test2. class).



Reference: Java class loading mechanism: parent delegate mechanism, or should it be called “parent delegate model”?Blog.csdn.net/u010841296/…