Abstract: In this newsletter we show you a puzzle, where a simple request causes memory to be released, that otherwise could not. Solution will be shown in the next newsletter.
Welcome to the 173rd issue of The Java(tm) Specialists' Newsletter, sent to you from Zürich in Switzerland. This is the 12th week I'm away from Crete this year alone, with another 2 weeks away before the middle of June. So out of 26 weeks in the first half of 2009, I will have been away for 14, which is more than 50%. Due to the economic crisis, I fully expected at least half of my engagements to get cancelled, but that did not happen. Our Java Specialist Master Course and Design Patterns Course are just way too popular. HOWEVER, as from the middle of June, I'll be on "holiday" in Crete for a few months, coinciding with my kids 14 week school holiday. This will give me more time to think and produce some nice newsletters. Also, I am talking to a publisher to perhaps put together a book of my most popular newsletters, so you will have something to take to the beach.
javaspecialists.teachable.com: Please visit our new self-study course catalog to see how you can upskill your Java knowledge.
Instead of telling you some mystery of Java memory, it is
time for you to put on your thinking caps. I had a
discussion a few weeks ago with one of my subscribers of
whether you should null
your local
variables, to make things easier for the garbage collector.
His understanding was that the local variables will be stored
on the stack and thus popped off at the end of the method
call anyway, so nulling them was a waste of time. In almost
all situations, he is right. However, he had a class that
did something most peculiar, something like this:
public class JavaMemoryPuzzle { private final int dataSize = (int) (Runtime.getRuntime().maxMemory() * 0.6); public void f() { { byte[] data = new byte[dataSize]; } byte[] data2 = new byte[dataSize]; } public static void main(String[] args) { JavaMemoryPuzzle jmp = new JavaMemoryPuzzle(); jmp.f(); } }
When you run this you will always get an OutOfMemoryError,
even though the local variable data
is no longer
visible outside of the code block.
So here comes the puzzle, that I'd like you to ponder about a bit. If you very politely ask the VM to release memory, then you don't get an OutOfMemoryError:
public class JavaMemoryPuzzlePolite { private final int dataSize = (int) (Runtime.getRuntime().maxMemory() * 0.6); public void f() { { byte[] data = new byte[dataSize]; } for(int i=0; i<10; i++) { System.out.println("Please be so kind and release memory"); } byte[] data2 = new byte[dataSize]; } public static void main(String[] args) { JavaMemoryPuzzlePolite jmp = new JavaMemoryPuzzlePolite(); jmp.f(); System.out.println("No OutOfMemoryError"); } }
Why does this work? In my original newsletter, I asked my readers to send an answer. 400 emails later, I'd now prefer you to look at the next newsletter for the answer. Please contact me via my website if you have something new to add to the puzzle.
Heinz
We are always happy to receive comments from our readers. Feel free to send me a comment via email or discuss the newsletter in our JavaSpecialists Slack Channel (Get an invite here)
We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.