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

Question

由于String在Java中(像其他语言一样)消耗大量内存,因为每个字符占用两个字节,Java 8引入了一个名为String Deduplication的新功能,它利用了char数组是字符串内部的最终事实,因此JVM可以搞砸他们.

到目前为止,我已经阅读了这个例子,但由于我不是一个专业的java编码器,我很难掌握这个概念.

这是它说的,

已经考虑了各种字符串复制策略,但现在实现的策略遵循以下方法:每当垃圾收集器访问String对象时,它会记录char数组.它接受它们的哈希值并将其与对数组的弱引用一起存储.一旦找到另一个具有相同哈希码的String,就会将它们与char进行比较.如果它们匹配,则将修改一个String并指向第二个String的char数组.然后不再引用第一个char数组,并且可以进行垃圾回收.

整个过程当然会带来一些开销,但是受到严格的限制.例如,如果找不到字符串有一段时间的重复项,则不再检查它.

我的第一个问题,

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

编辑:

上面的链接说,

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

我的第二个问题,

如果两个哈希码String相同,则Strings已经是相同的,那么为什么对它们进行比较char的char,一旦发现,这两个String具有相同的散列码？

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分钟后的结果.正如您所见,String Deduplication执行了452次,"重复数据删除"执行了801.6 MB字符串.String Deduplication检查了27 000 000个字符串.当我比较了Java 7的我的内存消耗与标准的并行GC到Java 8u20与G1 GC并启用字符串重复数据删除堆下降approximatley 50% :

Java 7并行GC

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

Answer 2

想象一下,你有一本电话簿,其中包含有a String firstName和a的人String lastName.在你的电话簿中,有10万人拥有相同的功能firstName = "John".

因为您从数据库或文件中获取数据,所以这些字符串不会被实现,因此您的JVM内存包含{'J', 'o', 'h', 'n'}10万次char数组,每个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小号意味着等于哈希,逆是不是一定是真的.

正如霍尔格在评论中所说,这代表了哈希冲突.

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

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

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

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