| Reproduced GC Overview of 1.JVM
The GC, or garbage collection mechanism, is the memory that the JVM uses to free objects that are no longer in use. The Java language does not require the JVM to have a GC, nor does it specify how the GC works. However, the common JVM has a GC, and most GC uses a similar algorithm to manage memory and perform collection operations.
After fully understanding the garbage collection algorithm and the execution process, can effectively optimize its performance. Some garbage collection is dedicated to special applications. For example, live applications are primarily designed to avoid garbage collection outages, while most OLTP applications focus on overall efficiency. By understanding the workload of the application and the garbage collection algorithm supported by the JVM, you can configure the garbage collector optimally.
The purpose of garbage collection is to clear objects that are no longer in use. GC Determines whether an object is collected by determining whether it is referenced by the active object. The GC first has to determine whether the object is time to collect. Two common methods are reference counts and object reference traversal.
1.1. Reference count
A reference count stores all the references to a particular object, that is, when an application creates a reference and the reference is out of range, the JVM must appropriately increase or decrease the number of references. When an object has a reference number of 0 o'clock, garbage collection can be done.
1.2. Object reference traversal
The early JVM used reference counting, and now most JVMs use object reference traversal. Object reference traversal determines the reachable (reachable) object, starting with a set of objects, and following each link along the entire object graph. If an object cannot arrive from one of these root objects (at least one), it is collected as garbage. In the object traversal phase, the GC must remember which objects are reachable so that the unreachable object is deleted, which is called a tag (marking) object.
Network Management Alliance Bitscn_com
Next, the GC removes unreachable objects. When deleted, some GC is just a simple scan stack, removing unmarked unmarked objects and freeing their memory to generate new objects, called scavenging (sweeping). The problem with this approach is that the memory is divided into small segments that are not sufficient for new objects, but are large in combination. As a result, many GC can rearrange objects in memory and compress (compact) to form available space.
To this end, the GC needs to stop other activity activities. This approach means that all application-related work stops and only the GC runs. As a result, many promiscuous requests were added or subtracted during the response. In addition, more complex GC increases or runs at the same time to reduce or eliminate application interruptions. Some GC use single-threaded to complete this work, while others use multithreading to increase efficiency.
2. Several garbage collection mechanisms
2.1. Mark-Clear Collector
This collector first iterates through the object graph and marks the reachable objects, and then scans the stack for unmarked objects and frees their memory. This collector typically uses single-threaded work and stops other operations.
2.2. Mark-Compress collector
Sometimes also called Mark-purge-compression collectors, which have the same mark stage as the tag-purge collector. In the second phase, the tagged object is copied to the new domain of the stack to compress the stack. This collector also stops other operations. Network Management bitscn_com
2.3. Replication Collector
This collector divides the stack into two domains, often called a half space. Using only half of the space each time, the new object generated by the JVM is placed in the other half of the space. When the GC runs, it compresses the stack by copying the reachable objects to the other half of the space. This approach applies to objects with short lifetimes, and continuous replication of long lifetime objects results in reduced efficiency.
2.4. Incremental collector
The incremental collector divides the stack into domains, collecting garbage from only one domain at a time. This can cause a smaller application outage.
2.5. Generational Collectors
This collector divides the stack into two or more domains for storing objects of different lifetimes. New objects generated by the JVM are generally placed in one of the domains. Over time, the objects that continue to exist will get the usage period and go into a longer lifetime domain. The generational collector uses different algorithms for different domains to optimize performance.
2.6. Concurrent Collectors
The concurrent collector runs concurrently with the application. These collectors generally have to stop other operations at some point, such as compression, to complete a specific task, but because other applications can do other background operations, the actual time to interrupt other processing is greatly reduced.
2.7. Parallel Collector Network Management Alliance bitscn_com
Parallel collectors use some traditional algorithms and use multithreading to perform their work in parallel. Using multithreading on multiple-CPU machines can significantly improve the scalability of Java applications.
3.Sun HotSpot 1.4.1 JVM Heap Size adjustment
Sun HotSpot 1.4.1 uses the generational collector, which divides the heap into three primary domains: The new domain, the old domain, and the permanent domain. All new objects generated by the JVM are placed in the new domain. Once the object has experienced a certain amount of garbage collection loops, it gets the usage period and goes into the old domain. In a permanent domain, the JVM stores the class and method objects. In the case of configuration, a permanent domain is a stand-alone domain and is not considered part of the heap.
The following describes how to control the size of these fields. You can use-XMS and-xmx to control the original size or maximum 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 proportions of the new domain in the heap.
The following command sets the entire heap to 128m, and the new domain ratio is set to 3, that is, the new domain is 1:3 of the old domain, and the new domain is 1/4 or 32M of the heap:
java–xms128m–xmx128m
–xx:newratio =3 can set the initial and maximum values of the new domain using-xx:newsize and-xx:maxnewsize.
The following command sets the initial value and maximum value of the new domain to 64m: network Management forum Bbs_bitscn_com
java–xms256m–xmx256m–xmn64m
The permanent domain default size is 4m. When you run the program, the JVM adjusts the size of the permanent domain to meet your needs. Each time the adjustment is made, the JVM makes a complete garbage collection of the heap.
Use the-XX:MAXPERSIZE flag to increase the permanent domain lap size. When a WebLogic server application loads more classes, it is often necessary to increase the maximum value of the permanent domain. When the JVM loads the class, the objects in the permanent domain increase dramatically, causing the JVM to constantly resize the permanent domain. To avoid adjustments, use the-XX:PERSIZE flag to set the initial value.
The following sets the permanent domain initial value to 32m and the maximum value is set 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. The first part is Eden, which is used to generate new objects. The other two parts are called rescue space, when Eden is full, the collector stops the application, copies all reachable objects to the current from relief space, and once the current from relief space is full, the collector copies the reachable objects to the current to save space. From and to relief space interchange roles. The active objects will continue to replicate in the salvage space until they are used and transferred to the old domain. Use-xx:survivorratio to control the size of the new domain subspace.
Like Newration, the Survivorration stipulates the ratio of a rescue domain to the Eden space. For example, the following command to set the new domain to 64m,eden for 32m, each of the rescue domain accounted for 16m: network management download dl.bitscn.com
Java-xms256m-xmx256m-xmn64m-xx:survivorration =2
As mentioned previously, hotspot uses a copy collector for the new domain by default, and a mark-purge-compress collector for the old domain. Using a replication collector in a new domain has many implications, because most of the objects that the application generates are short-lived. Ideally, all transition objects will be collected when they move out of Eden space. If so, and the objects that move out of the Eden space are long-lived, they can theoretically be moved immediately to the old domain, avoiding repeated duplication in the rescue space. However, applications cannot fit this ideal state because they have a small number of long-lived objects. It is best to keep these long-lived objects and put them in a new domain because copying a small number of objects is always cheaper than compressing the old domain. To control the replication of objects in the new domain, you can use-xx:targetsurvivorratio to control the proportion of the rescue space (this value is to set the usage ratio of the salvage space.) such as the rescue space bit 1M, the value of 50 indicates available 500K). The value is a percentage and the default value is 50. When a larger stack uses a lower sruvivorratio, the value should be increased to 80 to 90 to better exploit the rescue space. The upper limit can be controlled with-xx:maxtenuring threshold.
The maxtenuring threshold can be set to 0 to place all of the replication occurrences and to expect the object to extend from Eden to the old domain. After the setup is complete, the rescue space is no longer used, so the survivorratio should be set to maximize Eden space, set as follows: China Network management Forum Bbs.bitsCN.com
Java ...-xx:maxtenuringthreshold=0–xx:survivorratio=50000 ...
Use of the 4.BEA JRockit JVM
The new JVM used by Bea WebLogic 8.1 is used on the Intel platform. A folder similar to jrockit81sp1_141_03 can be seen in the BEA installed directory. This is the directory where Bea's new JVM resides. Unlike hotspot, which compiles Java bytecode to a cost code, it is precompiled into a class. JRockit also provides more granular functionality to observe the running state of the JVM, primarily a stand-alone GUI console (only for use with JRockit to use jrockit81sp1_141_ 03 the console is monitored with some CPU and memory parameters, or the WebLogic Server console.
The Bea JRockit JVM supports 4 kinds of garbage collectors:
4.1.1. Generational replication Collector
This is similar to the default generational collector work policy. Objects are allocated in the new domain, that is, the nursery in the JRockit document. This collector is best suited for small heap operations on single CPU machines.
4.1.2. Single Space Concurrent collector
The collector uses the full heap and works with the background thread. Although this collector eliminates interruptions, the collector takes a long time to find dead objects and the collector often runs when the application is processed. If the processor cannot cope with the garbage generated by the application, it interrupts the application and closes the collection.
Generational concurrent collectors This collector uses the exclusive replication collector in the care domain and the concurrent collector in the old domain. Because it is more frequent than a single space collector interrupt, it requires less memory and the application is running more efficiently, noting that too little care can cause a large number of temporary objects to be extended to the old domain. This can result in the collector being overloaded, and even in the way of exclusive working to complete the collection.
4.1.3. Parallel collector
The collector also stops
|
