It stinks when you don’t throw away of the Garbage
Every java application, whether it is an one line ‘hello world’ application, or an online banking application with millions of users, needs Physical memory to run. And this memory has an upper limit (sorry, you can’t have the cake and eat it too) which is defined by the parameter –Xmx in the Java command line that starts the application.
Example:
Java –Xmx128m HelloWorld
In the above command, 128M is the maximum memory the HelloWorld application can have. This memory is called Heap and it lives in the memory available in the host operating system. As your program executes, it creates Objects, which occupy memory. JVM allocates this memory using available heap.
As the program continues to run, more and more objects are created and they start to fill up heap. Note that the programmer does not explicitly allocate or deallocate memory.
Periodically JVM invokes a process named Garbage Collector whose main mission is to reclaim memory used by ‘unused’ objects. ‘Unused’ objects mean they don’t have any live references. As long as the objects are being referenced somewhere, GC will NOT clear out the object.
The mechanics of GC are mostly hidden to the developers. You cannot force a GC. Only JVM knows when to run the GC and ‘how’ to run the GC.
In part2, I will explain some additional GC concepts you should learn. I will cover Generational help, PermGen space and Native memory.
Coming up: Troubleshooting GC: What is GC and how it works – Part 2
Previous: Troubleshooting GC: Introduction