支持压缩string在HotSpot JVM中被丢弃？
在这个Oracle页面的Java HotSpot VM选项上，默认情况下它列出-XX:+UseCompressedStrings作为可用的。 但是，在Java 6更新29中，默认情况下是closures的，而在Java 7更新2中，它会报告警告
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseCompressedStrings; support was removed in 7.0
有谁知道删除这个选项背后的思想？
在java中sorting巨大的file.txt的行
使用-mx2g ，这个例子花费了4.541秒，在Java 6更新29中花了5.206秒。很难看出它会影响性能。
注意：Java 7 update 2需要2.0 G，而没有压缩string的Java 6 update 29需要1.8 GB，压缩string只需要1.0 GB。
最初，这个选项是为了提高SPECjBB性能而添加的。 这些收益是由于处理器和DRAM之间的内存带宽需求减less所致。 在字节[]中加载和存储字节消耗char []中字符的1/2带宽。
但是，这是有代价的。 代码必须确定内部数组是byte []还是char []。 这需要CPU时间，如果工作负载不是内存带宽受限，则可能导致性能下降。 由于增加了复杂性，还有代码维护价格。
由于没有足够的生产性工作负载显示出明显的收益（SPECjBB可能除外），因此该选项被删除。
还有另外一个angular度。 该选项减less了堆的使用。 对于适用的string，它将这些string的内存使用量减less了1/2。 在选项移除的时候，这个angular度没有被考虑。 对于内存容量受限的工作负载（即必须在有限的堆空间运行并且GC花费大量时间），此选项可能certificate是有用的。
如果足够的内存容量限制了类似生产的工作负载可以被certificate是合理的，那么也许这个选项就会被带回来。
编辑3/20/2013：平均服务器堆转储使用string的25％的空间。 大多数string是可压缩的。 如果重新引入该选项，则可以节省一半的空间（例如〜12％）！
编辑3/10/2016：类似于压缩string的function将回到JDK 9 JEP 254中 。
由于有了票，所以我认为我没有错过任何明显的东西，所以我将它logging为一个错误（至less在文档中是遗漏的）
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129417
（应该可以在几天内看到）
只是为了添加，对于那些感兴趣的…
java.lang.CharSequence接口（ java.lang.String实现）允许比UTF-16更紧凑的Strings表示。
处理大量string的应用程序可能应该被编写为接受CharSequence ，以便它们可以使用java.lang.String 或更紧凑的表示forms 。
8位（UTF-8），甚至是5,6或7位编码，甚至压缩的string都可以表示为CharSequence 。
CharSequence也可以更有效地操作 – 例如，子序列可以被定义为原始内容的视图（指针），而不是复制。
例如，在并发树中，十个莎士比亚戏剧的后缀树需要2GB的RAM，使用基于CharSequence的节点，如果使用char []或基于String的节点，则需要249GB的RAM 。
Java 9执行java中巨大的file.txt的sorting行两倍于我的机器上的速度，也只需要1G的内存，因为默认情况下启用了-XX:+CompactStrings 。 另外，在Java 6中，压缩string只能用于7位ASCII字符，而在Java 9中，它支持Latin1（ISO-8859-1）。 一些像charAt(idx)这样的操作可能会稍微慢一些。 随着新的devise，他们也可以支持未来的其他编码。
我在“Java专家的时事通讯”上撰写了一篇关于此的通讯 。
在OpenJDK 7（1.7.0_147-icedtea，Ubuntu 11.10）中，JVM只是失败
无法识别的VM选项“UseCompressedStrings”
当JAVA_OPTS （或命令行）包含-XX:+UseCompressedStrings 。
看来Oracle真的删除了这个选项。
