Interviewer: Have you ever done JVM tuning at work? Tell me what JVM tuning you have done?
I believe this kind of question will be encountered in most interviews, but let's discuss it today
After so many years of development and verification, the JVM is very robust overall. I personally think that in 99% of the cases, JVM tuning is basically not needed.
Usually, our jvm parameter tuning will follow the official recommendations:
- XX:NewRatio=2
- XX:SurvivorRatio=8
- The heap memory is set to about 3/4 of the physical memory
...
The default (recommended) values of JVM parameters are relatively reasonable values obtained through repeated tests by the JVM team and full verification by predecessors, so they are generally more reliable and common, and generally do not cause major problems.
What most students encounter more often is that their own code bugs lead to OOM, high CPU load, frequent GC, etc. These scenarios are basically code repairs, and usually do not need to move the JVM
There is no absolute in everything, and some businesses still need jvm tuning. Generally, it is parameter tuning to make it more suitable for our business. Instead of changing its source code.
Is jvm tuning necessary? Can a better garbage collector solve the problem?
- About actual combat
- Regardless of the factors to cope with the interview, upgrading the garbage collector will indeed be one of the most effective ways, such as upgrading CMS to G1, or even ZGC.
- interview angle
- Answering directly to upgrade the garbage collector may end the topic, so the answer will not add points but will deduct points. So you can answer to upgrade the garbage collector, but you can't just answer to upgrade the garbage collector.
JVM optimization steps?
For the core indicators of the JVM, our focus and commonly used tools are as follows:
- cpu indicator
- Find out which processes are using the most CPU
- View the most CPU-intensive threads
- View thread stack snapshot information
- Analyze code execution hotspots
- See which code takes the longest CPU execution time
- View the percentage of CPU time taken up by each method
Common tools: JProfiler, JVM Profiler, Arthas...// 显示系统各个进程的资源使用情况 top // 查看某个进程中的线程占用情况 top -Hp pid // 查看当前 Java 进程的线程堆栈信息 jstack pid - JVM memory metrics
- Check whether the current JVM heap memory parameter configuration is reasonable
- View statistics for objects in the heap
- View heap storage snapshots and analyze memory usage
- Check whether the memory growth in each area of the heap is normal
- See which area caused the GC
- Check whether the memory can be recovered normally after GC
// 查看当前的 JVM 参数配置 ps -ef | grep java // 查看 Java 进程的配置信息，包括系统属性和JVM命令行标志 jinfo pid // 输出 Java 进程当前的 gc 情况 jstat -gc pid // 输出 Java 堆详细信息 jmap -heap pid // 显示堆中对象的统计信息 jmap -histo:live pid // 生成 Java 堆存储快照dump文件 jmap -F -dump:format=b,file=dumpFile.phrof pid - JVM GC metrics
- Check whether the GC time per minute is normal
- Check whether the number of YGC per minute is normal
- Check whether the FGC times are normal
- Check whether the single FGC time is normal
- View the detailed time-consuming of each stage of a single GC, and find the stage with serious time-consuming
- Check whether the dynamic promotion age of the object is normal
GC log common JVM parameters:
// 打印GC的详细信息 -XX:+PrintGCDetails // 打印GC的时间戳 -XX:+PrintGCDateStamps // 在GC前后打印堆信息 -XX:+PrintHeapAtGC // 打印Survivor区中各个年龄段的对象的分布信息 -XX:+PrintTenuringDistribution // JVM启动时输出所有参数值，方便查看参数是否被覆盖 -XX:+PrintFlagsFinal // 打印GC时应用程序的停止时间 -XX:+PrintGCApplicationStoppedTime // 打印在GC期间处理引用对象的时间（仅在PrintGCDetails时启用） -XX:+PrintReferenceGC
Here I attach a few parameters of my own service configuration and the current renderings
-Xms1024m
-Xmx1024m
-Xmn512m
-Xss512k
-XX:SurvivorRatio=8
-XX:+UseConcMarkSweepGC
..
Explain the meaning of these parameters:
S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间
Overview of jvm parameters
- Meaning of JVM parameters
| parameter name | meaning |
|---|---|
| -Xms | initial heap size |
| -Xmx | maximum heap size |
| -Xmn | young generation size |
| -XX:NewSize | Set young generation size |
| -XX:MaxNewSize | Young Generation Maximum (for 1.3/1.4) |
| -XX:PermSize | Set the initial value of the permanent generation (perm gen) |
| -XX:MaxPermSize | Set the maximum value of the permanent generation |
| -Xss | Stack size per thread |
| -XX:ThreadStackSize | Thread Stack Size |
| -XX: NewRatio | The ratio of the young generation (including Eden and two Survivor areas) to the old generation (excluding the persistent |
| -XX:SurvivorRatio | The size ratio of Eden area to Survivor area |
| -XX:LargePageSizeInBytes | The size of the memory page cannot be set too large, which will affect the size of Perm |
| -XX:+UseFastAccessorMethods | Fast Optimization of Primitive Types |
| -XX:+DisableExplicitGC | Close System.gc() |
| -XX:MaxTenuringThreshold | garbage max age |
| -XX:+AggressiveOpts | speed up compilation |
| -XX:+UseBiasedLocking | Improved performance of lock mechanism |
| -Xnoclassgc | disable garbage collection |
| -XX:SoftRefLRUPolicyMSPerMB | Lifetime of SoftReference in free space per megaheap |
| -XX:PretenureSizeThreshold | Objects exceeding how big are allocated directly in the old generation |
| -XX:TLABWasteTargetPercent | TLAB as a percentage of eden area |
| -XX:+CollectGen0First | Whether to start YGC during FullGC |
- Parallel collector related parameters
| name | meaning |
|---|---|
| -XX:+UseParallelGC Full | GC uses parallel MSC |
| -XX:+UseParNewGC | Set young generation to collect in parallel |
| -XX:ParallelGCThreads | Number of threads for the parallel collector |
| -XX:+UseParallelOldGC | The old generation garbage collection method is parallel collection |
| -XX:MaxGCPauseMillis | Maximum time for each young generation garbage collection |
| -XX:+UseAdaptiveSizePolicy | Automatically select the size of the young generation area and the corresponding proportion of the Survivor area |
| -XX:GCTimeRatio | Set the percentage of garbage collection time to program running time |
| -XX:+ScavengeBeforeFullGC Full | Call YGC before GC |
- CMS related parameters
| name | meaning |
|---|---|
| -XX:+UseConcMarkSweepGC | Use CMS memory collection |
| -XX:CMSFullGCsBeforeCompaction | How many times to perform memory compression |
| -XX:+CMSParallelRemarkEnabled | lower mark pause |
| -XX+UseCMSCompactAtFullCollection | During FULLGC, the compression of the old generation |
| -XX:+UseCMSInitiatingOccupancyOnly | Start CMS collection with manually defined initialization definition |
| -XX:CMSInitiatingOccupancyFraction=70 | Use cms as garbage collection starts CMS collection after 70% usage |
| -XX:CMSInitiatingPermOccupancyFraction | Trigger when PermGen usage reaches the ratio |
| -XX:+CMSIncrementalMode | set to incremental mode |
- Supplementary information
| name | meaning |
|---|---|
| -XX:+PrintGC | print gc |
| -XX:+PrintGCDetails | gc details |
| -XX:+PrintGCApplicationStoppedTime | Prints how long the program was paused during garbage collection. Can be mixed with the above |
| -XX:+PrintGCApplicationConcurrentTime | Print the uninterrupted execution time of the program before each garbage collection. Can be mixed with the above |
| -XX:+PrintHeapAtGC | Print detailed stack information before and after GC |
| -Xloggc:filename | Record relevant log information to a file for analysis. Use with the above |
| -XX:+PrintClassHistogram | garbage collects before printing the histogram. |
| -XX:+PrintTLAB | View TLAB space usage |
| -XX:+PrintTenuringDistribution | View the threshold of new survival cycles after each minor GC |