Our of Memory on Memorial Day

I ran into some java.lang.OutOfMemoryError: Java heap space over this Memorial Day weekend. That's quite a coincidence. Actually, it can happen on any day, especially at night from my experience.

It's also a popular Java job interview question: why are there memory leaks in Java programs? Isn't Java supposed to automatically manage memory and garbage collection? How do you debug and solve it? Number one cause of memory leak is these dying objects are still referenced by other long-living objects. This is a simple program to reproduce java.lang.OutOfMemoryError:

package com.javahowto.test;
import java.util.Map;
import java.util.HashMap;

public class MemoryHog {
public static final Map threadMap = new HashMap();

public static void main(String[] args) {
MemoryHog hog = new MemoryHog();
for(int i = 0; ; i++) {

private void work(String id) {
Thread thread = new Thread(){
public void run() {
//@TODO: do some work
System.out.println("Current thread map size: " + threadMap.size());
threadMap.put(id, thread);
Running with default JVM options (heap size 64m), MemoryHog crashes when the pool size reaches 296,733. Various solutions are available:
  • Application designers will get rid of the pooling, or implement it correctly such that it reuses threads and set pool's initial size, max size, incremental size, and eviction policy. MemoryHog runs happily ever after.

  • Coders will just change the HashMap to java.util.WeakHashMap, and MemoryHog runs happily ever after.

  • Hackers will bump up heap size, with JVM option -Xmx128m. MemoryHog runs happily until the pool size grows to 592,646. Then keep doubling the heap size to make MemoryHog happy.


Anonymous said...

So what is your point, then, exactly? That there _is_ some beast out there called "unintentional object retention"? Nothing quite new, I'd say.

howto said...

Thanks for the comment, maik. You are absolutely right. This is not about a new discovery; it's my experience and thoughts on an interesting issue. Even AJAX is not new either.

Anonymous said...

This is one good example of where small code fragments fail to tell you the true story. Memory leaks in any significant Java are almost never easy to find. This is because they are buried in a sea of complexity that just comes when you have large things. It is much easier to find a needle when all the Hay is gone.

howto said...

Thanks for the comments. My intention was to showcase this java memory issue in its simplistic form, cause the "true story" is ugly and nobody has patience for it. This is where a good profiler tool comes into play. Hunting down memory leaks is not hard, it's just tedious and requires attention to details and a lot of trial-and-error.

Anna said...

Great and Useful Article.

Online Java Course

Java Online Training

Java Course Online

J2EE training

online J2EE training

Best Recommended books for Spring framework

Java Interview Questions

Java Training Institutes in Chennai

Java Training in Chennai

J2EE Training in Chennai

java j2ee training institutes in chennai

Unknown said...

This is a great web site. Good sparkling user interface and very informative blogs. I will be coming back in a bit, thanks for the great article. I have found it enormously useful.

Jack sparrow said...

That is nice article from you , this is informative stuff . Hope more articles from you . I also want to share some information about online devops training and devops online training