Garbage Collection in java

Garbage Collection

Garbage collection is a very common and interesting question in interviews. Many times interviewer will ask to explain “How garbage collection works? “ What are the algorithms it usages etc question you might have heard.

let me explain to you with real-time example. Usually we go to some restaurant in free time in evening with family. At hotel waiter clean the table and pick the garbage from the table and make it available for new customer.

Assume you are Object , restaurant is JVM and waiter is thread who clean the table and available for new customer.

Now with real -time example we have understand What is Garbagee Collector, In Computer language Garbage Collector is a Daemon thread that keeps running in the background. Basically, it frees up the heap memory by destroying the unreachable objects.

Types of Garbage Collectors

The Serial Collector

The single threaded systems and small heap size. It freezes all applications while working. Can be turned on using -XX:+UseSerialGC JVM option.

Parallel/Throughput GC

This is the JVM’s default collector. This uses multiple threads to scan through and the heap. The downside to the parallel collector is that it will stop application threads when performing either a minor or full GC collection.

It is best suited if applications that can handle such pauses, and try to optimize CPU overhead caused by the collector

The CMS Collector

CMS collector (“concurrent-mark-sweep”) algorithm uses multiple threads (“concurrent”) to scan through the heap (“mark”) for unused objects that can be recycled (“sweep”).

This algorithm Stop the World in two places:-

• when initializing the initial marking of roots objects in the old generation that are reachable from thread entry points or static variables
• when the application has changed the state of the heap while the algorithm was running concurrently, forcing it to go back and do some final touches to make sure it has the right objects marked.

This collector may face promotion failures. If some objects from young generation are to be moved to the old generation, and the collector did not have enough time to make space in the old generation space, a promotion failure will occur. To overcome this usually provide more heap size to the old generation space.

G1 collector

The Garbage first collector (G1) introduced in JDK 7. This was designed for better support of heaps larger than 4GB. The G1 collector utilizes multiple background threads to scan through the heap that it divides into regions, spanning from 1MB to 32MB (depending on the size of your heap). G1 collector is geared towards scanning those regions that contain the most garbage objects first, giving it its name (Garbage first). This collector is turned on using the –XX:+UseG1GC flag.

This strategy reduced the chance of the heap being depleted before background threads have finished scanning for unused objects, in which case the collector will have to stop the application which will result in a Stop The World(STW) collection. The G1 also has another advantage that is that it compacts the heap on-the-go, something the CMS collector only does during full STW collections.

Large heaps have been a fairly contentious area over the past few years with many developers moving away from the single JVM per machine model to more micro-service, componentized architectures with multiple JVMs per machine. This has been driven by many factors including the desire to isolate different application parts, simplifying deployment and avoiding the cost which would usually come with reloading application classes into memory (something which has actually been improved in Java 8).

Java 8 PermGen and Metaspace

One of the biggest changes made in Java 8 was removing the permgen part of the heap that was traditionally allocated for class meta-data, interned strings and static variables. This would traditionally require developers with applications that would load significant amount of classes (something common with apps using enterprise containers) to optimize and tune for this portion of the heap specifically. This has over the years become the source of many OutOfMemory exceptions, so having the JVM (mostly) take care if it is a very nice addition. Even so, that in itself will probably not reduce the tide of developers decoupling their apps into multiple JVMs.

Most of the allocations for the class metadata are made out of the native memory. There is a new flag MaxMetaspaceSize, to limit the amount of memory used for class metadata. If we do not specify the value for this, the Metaspace re-sizes at runtime as per the demand of the running application.

Metaspace garbage collection is triggered when the class metadata usage reaches MaxMetaspaceSize limit. Excessive Metaspace garbage collection may be a symptom of classes, classloaders memory leak or inadequate sizing for our application.