JVM Tuning Summary (10)-tuning method

JVM Tuning Tools

Jconsole,jprofile,visualvm

Jconsole: The JDK comes with a simple function, but it can be used with a certain load on the system. The garbage collection algorithm has a very detailed tracking. For more information, see here

Jprofiler: Commercial software, you pay for it. Powerful. For more information, see here

VisualVM: The JDK comes with powerful features similar to Jprofiler. Recommended.

How to Tune

Observe memory release, collection class check, Object tree

These tuning tools provide powerful features, but generally fall into the following types of functions

Heap Information View

View heap space size allocation (young generation, old generation, persistent generation allocation)

Provides instant garbage collection capabilities

Garbage monitoring (long-time monitoring of recycling)

View in-heap class, Object Information view: quantity, type, etc.

Object reference Scenarios View

With the ability to view the heap information, we can generally solve the following problems smoothly:

--Is it reasonable to divide the old generation into younger generations?

--Memory leaks

--whether the garbage collection algorithm is set properly

Thread Monitoring

Thread Information monitoring: The number of system threads.

Thread Status monitoring: What is the state of each thread

Dump thread Details: View Internal threads running

Deadlock Check

Hot Spot Analysis

CPU hotspots : Check which methods in the system consume a large amount of CPU time

Memory hotspots : Check which objects are the largest in the system (for a certain amount of time the surviving object and the destroyed object are counted together)

These two things are very helpful for system optimization. Based on the hotspots we find, we can find and optimize the system bottleneck, rather than the optimization of all the code without any purpose.

Snapshot

A snapshot is a freeze that the system runs to a certain point in time. When we are tuning, it is impossible to use the eyes to track all system changes, depending on the snapshot function, we can make the system two different running times, objects (or classes, threads, etc.) different, in order to quickly find the problem

For example, if I want to check the system for garbage collection, whether there are any objects that have been recalled are missing. Then, I can take a snapshot of the heap situation before and after the garbage collection, and then compare the object conditions of the two snapshots.

Memory leak Check

Memory leak is a common problem, and the solution is also more general, here can focus on, and the thread, hot issues are specific problems specific analysis.

Memory leaks can generally be understood as system resources (all aspects of resources, heaps, stacks, threads, etc.) in the case of incorrect use, resulting in the use of resources that are not recycled (or not recycled), resulting in a new resource allocation request cannot be completed, causing a system error.

A memory leak is more harmful to the system because he can directly cause the system to crash.

There is a difference between a memory leak and a system overload, although the end result may be the same. Memory leaks are exhausted resources that are not recycled causing errors, and system overload is that the system does not have so many resources to allocate (other resources are in use).

The old generation of heap space is occupied

exception: Java.lang.OutOfMemoryError:Java heap Space

Description

This is the most typical memory leak, simply to say that all the heap space is not recyclable garbage objects are full, the virtual machine can no longer allocate new space.

As shown, this is a very typical garbage collection scenario diagram for memory leaks. All peaks are a garbage collection point, and all Valley valleys represent the remaining memory after a garbage collection. Connecting all the points of the valley, you can find a bottom-to-high line, which means that, over time, the system's heap space is constantly occupied and will eventually fill the entire heap space. It is therefore possible to assume that there may be memory leaks inside the system. (The diagram above is for example only, in practice it takes longer to collect data, such as hours or days)

Solve:

This approach is easier to solve, generally based on the situation of garbage collection before and after the comparison, and based on the object reference (Common collection object reference) analysis, basically can find the leak point.

The permanent generation is fully occupied

exception:java.lang.OutOfMemoryError:PermGen space

Description

Perm space is occupied. The exception that is thrown when storage space cannot be allocated for the new class. This exception was not previously available, but today's exception is more common in Java reflection-heavy use. The main reason is that a large number of dynamic reflection generated classes are constantly being loaded, resulting in the perm area being fully occupied.

Even more frightening is that different classloader even use the same class, but will load it, equivalent to the same thing, if there are n ClassLoader then he will be loaded n times. Therefore, in some cases, the problem is basically considered as no solution. Of course, there are a lot of classloader and a lot of reflective classes in fact there is not much.

Solve:

1.-xx:maxpermsize=16m

2. Swap with the JDK. Like Jrocket.

Stack Overflow

Exception:java.lang.StackOverflowError

Note: this is not much to say, is generally recursive not return, or loop call caused

Thread Stack Full

exception : Fatal:stack size too small

Description : There is a limit to the space size of a thread in Java. This value is 1M after JDK5.0. The data associated with this thread will be stored in it. However, the above exception will occur when the thread space is full.

workaround : Increase the thread stack size. -xss2m. However, this configuration does not solve the underlying problem, but also depends on the part of the code that caused the leak.

System memory is fully occupied

exception : java.lang.OutOfMemoryError:unable to create new native thread

Description :

This exception is due to the fact that the operating system does not have sufficient resources to generate this thread. When the system creates a thread, the operating system itself needs to allocate resources to create threads, in addition to allocating memory in the Java heap. Therefore, when the number of threads is large enough, there may be room in the heap, but the operating system cannot allocate resources, and this exception occurs.

The more memory allocated to a Java virtual machine, the less resources the system has left, so that when the system memory is fixed, the more memory is allocated to the Java virtual machine, the fewer threads the system can produce, the inverse of the relationship. At the same time, you can reduce the amount of space allocated to a single thread by modifying-XSS, or you can increase the number of threads that the system produces in total.

Solve:

1. Redesign the system to reduce the number of threads.

2. If the number of threads cannot be reduced, a single thread size can be reduced by-XSS. So that more threads can be produced.

JVM Tuning Summary (10)-tuning method