Linked by Thom Holwerda on Fri 14th Sep 2012 02:30 UTC, submitted by MOS6510
Java "As a typical Java developer I never monitored the memory usage of my application apart from following typical best practices like closing the connections, streams etc. Recently we were struck with few issues in our JBoss servers that I had to dig in to the memory management."
Permalink for comment 535089
To read all comments associated with this story, please click here.
RE[4]: Memory management
by raboof on Fri 14th Sep 2012 17:52 UTC in reply to "RE[3]: Memory management"
Member since:

I can't see how these things (recycling objects and using stack, like setting references to null when the object they refer to is no longer needed) can cause more harm than good (regardless of language or VM).

I agree with moondevil that these kinds of 'optimizations' are a really bad idea.

The most important reason is they will make your code more complicated, and thus harder to maintain and more likely to contain bugs.

Recycling objects: this might be useful in languages where the construction of an object corresponds directly to a malloc call. Java's memory manager is smarter than that, so creating and destroying many objects is not really a performance problem (anymore - this used to be slow on older JVM's, like 1.4 old).

Stack: not a bad idea per se, but won't help much as Java only holds primitives on the stack, not objects. It's still a good idea to prefer local variables to fields, but for other reasons than performance.

Setting references to null: This might be useful in a situation where you have a mutable reference to a big data structure which you don't need anymore after a certain point. Such situations should be rare, and I'd suspect the code could/should be refactored in another way that would prevent the big structure to be kept alive for too long.

Of course it's hard to talk about such things without concrete examples, and I'm not giving any either, but I hope this provides some ideas.

Reply Parent Score: 4