Key steps for performance tuning of Java applications include: 1. Use JVM built-in tools such as jstat, jmap, and jstack to monitor GC frequency, memory distribution and thread status, and locate basic problems; 2. Use VisualVM, JProfiler or Async Profiler to analyze hot codes and identify CPU-intensive methods; 3. Optimize garbage collection behavior through GC logs and parameter adjustments, and select appropriate recyclers and heap configurations based on business load testing; 4. Avoid common traps such as excessive synchronization, frequent object creation, N 1 query, and excessive log output, and reduce unnecessary performance losses.

Performance tuning and analysis of Java applications are actually just a few key points: finding bottlenecks, understanding behavior, and rational optimization. You don't need to pursue the ultimate from the beginning, but you have to know where to start.

1. Use the built-in JVM tools to understand the running status

JVM comes with some tools, such as jstat , jmap , and jstack . Although these widgets are simple, they are very practical when troubleshooting problems. For example:

• jstat -gc <pid></pid> can see the GC frequency and time consumption. If you find that Full GC happens frequently, the memory may become a bottleneck.
• jmap -histo:live <pid></pid> can see the distribution of objects in the heap, which helps to detect memory leaks.
• jstack <pid></pid> Print thread stack, which can be used to check deadlock or thread blocking problems.

These commands do not need to be memorized, but you have to know which types of problems they can solve. When using it, use it to process the output with grep or script, which is more efficient.

2. Use Profiling tools to locate hotspot codes

With logs and command line tools alone, it is difficult to see which method is slowing down overall performance. At this time, you need to use the profiling tool to "show X-ray".

Commonly used are:

• VisualVM : Graphical interface, suitable for local debugging, can view threads, memory, and CPU usage, and can also perform sampling or profiling.
• JProfiler : More powerful, supports remote connections, and is also helpful for production environment diagnosis, but it is commercial software.
• Async Profiler : lightweight, low overhead, suitable for short-term opening in production environments, and can accurately find CPU-intensive methods.

When using these tools, it is recommended to run the sampling mode first to see if there are any obvious hot-spot methods. If necessary, turn on more detailed tracking mode to avoid affecting system stability.

3. Pay attention to GC behavior and adjust parameters appropriately

The performance of Java applications is closely related to GC. Different garbage collectors have a lot of performance. For example, G1 is suitable for large piles of memory, while ZGC focuses on low latency.

You can observe GC in the following ways:

• Startup parameters plus -XX: PrintGCDetails -XX: PrintGCDateStamps
• Use jstat to monitor GC frequency
• Use GC log analysis tools such as GCEasy or GCViewer to view trends

Adjusting GC parameters is not the more complicated the better, for example:

• It is easy to OOM if the pile is too small, and it will increase GC time if it is too large
• The young generation is too small to set up, which will lead to frequent promotion of objects to the elderly, causing Full GC
• You can select appropriate pause target parameters according to GC type, such as -XX:MaxGCPauseMillis=200

The key is to make decisions based on business load testing, rather than blindly applying other people's configuration.

4. Avoid common performance traps

Sometimes poor performance is not because the code is bad, but because it is a pitfall:

• Oversync : If synchronized is used too much, it will slow down the concurrency ability. You can use ReentrantLock or try lock-free structure.
• Frequently creating objects : For example, new objects in a loop can easily lead to high pressure on GC, consider reusing or using object pools.
• N 1 query problem : There is no batch processing for database access, and one interface triggers dozens of queries. This situation can be solved by adding a JOIN or cache.
• Too much log output : Too much DEBUG level log will affect IO. Remember to adjust the log level before going online.

These problems are often hidden in business logic and will only be exposed under actual stress measurement or real traffic.

Basically that's it. Performance tuning is a gradual process, don't modify JVM parameters or refactor code as soon as you start. Observe first, then analyze, and finally take action, the effect is better.

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