JVM- How to choose a suitable garbage collector

Echo edit. Welcome to add Echo wechat (wechat id: T2421499075) for exchange and learning. This article does not support reprinting, the main content comes from reading notes and network blog, as well as video learning arrangement.

List of resources:

Different versions of the JDK garbage collector: blog.csdn.net/weixin_3416…

Bubbling Institute Resource collection

Understanding the Java Virtual Machine in Depth: Advanced JVM Features and Best Practices (3rd edition)

The three most important indicators of garbage collectors are: Footprint, Throughput, and Latency. However, if we only know these and understand many garbage collectors, it is not effective and reasonable to choose a garbage collector that is suitable for us. See a lot of articles on the Internet description, are please according to the characteristics of each garbage collector and the corresponding scenario to use. This is true, but for someone who doesn’t have much contact with the garbage collector, it can be confusing. This article focuses on the method of selecting a garbage collector

Is the more advanced garbage collector the better?

The answer is no. In the process of updating our JDK, we found that many garbage collectors are adjusted according to the JDK version, such as G1 is released in JDK11 environment, and ZGC is released in JDK13 environment. Obviously, there are still a lot of companies using JDK1.7, JDK1.8, and very few using JDK11

Garbage collector selection scenario analysis

  • The application needs to compute the result as quickly as possible. The goal is to compute the result as quickly as possible, and throughput is the main point.
  • In SLA applications, the pause time directly affects the quality of service and even causes transaction timeouts. The focus is latency.
  • If it is a client or embedded application, the memory footprint of the garbage collector is not negligible.

What hardware conditions affect the garbage collector

  • Is the system architecture x86-32/64, SPARC or ARM/Aarch64
  • The number of processors
  • The size of allocated memory
  • The operating system is Linux, Solaris, or Windows

The impact of JDK versions on the garbage collector

  • Serial collector JDK1.3.1 was the only choice for HotSpot new generation collection
  • The garbage collector. [ParNew] [Parallel Insane] JDK1.4
  • CMS (Concurrent Mark Sweep) Serial Old JDK1.5 garbage collector version
  • Parallel Old: GARBAGE collector version of JDK1.6
  • [G1] Garbage collector version of JDK11
  • ZGC: garbage collector version of JDK13

The impact of JDK vendors on the garbage collector

Shenandoah is an official feature of OpenJDK12 and is not supported by Oracle