I was going through the String class API and looks like there is a potential memory leak caused by substring method as it shares same character array as original String.
In Java 7, String's subString is modified to :
/**
* Returns a new string that is a substring of this string. The
* substring begins with the character at the specified index and
* extends to the end of this string. <p>
* Examples:
* <blockquote><pre>
* "unhappy".substring(2) returns "happy"
* "Harbison".substring(3) returns "bison"
* "emptiness".substring(9) returns "" (an empty string)
* </pre></blockquote>
*
* @param beginIndex the beginning index, inclusive.
* @return the specified substring.
* @exception IndexOutOfBoundsException if
* <code>beginIndex</code> is negative or larger than the
* length of this <code>String</code> object.
*/
public String substring(int beginIndex) {
if (beginIndex < 0) {
throw new StringIndexOutOfBoundsException(beginIndex);
}
int subLen = value.length - beginIndex;
if (subLen < 0) {
throw new StringIndexOutOfBoundsException(subLen);
}
return (beginIndex == 0) ? this : new String(value, beginIndex, subLen);
}
Hence, everytime you do subString with beginIndex NOT equal to 0, we have new String Object.
There is a potential for a memory leak, if you take a substring of a sizable string and not make a copy (usually via the String(String)
constructor).
Note that this has changed since Java 7u6. See http://bugs.sun.com/view_bug.do?bug_id=4513622.
The original assumptions around the String
object implementing a flyweight pattern are no longer regarded as valid.
See this answer for more info.
It was the case until Java 7u6 - you would generally deal with the issue by doing:
String sub = new String(s.substring(...)); // create a new string
That effectively removes the dependency and the original string is now available for GC. This is by the way one of the only scenarios where using the string constructor makes sense.
Since Java 7u6, a new String is created and there is no memory issue any longer.