Question

由于Java中的String（与其他语言一样）消耗大量内存，因为每个字符占用两个字节，因此Java 8引入了一个名为 String Deduplication 的新功能利用char数组是字符串内部和final的事实，因此JVM可以搞乱它们。

到目前为止我已阅读this example但由于我不是一名专业的java编码员，因此我很难掌握这个概念。

这就是它所说的，

已经考虑了各种字符串复制策略，但是   现在实施的一个遵循以下方法：每当   垃圾收集器访问它注意到char的String对象   阵列。它需要使用哈希值并将其与弱值一起存储   对数组的引用。一旦找到另一个有的String   相同的哈希码它将char比作char。如果匹配为   好吧，一个String将被修改并指向的char数组   第二串。然后不再引用第一个char数组   再也可以垃圾收集了。

这整个过程当然会带来一些开销，但是受到控制   严格限制。例如，如果找不到字符串   重复一段时间后将不再检查。

我的第一个问题，

由于最近在Java 8更新20中添加了这个主题，因此仍然缺乏资源，这里是否有人可以分享一些关于它如何帮助减少Java中String消耗的内存的实际示例？ / p>

修改

上面的链接说，

一旦找到另一个具有相同哈希码的String 将它们与char进行比较

我的第二个问题，

如果两个String的哈希码相同，那么Strings已经相同，那么为什么一旦发现两个char，就char对它们进行比较String {1}}具有相同的哈希码？

Answer 1

@assylias回答basiclly告诉你它是如何工作的并且是非常好的答案。我已经使用String Deduplication测试了一个生产应用程序，并且有一些结果。网络应用程序大量使用字符串，所以我认为优势非常明显。

要启用String Deduplication，您必须添加这些JVM参数（至少需要Java 8u20）：

-XX:+UseG1GC -XX:+UseStringDeduplication -XX:+PrintStringDeduplicationStatistics

最后一个是可选的，但就像名称所示，它显示了String Deduplication统计信息。这是我的：

[GC concurrent-string-deduplication, 2893.3K->2672.0B(2890.7K), avg 97.3%, 0.0175148 secs]
   [Last Exec: 0.0175148 secs, Idle: 3.2029081 secs, Blocked: 0/0.0000000 secs]
      [Inspected:           96613]
         [Skipped:              0(  0.0%)]
         [Hashed:           96598(100.0%)]
         [Known:                2(  0.0%)]
         [New:              96611(100.0%)   2893.3K]
      [Deduplicated:        96536( 99.9%)   2890.7K( 99.9%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:              96536(100.0%)   2890.7K(100.0%)]
   [Total Exec: 452/7.6109490 secs, Idle: 452/776.3032184 secs, Blocked: 11/0.0258406 secs]
      [Inspected:        27108398]
         [Skipped:              0(  0.0%)]
         [Hashed:        26828486( 99.0%)]
         [Known:            19025(  0.1%)]
         [New:           27089373( 99.9%)    823.9M]
      [Deduplicated:     26853964( 99.1%)    801.6M( 97.3%)]
         [Young:             4732(  0.0%)    171.3K(  0.0%)]
         [Old:           26849232(100.0%)    801.4M(100.0%)]
   [Table]
      [Memory Usage: 2834.7K]
      [Size: 65536, Min: 1024, Max: 16777216]
      [Entries: 98687, Load: 150.6%, Cached: 415, Added: 252375, Removed: 153688]
      [Resize Count: 6, Shrink Threshold: 43690(66.7%), Grow Threshold: 131072(200.0%)]
      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
      [Age Threshold: 3]
   [Queue]
      [Dropped: 0]

这些是运行应用程序10分钟后的结果。如您所见，字符串重复数据删除执行 452 次，“重复数据删除” 801.6 MB 字符串。字符串重复数据删除检查 27 000 000 字符串。当我将Java 7的内存消耗与标准并行GC与Java 8u20与G1 GC和启用的字符串重复数据删除进行比较时，堆已经下降了近似 50％：

Java 7 Parallel GC

Java 7 Parallel GC

带字符串重复数据删除的Java 8 G1 GC

Java 8 G1 GC with String Deduplication

Answer 2

想象一下，您有一本电话簿，其中包含人员，其中包含String firstName和String lastName。在您的电话簿中，有10万人拥有相同的firstName = "John"。

因为您从数据库或文件中获取数据，所以这些字符串不会被中断，因此您的JVM内存包含char数组{'J', 'o', 'h', 'n'} 10万次，每个John字符串一个。这些数组中的每一个都占用了20个字节的内存，因此100k Johns占用了2 MB的内存。

通过重复数据删除，JVM将意识到“John”被多次复制，并使所有这些John字符串指向相同的底层字符数组，从而将内存使用量从2MB减少到20字节。

您可以在JEP中找到更详细的说明。特别是：

许多大型Java应用程序目前在内存上存在瓶颈。测量表明，在这些类型的应用程序中，大约25％的Java堆实时数据集被String对象使用。此外，这些String对象中大约有一半是重复的，其中重复表示string1.equals(string2)为真。在堆上拥有重复的String对象本质上只是浪费内存。

[...]

实际的预期收益最终减少了10％。请注意，此数字是基于广泛应用的计算平均值。特定应用程序的堆减少量可能会有很大差异。

Answer 3

由于您的第一个问题已经得到解答，我将回答您的第二个问题。

必须逐个字符地比较String个对象，因为虽然相等的Object s意味着相等的哈希值，但反之为不必然为真。

正如Holger在他的comment中所说，这代表了哈希冲突。

hashcode()方法的适用规范如下：

如果两个对象根据equals(Object)方法相等，则对两个对象中的每一个调用hashCode方法必须产生相同的整数结果。



如果两个对象根据equals(java.lang.Object)方法不相等则不是必需的，则在两个对象中的每一个上调用hashCode方法必须产生不同的整数结果。 ...

这意味着为了使它们保证相等，每个字符的比较是必要的，以便它们确认两个对象的相等性。他们首先比较hashCode而不是使用equals，因为他们使用哈希表作为参考，这样可以提高性能。

Answer 4

他们描述的策略是简单地在很多equal字符串中重用一个String的内部字符数组。如果每个String都相同，则不需要拥有自己的副本。

为了更快地确定2个字符串是否相等，哈希码被用作第一步，因为它是确定字符串可能是否相等的快速方法。因此他们的陈述：

一旦找到另一个具有相同哈希码的String，就会将它们与char进行比较

这是为了在使用哈希码确定可能的相等性后进行某些（但速度较慢）的相等比较。

最后，相等的字符串将共享一个底层字符数组。

Java已经有String.intern()很长一段时间，或多或少相同（即通过重复删除相等的字符串来节省内存）。关于这一点的新颖之处在于它发生在垃圾收集期间并且可以在外部进行控制。

Java 8的字符串重复数据删除功能

4 个答案: