To those saying its not a memory leak, you are being very strict with the term. I, and others I know, have spent many man months of effort tracking down leaks due to this “general” use case.

Well, unfortunately, its not very general. The problem is that any substring used (or split string used) will keep the whole block. When splitting up large JMS text messages (for example) this will leave the entire message in memory, for an unspecified time.

It is a real problem that for a general algorithm you will get a leak like effect but not be warned of it in the javadocs.

User Beware.

As soon as you remove the substrings from the ArrayList all the memory that has been allocated for it will be freed. No memory leak there.

True for String(char[] value, int offset, int count), but not for String(int offset, int count, char[] value). The constructor you mention is a public constructor. The constructor that is called from the substring method is a package private constructor.

Thanks

String(char value[], int offset, int count)

It sets the value using this:

this.value = Arrays.copyOfRange(value, offset, offset+count);

The behavior is intentional – it trades memory for performance. As most things in the standard library (eg collections) it’s optimized for general usage and, well, generally it’s alright. But you certainly shouldn’t tokenize a really big string this way.

The classic type of memory leaks doesn’t exist in managed languages. The only thing we can produce are so called reference leaks. That is… referencing stuff (and thus preventing em from being GCed) for longer as necessary (or for all eternity).

Fortunately it’s easy to avoid – for the most part.

The important things to know:

Locally defined objects can be GCed as soon as there are no more no more references to it. Typically it’s the end of the block they are defined in (if you don’t store the reference anywhere). If you do store references, be sure to remove em if you don’t need em anymore.

If you overwrite a reference with a new object, the object is first created and /then/ the reference is overwritten, which means the object can be only GCed /after/ the new object has been created.

Usually this doesn’t matter. However, if you want to overwrite an object which is so big that it only fits once into the memory, you’ll need to null the reference before creating/assigning the new instance.

Eg:
//FatObject fits only once into memory
FatObject fatty;
fatty=new FatObject();
fatty=new FatObject();

Will bomb with OOME. Whereas…

FatObject fatty;
fatty=new FatObject();
fatty=null;
fatty=new FatObject();

Will be fine, because the second creation of the FatObject will trigger a full GC and the GC will be able to clear enough memory (since the old reference has been nulled).

Well, that rarely matters, but it’s good to know.