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

JVM garbage collection mechanism is explained in detail and how to tune. In view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Here is a brief introduction to the detailed explanation and tuning of JVM garbage collection mechanism. Gc, that is, garbage collection mechanism, refers to jvm used to release the memory occupied by objects that are no longer used. The java language does not require jvm to have gc, nor does it specify how gc works.

Detailed explanation and tuning of JVM garbage collection mechanism

Overview of gc for 1.JVM

Gc, the garbage collection mechanism, means that jvm is used to free the memory occupied by objects that are no longer in use. The java language does not require jvm to have gc, nor does it specify how gc works. However, most jvm have gc, and most gc use similar algorithms to manage memory and perform collection operations.

After a full understanding of the garbage collection algorithm and execution process, its performance can be effectively optimized. Some garbage collection is dedicated to special applications. For example, real-time applications are primarily designed to avoid garbage collection interruptions, while most OLTP applications focus on overall efficiency. By understanding the workload of the application and the garbage collection algorithms supported by jvm, you can optimize the configuration of the garbage collector.

The purpose of garbage collection is to clear objects that are no longer in use. Gc determines whether to collect an object by determining whether it is referenced by the active object. Gc first determines whether the object is ready to be collected. Two common methods are reference counting and object reference traversal.

1.1. Reference count

The reference count stores the number of all references to a particular object, that is, when the application creates references and the references go out of scope, jvm must increase or decrease the number of references appropriately. Garbage collection can be performed when the number of references to an object is 0.

1.2. Object reference traversal

While early jvm used reference counting, most jvm now use object reference traversal. Object reference traversal starts with a set of objects and recursively determines which objects are reachable along each link on the entire object graph. If an object cannot be reached from one or at least one of these root objects, it is treated as garbage collection. During the object traversal phase, gc must remember which objects are reachable in order to delete unreachable objects, which are called marking objects.

Next, gc deletes unreachable objects. When deleting, some gc simply scan the stack, delete untagged and untagged objects, and free up their memory to generate new objects, which is called sweeping. The problem with this approach is that memory is divided into small pieces, which are not enough for new objects, but they are large in combination. As a result, many gc can reorganize objects in memory and compact them to form available space.

To do this, gc needs to stop other activities. This approach means that all application-related work stops, and only gc runs. As a result, many promiscuous requests were added or subtracted during the response. In addition, more complex gc is added or running at the same time to reduce or remove interruptions to the application. Some gc use single thread to do this, while others use multi-thread to increase efficiency.

two。 Several JVM garbage collection mechanisms

2.1. Mark-clear Collector

This collector first traverses the object graph and marks reachable objects, and then scans the stack for untagged objects and frees their memory. This collector typically uses a single thread to work and stop other operations.

2.2. Tag-compression collector

It is sometimes called Mark-clear-Compression Collector, which has the same marking phase as Mark-clear Collector. In the second stage, the tag object is copied to the new domain of the stack to compress the stack. This collector also stops other operations.

2.3. Copy collector

This collector divides the stack into two domains, often called a half-space. Only half of the space is used at a time, and new objects generated by jvm are placed in the other half. When gc runs, it copies reachable objects to the other half of the space, thus compressing the stack. This method is suitable for short-lived objects, and continuous replication of long-lived objects leads to reduced efficiency.

2.4. Incremental collector

The incremental collector divides the stack into multiple domains, collecting garbage from only one domain at a time. This can cause minor application interruptions.

2.5. Generational collector

This collector divides the stack into two or more fields to store objects with different lifetimes. New objects generated by jvm are typically placed in one of these domains. Over time, objects that continue to exist will be used and transferred to a longer-lived domain. Generational collectors use different algorithms for different domains to optimize performance.

2.6. Concurrent collector

The concurrent collector runs at the same time as the application. At some point (such as compression), these collectors generally have to stop other operations to complete specific tasks, but because other applications can perform other background operations, the actual time to interrupt other processing is greatly reduced.

2.7. Parallel collector

Parallel collectors use some traditional algorithm and use multiple threads to perform their work in parallel. Using multithreading technology on multi-cpu machines can significantly improve the scalability of java applications.

3.SunHotSpot

JVM heap size adjustment

