关于JDK中subString()尴尬的小故事

先来看一篇文章：

传送门：http://www.jointforce.com/jfperiodical/article/4070?ref=myread

Java中的substring真的会引起内存泄露么？
androidyue · 2017-01-20 12:02

在Java中开发，String是我们开发程序可以说必须要使用的类型，String有一个substring方法用来截取字符串，我们想必也常常使用。但是你知道么，关于Java 6中的substring是否会引起内存泄露，在国外的论坛和社区有着一些讨论，以至于Java官方已经将其标记成bug，并且为此Java 7 还重新进行了实现。读到这里可能你的问题就来了，substring怎么会引起内存泄露呢？那么我们就带着问题，走进小黑屋，看看substring有没有内存泄露，又是怎么导致所谓的内存泄露。

基本介绍
substring方法提供两种重载，第一种为只接受开始截取位置一个参数的方法。
1
public String substring(int beginIndex)

比如我们使用上面的方法，”unhappy”.substring(2) 返回结果 “happy”

另一种重载就是接受一个开始截取位置和一个结束截取位置的参数的方法。
1
public String substring(int beginIndex, int endIndex)

使用这个方法，”smiles”.substring(1, 5) 返回结果 “mile”

通过这个介绍我们基本了解了substring的作用，这样便于我们理解下面的内容。

准备工作

因为这个问题出现的情况在Java 6，如果你的Java版本号不是Java 6 需要调整一下。

终端调整（适用于Mac系统）

查看java版本号
1
2
3
4
13:03 $ java -version
java version “1.8.0_25”
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

切换到1.6
1
export JAVA_HOME=$(/usr/libexec/java_home -v 1.6)

Ubuntu使用alternatives –config java，Fedora上面使用alternatives –config java。

如果你使用Eclipse，可以选择工程，右击，选择Properties（属性）— Java Compiler（Java编译器）进行特殊指定。

问题重现

这里贴一下java官方bug里用到的重现问题的代码。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class TestGC {
private String largeString = newString(newbyte[100000]);

String getString() {
    returnthis.largeString.substring(0,2);
}

public static void main(String[] args) {
    java.util.ArrayList list = newjava.util.ArrayList();
    for(int i = 0; i < 1000000; i++) {
        TestGC gc = newTestGC();
        list.add(gc.getString());
    }
}

}

然而上面的代码，只要使用Java 6 （Java 7和8 都不会抛出异常）运行一下就会报java.lang.OutOfMemoryError: Java heap space的异常，这说明没有足够的堆内存供我们创建对象，JVM选择了抛出异常操作。

于是有人会说，是因为你每个循环中创建了一个TestGC对象，虽然我们加入ArrayList只是两个字符的字符串，但是这个对象中又存储largeString这么大的对象，这样必然会造成OOM的。

然而，其实你说的不对。比如我们看一下这样的代码,我们只修改getString方法。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class TestGC {
private String largeString = newString(newbyte[100000]);

String getString() {
    //return this.largeString.substring(0,2);
  returnnew String("ab");
}

public static void main(String[] args) {
    java.util.ArrayList list = newjava.util.ArrayList();
    for(int i = 0; i < 1000000; i++) {
        TestGC gc = newTestGC();
        list.add(gc.getString());
    }

}

}

执行上面的方法，并不会导致OOM异常，因为我们持有的时1000000个ab字符串对象，而TestGC对象（包括其中的largeString）会在java的垃圾回收中释放掉。所以这里不会存在内存溢出。

那么究竟是什么导致的内存泄露呢？要研究这个问题，我们需要看一下方法的实现，即可。

深入Java 6实现

在String类中存在这样三个属性

1、value 字符数组，存储字符串实际的内容
2、offset 该字符串在字符数组value中的起始位置
3、count 字符串包含的字符的长度

Java 6中substring的实现
1
2
3
4
5
6
7
8
9
10
11
12
13
public String substring(int beginIndex, int endIndex) {
if(beginIndex < 0) {
thrownew StringIndexOutOfBoundsException(beginIndex);
}
if(endIndex > count) {
thrownew StringIndexOutOfBoundsException(endIndex);
}
if(beginIndex > endIndex) {
thrownew StringIndexOutOfBoundsException(endIndex - beginIndex);
}
return((beginIndex == 0) && (endIndex == count)) ? this:
newString(offset + beginIndex, endIndex - beginIndex, value);
}

上述方法调用的构造方法
1
2
3
4
5
6
//Package private constructor which shares value array for speed.
String(int offset, int count, char value[]) {
this.value = value;
this.offset = offset;
this.count = count;
}

当我们读完上述的代码，我们应该会豁然开朗，原来是这个样子啊！

当我们调用字符串a的substring得到字符串b，其实这个操作，无非就是调整了一下b的offset和count，用到的内容还是a之前的value字符数组，并没有重新创建新的专属于b的内容字符数组。

举个和上面重现代码相关的例子，比如我们有一个1G的字符串a，我们使用substring(0,2)得到了一个只有两个字符的字符串b，如果b的生命周期要长于a或者手动设置a为null，当垃圾回收进行后，a被回收掉，b没有回收掉，那么这1G的内存占用依旧存在，因为b持有这1G大小的字符数组的引用。

看到这里，大家应该可以明白上面的代码为什么出现内存溢出了。

共享内容字符数组

其实substring中生成的字符串与原字符串共享内容数组是一个很棒的设计，这样避免了每次进行substring重新进行字符数组复制。正如其文档说明的,共享内容字符数组为了就是速度。但是对于本例中的问题，共享内容字符数组显得有点蹩脚。

如何解决

