When the CPU usage rate is too high, first use top -H and jstack to analyze the thread stack, and combine JProfiler or asyncProfiler to locate hot spots; 2. Frequent GC can detect memory leaks through log analysis and MAT, and pay attention to static collections, cache and other references; 3. I/O and database problems can be positioned through APM tools or logs, and the optimization methods include cache addition, asynchronous processing and database indexing; 4. Unreasonable thread pool configuration may lead to blockage, so the number of threads, queues and rejection policies should be set reasonably, and the running status should be monitored. Mastering these directions and tools can effectively identify Java performance bottlenecks.

Identifying Java performance bottlenecks is actually not that mysterious. The key is to master several common investigation directions and tools. Many times the problem is not complicated, but if you don’t know where to start, it’s easy to get stuck.

1. The CPU usage rate is too high: first look at what the thread is doing

If you find that the application's CPU occupies a lot, the first step should be to see which threads are "working hard". You can use top -H to find the thread PID that occupies a high occupancy, then convert it to hexadecimal, and then use jstack to dump the thread stack to find the corresponding thread state.

Common situations include:

• A thread is doing a lot of calculations (such as looping, encryption and decryption)
• Thread stuck in dead loop or frequent GC
• Multi-threaded competition to lock resources, resulting in frequent context switching

At this time, you can use tools such as JProfiler or VisualVM to visualize the hotspot method, or directly use asyncProfiler included with JDK to sample the CPU time-consuming distribution.

2. Memory issues: GC frequently or memory leaks?

One of the most common performance problems with Java applications is that garbage collection is too frequent. If you find that Full GC happens frequently and the recovery effect is not obvious every time, it is likely that it is a memory leak.

The problem of the investigation can be as follows:

• First look at the GC log to confirm which garbage collector it is, and whether Full GC is frequently triggered
• Use MAT (Memory Analyzer) to analyze the heap dump file to find large objects or suspicious reference chains
• Pay attention to static collection classes, caches, listeners and other places that are prone to memory leakage

For example, many people will use static Map to store data, but forget to clean it up, and the memory will burst over time. At this time, no matter how much memory is added, it is useless, and it has to be solved from the code level.

3. I/O and database operations slow down response

Many performance problems are not due to the JVM itself, but the access to external resources is too slow. for example:

• Database query has no index, long execution time
• Network request timeout or slow response
• Logs are slowly written to disk, affecting the main process

Such problems can be used to monitor the interface call chain through APM tools (such as SkyWalking, Pinpoint) to locate specific time-consuming steps. If there is no APM, you can also manually log and record each stage of time.

Optimization suggestions:

• Add cache (such as Redis) to reduce duplicate requests
• Asynchronous processing of non-core logic
• Add indexing to the database and avoid N1 queries

4. Unreasonable thread pool configuration causes blockage

Thread pools are commonly used in Java to handle concurrent tasks, but if the thread pool is not configured properly, it will cause performance degradation or even system crashes.

for example:

• Too few core threads, waiting for tasks for too long
• Reject policy settings improperly, and directly throwing exceptions affects user experience
• Thread pools are shared, and different businesses influence each other

It is recommended to split the thread pool according to different business scenarios and set appropriate queue size and rejection policies. At the same time, the status of the thread pool should be monitored, such as the number of active threads, queue backlog, etc.

Basically these are the more common points. If there are too many tools, you will easily get confused. The key is to understand the system operation mechanism and know where to start. Some problems look scary, but they can be located just by just taking action.

The above is the detailed content of Java Performance Bottlenecks Identification. For more information, please follow other related articles on the PHP Chinese website!