"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."

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.

I would imagine that setting to NULL is unnecessary, because static analysis can tell the JVM or compiler whether the variable is used any more, and if it's not, it can be GC'ed, whether it's set to NULL or not. Setting to NULL is only valuable in refcounted GC implementations, and neither Java nor .NET use such a scheme.

static analysis can tell the JVM or compiler whether the variable is used any more, and if it's not, it can be GC'ed, whether it's set to NULL or not.

This is true, but only for local variables.

For fields, there may be cases where an object needs to be kept alive, but one of its fields can be discarded, so setting it to NULL is advantageous. Static analysis won't help there, taking into account Java has a reflection API. Indeed, though, such cases are probably rare, and a form of code smell in the first place.