A list of selected anti-patterns provides real world examples on how to screw up with memory management in Java. Memory Leaks and other memory related problems are among the most prominent performance and scalability problems in Java. Reason enough to discuss this topic in more detail. The Java memory model- or more specifically the garbage collector – has solved many memory problems. At the same time new ones have been created. Especially in J EE Environments with a large number of parallel users, memory is more and more becoming a critical ressource. In times with cheap memory available, 64bit JVMs and modern garbage collection algorithms this might sound strange at first sight. So let us now take a closer look at Java memory problems. Learn more at http://blog.dynatrace.com/2009/08/13/java-memory-problems/

Couple of nits: The description of memory leaks here is not compatible with the classic CS definition of a memory leak. A more proper term is space leak. If an object cannot be collected, it's reachable. In order for an object to be leaked, it must be unreachable. "This behaviour is also referred to as GC trashing." I think you mean 'thrashing' here. Perhaps this is a typo. There is also a case where 'hundred' is misspelled as 'hundret'. In the Large Temporary Objects, section, you don't really offer any solution. In many cases like this and specifically the case you mention, the best choice is to put whatever is in the buffer to an output stream. This limits the memory usage of that part of the code to the buffer (nominally).

Couple of nits:

The description of memory leaks here is not compatible with the classic CS definition of a memory leak. A more proper term is space leak. ... I think you mean 'thrashing' here. Perhaps this is a typo. There is also a case where 'hundred' is misspelled as 'hundret'.

omfg someone plox call grammar, or even bettar, care police... James, as TSS poster, is fully compatible with classic definition of care police.

omfg someone plox call grammar, or even bettar, care police...

James, as TSS poster, is fully compatible with classic definition of care police.

Don't you ever get tired of being such a dork?

James, I agree that this is not the "classical" memory leak as known by C++ developers. You cannot leak memory that way. Actually it is always about "forgotten" objects Regarding the temporary objects creation stuff: In the case I stated creating a bigger initial array would have helped. You can also properly configure the Garbage Collector to better handle these situation with e.g. large Eden spaces or by using TLABs.

Regarding the temporary objects creation stuff: In the case I stated creating a bigger initial array would have helped. You can also properly configure the Garbage Collector to better handle these situation with e.g. large Eden spaces or by using TLABs.

Sure that will decrease the amount of objects being generated and the memory needed to an extent but the solution I'm proposing reduces to a much greater extent and in addition: 1. Limits the memory usage to consistent known amount of your choosing. 2. Will generally perform faster over all. Consider 10MB PDF. If you put the entire PDF into an array, you must allocate at least 10 megs. If you flush the buffer to the client instead, you limit the memory usage to 1K or whatever you choose for your buffer. This also tends to make things faster because you aren't waiting until you've read the last byte to start sending the first one.

Got your point know. Direct flushing in the case described definitely makes the most sense. In case you do not need the data for further processing.