Java 1.7.0_06中String类内部实现的一些变化

ChangeLog:

  • 20131119日,更新了Java8版本中的变化。
  • 0131128日,更新了Java 7u40版本中的变化。(感谢Sunny Chan以及他的同事提示我关注新版本的JDK

共享一个基础char[] 

原先的String类中有4个非静态变量:

  • char[] value用于存储字符串。
  • int offset用于记录字符串首字母在value数组中对应的下标。
  • int count用于记录字符串的长度。
  • int hash用于缓存该字符串的哈希值。

正如你所看到的,绝大多数String对象都会是offset=0并且count=value.length。除非通过调用String.substring方法创建的String对象,或是间接调用Pattern.split这类API创建对象。

String.substring创建的String对象将和原String对象共享同一个内部变量char[] value,这样设计的好处是:

  1. 通过共享字符串节省内存开销。
  2. String.substring方法的时间复杂度为O(1)。

然而,这样的设计有可能会导致内存泄露:如果你从一个长度很长的String对象中提取出一个很短的子串,当这个String对象不再需要时(该对象静候GC回收),你的子串中还保持着这个String对象中存储着完整字符串的char[] value数组的引用。这种情况的解决方法是通过构造函数new String(String)创建一个新的子串对象,进而解除短子串与长母串之间的依赖关系。

自Java 1.7.0_06版本起(包括Java 8的最新版本),String类中不再有offset和count变量。这意味着成员变量char[] value将不会被共享。你可以忘记上述有关内存泄露的描述以及如何使用new String(String)方法来避免内存泄露的发生。但需要记住的是,String.substring现在是线性级的时间复杂度,不再是常数级的时间复杂度。

哈希算法的改变

下面的部分仅适用于Java 7u6以上的Java 7版本,这些代码在Java 8中已被删除。

String类在本次更新中的另一个变化是一个新的哈希算法。Oracle表示新的算法能生成出更好的哈希分布,并且能够提高基于哈希算法的容器的性能,如HashMap、Hashtable、HashSet、 LinkedHashMap、LinkedHashSet、WeakHashMap和ConcurrentHashMap 。与本文第一部分介绍的变化不同,这部分变化是试验性质的,默认是关闭的。

你可能已经猜到了,这部分变化只适用于String类型的Key。如果想要启用它们,需要将系统变量jdk.map.althashing.threshold设置为一个非负的整数值(默认为-1)。当使用新的哈希方法时,这个值将是容器大小的阈值。这里需要注意的是:哈希方法只有在进行重哈希(rehash)的时候才会被更新。因此,如果容器上次执行重哈希是在size=160的时候,而jdk.map.althashing.threshold = 200,这样只有在容器的size增长到大约320的时候,哈希方法才会被更新。

String类现在有一个hash32()方法,它的结果被缓存在成员变量int hash32 中。这个方法最大的变化是,同一个字符串在不同的JVM上执行hash32()的结果可能不同(确切的说,多数情况下都会不同,因为其内部分别调用了一次System.currentTimeMillis()和两次System.nanoTime()用于初始化seed)。因此,某些容器在每次运行程序时迭代顺序都不同。

事实上,我对这个方法的改变有一点意外。如果原先的hashCode方法运行的很好,为什么我们需要一个新的哈希方法呢?我决定使用文章hashcode方法性能调优中的测试程序,测试一下使用hash32方法会产生多少个重复的哈希值。

String.hash32()方法不是公有的,因此我只能通过查看HashMap的源码来找到调用String.hash32()的方法。答案是issun.misc.Hashing.stringHash32(String)。

使用同一数据集(由1百万个各不相同的Key组成)进行测试,String.hash32生成了304个重复的哈希值,而相比之下String.hashCode并没有生成重复的哈希值。我想我们需要静候Oracle进一步的完善或者更多的使用场景说明。

新的哈希算法可能会严重影响高并发、多线程代码

本章节适用于Java 7版本的build 6(包含build 6)至build40(不包含build40)。这部分代码在Java 8中已被删除。有关Java 7u40以上版本的相关介绍请参见下一个章节。

Oracle在后面这些类的哈希实现中遗留了一个bug HashMap、Hashtable、HashSet、LinkedHashMap、LinkedHashSet和WeakHashMap,只有ConcurrentHashMap 不受影响。这是因为所有的非concurrent类中现在都引入了下面的成员变量:

/**
 * A randomizing value associated with this instance that is applied to
 * hash code of keys to make hash collisions harder to find.
 */
transient final int hashSeed = sun.misc.Hashing.randomHashSeed(this);

这意味着每一个map或set实例创建的过程中都会调用sun.misc.Hashing.randomHashSeed方法。randomHashSeed后续会调用java.util.Random.nextInt方法。Random类以其多线程环境下不友好而闻名:它有一个Atomic类型的成员变量private final AtomicLong seedfield。Atomic类型在多线程竞争程度较低或者适中的场景下性能表现较好,但在竞争激烈的场景下性能很差。

因此,很多处理HTTP/JSON/XML请求的高负载Web应用可能会被这个bug所影响,因为现有的解析器在表示名值对(name-value)时几乎都使用了上述的存在bug的容器。这些解析器还很可能使用了嵌套的map,这会进一步增加每秒中创建map实例的数量。

如何解决这一问题呢?

1. 使用ConcurrentHashMap :只有在设置系统变量jdk.map.althashing.threshold时才会调用randomHashSeed 方法。但很可惜的是,这种方式仅适用于JDK的核心开发者。

/**
 * A randomizing value associated with this instance that is applied to
 * hash code of keys to make hash collisions harder to find.
 */
private transient final int hashSeed = randomHashSeed(this);

private static int randomHashSeed(ConcurrentHashMap instance) {
    if (sun.misc.VM.isBooted() && Holder.ALTERNATIVE_HASHING) {
        return sun.misc.Hashing.randomHashSeed(instance);
    }

    return 0;
}

2. Hacker的方式:修改sun.misc.Hashing类,这种方式极度不推荐。但如果你依然想解决这个bug,解决的思路是:java.util.Random类并不是final的。你可以在Java 7中加入Random 类的一个Thread Local的子类:java.util.concurrent.ThreadLocalRandom,它内部使用了ThreadLocal<ThreadLocalRandom>(感谢Benjamin Possolo指出我在之前的文章中遗漏了这个类的介绍)。除此之外,ThreadLocalRandom属于CPU cache感知型:每个ThreadLocalRandom实例的seed后面增加了64字节的填充(cache行的大小),进而降低2个不同的seed在同一个cache行中碰撞的可能性。

然后你可以修改成员变量sun.misc.Hashing.Holder.SEED_MAKER,将它初始化为Random子类的实例(ThreadLocalRandom)。不用担心这个变量是私有的、静态的而且是final的,反射机制可以帮你

public class Hashing {
    private static class Holder {
        static final java.util.Random SEED_MAKER;

Java 7u40以上的版本中新的哈希算法不再影响高并发、多线程代码

OracleJava 7u40版本中修正了上述的bug

他们使用了上一章节中提到的方法一,仅在重哈希阀值被启用时(通过设置系统变量jdk.map.althashing.threshold启用)才调用sun.misc.Hashing.randomHashSeed方法。Oracle只修改了两个类:HashMap和Hashtable,进而间接修改了 HashSet、LinkedHashMap和LinkedHashSet,因为这三个类是基于HashMap实现的。唯一没有被修改的类是WeakHashMap,但我实在想不出这个类会被大量实例化的应用场景。

相关文章

最近,本文在Reddit上引起了激烈的讨论。我推荐读者们去看一看:

总结

  • 自Java 1.7.0_06版本起,String.substring方法会为每个子串创建一个新的char[] value(而不是共享母串的char[] value)。这意味着String.substring方法的时间复杂度由常数阶变为线性阶。这种变化的好处是String对象占用的内存稍微少了一些(比以前少8个字节),同时确保String.substring方法不会导致内存泄漏(有关Java对象内存布局的详细信息,请见String packing part 1: converting characters to bytes)。
  • Java 7u6+版本中的功能,在Java 8中被删除。自Java 1.7.0_06版本起,String类有了第二个哈希函数:hash32。该方法目前还不是公有的,只能通过使用反射机制或者是调用sun.misc.Hashing.stringHash32(String)来访问该方法。只有当那7种哈希相关的JDK容器的大小超过系统变量jdk.map.althashing.threshold所设定的阀值时,该方法才会被使用。这是一个试验性质的功能,目前我不推荐在代码中使用这一功能。
  • Java 7u6 (包含Java 7u6)至Java 7u40(不包含Java 7u40)版本中的功能,不适用于Java 8新的哈希实现引入了一个性能上的bug,这个bug涉及Java 7u6 (包含Java 7u6)到Java 7u40(不包含Java 7u40)之间所有版本中所有标准的非concurrent的MapSet容器。这个bug只影响多线程应用每秒钟创建Map实例的效率。详情请见本文第三章节。Java 7u40版本已修复这个bug
原文链接: java-performance 翻译: ImportNew.com - 夏千林
译文链接: http://www.importnew.com/7656.html
[ 转载请保留原文出处、译者和译文链接。]

关于作者: 夏千林

(新浪微博:@杂草千

查看夏千林的更多文章 >>



相关文章

发表评论

Comment form

(*) 表示必填项

还没有评论。

跳到底部
返回顶部