Java Performance Optimization Tips

How to make Java applications run is one thing, but getting them to run faster is another matter. In the face of the object of the environment, performance problems like the ferocious beast. But the complexity of the JVM adds a level of complexity to the performance tuning. Here Refcard covers the JVM internals, class loading (updated in Java8 to map the latest meta-space), garbage collection, troubleshooting, detection, concurrency, and so on.

Currently Java is one of the most widely used programming languages in the field of software development. Java applications are widely used in many vertical areas (banking, telecommunications, healthcare, etc.). The purpose of Refcard is to help developers improve the performance of applications in a business environment by focusing on internal JVM, performance tuning principles and best practices, and leveraging existing monitoring and troubleshooting tools.

It can define "optimal performance (Best performance)" in different ways, but the basic factor is the ability of the Java program to perform computational tasks within the business response time requirements, the ability of the program to perform business functions at high capacity, and the characteristics of high reliability and low latency. Sometimes the numbers themselves become stereotyped: for some large websites, excellent page response times should be below 500ms. In due course, the Refcard includes the target number. In most cases, however, you need to determine these yourself based on your business needs and your existing performance benchmarks.

JVM Internals

Code compilation and JIT

Compiling Java bytecode is obviously not as fast as executing native code directly from the host. To improve performance, the Hotspot JVM finds the busiest bytecode area and compiles it into more efficient native, machine code (Adaptive Optimizations). This local code is then stored in a code cache that is not in heap memory.

Note: Most JVMs are implemented by disabling the JIT compiler (Djava.compiler=none). You only need to consider the key optimizations that are disabled, such as JVM crashes.

Memory space

HotSpot Java Virtual Machine is made up of the following storage spaces.

storage space	description
java Heap	java program class instances and arrays of primary storage.
permanent Generation (JDK 1.7 and below) metaspace (JDK 1.8 and later)	java class metadata. Note: Starting with Java 8, The PermGen space is replaced by the meta-space and the use of local memory, similar to the IBM J9 JVM.
native Heap (c-heap)	local memory store thread, stack, package Code caches for objects, such as mmap files and third-party native libraries.

Class loading

Another important feature of Java is that it can load compiled Java classes (bytecode) after the JVM is started. Depending on the size of the program, the program will have a significantly lower performance during class loading after the restart. This behavior occurs because the internal JIT compiler needs to restart optimization after a reboot.

Since JDK version 1.7, there are some improvements that you should be concerned about. For example, the default JDK class loader has a better ability to load in class concurrency.

Hot

Areas of concern	Suggestions
Degraded performance after a JVM reboot	Avoid deploying excessive Java classes to a single application ClassLoader (for example: Very large war files)
The runtime found that excessive class load contention (thread lock, JAR file searches ...) reduced overall performance.	Analyzing your application and identifying code modules for dynamic class loading operations is too frequent. Actively looking for non-one-stop class loading errors, such as ClassNotFoundException and Noclassdeffounderror. Revisit the Java Mapping API and the use of optimized overuse.
Java.lang.OutOfMemoryError:PermGen Space (JDK version 1.7 and below) Java.lang.OutOfMemoryError: meta-space (JDK 1.8 and later)	Revisit the size of the JVM Permanent Generation, Metaspace (maxmetaspacesize), and local memory capacity where applicable. Parses the source of the application ClassLoader and memory leaks that identify metadata.

Garbage collection

The Java garbage collection process is critical for program performance. To provide effective garbage collection, the heap is essentially divided into sub-regions.

Heap Area

Regional	Describe
Latest Generation-young Generation (Nursery space)	New or ephemeral objects are allocated as part of the reserved heap. The garbage is recycled by a fast but Stop-the-world YG collector. Those who have stayed long enough in young space will be promoted to old space. Note: The size and GC frequency of YG space will significantly affect the response time of the program, resulting in an increase in the JVM's pause time.
Older generation-old Generation (tenured space)	Part of the heap is left to the long-lived object. Garbage is usually collected in parallel or concurrently (most of the time), such as CMS or GENCON (IBM JVM). Performance tip: It is important to choose and test the best GC strategy based on the needs of your application. For example, when switching to concurrent GC collections, such as CMS or G1, can significantly increase the average response time of the application (reducing latency).

GC Collectors

Choosing the right collector or GC policy optimizes the performance, scalability, and reliability of your program to the best possible state. Many applications are sensitive to response time delays, so most need to use a concurrent collector, such as a hotspot CMS or IBM GC policy balanced.

We strongly recommend that you determine the most appropriate GC policy with appropriate performance and load testing. A comprehensive monitoring strategy should be implemented in the production environment to track overall JVM performance and identify areas that need to be improved later.

Garbage first (G1) Collector

The HotSpot G1 Collector is designed for high-probability pause times that are designed to meet user-defined garbage collection (GC), while achieving higher throughput.

The latest hotspot collector divides the heap into a set of equally sized heap areas, with each area of virtual memory contiguous in scope. It concentrates the recycled compressed activity in the heap area, where it is filled with recyclable objects (garbage first). In other words, this area has a minimum of "live" objects.

Oracle recommends using G1 Collector in the following examples and scenarios, especially for those currently using CMS or parallel collectors:

• Designed for large heaps (>= 6 GB), and limits GC latency (pause time <= 0.5 seconds) for application design.
• More than 50% of Java heap is consumed by real-time data (objects cannot be recycled by GC).
• The object analysis rate and the promotion effect changed significantly.
• Do not expect too long garbage collection or compression pauses (more than 0.5 to 1 seconds).

Java Heap Size

You must know that there is no GC policy to save the Java heap size. These exercises involve configuring the maximum and minimum capacity, including metadata and local memory capacity, for different storage spaces, including different versions of the old and new. Here are some suggested guidelines:

• larger heap does not always perform better and faster, so there is no need to over-tune the Java heap. JVM performance tuning in parallel, to find a chance to reduce or "spread" the memory footprint of the program to ensure that the JVM's average response time <1%.
• for the 32-bit JVM, consider the maximum heap size of 2GB in order to set aside some memory from the metadata and the local heap.
• for the 64-bit JVM, we're going to try to scale up at the vertical and horizontal levels, rather than trying to increase the Java heap size to more than 15GB. This approach often provides better throughput, better use of hardware, and improved application failover capabilities.
• do not repeat development: make it possible by leveraging the benefits and monitoring tools of open source and business troubleshooting. APM (Application performance management) products have developed rapidly over the past decade.

JDK 1.8 Metaspace Guide

Goal

Suggestions

Memory size GC Tuning Monitoring and troubleshooting

By default, the meta-space memory space is unbounded and uses a process or OS native memory that can be used for dynamic expansion. The memory space is partitioned fast and is stored by the JVM through Mmap. We recommend that you keep the default setting, which is the starting point for dynamic adjustment of the mode, combining the simplified dimensions with the close monitoring application metadata footprint for better capacity planning. A new JVM option (-xx:maxmetaspacesize=) allows you to limit the local memory allocated to class metadata. It is recommended as a safeguard mechanism when faced with physical resource (RAM) tension or similar to a memory leak. For Java applications that have larger class metadata footprint or dynamic classloading, we recommend adjusting the initial meta-space size with the new JVM option:-xx:metaspacesize=, Example: 1GB. This adjustment method will help to avoid early garbage collection including class metadata, especially in the "warm-up" period of Java applications.

Java concurrency

Java concurrency can be defined as the ability of a program to perform multiple tasks at the same time. For large Java EE systems, this means the ability to perform the business functions of multiple users while achieving optimal throughput and performance.

Whether it is hardware capability or JVM stability, Java concurrency problems can cause programs to crash, seriously affecting the overall performance and usability of the program.

Thread Lock Contention

When you evaluate the stability of concurrent threads for Java applications, you will often encounter thread lock contention, which is the most common Java concurrency problem at the moment.

For example: Thread lock contention triggers non-stop, which attempts to load a missing Java class (ClassNotFoundException) into the default JDK 1.7 ClassLoader.

If you meet a problem like thread Dump analysis in a mature technical environment, we strongly recommend that you actively face it. The root cause of this problem is often different from the previous Java synchronization to legitimate IO blocking or other non-thread safe calls. The Lock contention problem is often the "symptom" of another problem.

Java-level Deadlocks

The real java-level deadlocks is less common, and it can also greatly affect the performance and stability of the application. This issue is triggered when two or more threads are stuck forever. This situation differs from other common "day-to-day" threading issues such as lock contention, threads waiting on blocking IO calls, and so on.

Oracle HotSpot and IBM JVM provide a solution for most deadlock detectors scenarios to help you quickly identify the threads that are responsible for this situation. Encountering a problem similar to lock contention troubleshooting, it is recommended to resolve the issue from a thread dump analysis as a starting point.

Once the source of the code that caused the problem is found, the solution involves lock-ordering conditional addressing and other concurrent programming techniques available from the JDK, such as java.util.concurrent.locks.ReentrantLock, that provide such things as Trylock ( ) method. This approach gives developers greater flexibility and provides more ways to prevent deadlock and thread lock "starvation".

Clock time and CPU Burn

While tuning the JVM, it is also necessary to check the behavior of the application, or, more specifically, the contributors to the highest clock time and CPU burn.

When Java garbage collection and thread concurrency are no longer a stress point, it is important to drill down into the execution mode of your application code and focus on the top response time contributors (also called clock times). It is also important to check the application code for CPU consumption and Java threads (CPU burn). High CPU Usage (>75%) is not normal (good physical resource utilization). Because this often means inefficiencies and capacity issues. For large Java EE enterprise applications, it is necessary to maintain a secure CPU buffer to cope with sudden load shock conditions.

Discard traditional tracking methods, such as adding response time "Logs" to your code. Java Profiling Tools and APM solutions can help you analyze this type of problem. This approach is more efficient and reliable. There is a lack of a robust APM solution for the Java production environment. You can still rely on tools such as Java VISUALVM, thread dump analysis with multiple snapshots, and analyze each thread using the OS CPU.

The final suggestion is not to try to solve all the problems at once. List the top 5 clock time and CPU burn issues, and then look for a solution.

Application budget

Other important aspects of Java application performance are stability and reliability. Under SLA umbrella with 99.9% typical available targets, stability and reliability are particularly important for program operations. These systems should have a high level of fault tolerance and a rigorous budget for applications and resources to prevent the multi-meter effect. This approach prevents some of these situations, such as the use of all available physical, middleware, or JVM resources for a business process.

Timeout management

The lack of a reasonable time-out between Java application and external systems can lead to severe performance degradation and disruption due to middleware and JVM thread consumption (blocking IO calls). A reasonable timeout can be avoided when the Java thread waits too long when the external service provider is experiencing slow speed.

Tools

Goal	Recommended Tools
Automated, real-time performance monitoring, tuning, alerting, trend analysis, capacity management, and more	Enterprise APM Solutions (Business-Class APM solution) Note: The APM solution provides tools that allow you to achieve most of the following Java performance goals.

Java Performance Optimization Tips