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)。