Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to optimize the Java virtual machine

2025-02-20 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/03 Report--

This article will give you a detailed explanation on how to optimize the Java virtual machine. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Heap settings

-Xmx3550m: set the maximum heap memory of JVM to 3550m.

-Xms3550m: sets the initial heap memory of JVM to 3550m. This value can be set to the same as-Xmx to prevent JVM from reallocating memory after each garbage collection.

-Xss128k: sets the stack size for each thread. The stack size of each thread after JDK5.0 is 1m, and the stack size of each thread before is 256K. It should be adjusted according to the amount of memory required by the applied thread. Decreasing this value generates more threads under the same physical memory. However, the operating system still has a limit on the number of threads in a process, which cannot be generated indefinitely, and the experience value is about 3000 to 5000.

-Xmn2g: sets the heap memory size to 2G. Whole heap memory size = young generation size + old generation size + persistent generation size. The permanent generation usually has a fixed size of 64m, so increasing the size of the younger generation will reduce the size of the old generation. This value has a great impact on system performance, and Sun officially recommends that it be configured as 3Universe 8 of the entire heap.

-XX:PermSize=256M: sets the initial value of heap memory persistence to 256m. (it seems to be the initialization parameters of Eclipse and other IDE)

-XX:MaxNewSize=size: the maximum amount of memory that a newly generated object can occupy.

-XX:MaxPermSize=512M: sets the maximum persistent generation to 512m.

-XX:NewRatio=4: sets the ratio of the younger generation of heap memory (including Eden and two Survivor zones) to the old generation of heap memory (excluding persistent generations). Set to 4, the ratio of the younger generation to the older generation is 1:4.

-XX:SurvivorRatio=4: sets the ratio of the size of Eden to Survivor in the younger generation of heap memory. Set to 4, the ratio of two Survivor zones (there are two Survivor zones by default in the younger generation of JVM heap memory) to one Eden zone is 2:4, and one Survivor area accounts for 1 Survivor 6 of the entire young generation.

-XX:MaxTenuringThreshold=7: indicates that an object is put into the older generation if it is moved in the rescue space (Survivor area) for 7 times before it has been recycled.

If set to 0, the younger generation will enter the older generation without going through the Survivor area, which can improve the efficiency of the older generation.

If you set this value to a large value, the younger generation object will be replicated multiple times in the Survivor area, which increases the survival time of the object in the younger generation and increases the probability that the object will be recycled in the younger generation.

Recycler selection

JVM gives three choices: serial collector, parallel collector and concurrent collector, but serial collector is only suitable for small amount of data, so the choice here is mainly for parallel collector and concurrent collector.

By default, JDK5.0 used to use serial collectors, and if you want to use other collectors, you need to add the appropriate parameters at startup. After JDK5.0, JVM will make intelligent judgments based on the current system configuration.

Serial collector

-XX:+UseSerialGC: set the serial collector

Parallel collector (throughput first)

-XX:+UseParallelGC: select the garbage collector as the parallel collector. This configuration is valid only for the younger generation. That is, in the above configuration, the younger generation uses concurrent collection, while the older generation still uses serial collection.

-XX:ParallelGCThreads=20: configure the number of threads in the parallel collector, that is, how many threads perform garbage collection at the same time. This value is preferably configured equal to the number of processors.

-XX:+UseParallelOldGC: configure the old generation garbage collection method to collect in parallel. JDK6.0 supports parallel collection of older generations.

-XX:MaxGCPauseMillis=100: sets the maximum time (in milliseconds) for each young generation garbage collection. If this time cannot be satisfied, JVM automatically adjusts the size of the younger generation to meet this value.

-XX:+UseAdaptiveSizePolicy: when this option is set, the parallel collector automatically selects the size of the younger generation area and the corresponding Survivor area ratio to achieve the minimum response time or collection frequency specified by the target system.

This parameter recommends that you keep it on when you use a parallel collector.

Concurrent collector (response time first)

-XX:+UseParNewGC: set the younger generation to collect concurrently. Can be used in conjunction with CMS collection. Above JDK5.0, JVM will be set according to the system configuration, so it is no longer necessary to set this value.

