原文链接 作者：baeldung 译者：Reion Chan
概述
字符串在 Java 的 String 类内部由一个包含该字符串中所有字符的 char[] 来表示，其中的每个字符 char 又是由 2 个字节组成，因为 Java 内部使用 UTF-16。举例来说，如果一个字符串含有英文字符，那么这些英文字符的前 8 比特都将为 0，因为一个ASCII字符都能被单个字节来表示。
当然有许多字符需要 16 比特，但从统计角度来说只需 8 比特的情况占大多数，例如：LATIN-1 ，因此这能成为一种改善内存占用及性能的一个机会。更重要的是：由于 JVM 存储字符串的方式导致 JVM 堆空间通常很大一部分都被字符串所占据。
大多数情况下，字符串实例常占用比它实际需要的内存多一倍的空间。
在此篇文章中，我们将讨论 JDK 6 引入的可选的 Compressed String 功能及 JDK 9 最新引入的 Compact String ，它们两者的设计目的都是优化字符串在 JVM 中的内存占用。
Compressed String - Java 6
JDK 6 update 21 版本中引入了一个新的虚拟机参数选项：
-XX:+UseCompressedStrings
当此选项启用时，字符串将以 byte[] 的形式存储，代替原来的 char[]，因此可以节省一些内存。然而，此功能最终在 JDK 7 中被移除，主要原因在于它将带来一些无法预料的性能问题。
Compact String - Java 9
Java 9 重新采纳字符串压缩这一概念。
这意味着无论何时我们创建一个所有字符都能用一个字节的 LATIN-1 编码来描述的字符串，都将在内部使用字节数组的形式存储，且每个字符都只占用一个字节。另一方面，如果字符串中任一字符需要多于 8 比特位来表示时，该字符串的所有字符都统统使用两个字节的 UTF-16 编码来描述。因此基本上能如果可能，都将使用单字节来表示一个字符。
现在的问题是：所有的字符串操作如何执行？ 怎样才能区分字符串是由 LATIN-1 还是 UTF-16 来编码？为了处理这些问题，字符串的内部实现进行了一些调整。引入了一个 final 修饰的成员变量 coder, 由它来保存当前字符串的编码信息。
Java 9 中字符串的实现
之前，字符串都是以字符数组来存储：
private final char[] value;
现在，它将使用字节数组来存储了：
private final byte[] value;
成员变量 coder 的声明：
private final byte coder;
coder 可以被赋值为如下的常量：
static final byte LATIN1 = 0;
static final byte UTF16 = 1;
现在，大多数的字符串操作都将检查 coder 变量，从而采取特定的实现：
public int indexOf(int ch, int fromIndex) {
return isLatin1()
? StringLatin1.indexOf(value, ch, fromIndex)
: StringUTF16.indexOf(value, ch, fromIndex);
}
private boolean isLatin1() {
return COMPACT_STRINGS && coder == LATIN1;
}
所有 JVM 需要的信息都准备就绪，虚拟机参数 CompactString 默认是被启用的，如果想要关闭它，可以使用如下启动参数：
+XX:-CompactStrings
coder 的作用
Java 9 中字符串长度计算是按如下方式实现的：
public int length() {
return value.length >> coder;
}
如果字符串只包含 LATIN-1编码的字符，coder 变量的值将为 0，因此字符串的长度就为字节数组的长度一致，否则 coder 变量的值为1，采用 UTF-16 编码，那么字符串的长度为字节数组长度的一半。
注意，所有因为采用 Compact String 技术而做出的改变，都单单存在于 String 类内部实现，因此对使用 String 类的开发者而言此种改变是完全透明的。
Compact Strings VS Compressed Strings
JDK 6 的 Compressed Strings ，主要的问题在于 String 类的构造方法只接受 char[ ] 类型的参数，因此许多字符串的操作方法都依赖于字符数组的表现形式，而非字节数组。介于此，很多的方法都需将压缩后的字节数组解压缩为字符数组，无形中影响了性能。
然而，JDK 9 的 Compact Strings ，维护额外的 coder 字段也会新增一些开销，为了缓和 coder 及 bytes 解压为 chars（针对 UTF-16编码的情形） 所带来的开销，一些方法都被内置化，由 JIT 编译器产生的汇编代码也将被优化改进。
这些改变也会带来一些反常规的结果。LATIN-1 编码的字符串的 indexOf(String) 方法能够调用内置化方法，而 indexOf(char) 方法却不能。 UTF-16 编码的字符串的这两种方法都能够调用内置化方法。这个问题只出现在 LATIN-1 编码的字符串中，会在将来的版本中被修复。
因此， Compact Strings 在性能方面要优于 Compressed Strings 。 许多的 Java 堆转存工具都可以用来分析采用 Compact Strings 技术后究竟能节省多少内存。当然结果严重依赖具体的应用，总体而言改善还是相当可观的。
性能差异
让我们通过一个非常简单的例子来观察开启与关闭 Compact Strings 时的性能差异：
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();
String appended = (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 千万个字符串，并且以简单的方式合并这些字符串。
运行这段代码后（默认开启了 Compact Strings），我们得到如下的输出：
Generated 10000000 strings in 854 ms.
Created string of length 488895 in 5130 ms.
类似的，如果我们通过 -XX:-CompactStrings 参数禁用 Compact Strings 得出如下输出：
Generated 10000000 strings in 936 ms.
Created string of length 488895 in 9727 ms.
显然，此项测试非常浅陋，并没有很高的代表性。它只能反映出，在某些场景下采用这种新技术确实能改善程序的性能。
总结
在此教程中，我们看到了 JDK 9 在 JVM 层面上，通过更有效的字符串存储方式来达到优化性能及内存占用的尝试。像以往一样，所有的代码可以在Github获取到。
