Java tuning experience

directory

• Tuning to prepare
• Performance analysis
• Performance tuning
• Other Optimization Suggestions
• JVM parameters advanced

For tuning, there are generally three processes:

• Performance monitoring: Problems don’t occur and you don’t know what you need to tune? In this case, some system and application monitoring tools are required to detect problems.
• Performance analysis: The problem has occurred, but you don’t know exactly what the problem is. In this case, you need to use tools and experience to analyze the bottleneck of the system and application in order to locate the cause of the problem.
• Performance tuning: After the analysis in the previous step, the problem is located, and the problem needs to be solved and optimized by means of code and configuration.

Java tuning is all about these three steps.

In addition, the performance analysis and tuning mentioned in this paper are independent of the following factors:

• Underlying system environment: hardware and operating system
• Use of data structures and algorithms
• Use of external systems such as databases and caches
• Use of some Api in Java, such as Random, StringBuilder, etc.

Tuning to prepare

Tuning requires preparation, because every application’s business goals are different, and performance bottlenecks are not always at the same point. At the business application level, we need to:

• Need to understand the overall architecture of the system, clear direction of pressure. For example, which interface and module of the system is the most used and faces the challenge of high concurrency.
• You need to build a test environment to test the performance of your application, using AB, LoadRunner, or JMeter.
• Analyze the volume of key business data, which mainly refers to quantitative analysis of some data, such as the daily data volume of the database; How much data is cached, etc
• Understand the system response speed, throughput, TPS, QPS and other indicators requirements, such as the corresponding speed and QPS of the second kill system is very demanding.
• Understand the version, mode, and parameters of the software related to the system. Sometimes, the version and mode of the service on which the application depends may affect the performance to some extent.

In addition, we need to know a few things about Java:

Performance analysis

Performance tuning

Corresponding to performance analysis, performance tuning is also divided into three parts.

CPU tuning

• Don’t have an always-running thread (an infinite while loop) and use sleep to sleep for a while. This situation is common in some pull consumption scenarios. If a pull fails to get data, it is recommended to sleep for the next pull.
• The wait/notify mechanism can be used for polling
• Avoid loops, regular expression matching, and overcalculation, including using String format, split, and replace methods (you can use apache’s commons-lang StringUtils equivalents). Use regex to determine mailbox formatting (sometimes causing endless loops), sequence/deserialization, and so on.
• Combine the JVM and code to avoid frequent GCS, especially full GCS.

In addition, the following points need to be noted when using multithreading:

• Use thread pools to reduce the number of threads and thread switching
• Multi-threaded lock competition can be considered to reduce the lock granularity (using ReetrantLock), split lock (similar to ConcurrentHashMap bucket locking), or use CAS, ThreadLocal, immutable objects and other lock-free technologies. The best way to write multithreaded code is to use the JDK’s package sending/closers framework, ForkJoin, and so on. Discuptor and Actor can also be used in appropriate scenarios.

Memory tuning

Tuning memory is primarily tuning the JVM.

• Set the size of each generation appropriately. Avoid Cenozoic Settings that are too small (not enough, often minor gc and into old) and too large (fragmentation), as well as Survivor Settings that are too large and too small.
• Choose the appropriate GC strategy. You need to choose the appropriate GC strategy for different scenarios. It should be said here that CMS is not omnipotent. Unless you need to set it up again, after all, THE CMS’s new generation recycling strategy parNew is not the fastest, and CMS will generate fragments. In addition, G1 was not widely used until the advent of JDK8 and is not recommended.
• JVM startup parameters -xx :+PrintGCDetails -xx :+PrintGCDateStamps -xLOGGc :[log_path] to record GC logs for troubleshooting.

In regard to the first point, there are specific suggestions:

• Young generation size selection: Response time first applications, as large as possible, until close to the system’s minimum response time limit (selected based on the actual situation). In this case, the frequency of GC occurring in young generation collections is minimal. At the same time, it can reduce the number of objects reaching the old generation. For throughput-first applications, set it as large as possible because there is no requirement on response time and garbage collection can be performed in parallel. It is recommended for applications with more than 8 cpus.
• Aged generation size selection: For response-time-first applications, teners generally use concurrent collectors, so their size needs to be carefully set, generally taking into account some parameters such as concurrent session rate and session duration. If the heap is set too small, it can cause memory fragmentation, high recycle frequency, and application pauses to use traditional token cleanup. If the heap is large, it takes longer to collect. The optimal scheme generally needs to refer to the following data:
  • Concurrent garbage collection information
  • Number of concurrent collections for persistent generation
  • Traditional GC information
  • The proportion of time spent on recycling between the younger and older generations

  Generally, throughput-first applications should have a large young generation and a small old generation. In this way, most short-term objects are reclaimed as much as possible, while intermediate objects are reduced, while the old generation stores long-lived objects.

In addition, the fragmentation problem caused by the smaller heap: because the concurrent collectors of the older generation use mark-and-sweep algorithms, the heap is not compressed. When the collector collects, adjacent Spaces are merged so that they can be allocated to larger objects. However, when heap space is low, “fragmentation” can occur after running for a while, and if the concurrent collector cannot find enough space, the concurrent collector will stop and recycle using the traditional mark-and-sweep method. If there is a “fragments”, may need to have the following configuration: – XX: + UseCMSCompactAtFullCollection, when using the concurrent collector, open to the older generation of compression. At the same time use – XX: CMSFullGCsBeforeCompaction = XX set how much time after Full GC, to compress old generation.

The remaining optimization issues for the JVM can be seen in the JVM Parameter Progression section below.

In code, note also:

• Avoid saving duplicate strings, and be careful with string.substring () and string.intern ()
• Try not to use Finalizer
• Release unnecessary references: Release ThreadLocal to prevent memory leaks, and close streams when they run out.
• Use object pooling to avoid excessive object creation and frequent GC. But don’t use object pools, except for initialization/creation scenarios like connection pools, thread pools, etc.
• For cache invalid algorithm, you can use SoftReference and WeakReference to save cache objects
• Use caution with hot deployment/loading, especially with dynamically loaded classes

• Do not use Log4j to output file names, line numbers, because Log4j does this by printing a thread stack, generating a large number of strings. In addition, when using Log4j, it is recommended to use this classical method to check whether logs of the corresponding level are opened before performing operations. Otherwise, a large number of strings will be generated.

    if (logger.isInfoEnabled()) {
        logger.info(msg);
    }
  Copy the code

IO tuning

Note on file IO:

• Consider using asynchronous writes instead of synchronous writes, using redis’s AOF mechanism as a reference.
• Use caching to reduce random reads
• Try to batch write, reduce I/O times and addressing
• Use a database instead of file storage

Note the following on network I/O:

• Similar to file IO, asynchronous and multiplexed IO/ event-driven IO are used instead of synchronous blocking IO
• Batch performing network I/OS to reduce I/O count
• Use cache to reduce the read of network data
• Use coroutines: Quasar

Other Optimization Suggestions

JVM parameters advanced

Setting JVM parameters has always been a bit of a muddle, with a lot of confusion about what parameters can be configured, what they mean, and why. Here are some common sense explanations of these and some of the parameters that can easily lead to pitfalls.

All of this is for Oracle/Sun JDK 6

1. Startup parameter default value

   Java has many startup parameters, and many versions are different. But now the web is full of information, many of which are ineffective or default if used undiscriminately. In general, we can see all the parameters that can be set and their default values by using Java -xx :+PrintFlagsInitial. You can also add -xx :+PrintCommandLineFlags at program startup to view startup parameters that are different from the default values. If you want to see all the startup parameters (including the default values), use -xx :+PrintFlagsFinal.

   The “=” in the output indicates that the default value is used, while the “:=” indicates that the default value is not used. It may be a parameter passed in from the command line, a parameter in the configuration file, or ergonomics automatically selects another value.

   In addition, you can use the jinfo command to display startup parameters.

   • Jinfo-flags [pid] # check the current valid startup parameters
   • Jinfo-flag [flagName] [pid] #

   It is important to note that when you are configuring JVM parameters, it is best to use the above commands to check the default values of the parameters before deciding whether to set them. It’s also best not to configure parameters that you don’t know what they’re for, because there’s a reason for default Settings.

2. Dynamic setting parameters

   When the Java application starts up, the performance problem is identified as GC, but when you start up, you do not add the parameters to print GC, many times you just add the parameters again and restart the application. However, the service will be unavailable for a certain period of time. The best practice is to be able to set parameters dynamically without restarting the application. You can do this using JInfo (again, essentially JMX-based).

   Jinfo-flag [+/-][flagName] [pid] # Enable/disable a parameter jinfo-flag [flagName=value] [pid] # Set a parameterCopy the code

   In the above GC case, you can use the following command to open heap dump and set the dump path.

    jinfo -flag +HeapDumpBeforeFullGC [pid] 
    jinfo -flag +HeapDumpAfterFullGC [pid]
    jinfo -flag HeapDumpPath=/home/dump/dir [pid]
   Copy the code

   It can also be turned off dynamically.

    jinfo -flag -HeapDumpBeforeFullGC [pid] 
    jinfo -flag -HeapDumpAfterFullGC [pid]
   Copy the code

   Other parameter Settings are similar.

3. Verbose: gc and – XX: + PrintGCDetails

   Many GC recommendations use both of these parameters. In fact, once -xx :+PrintGCDetails is turned on, the previous options will be turned on at the same time.

4. -XX:+DisableExplicitGC

   The purpose of this parameter is to make system.gc available for air conditioning, which is recommended in many Settings. However, using this option will result in oom if you are using NIO or other out-of-heap memory. Can use XX: + ExplicitGCInvokesConcurrent or XX: + ExplicitGCInvokesConcurrentAndUnloadsClasses (use with CMS makes system. Gc triggered a concurrent gc) instead.

   There is another interesting point. If you do not set this option, full GC will be performed periodically when you use RMI. This phenomenon is due to distributed GC, which serves RMI. Specific visible in the the link content related to the DGC: docs.oracle.com/javase/6/do…

5. MaxDirectMemorySize

   This parameter is the upper limit of the set out-of-heap memory. When not set to -1, the value is -xmx minus the reserved size of a survivor space.

6. For legacy reasons, the same parameters are used

   • Xss and – XX: ThreadStackSize
   • -xmn :NewSize -xx :NewSize -xmn :NewSize -xx :NewSize -xmn :NewSize

7. -XX:MaxTenuringThreshold

   The default value is 15, but when CMS is selected, the value will change to 4. When this value is set to 0, all live objects in Eden are promoted to Old Gen on their first minor GC, and survivor Spaces are not.

8. -XX:HeapDumpPath

   Use this parameter to specify the – XX: + HeapDumpBeforeFullGC, XX: + HeapDumpAfterFullGC, XX: + HeapDumpOnOutOfMemoryError trigger heap dump file storage location.

The resources