Java JVM Learning Note II (Architecture of class loader)

Java class is loaded into memory only when needed, and executed by the execution engine of the Java Virtual machine, and the execution engine is divided into four main ways of execution,

The first, one-time interpretation of the code, that is, when the bytecode is reproduced in memory, every need will be re-parsed once,

Second, instant parsing, which is reproduced into the memory of the bytecode will be parsed cost of machine code, and cached to improve reusability, but more memory consumption,

Third, adaptive optimization parsing, the Java will use the poorest code to compile the cost of the machine code, and the use of the non-poor to keep bytecode unchanged, an adaptive optimizer can enable the Java Virtual machine in 80%-90% of the time to execute the optimized local code, and only need to execute 10%-20% Code that has an impact on performance.

Fourth, a chip capable of parsing Java bytecode directly using local methods.

Java JVM Learning Note II (Architecture of class loader)

Before we know the class loader for a Java Virtual machine, there is a concept that we must know first, that is, the Java sandbox, what is the Java sandbox, and the Java sandbox has gone through such a process, from the simple java1.0 base sandbox to the java1.1 Granular access control based on the signature and authentication sandbox to the later java1.2 based on the base sandbox + signature authentication sandbox .

The Java sandbox is where you can accept code from any source, but the sandbox restricts its ability to do anything that could disrupt the system, because the sandbox's overall access to the system has been limited, so the sandbox image is more like a prison, trapping code that has destructive power.

The basic components of the Java sandbox are as follows:

1. Class loader structure (can be customized by the user)

2.class File verifier

3. Built-in Java virtual machine

4. Security Manager (can be customized by user)

5.java Core API

Java's sandbox class loader and security Manager can be customized , but this increases the risk of Java code security, so Java has a call access control architecture, which includes Security policy specification and Runtime Security Policy enforcement, Java has a default security policy manager that allows users to extend on top of it by using the default security Policy manager.

Architecture of the Java class loader

The Java Class loader works on the Java sandbox in three ways:

1. It prevents malicious code areas from interfering with good-natured code

How to understand this sentence, different class loaders will be loaded into the same class when a unique namespace, the Java Virtual Machine maintenance of these namespaces, the same class, a namespace can only be loaded once, and will only be loaded once, the classes between different namespaces as if each have a shield, do not feel the existence of each other , as shown in 3-1

2. It protects the trusted class library boundaries

Here are two concepts that need to be understood, one, two-parent-delegate mode, the second run-time package, andthe Java Virtual machine to define the boundary of the class library through these two aspects

What is parental delegation mode

Let's take a look at a diagram and a piece of code

This diagram illustrates the class loading process, but the light is not so clear, we only know that when the virtual machine starts to start Bootstrapclassloader, it is responsible for loading the Java Core API, and then Bootstrapclassloader will load

The Extclassloader ( Extension class loader)in Launcher.java, and sets its parent to null, which represents the Bootstraploaderextclassloader again extclassloader to load the expansion class library under Ext, then Bootstrap Loader to load Launcher.java appclassloader ( user-defined class loader ), and sets its Parent as the Extclassloader entity that was previously produced. Both loaders exist in the form of static classes, and below we find Java.lang.ClassLoader's LoadClass method

[Java]View Plaincopy

2. <span style="FONT-SIZE:14PX;" >protected synchronized class<?> loadclass (String name, boolean resolve)
4. throws ClassNotFoundException
6. {
8. //First, check if the class has already been loaded
10. Class C = findloadedclass (name);
12. if (c = = null) {
14. try {
16. if (parent! = null) {
18. c = Parent.loadclass (name, false);
20. } Else {
22. c = FINDBOOTSTRAPCLASS0 (name);
24. }
26. } catch (ClassNotFoundException e) {
28. //If still not found, then invoke Findclass in order
30. //To find the class.
32. c = findclass (name);
34. }
36. }
38. if (resolve) {
40. Resolveclass (c);
42. }
44. return C;
46. }</span>

This method tells us the process of the parent-delegate mode, when the virtual machine to load a class will call a method called LoadClass, and then in this method it will first call Findloadedclass to determine whether to load the class byte code has been transferred to the memory, if not, It will find its parent (here the parent refers to the loader that loads itself, generally our application class's parent is Appclassloader), then calls the parent's loadclass, repeats itself loadclass process, If the parent does not have the class loaded, call Findbootstrapclass (here refers to bootstrap, boot loader) to try to load the class's bytecode, and if Bootstrap is not able to load the class, It calls its own findclass to try to mount the class, and throws an exception if it is still not able to load.

The above is a simple description of the parental pattern, so what are the benefits of the parental delegation description?

You try to write a java.lang.String class, and then run around the ecplise, there is no exception found thrown, to see this exception

[Java]View Plaincopy

1. <span style="FONT-SIZE:14PX;" >java.lang.NoSuchMethodError:main</span>

To run this java.lang.String of our own defined class, the parent-delegate mode loading process is as follows Appclassloader-Extclassloader-Bootstraploader, Since Bootstraploader only loads the class in the core API and matches it to the string class in the core API (Java_home\jre\lib), it thought that finding the class would go directly to the main function in the string class in the core API. So it throws an exception, and the string we write ourselves doesn't have a chance to be loaded into memory, which prevents our own class from destroying the Java core code.

What is a run-time package

To understand the runtime package, let's start with a question, if you define a JAVA.LANG.A class yourself, can you access the friend member of the Java.lang.String class?

No, why? This is the runtime package in effect, Java syntax, the members of the package access can be accessed by the class under the same package, that is why not access it, the same is to prevent virus code corruption, the Java Virtual machine allows only the same class loader loaded into the same package type mutual access, The same type of loader, which belongs to the same package, is the runtime package that we refer to as a collection of multiple types.

3. Classify the code into a class (the protection domain) that determines what the code can do

Except 1. Block different namespaces, 2. Outside the bounds of the Trust class library, the third important role of the class loader is to protect the domain, and the class loader must put the code into the protection domain to qualify the actions that the code can perform when it runs, as I said above, like a prison, and not allow it to operate in the prison area unexpectedly.

Special Note: The above part of the content, there are references to other online authors of the wonderful refinement, if offended, please forgive me, only to do the study notes use!

Java JVM Learning Note II (Architecture of class loader)