正如我们在上面文章提到的内容，在英文语境中上面 2 个方法还是有区别的，在中文环境下主要表达就是字符串压缩。
JDK 6 使用的压缩字符串方法，主要原因是我们修改了 String 的存储结构，char[]在 Java 的很多地方都会用到，并且 String 因为这个修改就只能接受使用char[]为参数的构造方法了。
在很多算法中，String 的操作又严重依赖char[]数组，如果我们进行这样修改的话，很多程序的代码都会需要跟着修改，这个显然是不划算的。
在后面我们使用的缩小字符串的处理方案来说也会有问题的，同样也会增加一些不少的问题，例如会导致一些方法修改为内部方法intrinsified同时一些 JIT compiler 编译的代码也需要进行改进。
因为存储方式的改变，也会有一些反人类的情况会出现：
LATIN-1 的indexOf(String)方法调用的是内部方法，但是indexOf(char)不是小的。
在 UTF-16 环境下，这 2 个方法都可以使用相同的内部方法，这个问题只会对 LATIN-1 字符集的 String 字符串有影响，并且也会在后续的版本中修正。
整体来说使用缩小字符串（ Compact String）的效率更高一些。
你可以将 Java 应用程序的 Heap 内存空间 dump 出来后进行分析，针对 String 的改进不会对你应用程序的提高产生非常显著的影响，如果你的程序有很多逻辑上面的问题，修改程序上面的逻辑问题比考虑如何使用 String 要实际得多。
但是对 JVM 来说这种提高还是有必要的。
让我们通过下面的一个简单的测试来看看启用缩小字符串（ Compact String）配置和不启用这个配置对性能产生的异同。
long startTime = System.currentTimeMillis(); List strings = IntStream.rangeClosed(1,10_000_000) .mapToObj(Integer::toString) .collect(toList()); long totalTime = System.currentTimeMillis() - startTime;System.out.println("Generated "+ strings.size() +" strings in "+ totalTime +" ms.");startTime = System.currentTimeMillis();Stringappended = (String) strings.stream() .limit(100_000) .reduce("",(l, r)->l.toString() + r.toString()); totalTime = System.currentTimeMillis() - startTime;System.out.println("Created string of length "+ appended.length() +" in "+ totalTime +" ms.");
在这里，我们首先使用一个基本的方法来创建 1千万个 String 字符串，然后使用默认开启的配置来看看上面的代码的输出：
Generated10000000strings in854ms.Createdstring of length488895in5130ms.
同样的，我们禁用 JVM 的这个参数-XX:-CompactStrings参数选项再来看看输出：
Generated10000000strings in936ms.Createdstring of length488895in9727ms.
通过上面的代码，我们可以看到上面 2 个参数修改后对比的输出并不是非常的明显，但是也可以看到有明确的性能提升。
