7 things that are misunderstood by Java Virtual Machine garbage collection

What is the biggest misconception about Java garbage collection? What is it actually like?

When I was a child, my parents used to say that if you don't study hard, you can only sweep the streets. What they don't know is that cleaning up rubbish is actually a great thing. Maybe this is also the reason why, even in the Java world, there are many developers who misunderstand GC algorithms-including how they work, how the GC affects the program, and what you can do about it. So we found Java performance Tuning expert Haim Yadid and posted an article on the TAKIPI blog called Java Performance Tuning Guide.

Latest blog post: 7 things to be misunderstood about garbage collection
Http://t.co/3QJLJuKCRqpic.twitter.com/aqQEF0zTkK
-takipi (@takipid) April 6, 2015

With a strong interest in the performance Tuning guide, we decided to gather some popular ideas about garbage collection in this follow-up blog post, and to point out why they were completely wrong.

Take a look at the top 7 people:

1. Only one garbage collector

No, and 4 is also the wrong answer. The HotSpot JVM has a total of 4 garbage collector: Serial, Parallel/throughput. CMS, and the new kid on the Block G1. Don't worry, there are also non-standard garbage-collector and bolder implementations, such as Shenandoah or other JVM-used recyclers (C4--azul developed without a standstill collector). Hotspot uses the Parallel/throughput collector by default, but it is often not the best choice to run your program. For example, CMS and G1 will cause the GC pauses (GC pause) to occur less often, but the time spent on each pause is likely to be longer than the parallel collector. On the other hand, with the same size heap memory, the parallel collector can deliver higher throughput.

Conclusion: Select the appropriate garbage collector based on your needs (acceptable GC pause frequency and duration).

2. Parallel (Parallel) = concurrency (Concurrent)

A GC cycle (garbage Collection cycle) can occur in the form of STW (Stop-the-world), which can occur in a GC pause or concurrently, without pausing the application. Further, the GC algorithm itself can be either serial (single-threaded) or parallel (multithreaded). Therefore, when we refer to concurrent GC, it does not mean that it is done in parallel, but when it comes to serial GC, it does not imply that GC pauses will occur. In the world of GC, concurrency and parallelism are two completely different concepts. Concurrency is for GC cycles, while parallelism targets the GC algorithm itself.

Conclusion: the process of garbage collection actually has two steps, starting the GC cycle and running the GC itself, which is different two things.

3. G1 can solve all problems

After a series of corrections and improvements, Java 7 introduces the G1 collector, which is the newest component in the JVM garbage collector. G1 's biggest advantage is that it solves the common memory fragmentation problem in the CMS: the GC cycle frees up memory blocks from the old Generation, resulting in the memory becoming so riddled with Swiss cheese that the JVM has to stop to deal with the fragments until it does. But the story is not so simple, in some cases other recyclers may have better performance than G1, which depends entirely on your needs.

conclusion: without a miraculous collector to solve all GC problems, you should choose a suitable collector through specific experiments.

4. Average transaction time is the most needed indicator

If you only monitor the server's average transaction time, you are likely to miss some outliers. These abnormal situations can be devastating for the user, and people are unaware of its importance. For example, a transaction that normally takes 100ms of time, but is affected by a GC pause, took 1 minutes to complete. No one will notice this problem except the user, because you only observe the average transaction time. Imagine that 1% or more users have experienced this scenario, and if you focus only on the average, it's too easy to ignore. To learn more about latency-related issues and how to handle them correctly, you can read Gil Tene's blog here.

Conclusion: be mindful of the outliers, and you will know the last 1% of the system. (Not this 1%)

5. Reducing the allocation rate of new objects can improve the health of GC

We can roughly divide the objects in the system into three kinds: long-lived (long-lived) objects, we generally do not do anything about them; medium-Life (mid-lived) objects, the biggest problems may arise in this; ephemeral (short-lived) objects, which are often released and recycled quickly , it disappears when the next GC cycle arrives. Focusing on the distribution of medium-life objects can yield beneficial results, which are not so effective for short-lived and long-lasting objects. In addition, controlling a medium-life object is often a difficult task.

Conclusion: the pressure on the server is not simply the allocation of objects, the type of these objects in the course of operation is the source of all trouble.

6. Tuning can solve everything

If your program needs to save a large number of frequently modified states, tuning the JVM heap memory does not provide a good benefit. The longer GC pauses are unavoidable. One solution is to improve the architecture to ensure that there is not a lot of state in the process that has a decisive impact on the response time or creates a bottleneck. Large amounts of state and responsiveness are difficult to coexist, so separating them is the best choice.

Conclusion: not all problems can be solved by adjusting the JVM parameters, sometimes you just need to review your drawing board. (re-examine the design of the program)

7. GC logs can lead to significant system overhead

In simple terms, this is wrong, especially under the default log configuration. Log data is extremely valuable, and Java 7 also introduces hooks to control their size to ensure that hard disk space is not exhausted. If you do not collect GC logs, you will lose this almost unique method of knowing how the JVM garbage collector works in a production environment. The generally acceptable GC overhead is capped at 5%, which is trivial if you know the cost of the system for GC pauses and can take action to minimize the cost.

Conclusion: in the capacity range, as much as possible to obtain the system in the production environment of the operational data, you will find that it is a new world.

Summarize

Hopefully the above conclusions will help you to better grasp the work of the Java garbage collector. Have you had any similar problems in your program? Are there any other common misconceptions about GC around you? Please leave a comment in the comments section below.

original link: Javacodegeeks translation: Importnew.com - Chekiang Wu
translation Links: Http://www.importnew.com/15796.html

7 things that are misunderstood by Java Virtual Machine garbage collection