Java中的字符串表示和压缩字符串

Question

最近，我偶然发现了这个JEP 254：紧凑字符串，其基本目标是：

小结：对字符串采用更节省空间的内部表示。

根据我目前的经验，字符串和字符[]占据了堆总消耗量的很大比例。正如JIRA已经指出的那样：

String类的当前实现将字符存储在字符数组中，每个字符使用两个字节（十六位）。从许多不同的应用程序收集的数据表明，字符串是堆使用的主要组成部分，而且，大多数字符串对象只包含拉丁文1字符。这些字符只需要一个字节的存储空间，因此这些字符串对象的内部字符数组中有一半空间没有使用。

考虑到这一点，我有以下问题：

• 当字符串只存储需要1字节的字符并且也是堆配置文件的一大部分时，其他开发人员当前如何处理这个问题

我已经讨论了一些关于字符串的基本问题，其中包括字符串池和字符串的工作原理，以及字符串中的单个字符当前占用2个字节的原因。




Answer 1

Java中字符（因此字符串）的内存表示/编码是UTF-16，每个字符至少需要2个字节。即使您在程序中使用的字符和编码需要在其他字符集中使用一个字节（Latin-1，UTF-8的一部分，等等）。

这个问题在早些时候可能不是最相关的，但现在有了数千GB的堆，谁知道他们对精简JVM堆签名有什么新的看法。

由于这是一个JVM内部问题，因此没有库会影响它。您需要一个自定义JVM，该JVM可能不符合规则（假设在某个地方指定了UTF-16编码）。

Answer 2

UTF-8是一种适用于所有Unicode字符的字符编码，Java字符串存储在UTF-16编码中，并且总是这样。实现可变striong存储可能会对性能造成巨大的影响，因为JVM必须首先决定是查看拉丁语1字符串值还是UTF-16字符串值。

此外，UTF16编码提供了对字符串属性和操作的更一致的处理。拉丁-1字符串必须首先转换为UTF-16才能附加非拉丁-1字符。此外，将拉丁-1字符串与UTF-16字符串进行比较是一件相当混乱的事情。基本上，您必须将拉丁-1字符串转换为UTF-16字符串（或至少通过CharSequence接口迭代它）对于几乎所有操作。

Answer 3

这实际上是在前面尝试过的：在Java-6中有一个选项XX:UseCompressedStrings，它启用了类似于JEP 254的功能。然而，由于额外的复杂性（引入了类似这样的bug）和性能损失，Java-7中放弃了此功能。其中一个问题是，这些时间字符串能够共享底层缓冲区（substring（）返回一个新字符串，该字符串与原始字符串共享同一缓冲区）。这增加了字符串压缩的复杂性（如果原始字符串使用非拉丁文1符号，而子字符串仅使用拉丁文1怎么办？）。

现在，字符串缓冲区永远不会在不相等的字符串之间共享，因此实现变得更加容易。尽管如此，这还是相当困难，并且涉及到许多警告。JEP 254个进球中的一个就是努力不让自己失去一点点表现。不要忘记，String类是非常基本的：它的一些方法（如equals、indexOf）是由JIT编译器内部化的；有些场景是专门处理的（比如字符串串联的优化）。所有这些特性都严重依赖于内部字符串表示，对于紧凑字符串也应该重写。

如果您想压缩您当前的代码，您可以实现自定义CompactString，它实现CharSequence接口并在内部使用byte[]。问题是大量现有代码与String一起使用，而不是CharSequence和CharSequence接口实际上非常有限。因此很难广泛使用此类。