对于之前比较不常见的1G字符串只截取2个字符的情况可以使用下面的代码，这样的话，就不会持有1G字符串的内容数组引用了。
1
String littleString = newString(largeString.substring(0,2));

下面的这个构造方法，在源字符串内容数组长度大于字符串长度时，进行数组复制，新的字符串会创建一个只包含源字符串内容的字符数组。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public String(String original) {
int size = original.count;
char[] originalValue = original.value;
char[] v;
if(originalValue.length > size) {
// The array representing the String is bigger than the new
// String itself. Perhaps this constructor is being called
// in order to trim the baggage, so make a copy of the array.
int off = original.offset;
v = Arrays.copyOfRange(originalValue, off, off+size);
}else{
// The array representing the String is the same
// size as the String, so no point in making a copy.
v = originalValue;
}
this.offset = 0;
this.count = size;
this.value = v;
}

Java 7 实现

在Java 7 中substring的实现抛弃了之前的内容字符数组共享的机制，对于子字符串（自身除外）采用了数组复制实现单个字符串持有自己的应该拥有的内容。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public String substring(int beginIndex, int endIndex) {
if(beginIndex < 0) {
thrownew StringIndexOutOfBoundsException(beginIndex);
}
if(endIndex > value.length) {
thrownew StringIndexOutOfBoundsException(endIndex);
}
int subLen = endIndex - beginIndex;
if(subLen < 0) {
thrownew StringIndexOutOfBoundsException(subLen);
}
return((beginIndex == 0) && (endIndex == value.length)) ? this
:newString(value, beginIndex, subLen);
}

substring方法中调用的构造方法，进行内容字符数组复制。
1
2
3
4
5
6
7
8
9
10
11
12
13
public String(char value[], int offset, int count) {
if(offset < 0) {
thrownew StringIndexOutOfBoundsException(offset);
}
if(count < 0) {
thrownew StringIndexOutOfBoundsException(count);
}
// Note: offset or count might be near -1>>>1.
if(offset > value.length - count) {
thrownew StringIndexOutOfBoundsException(offset + count);
}
this.value = Arrays.copyOfRange(value, offset, offset+count);
}

真的是内存泄露么

我们知道了substring某些情况下可能引起内存问题，但是这个叫做内存泄露么？

其实个人认为这个不应该算为内存泄露，使用substring生成的字符串b固然会持有原有字符串a的内容数组引用，但是当a和b都被回收之后，该字符数组的内容也是可以被垃圾回收掉的。

哪个版本实现的好

关于Java 7 对substring做的修改，收到了褒贬不一的反馈。

个人更加倾向于Java 6的实现，当进行substring时，使用共享内容字符数组，速度会更快，不用重新申请内存。虽然有可能出现本文中的内存性能问题，但也是有方法可以解决的。

Java 7的实现不需要程序员特殊操作避免了本文中问题，但是进行每次substring的操作性能总会比java 6 的实现要差一些。这种实现显得有点“糟糕”。

问题的价值

虽然这个问题出现在Java 6并且Java 7中已经修复，但并不代表我们就不需要了解，况且Java 7的重新实现被喷的很厉害。

其实这个问题的价值，还是比较宝贵的，尤其是内容字符数组共享这个优化的实现。希望可以为大家以后的设计实现提供帮助和一些想法。

受影响的方法

trim和subSequence都存在调用substring的操作。Java 6和Java 7 substring实现的更改也间接影响到了这些方法。

参考资源

以下三篇文章写得都比较不错，但是都稍微有一些问题，我都已经标明出来，大家阅读时，需要注意。

The substring() Method in JDK 6 and JDK 7 本文中解决java6中问题提到的字符串拼接不推荐，具体原因可以参考Java细节：字符串的拼接
How SubString method works in Java – Memory Leak Fixed in JDK 1.7 本文中提到的有一个概念错误，新的字符串不会阻止旧的字符串被回收，而是阻止旧字符串中的内容字符数组。阅读时需要注意。
JDK-4513622 : (str) keeping a substring of a field prevents GC for object 本文中提到的有一个测试，使用非new的形式有一点问题，其忽视了字符串常量池的存在，具体查看下面的注意。

============================
以上是别人写的文章

这里我要说的是，subString()由JDK6到JDK7的改动就是将原先的浅拷贝变成深拷贝，目的就是防止用户不规范的编码导致内存泄露，看似用心良苦，实则在打脸。为什么要这么说？

先来看看JDK8里面ArrayList对List接口的subList方法的实现：

public List subList(int fromIndex, int toIndex) {
subListRangeCheck(fromIndex, toIndex, size);
return new SubList(this, 0, fromIndex, toIndex);
}

SubList(AbstractList parent,
int offset, int fromIndex, int toIndex) {
this.parent = parent;
this.parentOffset = fromIndex;
this.offset = offset + fromIndex;
this.size = toIndex - fromIndex;
this.modCount = ArrayList.this.modCount;
}
上面代码看出来，其实subList也是浅拷贝，和JDK6的subString的做法是一致的，
换句话说，如果subList使用不当也会造成内存泄露。这是JDK6以前对sub**方法的传统都是浅拷贝，只要稍微注意就好。

由于社区有人觉得这锅要官方解决，官方也是乖，就在JDK7把subString变成深拷贝，而subList依然是浅拷贝。

导致的结果就是，subList依然是当年的subList，而subString已经物是人非了。
至于我为什么发觉这个问题呢？因为我本来是一个比较懒得人，我看过subList的源码，没看过subString的源码，我会推测subList是浅拷贝，subString应该也是浅拷贝，这是合理的做法。然后现在我再也不能那么轻狂的自以为是了，遇到没把握的还是得看看源码，能少一个坑是一个。