SunHotSpot1.4.1 uses a generational collector, which divides the heap into three main domains: new domain, old domain, and * domain. All new objects generated by Jvm are placed in the new domain. Once the object goes through a certain number of garbage collection cycles, it gets its useful life and enters the old domain. Jvm stores class and method objects in the * domain. In terms of configuration, the * domain is a separate domain and is not considered part of the heap.

How to control the size of these fields is described below. You can use-Xms and-Xmx to control the raw size or * * value of the entire heap.

The following command sets the initial size to 128m:

Java-Xms128m

-Xmx256m to control the size of the new domain, you can use-XX:NewRatio to set the proportion of the new domain in the heap.

The following command sets the entire heap to 128m and the new domain ratio to 3, that is, the ratio of the new domain to the old domain is 1:3, and the new domain is 1x4 or 32m of the heap:

Java-Xms128m-Xmx128m

-XX:NewRatio=3 can use-XX:NewSize and-XX:MaxNewsize to set the initial and * * values of the new domain.

The following command sets the initial and * * values of the new field to 64m:

Java-Xms256m-Xmx256m-Xmn64m

The default size of the domain is 4m. When you run the program, jvm resizes the * domain to meet your needs. With each adjustment, jvm does a full garbage collection on the heap.

Use the-XX:MaxPerSize flag to increase the * domain size. When WebLogicServer applications load more classes, you often need to increase the value of the * domain. When jvm loads classes, the number of objects in the * * domain increases dramatically, causing jvm to constantly resize the * * domain. To avoid tuning, you can use the-XX:PerSize flag to set the initial value.

Set the initial value of the * * field to 32m and set it to 64m.

Java-Xms512m-Xmx512m-Xmn128m-XX:PermSize=32m-XX:MaxPermSize=64m

By default, HotSpot uses the replication collector in the new domain. The domain is generally divided into three parts. * part is Eden, which is used to generate new objects. The other two parts are called salvage space. When Eden is full, the collector stops the application and copies all reachable objects to the current from salvage space. Once the current from salvage space is full, the collector copies reachable objects to the current to salvage space. From and to Rescue Space swap roles. Objects that remain active will continue to replicate in the rescue space until they are used and transferred to the old domain. Use-XX:SurvivorRatio to control the size of the subspace of the new domain.

Like NewRation, SurvivorRation specifies the ratio of a rescue domain to an Eden space. For example, the following command sets the new domain to 64m, with 32m for Eden and 16m for each rescue domain:

Java-Xms256m-Xmx256m-Xmn64m-XX:SurvivorRation=2

