Garbage Collection Is For Suckers!
Programming is fraught with pitfalls. The potential for errors to occur is high and unavoidable. Simple bugs, such as one-off errors1, can be committed by the most veteran software developer. If simple bugs are unavoidable, one can only imagine how difficult it would be to prevent more complex ones involving memory management.
Long ago, in a time when I wrote code in C and had to take care of allocating and freeing memory, it was a pain whenever a memory issue would occur that I had to debug. The problem was typically an issue with forgetting to free up unused memory or accidentally freeing up memory that had already been released. These problems are difficult to trace and harder to fix. Once a memory leak is determined, it has to be traced back to the portion of code that is allocating this memory. Next, you have to find where this memory segment is used and, more importantly, where it is no longer used in the execution path. Worse, if you release a portion of memory that is still being used, your program will certainly behave incorrectly and is vulnerable to being compromised. Imagine releasing a portion of memory that is still being used elsewhere in the program; this portion is later allocated and subsequently used. Now you have the same portion of memory being used for two different purposes and expected to contain different sets of data. This is certainly a recipe for corruption.
Are you a garbage man?
One of the reasons I was quick to adopt the Java language as my preferred programming language is the automated garbage collection feature offered. This liberates the me from having to deal with tracking memory usage. Memory management should be something that a programmer is aware of, but if it can be (partially) automated, it would increase a programmers productivity by eliminating a swath of bugs that could arise if memory management hand to be done manually. The garbage collector should be considered a tool in a programmer's arsenal to help get the job done.
I have heard many C programmers who mock Java programmers believing, that because Java takes care of memory management, C programmers are superior to their Java counterparts. The ability to effectively handle memory is not the end-all-and-be-all of a skilled programmer. Why leave the responsibility of memory management to programmers when it can be automated by the computer -- automation is what computers do! Essentially, Java removes the responsibility of memory management to the run-time environment and allows the developer to concentrate on other things, such as writing the software at-hand. If a significant portion of a programmer's time is dedicated to handling and fixing memory issues, then programmers become glorified garbage men cleaning up unused memory areas. Wouldn't automating this mundane task be more productive than having to deal with it manually?
Manual memory management is a tricky endeavour: tracking memory allocations; where it is being used; when it is no longer being used; and safely releasing it back to the system. If a portion of memory is being used in multiple places, tracking how many places are using it requires keeping count and only releasing the memory when this count is zero. Determining when the count is zero implies that checks need to be made periodically to see if the count has reached zero. Well, the garbage collection facility in Java provides this out-of-the-box, so developers don't have to code these functions. The developer has to give up some control of when these checks are performed and when clean-up occurs, but in the majority of cases this is a small price to pay for not having to manage memory manually.
Not a cure-all
The garbage-collection feature in Java does not exempt Java code from memory leaks. It also does not give carte-blanche permission to programmers to create objects with wanton abandonment. Java code can still be written in such a way that memory can be allocated for an object and never released during the execution lifetime of the application. This type of memory leak can be just as detrimental, especially for long-running applications that run as services. Memory leaks can happen especially in the case of static variables. Static variables endure for the duration of the application, so any objects referenced by static variables will exist for the equivalent amount of time. For instance, if your code contains a static variable that is a list, or map, or a composite object that can accumulate other objects, it is possible for a memory leak to occur if objects are added to these containers but none are never removed. As more objects are added while the application runs, more memory is allocated to hold these objects that are never garbage-collected and, eventually, memory will be exhausted holding these objects in memory.
Make life simple
So garbage collection does not exempt a programmer from considering memory issues, but it does diminish the programmer's role as a garbage collector. So pooh-pooh to those who would frown upon using garbage collection -- if they want to take away their own garbage, then so be it. I would prefer to just leave it on the curbside for pick up, thank you.