CMS, whose full name is ConcurrentLowPauseCollector, is a new gc algorithm introduced in the later version of jdk1.4. It has been further improved in jdk5 and jdk6. It is mainly suitable for scenarios where the importance of response time is greater than that of throughput, it can withstand garbage collection threads and application threads to share processor resources, and there are more long-life-cycle objects in applications. CMS is used for the collection of tenuredgeneration, that is, the collection of the older generation. The goal is to minimize the pause time of the application, reduce the probability of FullGC occurrence, and use garbage collection threads concurrent with the application thread to mark the older generation of cleanup.

-XX:+UseConcMarkSweepGC: set the older generation to collect concurrently. After configuring this in the test, the configuration of-XX:NewRatio=4 failed. Therefore, at this time, the size of the younger generation is best set with-Xmn.

-XX:CMSFullGCsBeforeCompaction=: because the concurrent collector does not compress or clean up the memory space, so it will produce "fragments" after running for a period of time, which reduces the running efficiency. This parameter sets the memory space to be compressed and organized after running the secondary FullGC.

-XX:+UseCMSCompactAtFullCollection: turn on the compression of the older generation. It may affect performance, but memory fragmentation can be eliminated.

-XX:+CMSIncrementalMode: set to incremental collection mode. It is generally applicable to the case of single CPU.

-XX:CMSInitiatingOccupancyFraction=70: it means that CMS will be implemented when the space of the older generation reaches 70%, to ensure that the older generation has enough space to accept objects from the younger generation.

Note: if you use both throughputcollector and concurrentlowpausecollector garbage collectors, you need an appropriate high memory size to prepare for multithreading.

Other

-XX:+ScavengeBeforeFullGC: the new generation of GC takes precedence over FullGC.

-XX:-DisableExplicitGC: the call to System.gc () is prohibited, but the gc of JVM is still valid.

-XX:+MaxFDLimit: maximize the limit on the number of file descriptors.

-XX:+UseThreadPriorities: enables the local thread priority API, even if java.lang.Thread.setPriority () takes effect, and vice versa.

-XX:SoftRefLRUPolicyMSPerMB=0: objects with "soft references" can survive for 0 milliseconds (default is 1 second) after being last accessed.

-XX:TargetSurvivorRatio=90: allows 90% of the Survivor space to be occupied (the default is 50%). Increase the use of Survivor-if you exceed it, you will try garbage collection.

Auxiliary information

-XX:-CITime: print the time consumed in JIT compilation

-XX:ErrorFile=./hs_err_pid.log: save error log or data to the specified file

-XX:-ExtendedDTraceProbes: turn on the dtrace probe specific to solaris

-XX:HeapDumpPath=./java_pid.hprof: specifies the path or file name when exporting heap information

-XX:-HeapDumpOnOutOfMemoryError: export the relevant information in the heap when you encounter a memory overflow for the first time

-XX:OnError= ";": runs a custom command after a fatal ERROR occurs

-XX:OnOutOfMemoryError= ";": executes custom commands when memory overflows are encountered for the first time

-XX:-PrintClassHistogram: print the column information of the class instance when you encounter Ctrl-Break, which has the same function as jmap-histo

-XX:-PrintConcurrentLocks: prints information about concurrent locks when Ctrl-Break is encountered, which has the same function as jstack-l

-XX:-PrintCommandLineFlags: print tags that have appeared on the command line

-XX:-PrintCompilation: prints relevant information when a method is compiled

-XX:-PrintGC: print relevant information every time you GC

-XX:-PrintGCDetails: print details every time you GC

-XX:-PrintGCTimeStamps: prints the timestamp of each GC

-XX:-TraceClassLoading: tracks the loading information of the class

-XX:-TraceClassLoadingPreorder: tracks the loading information of all referenced classes

-XX:-TraceClassResolution: trace constant pool

-XX:-TraceClassUnloading: tracks the unloading information of a class

-XX:-TraceLoaderConstraints: tracks information about class loader constraints

Practical practice of JVM Service tuning

Server: 8Gmem 8Gmem