As mentioned earlier, by default, HotSpot uses a replication collector for the new domain and a mark-clear-compression collector for the old domain. Using replication collectors in a new domain makes a lot of sense because most of the objects generated by the application are short-lived. Ideally, all transition objects will be collected when they are moved out of Eden space. If this is possible, and the objects removed from the Eden space are long-lived, then in theory they can be moved into the old domain immediately to avoid repeated replication in the rescue space. However, applications are not suitable for this ideal state because they have a small number of medium-and long-lived objects. * is to keep these medium-and long-lived objects in the new domain, because it is always cheaper to copy a small number of objects than to compress the old domain. To control the replication of objects in the new domain, use-XX:TargetSurvivorRatio to control the proportion of salvage space (this value is to set the proportion of salvage space used. If the rescue space is 1m, a value of 50 indicates that 500K is available. The value is a percentage and the default value is 50. When larger stacks use lower sruvivorratio, you should increase this value to 80 to 90 to make better use of salvage space. The upper limit can be controlled with-XX:maxtenuringthreshold.

To place that all replication occurs and you want the object to extend from eden to the old domain, you can set MaxTenuringThreshold to 0. After the setting is completed, the rescue space is no longer used, so the SurvivorRatio should be set to a * * value to convert the Eden space, as follows:

Java... -XX:MaxTenuringThreshold=0-XX:SurvivorRatio=50000...

The use of 4.BEAJRockitJVM

The new JVM used by BeaWebLogic8.1 is for the Intel platform. You can see a folder similar to jrockit81sp1_141_03 in the directory where Bea is installed. This is the directory where Bea's new JVM is located. Unlike HotSpot, which compiles Java bytecode at a cost, it is pre-compiled into classes. JRockit also provides more detailed features to observe the running status of JVM, mainly a stand-alone GUI console (only suitable for using Jrockit to monitor some cpu and memory parameters using console included with jrockit81sp1_141_03) or WebLogicServer console.

BeaJRockitJVM supports four types of garbage collectors:

4.1.1. Generational replication collector

It is similar to the default generational collector working policy. Object is assigned in the new domain, that is, nursery in the JRockit document. This kind of collector is most suitable for small heap operation on a single cpu.

4.1.2. Single space concurrent collector

The collector uses the full heap and works with the background thread. Although this collector can eliminate interrupts, the collector takes a long time to find dead objects, and the collector often runs when dealing with applications. If the processor cannot cope with the garbage generated by the application, it interrupts the application and turns off collection.

Generational concurrent collectors this collector uses exclusive replication collectors in the care domain and concurrent collectors in the old domain. Because it is more frequent than single space co-occurrence of collector interruptions, it requires less memory, and the application is more efficient. Note that too small a care domain can cause a large number of temporary objects to be extended to the old domain. This will cause the collector to overload and even complete the collection in an exclusive way.

4.1.3. Parallel collector

The collector also stops the work of other processes, but uses multithreading to speed up the collection process. Although it is easier to cause long interrupts than other collectors, it can generally make better use of memory and the program is more efficient.

By default, JRockit uses generational concurrent collectors. To change the collector, use-Xgc:, to correspond to the four collectors: gencopy,singlecon,gencon and parallel. You can use-Xms and-Xmx to set the initial size and * * values of the heap. To set up a nursing domain, use-Xns:java-jrockit-Xms512m-Xmx512m-Xgc:gencon-Xns128m … Although JRockit supports the-verbose:gc switch, the information it outputs varies from collector to collector. JRockit also supports output of memory, load, and codegen.

Note: if you use JRockitJVM, you can also use console included with WLS (under C:\ bea\ jrockit81sp1_141_03\ bin) to monitor some data, such as cpu,memery, etc. To be able to monitor, you must add the-Xmanagement parameter to the startWeblogic.cmd when the service is started.

5. How to get information from JVM to make adjustments

The-verbose.gc switch displays the operation content of the gc. When you open it, you can show when the busiest and most idle collection behavior occurred, the amount of memory before and after the collection, the time needed for the collection, and so on. Turn on the-xx:+printgcdetails switch to learn more about the changes in gc. Turn on the-XX:+PrintGCTimeStamps switch to see when these garbage collections occur and are measured in seconds since jvm starts. *, learn more about the heap through the-xx:+PrintHeapAtGC switch. In order to understand the situation of the new domain, you can use the-XX:=PrintTenuringDistribution switch to learn about the object rights of the useful life.

6.Pdm system JVM adjustment

6.1. Server: premise memory 1G single CPU

You can adjust it with the following parameter:-server enables server mode (recommended for servers if there are too many CPU)

-Xms,-Xmx is generally set to the same size. 800m

-Xmn sets NewSize to be consistent with MaxNewSize. 320m

-XX:PerSize64m

-XX:NewSize320m this value sets a large adjustable Daxin object area to reduce the number of FullGC

-XX:MaxNewSize320m

-XX:NewRatoNewSize is set but not set.

-XX:SurvivorRatio

-XX:userParNewGC can be used to set parallel collection

-XX:ParallelGCThreads can be used to increase parallelism.

-after XXUseParallelGC setting, you can use the parallel purge collector.

-XX:UseAdaptiveSizePolicy works better with the above one, which can be used to automatically optimize the size of the new domain and the ratio of salvage space.

6.2. Client: adjust the client JVM by setting parameters in the JNLP file

Parameters in JNLP: initial-heap-size and max-heap-size

This allows you to add the above parameters when generating the JNLP file in framework's RequestManager, but these values are required to vary according to the hardware state of the client (such as the client's memory size, etc.). It is recommended that these two parameter values be set to 60% of the available memory of the client (to be tested). In order to make the above two parameter values vary from client to client when dynamically generating JNLP, you can obtain the client system information and embed these in the home page index.jsp as parameters of the connection request.

After setting the above parameters, you can observe the status of some parameters of garbage collection through Visualgc, and then make corresponding adjustments to improve performance. The general standard is to reduce the number of fullgc, and the hardware supports the use of parallel garbage collection (requiring multiple CPU).

This is the end of the detailed explanation of the JVM garbage collection mechanism and the answer to the question on how to tune it. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.