Initial use of JVisualVM

Initial use of JVisualVM

1 Introduction

The common jvm tuning tools are Jconsole, jProfile, VisualVM ,

• Jconsole : comes with jdk, the function is simple, but it can be used when the system has a certain load. There is a very detailed trace of the garbage collection algorithm.
• JProfiler : commercial software, need to pay. Powerful.
• VisualVM : It comes with JDK and has powerful functions, similar to JProfiler. It can monitor threads, memory conditions, view the CPU time of methods and objects in memory, objects that have been GC, reverse view the allocated stack and other functions.

2. Initial use of JVisualVM

2.1 installation

VisualVM can perform remote and local monitoring, run jvisualvm.exe (E:\work\Java\jdk1.8.0_321\bin) in the jdk installation directory, or download the independent version of visual vm (download link address: https:// github.com/oracle/visualvm/releases/download/2.1.3/visualvm_213.zip).

2.2 Plugins

You can choose to install some plug-ins you need, menu bar -> tools -> plug-ins, select the plug-ins you need to install

2.3 visual Gc

For example, the downloaded visual gc plug-in can track the situation of gc, and can better configure jvm parameters after analysis

3. Remote connection

Connection tutorial: https://blog.csdn.net/qq_44872773/article/details/122042495

Pit point: https://blog.csdn.net/weixin_44906271/article/details/121373973

4. How to tune the JVM

Observe memory release, collection class inspection, object tree

The above tuning tools all provide powerful functions, but in general, they are generally divided into the following types of functions

4.1 Heap information viewing

You can view the heap space size allocation (young generation, old generation, permanent generation allocation)

Provides instant garbage collection

Garbage monitoring (monitoring recycling over a long period of time)

View the class in the heap, view object information: quantity, type, etc.

View object references

With the function of viewing heap information, we can generally solve the following problems smoothly:

– Whether the size division of the old generation and the young generation is reasonable

– memory leak

– Whether the garbage collection algorithm setting is reasonable

4.2 Thread Monitoring

Thread information monitoring: the number of system threads.

Thread state monitoring: What state are each thread in?

Dump thread details: view the internal operation of the thread

deadlock check

Hot spot analysis

CPU hotspots : check which methods of the system take up a lot of CPU time

Memory hotspots : Check which objects have the largest number in the system (survival objects and destroyed objects are counted together within a certain period of time)

These two things are very helpful for system optimization. Based on the hotspots we find, we can search for system bottlenecks and optimize the system in a targeted manner, instead of aimlessly optimizing all codes.

snapshot

A snapshot is a freeze frame of the system running to a certain moment. When we are tuning, it is impossible to track all system changes with our eyes. Relying on the snapshot function, we can perform two different runtimes of the system, different objects (or classes, threads, etc.), so as to quickly find problems

For example, I want to check whether there are any objects that should be recovered after the system performs garbage collection. Then, I can take a snapshot of the heap situation before and after garbage collection, and then compare the object situation of the two snapshots.

4.3 Memory Leak Check

Memory leaks are relatively common problems, and the solutions are relatively general. Here we can focus on them, while the problems of threads and hotspots are analyzed in detail.

Memory leaks can generally be understood as system resources (all aspects of resources, heap, stack, threads, etc.) in the case of incorrect use, resulting in the use of resources that cannot be recycled (or not recycled), resulting in the inability to complete new resource allocation requests , causing a system error.

Memory leaks are more harmful to the system because they can directly lead to system crashes.

It needs to be distinguished. There is a difference between memory leaks and system overloads, although the possible end results are the same. A memory leak is an error caused by exhausted resources that are not recycled, and a system overload is that the system does not have so many resources to allocate (other resources are in use).

4.3.1 Old generation heap space is full

异常： java.lang.OutOfMemoryError: Java heap space

illustrate:

This is the most typical way of memory leaks. Simply put, all the heap space is occupied by garbage objects that cannot be recycled, and the virtual machine can no longer allocate new space.

As shown in the figure above, this is a very typical garbage collection diagram of a memory leak. All peaks represent a garbage collection point, and all valleys represent memory remaining after a garbage collection. Connecting all the valley points, a line from bottom to high can be found, which shows that as time goes by, the heap space of the system is continuously occupied, and eventually the entire heap space will be occupied. Therefore, it can be preliminarily considered that there may be a memory leak inside the system. (The graph above is just an example, in actual situations it takes longer to collect data, such as hours or days)

solve:

This method is also relatively easy to solve. Generally, it is based on the comparison before and after garbage collection, and at the same time, based on the analysis of object references (common collection object references), the leak point can basically be found.

4.3.2 Metaspace is full

**Exception:**java.lang.OutOfMemoryError: PermGen space

illustrate:

The system has a lot of code or refers to a lot of third-party packages, or uses methods such as dynamic code generation and class loading, resulting in a large memory usage in the metaspace.

solve:

• Optimize parameter configuration to avoid affecting other JVM processes
• Be cautious about citing third-party packages
• Focus on frameworks for dynamically generated classes

4.3.3 Stack overflow

• Exception: java.lang.StackOverflowError

• Explanation: I won't say much about this, generally it is caused by recursion not returning, or loop call

thread stack full

Exception : Fatal: Stack size too small

Explanation : The space size of a thread in java is limited. After JDK5.0, this value is 1M. Data related to this thread will be saved in it. But when the thread space is full, the above exception will occur.

Solution : Increase the thread stack size. -Xss2m. But this configuration cannot solve the fundamental problem, and it depends on whether there is a part of the code that causes the leak.

4.3.4 The system memory is full

异常：java.lang.OutOfMemoryError: unable to create new native thread

Description :

This exception is caused by the operating system not having enough resources to spawn this thread. When the system creates a thread, in addition to allocating memory in the Java heap, the operating system itself also needs to allocate resources to create threads. Therefore, when the number of threads reaches a certain level, there may still be space in the heap, but the operating system cannot allocate resources, and this exception occurs.

The more memory allocated to the Java virtual machine, the less resources left in the system. Therefore, when the system memory is fixed, the more memory allocated to the Java virtual machine, the fewer threads the system can generate in total. are inversely proportional to each other. At the same time, the space allocated to a single thread can be reduced by modifying -Xss, and the number of threads generated in the system can also be increased.

solve:

1. Redesign the system to reduce the number of threads.
2. If the number of threads cannot be reduced, use -Xss to reduce the size of a single thread. In order to be able to produce more threads.

5. Suggestions for jvm parameter optimization

Essentially, it is to reduce the number of GC.

If it is an application that frequently creates objects, the size of the new generation can be appropriately increased. More constants can increase the size of the permanent generation. For objects with many singletons, the size of the old generation can be increased. For example, in spring applications.

GC selection, after JDK5.0, JVM will judge according to the current system configuration. Generally, you can execute the -Server command. GC includes three strategies: serial, parallel, and concurrent.

The throughput is greatly applied, and parallel collection is generally used to open multiple threads to speed up the gc.

Applications with high response speed generally use concurrent collection, such as application servers.

It is recommended to configure the old generation as a concurrent collector. Since the concurrent collector will not compress and defragment disks, it is recommended to configure:

-XX:+UseConcMarkSweepGC #Concurrently collect the old generation

-XX:CMSInitiatingOccupancyFraction=80 # Indicates that the CMS will be executed when the old generation space reaches 80%

-XX:+UseCMSCompactAtFullCollection # Turn on the compression of the old generation. May affect performance, but eliminates memory fragmentation.

-XX:CMSFullGCsBeforeCompaction=10 # Since the concurrent collector does not compress and organize the memory space, "fragmentation" will be generated after running for a period of time, which will reduce the operating efficiency. This parameter is set to compress and organize the memory space after running FullGC.

Reprinted: https://blog.csdn.net/Wulawuba/article/details/124993165