E.g.

Java-Xmx3550m-Xms3550m-Xss128k-XX:NewRatio=4-XX:SurvivorRatio=4-XX:MaxPermSize=16m-XX:MaxTenuringThreshold=0

Tuning scheme:

-Xmx5g: set the maximum available memory of JVM to 5G.

-Xms5g: set the initial memory of JVM to 5G. This value can be set to the same as-Xmx to prevent JVM from reallocating memory after each garbage collection.

-Xmn2g: set the size of the younger generation to 2G. Whole heap memory size = young generation size + old generation size + persistent generation size. The permanent generation usually has a fixed size of 64m, so increasing the size of the younger generation will reduce the size of the old generation. This value has a great impact on system performance, and Sun officially recommends that it be configured as 3Universe 8 of the entire heap.

-XX:+UseParNewGC: set the younger generation to collect in parallel. Can be used in conjunction with CMS collection. Above JDK5.0, JVM will be set according to the system configuration, so it is no longer necessary to set this value.

-XX:ParallelGCThreads=8: configure the number of threads in the parallel collector, that is, how many threads perform garbage collection at the same time. This value is preferably configured equal to the number of processors.

-XX:SurvivorRatio=6: sets the ratio of the size of the Eden region to the Survivor region in the younger generation. According to experience, if it is set to 6, the ratio of two Survivor regions to one Eden region is 2:6, and one Survivor region accounts for 1max 8 of the whole young generation.

-XX:MaxTenuringThreshold=30: sets the maximum age of garbage (number of times). If set to 0, the younger generation will enter the older generation without going through the Survivor area. For more applications of the older generation, it can improve the efficiency. If you set this value to a large value, the younger generation object will be replicated multiple times in the Survivor area, which can increase the survival time of the younger generation and increase the probability of being recycled in the younger generation. A setting of 30 means that an object is put into the older generation if it is moved 30 times in Survivor space and has not been recycled.

-XX:+UseConcMarkSweepGC: set the older generation to collect concurrently. After testing and configuring this parameter, the parameter-XX:NewRatio=4 is invalid, so the younger generation size is best set with-Xmn at this time, so this parameter is not recommended.

Reference-Generation of JVM heap memory

The heap memory of virtual machines is divided into three generations: the younger generation (YoungGeneration), the older generation (OldGeneration) and the persistent generation (PermanentGeneration). The persistent generation mainly stores the class information of the Java class, which has little to do with the Java objects to be collected by the garbage collector. Therefore, the division of the younger generation and the older generation has a greater impact on garbage collection.

Young generation

All newly generated objects are first of all placed in the younger generation. The goal of the younger generation is to collect objects with a short life cycle as quickly as possible. The younger generation is divided into three districts. One Eden zone and two Survivor zones (generally speaking).

Most objects are generated in the Eden zone. When the Eden area is full, the surviving objects will be copied to the Survivor area (one of the two), when one Survivor area is full, the surviving objects in this area will be copied to the other Survivor area, and when the other Survivor area is also full, the objects copied from the previous Survivor area and still alive at this time will be copied "Tenured".

It should be noted that the two Survivor regions are symmetrical and have no sequential relationship, so there may be both objects copied from the Eden area and objects copied from another Survivor area in the same Survivor area, while only the objects copied to the old zone are objects from the previous Survivor area (relative). Also, one of the Survivor zones is always empty. In special cases, according to the needs of the program, the Survivor area can be configured as multiple (more than two), which can increase the duration of the object in the younger generation and reduce the possibility of being placed in the older generation.

The old generation

Objects that survive N (configurable) garbage collections in the younger generation will be placed in the older generation. Therefore, it can be considered that the objects stored in the elderly are objects with a longer life cycle.

Persistent generation

Used to store static data, such as JavaClass,Method, etc. Persistent generation has no significant impact on garbage collection, but some applications may dynamically generate or call some Class, such as Hibernate, etc., at this time, you need to set a large persistent generation space to store these dynamically increased types during the run. The persistent generation size is set through-XX:MaxPermSize=.

This is the end of the article on "how to optimize the Java virtual machine". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report