one. Introduction to JVM
1. java class loading mechanism
After the java command starts the java program, it will start the java virtual machine to load the binary data in the .class file of the class class and read it into the memory, put it in the method area of the runtime data area, and then create a java.lang. Class objects
From the perspective of Java developers, class loaders can be roughly divided into the following three categories:
- Startup class loader: Bootstrap ClassLoader, responsible for loading the class library stored in JDK\jre\lib (JDK represents the installation directory of JDK, the same below), or in the path specified by the -Xbootclasspath parameter, and can be recognized by the virtual machine (Such as rt.jar, all classes starting with java. are loaded by Bootstrap ClassLoader). The startup class loader cannot be directly referenced by a Java program.
- Extension class loader: Extension ClassLoader, which is implemented by sun.misc.Launcher$ExtClassLoader, which is responsible for loading all classes in the JDK\jre\lib\ext directory or the path specified by the java.ext.dirs system variable Libraries (such as classes starting with javax.), developers can directly use the extension class loader.
- Application class loader: Application ClassLoader, this class loader is implemented by sun.misc.Launcher$AppClassLoader, which is responsible for loading the classes specified by the user class path (ClassPath), developers can use this class loader directly, if the application The program has not customized its own class loader. In general, this is the default class loader in the program.
- Custom class loader (such as UrlClassLoader, etc.)
The hierarchical relationship of the category loader is shown in the following figure:
JVM class loading related strategies
- Overall responsibility, when a class loader is responsible for loading a class, other classes that the class depends on and references will also be loaded by the class loader, unless another class loader is displayed to load
- Parent class delegation (parent delegation), first let the parent class loader try to load the class, and only try to load the class from its own class path when the parent class loader cannot load the class (in order to avoid different loaders loading the same class the class has duplicate bytes)
- Cache mechanism, the cache mechanism will ensure that all loaded classes will be cached. When a class needs to be used in the program, the class loader first looks for the class from the cache area, and the system will read the class only if the cache area does not exist. The binary data corresponding to the class is converted into a Class object and stored in the buffer area. This is why after modifying the Class, the JVM must be restarted for the program modification to take effect.
java code test
public class ClassLoader {
public static void main(String[] args) throws Exception {
java.lang.ClassLoader classLoader = ClassLoader.class.getClassLoader();
System.out.println(classLoader);
System.out.println(classLoader.getParent());
//Bootstrap Loader (bootstrap class loader) is implemented in C language, and cannot find a definite way to return to the parent Loader, so it returns null.
System.out.println(classLoader.getParent().getParent());
//Create a random class and compile the class, throw it to the f disk and use a custom loader to load it if
//There is still this class on the current project classpath. The current URLClassLoader parent loader is loaded using AppClassLoader
//There is no class path, only the f disk has URLClassLoader
String curBin="f:\\";
URLClassLoader mycls=new URLClassLoader(new URL[]{new File(curBin).toURL()});
Class cls=mycls.loadClass("TT");
System.out.println(cls.getClassLoader());
}
}
The output is
sun.misc.Launcher$AppClassLoader@1a28362 sun.misc.Launcher$ExtClassLoader@5fcf29 null java.net.URLClassLoader@3ef810
Note that two classes with an inheritance relationship cannot use different custom loaders to load each other, otherwise an error will be reported corresponding to the first item of the jvm class loading strategy
2. jvm memory structure
After the class loader loads the class, the variable methods in the class and how the instances are stored depends on the jvm memory structure. The following figure shows the jvm memory structure
The JVM memory structure mainly has three main blocks: heap memory, method area and stack.
- The heap memory is the largest piece in the JVM. It consists of the young generation and the old generation, and the young generation memory is divided into three parts, Eden space, From Survivor space, and To Survivor space. By default, the young generation follows the ratio of 8:1:1 To allocate (SurvivorRatio parameter) For example, memory 200M eden occupies 8/10 or 160M, and the other two stand at 1/10 or 20M respectively;
- The method area stores data such as class information, constants, static variables, etc. It is an area shared by threads. To distinguish it from the Java heap, the method area also has an alias Non-Heap (non-heap);
- The stack is divided into java virtual machine stack and local method stack, which are mainly used for method execution. During method execution, variable pointers are temporarily stored to call the parameters of the method, etc. (refer to the
article on assembly function calling principle https://blog.csdn.net/liaomin416100569 /article/details/8154681, https://blog.csdn.net/liaomin416100569/article/details/52135500).
The java command configures the virtual parameter -X or -XX to modify the specific memory allocation
control parameter
- -Xms sets the minimum size of the heap.
- -Xmx sets the maximum size of the heap.
- -XX:NewSize sets the minimum space size of the new generation.
- -XX:MaxNewSize sets the maximum space size of the new generation.
- -XX:PermSize sets the minimum size of the permanent generation.
- -XX:MaxPermSize sets the maximum size of the permanent generation.
- -Xss sets the stack size per thread.
Help view -X parameters (java -X)
View -XX parameters (java -XX:+PrintFlagsFinal or -XX:+PrintFlagsInitial)
In addition to monopolizing its own virtual machine stack and local method stack, threads also have a program counter (Program Counter Register), which is used for
the status information of the current thread running code during the thread switching process, such as the number of lines it runs to, etc.
An exception occurs in the heap and method area, an OutOfMemoryError error occurs,
an exception occurs on the stack, and a StackOverflowError error is thrown
Suppose there is a class:
public class T1 {
static int i=0;
public static void main(String[] args) {
String str="hello";
}
}
heap: object "hello" array args
method area: static variable i, class T1 definition
stack: str application args application
3. garbage collection
Garbage Collection Garbage Collection is often referred to as "GC", it was born in MIT's Lisp language in 1960, after more than half a century, it is now very mature. In jvm, the program counter, virtual machine stack, and local method stack are all created and destroyed with the thread. The stack frame is pushed into and out of the stack with the entry and exit of the method, which realizes automatic memory cleanup. Therefore, Our memory garbage collection is mainly concentrated in the java heap and method area. During the running of the program, the allocation and use of this part of the memory are dynamic.
》》Object survival judgment
- Reference count: Each object has a reference count attribute. When a new reference is added, the count is increased by 1, and when the reference is released, the count is decreased by 1. When the count is 0, it can be recycled. This method is simple and cannot solve the problem of circular reference of objects to each other.
- Reachability Analysis: Search down from GC Roots, and the path traversed by the search is called the reference chain. When an object does not have any reference chain connected to GC Roots, the object is proved to be unavailable. Unreachable object.
》》 Garbage Collection Algorithm
After judging whether the objects are alive, these objects need to be marked and then deleted from the corresponding area. Common algorithms are as follows:
- Mark-Sweep
- Copying algorithm (Copying)
- Mark-Compact (Collation) Algorithm (Mark-Compact)
move all surviving objects to one end, and then directly clean up the memory outside the end boundary
- Generational Collection Algorithm
The "Generational Collection" algorithm divides the Java heap into the new generation and the old generation, so that the most appropriate collection algorithm can be adopted according to the characteristics of each generation. In the new generation, a large number of objects are found to die during each garbage collection, and only a few survive, so the replication algorithm is used, and the collection can be completed with only a small cost of copying the surviving objects. In the old age, because the object has a high survival rate and there is no extra space to allocate it, it must use the "mark-sweep" or "mark-clean" algorithm for recycling.
》Garbage collector
The garbage collection algorithm is the methodology of memory recycling, and the garbage collector is the specific implementation of memory recycling. The
syntax of the -XX parameter used below is
1) Boolean parameter options: -XX:+ on, -XX:- off. (Translator's Note: For example -XX:+PrintGCDetails)
2) Numeric and character parameter options are set through -XX:=. Numbers can be m/M (megabytes), k/K (kilobytes), g/G (gigabytes). For example: 32K means 32768 bytes. (eg -XX:HeapDumpPath=./java_pid.hprof)
- Serial collector
- Serial collector (new and old generations are single-threaded): parameter control: -XX:+UseSerialGC
- ParNew collector (new generation multi-threaded old generation single-threaded): The ParNew collector is actually a multi-threaded version of the Serial collector. The new generation is parallel, the old generation is serial; the new generation replication algorithm, the old generation mark-compression
parameter control:
-XX:+UseParNewGC ParNew collector
-XX:ParallelGCThreads The default number of limited threads is the number of cpu cores to view through the following command (java -XX :+PrintFlagsFinal -version | find "ParallelGCThreads" )
C:\Users\jiaozi>java -XX:+PrintFlagsFinal -version | find "ParallelGCThreads"
uintx ParallelGCThreads = 4
{product}
- Parallel collector
Parallel Scavenge collector is similar to ParNew collector, Parallel collector pays more attention to the throughput of the system. You can turn on the adaptive adjustment strategy through parameters. The virtual machine collects performance monitoring information according to the current system operation, and dynamically adjusts these parameters to provide the most suitable pause time or maximum throughput; you can also control the GC time through parameters not to exceed How many milliseconds or proportions; new generation copy algorithm, old generation mark-compression
parameter control: -XX:+UseParallelGC Use Parallel collector + old generation serial view the default value of this parameter java -XX:+PrintFlagsFinal -version | find "UseParallelGC" On by default
- Parallel Old Collector
Parallel Old is an older version of the Parallel Scavenge collector, using multithreading and a "mark-and-clean" algorithm.
This collector only began to provide
parameter control in JDK 1.6: -XX:+UseParallelOldGC Use Parallel collector + old generation parallel view as above to open by default - CMS collector
CMS (Concurrent Mark Sweep) collector is a collector whose goal is to obtain the shortest recovery pause time. At present, a large part of Java applications are concentrated on the server side of Internet sites or B/S systems. Such applications pay special attention to the response speed of services, and hope that the system pause time is shortest to bring users a better experience. From the name (including "Mark Sweep"), it can be seen that the CMS collector is based on the "mark-sweep" algorithm.
Advantages: concurrent collection, low pause
Disadvantages: a large number of space fragments are generated, and the concurrent stage will reduce throughput
. Parameter control:
-XX:+UseConcMarkSweepGC Use the CMS collector
-XX:+UseCMSCompactAtFullCollection After Full GC, perform a defragmentation; the defragmentation process is exclusive, which will cause longer pause times
-XX:+CMSFullGCsBeforeCompaction Set to perform a full GC after several times Defragmentation
-XX:ParallelCMSThreads Set the number of threads of the CMS (generally equal to the number of available CPUs) - G1 collector
- Space integration, the G1 collector uses the mark sorting algorithm, and will not generate memory space fragmentation. When allocating large objects, the next GC will not be triggered early because the contiguous space cannot be found.
- Predictable pause is another major advantage of G1. Reducing pause time is a common concern of G1 and CMS, but in addition to pursuing low pause, G1 can also establish a predictable pause time model, allowing users to specify In a time segment of length N milliseconds, the time spent on garbage collection must not exceed N milliseconds, which is almost a feature of real-time Java (RTSJ) garbage collectors.
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC #Open;
-XX:MaxGCPauseMillis =50 #Pause time target;
-XX:GCPauseIntervalMillis =200 #Pause interval target;
-XX:+G1YoungGenSize=512m #Young generation size;
-XX:SurvivorRatio=6 #survivor area ratio
3. JVM common commands
Reference https://blog.csdn.net/liaomin416100569/article/details/45688599
three. Instance tuning
【To be continued】
Article writing reference blog http://www.ityouknow.com/jvm.html