* Garbage Collection is an automatic memory management feature.
* The process of destroying unreferenced objects is called Garbage Collection.
* Once object is unreferenced it is considered as unused object, hence JVM automatically destroys that object.
* In java it is developers responsibility to create objects and unreference those objects after usage.
No, we can not force garbage collector to destroy objects , but we can request it.
* JVM internally uses a daemon thread called "garbage collector" to destroy all unreferenced objects.
* A daemon thread is a service thread. Garbage Collector thread is called daemon thread because it provides services to JVM to destroy unreferenced objects.
* This thread is low priority thread. Since it is a low priority thread we cannot guarantee its execution.
* No, we cannot guarantee objects destruction even though it is unreferenced, because we can not guarantee garbage collector's execution.
* So, we can confirm whether object is eligible for garbage collection or not.
Java Garbage Collection is the process to identify and remove the unused objects from the memory and free space to be allocated to objects created in the future processing. One of the best feature of java programming language is the automatic garbage collection, unlike other programming languages such as C where memory allocation and deallocation is a manual process.
Garbage Collector is the program running in the background that looks into all the objects in the memory and find out objects that are not referenced by any part of the program. All these unreferenced objects are deleted and space is reclaimed for allocation to other objects.
One of the basic way of garbage collection involves three steps:
1:Marking: This is the first step where garbage collector identifies which objects are in use and which ones are not in use.
2:Normal Deletion: Garbage Collector removes the unused objects and reclaim the free space to be allocated to other objects.
3:Deletion with Compacting: For better performance, after deleting unused objects, all the survived objects can be moved to be together. This will increase the performance of allocation of memory to newer objects.
There are two problems with simple mark and delete approach.
1:First one is that it’s not efficient because most of the newly created objects will become unused.
2:Secondly objects that are in-use for multiple garbage collection cycle are most likely to be in-use for future cycles too.
The above shortcomings with the simple approach is the reason that Java Garbage Collection is Generational and we have Young Generation and Old Generation spaces in the heap memory. I have already explained above how objects are scanned and moved from one generational space to another based on the Minor GC and Major GC.
* We have a method called gc() in system class as static method and also in Runtime class as non static method to request JVM to start garbage collector execution.
JVM internally uses "mark and swap" algorithm for destroying objects.
* Garbage Collector frees the memory occupied by the unreachable objects during the java program by deleting these unreachable objects.
* It ensures that the available memory will be used efficiently, but does not guarantee that there will be sufficient memory for the program to run.
An object becomes eligible for garbage collection when no live thread can access it.
Runtime.getRuntime().runFinalizersOnExit(boolean value). Passing the boolean value true or false in the mentioned method here will enable or disable the call to finalize() method.
The exception will be ignored and the garbage collection (finalization) of that object terminates.
There are five types of garbage collection types that we can use in our applications. We just need to use JVM switch to enable the garbage collection strategy for the application. Let’s look at each of them one by one.
Serial GC (-XX:+UseSerialGC):
Serial GC uses the simple mark-sweep-compact approach for young and old generations garbage collection i.e Minor and Major GC. Serial GC is useful in client-machines such as our simple stand alone applications and machines with smaller CPU. It is good for small applications with low memory footprint.
Parallel GC (-XX:+UseParallelGC):
Parallel GC is same as Serial GC except that is spawns N threads for young generation garbage collection where N is the number of CPU cores in the system. We can control the number of threads using -XX:ParallelGCThreads=n JVM option. Parallel Garbage Collector is also called throughput collector because it uses multiple CPUs to speed up the GC performance. Parallel GC uses single thread for Old Generation garbage collection.
Parallel Old GC (-XX:+UseParallelOldGC):
This is same as Parallel GC except that it uses multiple threads for both Young Generation and Old Generation garbage collection.
Concurrent Mark Sweep (CMS) Collector (-XX:+UseConcMarkSweepGC):
CMS Collector is also referred as concurrent low pause collector. It does the garbage collection for Old generation. CMS collector tries to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads. CMS collector on young generation uses the same algorithm as that of the parallel collector. This garbage collector is suitable for responsive applications where we can’t afford longer pause times. We can limit the number of threads in CMS collector using -XX:ParallelCMSThreads=n JVM option.
G1 Garbage Collector (-XX:+UseG1GC):
The Garbage First or G1 garbage collector is available from Java 7 and it’s long term goal is to replace the CMS collector. The G1 collector is a parallel, concurrent, and incrementally compacting low-pause garbage collector. Garbage First Collector doesn’t work like other collectors and there is no concept of Young and Old generation space. It divides the heap space into multiple equal-sized heap regions. When a garbage collection is invoked, it first collects the region with lesser live data, hence “Garbage First”. You can find more details about it at Garbage-First Collector Oracle Documentation.
All the Garbage Collections are “Stop the World” events because all application threads are stopped until the operation completes.
Since Young generation keeps short-lived objects, Minor GC is very fast and the application doesn’t get affected by this.
However Major GC takes longer time because it checks all the live objects. Major GC should be minimized because it will make your application unresponsive for the garbage collection duration. So if you have a responsive application and there are a lot of Major Garbage Collection happening, you will notice timeout errors.
The duration taken by garbage collector depends on the strategy used for garbage collection. That’s why it’s necessary to monitor and tune the garbage collector to avoid timeouts in the highly responsive applications.