Java Performance Tuning Guide中看到的: http://java-performance.info/inefficient-byte-to-string-constructor/
大致是传递byte array,offset,len, 还有charset时其在内部会arrays.copyOf整个数组(而不是那个slice),这样如果数组本身很大,slice很小,byte array很大时造成很大的性能浪费。我的mac上装的是sun jdk 1.6.0_65,还有一台服务器sun jdk 1.6.0_26,使用文中的StringConstructorTest均检查倒该问题，这个测试差别会非常明显，前后花费时间至少差7，8倍。不过我下的open jdk 1.6较新的版本已经修复这个问题，jdk7就没这个问题了。
在测试docvalues加载时间时我也发现这个问题，如果bytearray超过1M，会非常慢，实际字符串平均的slice也就13字节，但不同于StringConstructorTest，在数组为4K时没有明显的的性能差别，看起来实际的encoding应该是这样(StringConstructorTest中用的是一个0填充数组，外加一个5)。
Sun JDK 1.6中String Constructor的一个bug,布布扣,bubuko.com
Sun JDK 1.6中String Constructor的一个bug
原文：http://blog.csdn.net/jollyjumper/article/details/24270965