Table of contents
[JVM study notes] JVM memory area definition and memory structure
[JVM study notes] object creation process, object memory layout, how to locate and use objects
1. Pre-knowledge of JVM
1. The meaning of -X, -XX
Parameter prefix meaning :
All our JVM parameters are actually passed through the java command, that is, any jvm parameter is actually part of the Java command.
There are actually many types of Java commands, and we can view all available commands through Java -h .
Grammar :
- java [options] classname [args]
- java [options] -jar filename [args]
- javaw [options] classname [args]
- javaw [options] -jar filename [args]
The JVM parameter is [-options] in the java command, and some types supported by Options are as follows:
- [-] : Standard Options (Standard Options): Ensure that all Java Virtual Machine (JVM) implementations support standard options. They are used for common operations, such as checking the JRE version, setting the classpath, enabling verbose output, etc., you can pass " java -h " to view the available standard options.
- [-X] : Non-standard options (Non-Standard Options) are specific to the Java HotSpot virtual machine, so there is no guarantee that other virtual machine implementations support this parameter, and no changes will be notified in future JDK versions (a certain version No special instructions will be given when it does not take effect or the meaning changes), you can view the available non-standard options through " java -X ".
- [-XX] : Advanced Options (Advanced Options), these options can control the behavior of the Java HotSpot virtual machine runtime. These are developer options for tuned operation of the HotSpot virtual machine in specific areas that typically have specific system requirements and may require privileged access to system configuration parameters. They are also not guaranteed to be supported by all JVM implementations and are subject to change.
2. Types and setting methods of JVM parameter values
Note: If parameters of the same or the same function are set at the same time, the value set later in the command line will take effect. That is, "-Xmx=2m -XX:MaxHeapSize=4m", the effective value is 4m.
The parameter types and setting methods of -X and -XX are the same, here we take -XX as an example
1. Boolean value
Parameter form : -XX:+/-<option>
On : -XX:+<option>
Off : -XX:-<option>
For example : -XX:+UseSerialGC
2. Value
Parameter form : -XX:<option><number> | -XX:<option>=<number> (these two forms are not interoperable, choose which form to use according to the specific parameters, and distinguish it with or without the = sign below )
Value unit : None (byte), K (kb), M (mb), G (gb)
For example : -Xmx32M, -XX:MaxNewSize=32k (32 * 1024 = 32768(b))
3. Characters :
Parameter form : -XX:<option>=<string>
Explanation : set character value, generally used to set file, address and command
3. View the commands and JVM parameters used in GC
1. View the default JVM parameters on the current machine :
java -XX:+PrintCommandLineFlags -version
2. View the JVM parameters of the specified running program (if the JVM parameters are set, the above default values will be overwritten)
jinfo -flags <pid>
Query the specified parameter (options) setting: jinfo -flag <options> <pid>
3. Use jmap to check which algorithm collector is used
jmap -heap <pid>
Windows: jmap -heap <pid> | findstr GC
Linux: jmap -heap <pid> | grep GC
4. Force gc through jcmd
jcmd <pid> GC.run
Note: You can view the commands that the program can execute through jcmd <pid> help
5. View the GC log , which is convenient to view what collector is used during GC and the memory information during collection (use the -Xlog parameter to print the log after JDK8 and JDK9)
-XX:+PrintGC: Print the basic information of GC
-XX:+PrintGCDetails: Print GC details
-XX:+PrintHeapAtGC: Print the change of available capacity of heap and method area before and after GC
-XX:+PrintGCTimeStamps**: Print GC timestamp
The Java program that has already started can enable the above parameters through the following command:
jinfo -flag +PrintGC <pid>
4. View JVM default parameters
JVM default parameters will have different default values depending on the system, memory size, jdk version, vm, etc., so the values you see may be partially different from the following values.
Local configuration information :
Memory: 16GB
Operating system: WIN10 x64
JDK version: 1.8.0_171
VM: Java HotSpot™ 64-Bit Server VM
View default JVM parameter settings
D:\Project>java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=257905728 -XX:MaxHeapSize=4126491648 -XX:+PrintCommandLineFlags
-XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation
-XX:+UseParallelGC
java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
View default memory configuration
# 查看pid
jps -l
# 查看heap信息
jmap -heap 2028
Get the following default memory configuration information:
Heap Configuration:
MinHeapFreeRatio = 0 // 闲置堆空间的最小百分比，默认40
MaxHeapFreeRatio = 100 // 闲置堆空间的最大百分比，默认70
MaxHeapSize = 4127195136 (3936.0MB) // 最大堆空间，默认1/4内存
NewSize = 85983232 (82.0MB) // 当前新生代大小
MaxNewSize = 1375731712 (1312.0MB) // 新生代最大值，根据堆大小和NewRatio来决定
OldSize = 171966464 (164.0MB) // 当前老年代大小
NewRatio = 2 // old/new的比例，默认2
SurvivorRatio = 8 // eden/survivor的比例，默认8
MetaspaceSize = 21807104 (20.796875MB) // 当前元空间大小
CompressedClassSpaceSize = 1073741824 (1024.0MB) // 类压缩空间，默认1G，-XX:CompressedClassSpaceSize指定，大小受限于MaxMetespaceSize
MaxMetaspaceSize = 17592186044415 MB // 允许的最大元空间，如果不设置元空间大小，默认无限大
G1HeapRegionSize = 0 (0.0MB) // G1垃圾收集器中每个区域的大小（启动G1时才生效）
2. Garbage collector selection
Refer to this article: HotSpot VM Garbage Collector - JVM Parameters, Usage Instructions, GC Analysis of Serial Parallel CMS G1 Garbage Collector
-XX:+UseSerialGC
Enable combination : Serail Young (DefNew) + Serial Old Mark Sweep Compact
View enable parameters and GC content:
D:\Project>jinfo -flag UseSerialGC 4288
-XX:+UseSerialGC
D:\Project>jmap -heap 4288 | findstr "GC"
Mark Sweep Compact GC
View GC collector details:
D:\Project>jcmd 4288 GC.run
4288:
Command executed successfully
325.368: [Full GC (System.gc()) 325.368:
[Tenured: 32742K->32744K(349568K), 0.0769539 secs] 38309K->32744K(506816K),
[Metaspace: 57305K->57305K(1101824K)], 0.0770048 secs]
[Times: user=0.08 sys=0.00, real=0.08 secs]
Full GC (System.gc()) : Indicates that the reason for this Full GC is the execution of the System.gc() command.
Tenured : Old generation collection, generally indicates that the old generation uses the Serial Old collector.
Metaspace : In the case of metaspace collection, metaspace is a non-heap, which is a piece of memory located outside the heap.
Times : The time spent in this GC.
-XX:+UseParallelGC
启用组合：Parallel Young (PSYoungGen、Parallel Scavenge) + Serial Old Mark Sweep Compact | Parallel Old Mark Sweep Compact
The JVM parameter enables the Parallel Scavenge collector, and its old age collector defaults to Parallel Old. You can combine other old age collectors by setting parameters.
View enable parameters and GC content:
D:\Project>jinfo -flag UseParallelGC 15404
-XX:+UseParallelGC
D:\Project>jmap -heap 15404 | findstr "GC"
Parallel GC with 10 thread(s)
View GC collector details:
D:\Project>jcmd 15404GC.run
15404:
Command executed successfully
76.217: [GC (System.gc())
[PSYoungGen: 2870K->288K(140288K)] 35650K->33075K(489984K), 0.0026375 secs]
[Times: user=0.00 sys=0.00, real=0.00 secs]
76.220:
[Full GC (System.gc())
[PSYoungGen: 288K->0K(140288K)]
[ParOldGen: 32787K->31310K(349696K)] 33075K->31310K(489984K),
[Metaspace: 57241K->57241K(1101824K)], 0.0767850 secs]
[Times: user=0.22 sys=0.00, real=0.08 secs]
-XX:+UseParallelOldGC
启用组合：Serail Young (DefNew) | Parallel Young (PSYoungGen、Parallel Scavenge) | Parallel Young (ParNew)
+ Parallel Old Mark Sweep Compact
- The Parallel Old collector is only available in JDK 6.
- This JVM parameter only enables the Parallel Old collector, and the new generation collector will be set according to the JVM default parameters, or you can specify the new generation collector through other JVM parameters.
- My machine uses the UseParallelGC parameter by default, so the new generation is PSYoungGen.
View enable parameters and GC content:
D:\Project>jinfo -flag UseParallelOldGC 4964
-XX:+UseParallelOldGC
D:\Project>jmap -heap 4964 | findstr "GC"
Parallel GC with 10 thread(s)
View GC collector details:
D:\Project>jcmd 4964 GC.run
4964:
Command executed successfully
675.850: [GC (System.gc())
[PSYoungGen: 3065K->224K(141312K)] 29892K->27050K(491008K), 0.0026659 secs]
[Times: user=0.00 sys=0.00, real=0.00 secs]
675.852: [Full GC (System.gc())
[PSYoungGen: 224K->0K(141312K)]
[ParOldGen: 26826K->26795K(349696K)] 27050K->26795K(491008K),
[Metaspace: 56938K->56938K(1101824K)], 0.1212485 secs]
[Times: user=0.27 sys=0.00, real=0.12 secs]
-XX:+UseParNewGC
启用组合：Parallel Young (ParNew)
+ Serial Old Mark Sweep Compact | Parallel Old Mark Sweep Compact | Concurrent Mark Sweep (Old)
- In addition to the Serial collector, currently only it works with the CMS collector.
- The combination of ParNew + CMS and ParNew + Serial Old was declared obsolete in JDK8, and JDK9 canceled the support for this combination.
- The -XX:+UseParNewGC parameter was also canceled directly after JDK9.
View enable parameters and GC content:
D:\Project>jinfo -flag UseParNewGC 20052
-XX:+UseParNewGC
D:\Project>jmap -heap 20052 | findstr "GC"
Mark Sweep Compact GC
View the details of the GC collector (the same as serial, and the printed GC logs are the same):
D:\Project>jcmd 20052 GC.run
20052:
Command executed successfully
16.495: [GC (Allocation Failure) 16.495:
[ParNew: 156622K->9790K(157248K), 0.0050190 secs] 213221K->66389K(506816K), 0.0050597 secs]
[Times: user=0.00 sys=0.00, real=0.00 secs]
89.628: [Full GC (System.gc()) 89.628:
[Tenured: 50767K->32723K(349568K), 0.0939450 secs] 83372K->32723K(506816K),
[Metaspace: 57211K->57211K(1101824K)], 0.0940025 secs]
[Times: user=0.09 sys=0.00, real=0.09 secs]
GC (Allocation Failure) : Indicates that the cause of this GC is the GC caused by memory allocation failure, and thus the new generation garbage collection (mirrorGC or youngGC). If the memory cannot be allocated after the GC, it will try to expand the heap. If the maximum capacity of the heap has been reached, a full heap collection will be performed. When the object cannot be allocated memory after the whole heap is collected, an OOM exception will be thrown.
-XX:+UseConcMarkSweepGC
Enable combination : Serial Young (DefNew) | Parallel Young (ParNew) + Concurrent Mark Sweep (Old)
- The default new generation of CMS is ParNew.
- The combination of ParNew + CMS was declared obsolete in JDK8, and JDK9 canceled the support for this combination
View enable parameters and GC content:
D:\Project>jinfo -flag UseConcMarkSweepGC 7156
-XX:+UseConcMarkSweepGC
D:\Project>jmap -heap 7156 | findstr "GC"
Concurrent Mark-Sweep GC
View GC collector details:
D:\Project>jcmd 7156 GC.run
7156:
Command executed successfully
18.303: [GC (Allocation Failure) 18.303:
[ParNew: 153906K->13619K(157248K), 0.0094748 secs] 159600K->23724K(506816K), 0.0095149 secs]
[Times: user=0.02 sys=0.00, real=0.01 secs]
111.118: [Full GC (System.gc()) 111.118:
[CMS: 35564K->31991K(349568K), 0.0956757 secs] 37072K->31991K(506816K),
[Metaspace: 57246K->57246K(1101824K)], 0.0957642 secs]
[Times: user=0.09 sys=0.00, real=0.10 secs]
-XX:+UseG1GC
Enable the G1 collector
View enable parameters and GC content:
D:\Project>jinfo -flag UseG1GC 14300
-XX:+UseG1GC
D:\Project>jmap -heap 14300 | findstr "GC"
Garbage-First (G1) GC with 10 thread(s)
View GC collector details:
D:\Project>jcmd 14300 GC.run
14300:
Command executed successfully
91.976: [Full GC (System.gc()) 65M->31M(512M), 0.1022988 secs]
[Eden: 23.0M(284.0M)->0.0B(307.0M) Survivors: 23.0M->0.0B Heap: 65.8M(512.0M)->31.6M(512.0M)],
[Metaspace: 57227K->57206K(1101824K)]
[Times: user=0.11 sys=0.00, real=0.11 secs]
Eden : Collection of the new generation.
Survivors : Survival area collection situation.
Heap : The collection of the entire heap space.
3. Garbage collector specific parameters
1.ParNew
-XX:ParallelGCThreads=
Sets the number of threads for garbage collection, the default value varies by platform.
2. Parallel Scavenge
-XX:MaxGCPauseMillis=
Control the maximum garbage collection pause time, the collector will try its best to ensure that the time spent on memory recovery does not exceed the user-set value.
Setting MaxGCPauseMillis smaller does not necessarily make the garbage collection speed of the system faster. The shortened garbage collection pause time is at the expense of throughput and new generation space: the system adjusts the new generation smaller, collects 300MB young generation is definitely faster than collecting 500MB, but it also directly causes garbage collection to happen more frequently. Pause times did drop, but so did throughput.
-XX:GCTimeRatio=
Set the throughput size, range (0 < n <100). That is, the ratio of garbage collection time to the total time, which is equivalent to the reciprocal of throughput. For example, if this parameter is set to 19, the maximum allowed garbage collection time will account for 5% of the total time (ie 1/(1+19)), and the default value is 99, which means a maximum of 1% is allowed (ie 1/(1+19) 99)) garbage collection time.
-XX:+/-UseAdaptiveSizePolicy
This is a switch parameter. When this parameter is activated, there is no need to manually specify the size of the new generation (-Xmn), the ratio of Eden to the Survivor area (-XX: SurvivorRatio), and the size of objects in the old generation (-XX: PretenureSizeThreshold ) and other detailed parameters, the virtual machine collects performance monitoring information according to the current system operation status, and dynamically adjusts these parameters to provide the most suitable pause time or maximum throughput. This adjustment method is called the adaptive adjustment strategy of garbage collection (GC Ergonomics)
4. Memory settings
-Xmx | -XX:MaxHeapSize=
Sets the maximum size of the heap. The value needs to be a multiple of 1024 and greater than 2M. The setting of the default value is based on the system configuration. On a 64-bit JVM, the default maximum heap size is 1/4 of the physical memory, and the default value can reach up to 1G.
-Xms | -XX:InitialHeapSize=
Sets the minimum size for the heap. The value needs to be a multiple of 1024 and greater than 1M. The default value is the sum allocated to newSize and oldSize (the default value is 1/64 of the physical memory), and the default value can be up to 1G.
-Xmn | -XX:NewSize= | -XX:MaxNewSize=
- -Xmn sets both the initial and maximum values of the new generation.
- -XX:NewSize sets the initial value of the new generation.
- -XX:MaxNewSize sets the maximum value of the new generation.
If the value is set too small, frequent mirrorGC will occur. If the value is set too large, it will cause a very long time to execute GC each time. Oracle officially recommends that the new generation size be set to 1/2 or 1/4 of the entire heap size.
-Xss | -XX:ThreadStackSize=
Set this parameter to set the stack capacity, the larger the value, the deeper the stack can be accommodated.
The default is platform dependent:
- Linux/ARM (32-bit): 320 KB
- Linux/i386 (32-bit): 320 KB
- Linux/x64 (64-bit): 1024 KB
- macOS (64-bit): 1024 KB
- Oracle Solaris/i386 (32-bit): 320 KB
- Oracle Solaris/x64 (64-bit): 1024 KB
- Windows: Default value depends on physical memory size
-XX:MetaspaceSize= | -XX:MaxMetaspaceSize= ——-XX:PermSize= | -XX:MaxPermSize=
Metaspace is used for metaspace, and perm permanent generation. Before jdk8, the perm parameter was used to limit the size of the permanent generation. After jdk8, the permanent generation was replaced by the metaspace, and the metaspace parameter was used to limit the size of the metaspace.
- -XX:PermSize | -XX:MaxPermSize: Set the initial size and maximum size of the permanent generation respectively.
- -XX:MetaspaceSize | -XX:MaxMetaspaceSize: Set the initial size and maximum size of the metaspace, respectively.
- The permanent generation is the same as the meta space. When the metadata usage exceeds the current space size, a gc will be generated. The default value depends on the system platform.
Five, memory allocation strategy
-XX:FieldsAllocationStyle=
This parameter has been deprecated in JDK14. You can refer to Deprecate -XX:FieldsAllocationStyle product option
The storage order of instance data in the object memory structure will be affected by the virtual machine allocation policy parameters (-XX:FieldsAllocationStyle parameter) and the order in which fields are defined in the Java source code.
Fields of the same width are always allocated together for storage. When this precondition is met, variables defined in the parent class will appear before the subclass. This parameter has three options:
0: oops, longs/doubles, ints, shorts/chars, bytes/booleans
1: The default allocation order of the HotSpot virtual machine, longs/doubles, ints, shorts/chars, bytes/booleans, oops
2: Put parent and child oops together
-XX:+/-CompactFields
The effect of enabling or disabling is not obvious, this parameter has been abandoned in JDK14. You can refer to Deprecate product flag -XX:CompactFields
Enabled by default, when enabled, will allow narrower variables in subclasses to be inserted into gaps in parent class variables to save a little space.
-XX:+/-UseTLAB
When allocating memory for an object, the thread allocates a block of memory for the object in the available memory area. At this time, there will be a problem, that is, object creation is a very frequent operation. In the case of concurrency, memory allocation becomes not so safe. By default, the virtual machine uses CAS to ensure the safety of concurrent operations. sex. UseTLAB actually provides another solution, which is to allocate a piece of memory for each thread separately, and each thread uses this memory to allocate objects. When the memory is used up, CAS will be used to allocate a new piece of private memory for the thread. .
Enabled by default. When enabled, each thread will pre-allocate a small piece of memory in the new generation of the Java heap. This piece of memory is called the local thread allocation buffer (thread-local allocation blocks, TLABs). Using this memory can guarantee concurrent allocation of memory security and concurrency.
-XX:MinHeapFreeRatio= | -XX:MaxHeapFreeRatio=
Here you can refer to: 4 Factors Affecting Garbage Collection Performance
- -XX:MinHeapFreeRatio: Set the minimum idle percentage of the heap after GC, the default is 40. After GC, if the percentage of free space in the heap is below 40%, it will expand to keep 40% free space, up to the maximum heap size allowed.
- -XX:MaxHeapFreeRatio: Set the maximum idle percentage of the heap after GC, the default is 70. After GC, if the free space exceeds 70%, then according to the minimum size of the heap, the generated generation will shrink so that only 70% of the space is free.
- The role of these two is to limit the free space within a certain range, to ensure the lower limit to avoid frequent heap space expansion when creating objects, and to ensure the upper limit to avoid a large amount of space being invalidly occupied.
- The space for calculating the percentage of the two is calculated according to the -Xms and -Xmx parameters, namely: heap free space/total space of the current heap; among them, the total space of the current heap (due to expansion or contraction after GC, this space is always Changing; of course, when the values of -Xms and -Xmx are the same, the total space remains unchanged) The lower limit is the value of -Xms, and the upper limit is the value of -Xmx.
Six, memory analysis
These parameters are disabled by default unless otherwise specified. They can all be started at runtime, using the command line tool mentioned earlier: jinfo -flag
-XX:+/-HeapDumpOnOutOfMemoryError
When a memory overflow exception occurs in the virtual machine, the current memory heap dump snapshot is automatically dumped for post-event analysis. It is generally used to analyze crash machines. Turning this on in a normal production environment will easily cause the system to process business slowly.
-XX:+/-TraceClassLoading
Check the type loading information, enable this configuration, and you can see which classes are loaded by the JVM in the printed log.
[Loaded java.lang.Object from C:\Program Files\Java\jdk1.8.0_171\jre\lib\rt.jar]
[Loaded java.io.Serializable from C:\Program Files\Java\jdk1.8.0_171\jre\lib\rt.jar]
[Loaded java.lang.Comparable from C:\Program Files\Java\jdk1.8.0_171\jre\lib\rt.jar]
[Loaded java.lang.CharSequence from C:\Program Files\Java\jdk1.8.0_171\jre\lib\rt.jar]
[Loaded java.lang.String from C:\Program Files\Java\jdk1.8.0_171\jre\lib\rt.jar]
-XX:+/-TraceClassUnloading
Check the type unloading information, and print the unloaded information when the type is unloaded by the JVM.
-Xloggc:filename & -XX:+/-PrintGC and other GC log printing related parameters
-Xloggc:filename : Use -Xloggc to specify a specific file to collect all gc logs. This parameter is similar to the output log of **-verbose:gc**. When used at the same time, -Xloggc will override -verbose:gc.
In addition, if more GC logs are required, they can be controlled by specific GC log parameters .
-Xloggc log content is as follows:
Java HotSpot(TM) 64-Bit Server VM (25.171-b11) for windows-amd64 JRE (1.8.0_171-b11), built on Mar 28 2018 16:06:12 by "java_re" with MS VC++ 10.0 (VS2010)
Memory: 4k page, physical 16119108k(7787392k free), swap 34862400k(22884524k free)
CommandLine flags: -XX:-BytecodeVerificationLocal -XX:-BytecodeVerificationRemote -XX:InitialHeapSize=52428800 -XX:+ManagementServer -XX:MaxHeapSize=52428800 -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:TieredStopAtLevel=1 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
0.408: [GC (Allocation Failure) 12800K->1872K(49152K), 0.0016370 secs]
0.540: [GC (Allocation Failure) 14672K->3393K(49152K), 0.0024662 secs]
0.676: [GC (Allocation Failure) 16193K->5145K(49152K), 0.0028768 secs]
You can see that after enabling -Xloggc, it opens the two options -XX:+PrintGC -XX:+PrintGCTimeStamps by default. In fact, -Xloggc only has the ability to record gc logs to files, and what to record depends on these GC log parameters.
GC log parameters (the following parameters are disabled by default):
- -XX:+PrintGC: Print GC summary data.
- -XX:+PrintGCApplicationConcurrentTime : Allows to print how much time has elapsed since the last pause (eg, GC pause).
- -XX:+PrintGCApplicationStoppedTime : How long printing pauses (for example, GC pauses) have been allowed to last.
- -XX:+PrintGCDateStamps: Allows printing datetime stamps at each GC.
- -XX:+PrintGCDetails: Allows to print detailed messages on each GC.
- -XX:+PrintGCTaskTimeStamps: Allows to print timestamps for each GC worker task.
- -XX:+PrintGCTimeStamps: Record the time of printing the log, which is the total time since the virtual machine was started.
reference
In-depth understanding of Java Virtual Machine: JVM Advanced Features and Best Practices (3rd Edition) Zhou Zhimingjava
java
8 doc
javase doc
Java HotSpot VM
memorymanagement
Java Virtual Machine Technology
Java HotSpot Equivalents of Exact VM Flags
Java Platform, Standard Edition Documentation
4 Factors Affecting Garbage Collection Performance
Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide