# Java 9 中的字符串（String）压缩 **URL:** \ **Category:** 程序语言\ **Tags:** java\ **Created:** [July 2, 2022, 1:26pm UTC](https://www.isharkfly.com/t/java-9-string/14024 "2022-07-02T13:26:43Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![honeymoose](https://www.isharkfly.com/user_avatar/www.isharkfly.com/honeymoose/32/20796_2.png) [@honeymoose](https://www.isharkfly.com/u/honeymoose)\ **Post date:** [July 2, 2022, 1:26pm UTC](https://www.isharkfly.com/t/java-9-string/14024/1 "2022-07-02T13:26:43Z")
我们都知道 Strings 在 Java 中使用 _char[]_ 数组来实现的。 ![f506a5a5b137c8eded8ab625bf113fa4](https://cdn.isharkfly.com/com-isharkfly-www/discourse-uploads/original/2X/0/030e0a7f70c4c3403356bd22831b194037ccb416.png) 每一个 _char[]_ 数组中的元素将会使用 2 个字节（byte）的存储空间，这是因为 Java 最初的实现使用 UTF-16 字符集。 如果你不需要存储其他语言，你的语言只有英文，或者 ASCII 码就可以满足的情况下，Java String 使用的 _char[]_ 数组中存储的字符元素还是会使用 UTF-16 字符集，那么就会导致存储一个字符的时候，我们使用了 2 字节，16 位。但是，因为我们又全是存储为16 位，那么存储的这个字符的前 8 位全部都会为 0。 因为 ASCII 使用单字节存储，这明显是一个存储空间的浪费。 实际上，很多字符存储都需要使用 2 字节，比如 UTF-8，比如 GBK，但是针对因为和 拉丁文 LATIN-1 使用 1 个字节的存储就够了，很显然这里有一个可以改进的空间。 在 JDK 9 之前，Java 不管什么字符都一股脑的使用 2 字节存储，在 JDK 9 以后，Java 对这里进行了改进。 同时我们知道 Java 是使用 String Pool 来存储的，String Pool 通常使用了 JVM 的 heap 内存空间，Heap 内存空间又是 JVM 垃圾清理程序活动的地方。 在老的设计中，String 占用了 2 个字节，但是很多时候可能用不到，如果我们对这里进行了改进的话，我们也能提高垃圾清理程序的工作量。 显然这个是需要重新考虑的问题。 在本页面中，我们将会讨论在 JDK 6 中使用的 Java String 的压缩选项和在 JDK 9 中使用的新的方法。 这 2 种方法主要目的就是为了降低 String 在 JVM 中内存消耗，提供空间利用率。 ## Java 6 压缩字符串（Compressed String） JDK 考虑开始对字符串进行优化是从 Java 6 开始的。 从 JDK 6 update 21 版本更新开始，我们可以为 JVM 添加下面的参数: ```auto -XX:+UseCompressedStrings ``` 上面参数的主要目的就是将 String 存储使用的 _char[]_ 数组修改为 _byte[]_ 数组。 简单来说就是存储粒度更小，能够提供更多的空间利用率。 但是， **这个参数在 JDK 7 后被移除了** ，主要原因可能是因为修改了存储结构导致的一些不可以预料的情况。 ## Java 9 缩小字符串（ Compact String） 从 Java 9 开始，JDK 开始引入了一个叫做 缩小字符串（ Compact String）。 ![e8b028d918b8593194f2b939be1cdfd9383ec54a](https://cdn.isharkfly.com/com-isharkfly-www/discourse-uploads/original/2X/7/7e23c559fdc210b02da5fa2f83d4529cdc43be84.png) 在中文语境下，压缩和缩小都是削减的意思，很多时候是可以通用的，但是实际上还是有区别的。 JDK 9 的处理方式是不改变字符串存储使用的 _char[]_ 数组，而是根据字符集来进行处理。 当 String 在创建的时候，如果我们知道这个字符集使用的 LATIN-1 来表示的话，我们就使用一个字节来存储。 如果是中文，或者我们知道不能用 1 个字节来存储的话，我们还是使用 2 个字节来存储，与原来的存储方式保持一致。 换句话说就是尝试用 1 个字节来存储我们可以存储的自己，而不再浪费存储空间。 现在我们需要知道的问题就是，针对 String 的操作是不是会因为这种存储格式的改变而有影响呢，因为我们在数组中存储了 2 个字符集， LATIN-1 和 UTF-16 字符集之间的混合操作是不是会受到改变？ 本文章的后续部分就对这种情况进行一些说明和演示，来让我们大致了解这个改进对我们的影响。 针对日常使用 Java 的开发人员来说，这个改变是感觉不到的，至于你使用的比较等操作还是会按照正常的处理方式来处理，对你来说这个是透明的。 ### Java 9 中的字符串实现 直到现在，我们应该非常明确的了解到 Java 中存储 String 是使用 _char[]_ 来处理的，这个是没有改变的。 首先，我们先定义一个 _char[]_ 数组 ```auto private final char[] value; ``` 然后我们再定义一个 _byte[]_ 数组： ```auto private final byte[] value; ``` 定义一个 _coder_ 变量： ```auto private final byte coder; ``` 这个 Code 的变量可以为下面 2 个值： ```auto static final byte LATIN1 = 0; static final byte UTF16 = 1; ``` 大部分情况下，Stgring 将会对 Coder 进行判断，然后根据值使用不同的实现： ```auto 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; } ``` _CompactString_ 在 JVM 中是默认启用的，如果你不想启用，你可以使用下面的参数告诉 JVM 不使用 String 压缩功能： ```auto +XX:-CompactStrings ``` ### coder 是如何工作的 在 Java 9 的 _String_ 类实现中，有关字符串的长度是下面的方法来进行计算的： ```auto public int length() { return value.length >> coder; } ``` 如果 _String_ 只含有 LATIN-1 字符的话， _coder_ 的值为 0，那么获得 String 字符串长度的方法就直接返回字节数组的的长度，因为你这个数组的长度就是一个自己一个元素。 在另外的一种情况，如果 Stirng 使用了 UTF-16 字符集的话，_coder_ 的值为 1 Java 将会使用数组中存储的元素的字节实际长度来返回，这是因为数组中存储的字符可能是 2 字节的。 需要注意的是，这个修改是针对 String 的内部修改，针对绝大部分开发者来说，所有有关 String 的处理方法都是透明的。 如果你想了解更多 String 有关的内部实现，这个是你值得深入的地方。 ## 缩小字符串（ Compact String）和 压缩字符串（Compressed String） 正如我们在上面文章提到的内容，在英文语境中上面 2 个方法还是有区别的，在中文环境下主要表达就是字符串压缩。 JDK 6 使用的压缩字符串方法，主要原因是我们修改了 String 的存储结构，_char[]_ 在 Java 的很多地方都会用到，并且 String 因为这个修改就只能接受使用 _char[]_ 为参数的构造方法了。 在很多算法中，String 的操作又严重依赖 _char[]_ 数组，如果我们进行这样修改的话，很多程序的代码都会需要跟着修改，这个显然是不划算的。 在后面我们使用的缩小字符串的处理方案来说也会有问题的，同样也会增加一些不少的问题，例如会导致一些方法修改为内部方法 [intrinsified](https://en.wikipedia.org/wiki/Intrinsic_function) 同时一些 JIT compiler 编译的代码也需要进行改进。 因为存储方式的改变，也会有一些反人类的情况会出现： LATIN-1 的 _indexOf(String)_ 方法调用的是内部方法，但是 _indexOf(char)_ 不是小的。 在 UTF-16 环境下，这 2 个方法都可以使用相同的内部方法，这个问题只会对 LATIN-1 字符集的 String 字符串有影响，并且也会在后续的版本中修正。 整体来说使用缩小字符串（ Compact String）的效率更高一些。 你可以将 Java 应用程序的 Heap 内存空间 dump 出来后进行分析，针对 String 的改进不会对你应用程序的提高产生非常显著的影响，如果你的程序有很多逻辑上面的问题，修改程序上面的逻辑问题比考虑如何使用 String 要实际得多。 但是对 JVM 来说这种提高还是有必要的。 ### 性能的不同 让我们通过下面的一个简单的测试来看看启用缩小字符串（ Compact String）配置和不启用这个配置对性能产生的异同。 ```auto 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千万个 String 字符串，然后使用默认开启的配置来看看上面的代码的输出： ```auto Generated 10000000 strings in 854 ms. Created string of length 488895 in 5130 ms. ``` 同样的，我们禁用 JVM 的这个参数 _-XX:-CompactStrings_ 参数选项再来看看输出： ```auto Generated 10000000 strings in 936 ms. Created string of length 488895 in 9727 ms. ``` 通过上面的代码，我们可以看到上面 2 个参数修改后对比的输出并不是非常的明显，但是也可以看到有明确的性能提升。 ## 结论 在我们这个对 String 在 JVM 中性能的提升和存储的改变进行了一些讨论。 ![975977e68f50809bbb34acabca720e9a3ca45289](https://cdn.isharkfly.com/com-isharkfly-www/discourse-uploads/original/2X/b/b32128fe01806c141a6fa22400c888fa7c85be66.png) 这种改变对程序员来说是透明的，但是有必要对 String 的内部存储进行一些剖析，因为 String 可能是 Java 中用得最多的变量了。 ### 测试源代码 相关的测试源代码，请访问链接： > **[java-tutorials/CompactStringDemo.java at main](https://src.isharkfly.com/iSharkFly-Docs/java-tutorials/src/branch/main/core-java-modules/core-java-strings/src/main/java/com/ossez/java9/compactstring/CompactStringDemo.java)** > > java-tutorials 您也可以 Fork 代码后提交更新。