directory
- 1. The description of the JVM
- 2. Class loading subsystem
- 3. Run time data area
- 4. Vm stack
- 5. The heap area
- 6. Method of area
- 7. Object instantiation and memory access
- Overview of garbage collection
- 9. Classic garbage collector
- 10. The G1 and ZGC
JVM detail structure
1. The role of the classloading subsystem
- 1. The class loading subsystem is responsible for loading class files from the file system or network.
- 2. The loaded Class information is stored in a memory space called the method area. In addition to Class information, the method area stores runtime constant pool information, possibly including string literals and numeric constants (this constant information is a memory map of the constant pool portion of the Class file)
2. The loading process of classes
The class loading subsystem is responsible for loading the class files generated by Java code into memory. The information about the loaded classes is stored in the memory space called the method block. In addition to the loading class information, the method area also stores the runtime constant pool information, which contains string and numeric constants
Loading a class file into memory requires three steps:
-
Loading:
- 1. Use the class loader to find the class file and obtain the byte stream of the class by the fully qualified class name.
- 2. Transform the static storage structure represented by the byte stream into the runtime data structure of the method area
- 3. Generate a java.lang.Calss object representing the Class in the method area. This Class object contains the context information of the Class and acts as the interface for the method to access various data
-
Linking:
- Verify: To ensure that the information in the class file does not harm the JVM. Invalid bytecode files report errors
- 2. Perpare: ForClass variablesAllocates memory, and sets the default value for this variable. namelyZero value.
- The prep phase does not include the final modifier static(static constant) because final variables are assigned values at compile time and the prep phase is initialized directly
- Instead of initialization for instance variable allocation, class variables are allocated to the method area, and instance variables are allocated to the Java heap along with the object
- 3. Resolve: Convert symbolic references in the constant pool to direct references
-
Initiallization:
- The initialization phase is executionClass constructor method
<clinit>()
The compiler will automatically collect all of theClass variablesThe assignment statement andStatic code fastThe assignment statement in theClinit () method.
- The initialization instructions in the constructor method are executed in the order declared in the source file
- The subclass’s Clinit () method is executed before the parent class’s Clinit () method is executed
- The virtual machine must ensure that a class’s Clinit methods are locked synchronously in multiple threads
- The initialization phase is executionClass constructor method
3. Class loading subsystem
3.1 Classification of class loading subsystems
1. The JVM supports two types of loaders, BootStrap classloaders implemented in C/C++ and custom classloaders implemented in Java
2. A custom ClassLoader is conceptually a class of class loaders defined by a developer in a program, but the Java virtual machine specification does not define it this way. Instead, it classifies all classloaders derived from the abstract ClassLoader as custom classloaders.
3. Note that the loader in the figure above is classified as an inclusion relationship, not an inheritance relationship
4. According to the classification of such loaders, our most common class loaders in programs are: BootStrapClassLoader, Extension ClassLoader, System ClassLoader, User-defined ClassLoader
3.2 Functions of various class adders
1. For user-defined classes, AppClassLoader in System ClassLoader is used to load them
2. Java core class libraries are loaded using the BootStrapClassLoader
-
Start the ClassLoader (Bootstrap ClassLoader)
-
1. Use C/C ++ language
-
2. Used to load the Java core class libraries, loading JAVA_HOME/jre/lib/rt. The jar/resources. The jar or sun. Boot. Class. The path the contents of the directory
-
3. Does not inherit to java.lang.ClassLoader, no parent loader
-
4. Load Extension ClassLoader and System ClassLoader.
-
5. For security, only consider loading classes whose package names start with Java, Javax, Sun, etc
-
-
Extension ClassLoader (custom ClassLoader) Extension ClassLoader
-
1. Written in Java language, implemented by Sun.misc.Launcher$ExtClassLoader
-
2. Derived from the ClassLoader class
-
3. Load the class library from the directory specified by the java.ext.dirs system property. If the jar package created by the user is placed in this directory, it will be automatically loaded by the extension class loader
-
-
System application loader (System class loader)AppClassLoader
-
1. Written in The Java language
-
2. Load the class libraries in the path specified by the environment variable classpath or system property java.class.path.
-
3. The class loader is the default class loader in the program. Generally speaking, classes in Java applications are loaded by it
-
4. Use the ClassLoader getSystemClassLoader() method to obtain the ClassLoader
-
-
Custom class loaders
-
1. Implement your own ClassLoader by inheriting the abstract java.lang.ClassLoader class to meet some special needs
-
2. Write your custom class loading logic in the findClass() method
-
3. The URLClassLoader class can be inherited directly without too much responsibility
-
4. Main Functions:
- Isolation load class
- Modify the way classes are loaded
- Expand the loading source
- Preventing source code leakage
-
/** * The VM has a built-in loader */
public class ClassLoaderTest1 {
public static void main(String[] args) {
System.out.println("******** Start class loader *********");
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
// Get the API path that BootStrapClassLoader can load
for (URL e:urls){
System.out.println(e.toExternalForm());
}
// Select a class from the path above and see what its classloader is
. / / the Provider in the/jdk1.8.0 _171 JDK/Contents/Home/jre/lib/jsse jar, the bootstrap class loader to load it
ClassLoader classLoader = Provider.class.getClassLoader();
System.out.println(classLoader);//null
System.out.println("******** extended class loader ********");
String extDirs = System.getProperty("java.ext.dirs");
for (String path : extDirs.split(";")){
System.out.println(path);
}
// Select a random class from the path above and see what its classloader is: extender classloader
ClassLoader classLoader1 = CurveDB.class.getClassLoader();
System.out.println(classLoader1);//sun.misc.Launcher$ExtClassLoader@4dc63996}}Copy the code
3.2 Common methods of CLassLoader
How to obtain a ClassLoader
4. Parent delegation
4.1 Functions of parental delegation mechanism:
-
Avoid classes being loaded repeatedly, using the same classloader for the same class
-
Prevent the core API from being tampered with, and the core class library from being loaded by the startup class loader. Prevent custom classes from being loaded with the same name as the core class, endangering the operation of the JVM
5. Determine whether two classes are equal
5.1 Two necessary conditions in the JVM to indicate whether two class objects exist as the same class
-
The full class name of the class must be consistent, including the package name, even if the full class name of the class is consistent
-
The ClassLoader that loads this class must be the same. In other words, even if these two class objects come from the same class file and are loaded by the same virtual machine, they are not equal in the JVM as long as they are loaded by different ClassLoader instances.
5.2 References to class loaders
The JVM must know whether a type is loaded by the boot class loader or by the user class loader. If a type is loaded by a user class loader, the JVM stores a reference to that class loader in the method area as part of the type information. When resolving a reference from one type to another, the JVM needs to ensure that the loaders for both types are the same.
6. Active and passive use of classes
Java programs can use classes either actively or passively, depending on whether the Clinit () method is invoked
-
Active use of the clinit() method during the third initialization phase in a class-loading system
-
Passive use does not invoke the clinit() method
Active use, divided into seven situations
1. Create an instance of the class
2. Access static variables of a class or interface or assign values to static variables
3. Call the static method of the class
4. Reflection such as class.forname (com.dsh.jvm.xxx)
Initialize a subclass of a class
6. The class that is marked as the startup class when the Java VM starts
7. The JDK 7 began to offer a dynamic language support: Java. Lang. Invoke. Analytical results REF_getStatic MethodHandle instance, REF_putStatic, REF_invokeStatic handle corresponding class does not initialize, is initialized
Except for these seven cases, any other way of using A Java class is considered a passive use of the class and does not result in class initialization.
7 Sandbox safety mechanism
At the heart of the Java security model is the Java sandbox. The sandbox mechanism ensures effective isolation of Java code and prevents damage to the local system by limiting access to local resources by limiting Java code to the JVM’s specific running scope.
Sandboxes restrict access to system resources, such as CPUS, memory, file systems, and networks. Different levels of restrictions on access to these resources can vary
The latest implementation of security mechanism introduces the concept of Domain.
The virtual machine loads all the code into different system domains and application domains:
- The system domain section is dedicated to interacting with critical resources.
- The application domain accesses the required resources through the partial proxy of the system domain. Different Protected domains in VMS have different permissions. Class files that exist in different domains have full permissions for the current domain, as shown below in the latest security model
In layman’s terms, the virtual machine loads code into a domain with different permissions, and then the code has all the permissions for that domain. This allows different code to have different permissions to call the operating system and local resources
The basic components of a sandbox:
1. Bytecode verifier: Ensures that Java class files comply with Java language specifications. Can help Java programs to achieve memory protection. Core classes do not undergo bytecode verification
2. Class loaders: Class loaders work for the Java sandbox in three ways
- Preventing malicious code from interfering with well-meaning code (parental delegation)
- Protects trusted library boundaries
- It classifies code into protected domains and determines what it can do
- The mechanism used by the classloader is the parent delegate mechanism:
1. Start loading from the class loader of the innermost JVM. The outer malicious class with the same name cannot be loaded and therefore cannot be called
2. Because the access domain is strictly differentiated by package, the outer malicious class cannot get access to the inner class through the built-in code, so the destruction of the code cannot take effect naturally
3. Access Controller: The access controller can control the access permission of core API to the operating system, and the policy setting of this control can be specified by users.
4. Security Manager: the main interface between the core API and the operating system. Implement permission control, higher priority than access controller
5. Security Package: Classes under Java. security and extension packages allow users to add new security features for their applications, including security provider message digest digital signature encryption and authentication