jps
JPS (JavaVirtual Machine Process Status Toll) A tool used to view the current Java process.
See the usage details in jps-help.
usage: jps [-help]
jps [-q] [-mlvV] [<hostid>]
Definitions:
<hostid>: <hostname>[:<port>]
Copy the codeJps-lv can output process ID, fully qualified main class name,jar package full path and manually configured JVM parameters, as follows: jps-lv
3433 sun. Tools. The JPS. The JPS - Dapplication. Home = / Library/Java/JavaVirtualMachines jdk1.8.0 _211. JDK/Contents/home - Xms8m 1262 org.jetbrains.jps.cmdline.Launcher -Xmx700m -Djava.awt.headless=true -Djava.endorsed.dirs="" -Dpreload.project.path=/Users/naigaipaopao/IdeaProjects/study - Dpreload. Config. Path = / Users/naigaipaopao/Library/Application Support/JetBrains/IntelliJIdea2021.3 / options -Dcompile.parallel=false -Drebuild.on.dependency.change=true -Djdt.compiler.useSingleThread=true -Daether.connector.resumeDownloads=false -Dio.netty.initialSeedUniquifier=3850549903300846449 -Dfile.encoding=UTF-8 - Duser. Language = useful - Duser. Country = CN - Didea. Paths. The selector = IntelliJIdea2021.3 - Didea. Home. The path = / Applications/IntelliJ IDEA. The app/Contents - Didea. Config. Path = / Users/naigaipaopao/Library/Application Support/JetBrains/IntelliJIdea2021.3 - Didea. Plugins. Path = / Users/naigaipaopao/Library/Application Support/JetBrains/IntelliJIdea2021.3 / plugins - Djps. The dir = / Users/naigaipaopao/Library/Logs/JetBrains/IntelliJIdea2021.3 / build - log - Djps. Fallback. JDK. Home = / Applications/IntelliJ IDEA. The app/Contents/JBR/Contents/home - Djps. Fallback. JDK. Version = 11.0.13 -Dio.netty.noUnsafe=true -Djava.io.tmpdir=/ 1263 com.study.StudyApplication -XX:PreInflateSpin=10 -Xms100M -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=51029:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 1183 -Xms128m -Xmx750m -XX:ReservedCodeCacheSize=512m -XX:+IgnoreUnrecognizedVMOptions -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false -Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Dkotlinx.coroutines.debug=off -XX:ErrorFile=/Users/naigaipaopao/java_error_in_idea_%p.log -XX:HeapDumpPath=/Users/naigaipaopao/java_error_in_idea.hprof -Xmx1024m -javaagent:/Users/naigaipaopao/JetbrainsIdesCrack_5_3_1_KeepMyLic.jar - Djb. VmOptionsFile = / Users/naigaipaopao/Library/Application Support/JetBrains/IntelliJIdea2021.3 / idea. Vmoptions -Dsplash=true -Didea.home.path=/Applications/IntelliJ IDEA.app/Contents -Didea.jre.check=true -Didea.executable=idea . - Djava. System. The class loader. = com intellij. Util. Lang. PathClassLoader - Didea. Paths. The selector = IntelliJIdea2021.3 -Didea.vendor.name=JetBrainsCopy the codejstat
Jstat (JVM statistics-monitoring Tool) is a command line Tool used to monitor vm running status information.
It can display runtime data such as class loading, memory, garbage collection, JIT compilation, etc. in local or remote virtual machines. On servers with no GUI graphical interface and only plain text console environment, it is the preferred tool for locating virtual machine performance problems at runtime.
Common parameters:
- -class (class loader)
- -compiler (JIT)
- – GC (GC heap state)
- – GcCapacity (District size)
- – GCCause (last GC stat and cause)
- – GCNEW (New District Statistics)
- – gcnewCapacity (New area size)
- – Gcold (Statistics in Old Districts)
- -gcoldcapacity (old area size)
- – gcpermCapacity (Permanent region size)
- – GCUTIL (GC Statistics Summary)
- -printcompilation (HotSpot compilation statistics)
We used jstat-gccapacity < PID > 1000 10 and jstat-gCCause < PID > 1000 10
jstat -gccapacity
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX CCSMN CCSMX CCSC YGC FGC 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 8 2 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 82 33792.0 698880.0 223232.0 10240.0 12800.0 195072.0 68608.0 1398272.0 68608.0 68608.0 0.0 1079296.0 35496.0 0.0 1048576.0 4776.0 8 2Copy the code- NGCMN: minimum capacity of young generation.
- NGCMX: maximum capacity of young generation.
- NGC: Current young generation capacity.
- S0C: current capacity of the FROM area.
- S1C: current to area capacity.
- EC: indicates the current Eden capacity.
- OGCMN: minimum capacity in the old age.
- OGCMX: Old age maximum capacity.
- OGC: Current age capacity.
- OC: indicates the current capacity of the old space.
- MCMN: minimum metaspace capacity.
- MCMX: indicates the maximum metaspace capacity.
- MC: indicates the current capacity of the meta space.
- CCSMN: minimum capacity of compressed class space.
- CCSMX: minimum capacity of compressed class space.
- CCSC: the capacity of the currently compressed class space.
- YGC: indicates the number of GC in the young generation.
- FGC: The number of total heap GC.
jstat -gccause
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 0.00 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 3.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GC 0.00 0.00 83.70 26.53 95.73 92.72 8 0.111 2 0.072 0.183 Metadata GC Threshold No GCCopy the code- S0: percentage of the FROM area usage in the current capacity.
- S1: Percentage of the to area usage in the current capacity.
- E: Percentage of the Eden area utilization in the current capacity.
- O: The percentage of the utilization of the old age area in the current capacity.
- M: percentage of the meta-space usage in the current capacity.
- CCS: indicates the percentage of the compressed metacase usage in the current capacity.
- YGC: number of GC occurrences in the young generation.
- YGCT: recovery time of young generation.
- FGC: total heap GC count.
- FGCT: time of full heap GC.
- GCT: Total time spent on GC.
- LGCC: Cause of last GC.
- GCC: The reason for the current GC.
jinfo
Jinfo (Configuration Info for Java) is used to view and modify vm parameters.
Usage:
jinfo <option> <pid>
(to connect to a running process)
where <option> is one of:
-flag <name> to print the value of the named VM flag
-flag [+|-]<name> to enable or disable the named VM flag
-flag <name>=<value> to set the named VM flag to the given value
-flags to print VM flags
-sysprops to print Java system properties System.getProperties()
<no option> to print both VM flags and system properties
-? | -h | --help | -help to print this help message
Copy the codeGenerally, run jinfo-flags
jmap
It is mainly used to produce dump files, and can also query finalize execution queue, Java heap, and persistent generation details, such as space usage, which collector is currently used, etc.
Usage:
jmap [option] <pid>
(to connect to running process)
jmap [option] <executable <core>
(to connect to a core file)
jmap [option] [server_id@]<remote server IP or hostname>
(to connect to remote debug server)
where <option> is one of:
<none> to print same info as Solaris pmap
-heap to print java heap summary
-histo[:live] to print histogram of java object heap; if the "live"
suboption is specified, only count live objects
-clstats to print class loader statistics
-finalizerinfo to print information on objects awaiting finalization
-dump:<dump-options> to dump java heap in hprof binary format
dump-options:
live dump only live objects; if not specified,
all objects in the heap are dumped.
format=b binary format
file=<file> dump heap to <file>
Example: jmap -dump:live,format=b,file=heap.bin <pid>
-F force. Use with -dump:<dump-options> <pid> or -histo
to force a heap dump or histogram when <pid> does not
respond. The "live" suboption is not supported
in this mode.
-h | -help to print this help message
-J<flag> to pass <flag> directly to the runtime system
Copy the codeJmap-heap
jstack
The jstack(Stack Trace for Java) command is used to generate a thread snapshot at the current time. A thread snapshot is a stack of methods that are being executed by each thread in a VM. The main purpose of a thread snapshot is to locate the cause of a thread’s time pause. The common causes of a thread’s time pause are deadlocks, dead loops, and long waits caused by requests for external resources.
Let’s look at the deadlock example in Thread source code.
package com.study.thread; import lombok.SneakyThrows; public class DeadLock { public static void main(String[] args) { Object lock1 = new Object(); Object lock2 = new Object(); Thread thread1 = new Thread(new Runnable() { @SneakyThrows @Override public void run() { synchronized (lock1) { System.out.println("thread1 successfully holds lock1"); Thread.sleep(1000); Synchronized (lock2) {system.out.println ("thread1 successfully holds lock2"); }}}}); Thread thread2 = new Thread(new Runnable() { @SneakyThrows @Override public void run() { synchronized (lock2) { System.out.println("thread2 successfully holds lock2"); Thread.sleep(1000); Synchronized (lock1) {system.out.println ("thread2 successfully holds lock1"); }}}}); thread1.start(); thread2.start(); }}Copy the codeJstack < PID > = jstack
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x00007f9d8d8142a8 (object 0x00000007957f0f10, a java.lang.Object),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x00007f9d8d8118b8 (object 0x00000007957f0f20, a java.lang.Object),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at com.study.thread.DeadLock$2.run(DeadLock.java:35)
- waiting to lock <0x00000007957f0f10> (a java.lang.Object)
- locked <0x00000007957f0f20> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:748)
"Thread-0":
at com.study.thread.DeadLock$1.run(DeadLock.java:19)
- waiting to lock <0x00000007957f0f20> (a java.lang.Object)
- locked <0x00000007957f0f10> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:748)
Found 1 deadlock.
Copy the codeThis tells you the specific line of code, and the waiting lock is easily located by who holds it.
Special broadcast – Anomaly analysis
If the careful reader can find some problems: starting with the JPS, the author manually set -xms to the minimum heap space. We learned from jstat that there were 8 YGCs and 2 FGCS.
Why does 8 YGC happen?
According to the jstat -gccapactity command, the minimum value of the young generation is 33 MB, and the maximum value is 68 MB. The current young generation occupies 218 MB. Jstat-gccause shows that Eden’s utilization is currently 83.7%.
The project was just started, not used yet. Obviously our -xms is small, we can try it at 500M.
Jstat – gccapacity:
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 170496.0 698880.0 209920.0 17408.0 20992.0 128512.0 341504.0 1398272.0 341504.0 341504.0 0.0 1087488.0 44072.0 0.0 1048576.0 5928.0 5 2 170496.0 698880.0 209920.0 17408.0 20992.0 128512.0 341504.0 1398272.0 341504.0 341504.0 0.0 1087488.0 44072.0 0.0 1048576.0 5928.0 5 2 170496.0 698880.0 209920.0 17408.0 20992.0 128512.0 341504.0 1398272.0 341504.0 0.0 1087488.0 44072.0 0.0 1048576.0 5928.0 5 2 170496.0 698880.0 209920.0 17408.0 20992.0 128512.0 341504.0 1398272.0 341504.0 341504.0 0.0 1087488.0 44072.0 0.0 1048576.0 5928.0 5 2 170496.0 698880.0 209920.0 17408.0 20992.0 128512.0 341504.0 1398272.0 341504.0 341504.0 0.0 1087488.0 44072.0 0.0 1048576.0 5928.0 5 2 170496.0 698880.0 209920.0 17408.0 20992.0 128512.0 341504.0 1398272.0 341504.0 341504.0 0.0 1087488.0 44072.0 0.0 1048576.0 5928.0 5 2Copy the codeJstat – gccause:
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC
0.00 63.74 19.11 5.79 95.03 92.11 5 0.080 2 0.063 0.142 Allocation Failure No GC
0.00 63.74 19.11 5.79 95.03 92.11 5 0.080 2 0.063 0.142 Allocation Failure No GC
0.00 63.74 19.11 5.79 95.03 92.11 5 0.080 2 0.063 0.142 Allocation Failure No GC
0.00 63.74 19.11 5.79 95.03 92.11 5 0.080 2 0.063 0.142 Allocation Failure No GC
0.00 63.74 19.11 5.79 95.03 92.11 5 0.080 2 0.063 0.142 Allocation Failure No GC
Copy the codeAs you can see, YGC changes to 5 times, FGC changes to 2 times, and Metadata GC Threshold changes to Allocation Failure.
After adjustment, the minimum and maximum of the young generation are 166.5M and 68.25M respectively. The current young generation occupies 205M. Jstat-gccause shows that Eden currently has a utilization of 19.11%. That why there will be five times YGC, that is because the default opened – XX: + UsePSAdaptiveSurvivorSizePolicy dynamic adjustment, Resizing is resizing SurvivorSize from small to a suitable value and since only -xms is set the whole heap partition is dynamically resizing until a suitable value is found, so it is normal for YGC to occur during resizing, as long as -xms is not given too small, otherwise it will start from a very small value.
Why does it happen twice?
The Metadata GC Threshold is set to -xms100m. The Metadata GC Threshold is set to -xms100m. The Metadata GC Threshold is set to -xms100m.
Let’s take a look at the configuration related to the meta space:
-XX:MetaspaceSize: Indicates the initial value of the space. The default value is 20M.-XX:MaxMetaspaceSize: The default value is 2^64-1, which is the maximum capacity.-XX:MinMetaspaceFreeRatio: Indicates the minimum idle ratio. The default value is 40%.-XX:MaxMetaspaceFreeRatio: The maximum space ratio. The default is 70%. If it is greater than this, it needs to be freed.-XX:MaxMetaspaceExpansion: Maximum expansion stride length. The default value is 5.2M.-XX:MinMetaspaceExpansion: Minimum expansion step, 0.32m.
Let’s take a look at the Metadata GC Threshold:
- The minimum value is 0M.
- The maximum value is 1054M.
- The current value is 34.7M.
- The current M usage is 95.73%.
-xms100m -xx :MetaspaceSize=100M jstat -gccapacity -xms100m -xx :MetaspaceSize=100M jstat -gccapacity
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC
99.93 0.00 45.21 30.20 94.85 92.22 8 0.132 0 0.000 0.132 Allocation Failure No GC
99.93 0.00 45.21 30.20 94.85 92.22 8 0.132 0 0.000 0.132 Allocation Failure No GC
99.93 0.00 45.21 30.20 94.85 92.22 8 0.132 0 0.000 0.132 Allocation Failure No GC
99.93 0.00 45.21 30.20 94.85 92.22 8 0.132 0 0.000 0.132 Allocation Failure No GC
99.93 0.00 45.21 30.20 94.85 92.22 8 0.132 0 0.000 0.132 Allocation Failure No GC
Copy the codeYou can see that no FGC has occurred. So let’s go ahead and set the parameter to -xms500m -xx :MetaspaceSize=100M:
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 99.99 0.00 9.59 2.84 95.13 93.12 4 0.148 0 0.000 0.148 Allocation Failure No GC 99.99 0.00 9.59 2.84 95.13 93.12 4 0.148 0 0.000 0.148 Allocation Failure No GC 99.99 0.00 9.59 2.84 95.13 93.12 4 0.148 0 0.000 0.148 Allocation Failure No GC 99.99 0.00 9.59 2.84 95.13 93.12 4 0.148 0 0.000 0.148 Allocation Failure No GC 99.99 0.00 9.59 2.84 95.13 93.12 4 0.148 0 0.000 0.148 Allocation Failure No GC 99.99 0.00 9.59 2.84 95.13 93.12 4 0.148 0 0.000 0.148 Allocation Failure No GCCopy the codeYou can see that YGC becomes 4 times and FGC becomes 0 times, indicating that the changes -xms and -xx :MetaspaceSize are valid.
conclusion
- JPS lets you know what Java processes are running and see manually configured JVM parameters
- Jstat provides information about GC (memory allocation for each partition, usage, gc reasons, etc.).
- We can use jinfo to view and modify the virtual parameters (parameters manageable).
- We can use JMP to generate dump files for analysis, as well as details about the collector and heap/persistent generation currently in use.
- You can use JStack to view snapshots of threads to locate threads with long dwell time.