• 首页 首页 icon
  • 工具库 工具库 icon
    • IP查询 IP查询 icon
  • 内容库 内容库 icon
    • 快讯库 快讯库 icon
    • 精品库 精品库 icon
    • 问答库 问答库 icon
  • 更多 更多 icon
    • 服务条款 服务条款 icon

java的hashmap的一些性能测试

武飞扬头像
nyingping
帮助41

0.前言

 

可hashmap背后的思想,在缓存,在数据倾斜,在负载均衡等分布式大数据领域都能广泛看到其身影。了解其背后的思想不仅仅只是为了一个hashmap.

更重要的是,hashmap不像jvm底层原理那么遥远,不像并发编程那么宏大,它只需要通勤路上十分钟就可搞定基本原理,有什么理由不呢?

所以本文试着从相对少见的一个微小角度来重新审视一下hashmap.

1.准备工作。

1.1模拟哈希冲突

新建两个class,一个正常重写equalshashcode方法,一个故意在hashcode方法里返回一定范围内的随机数,模拟哈希冲突,以及控制哈希冲突的程序。

不冲突的类

@Setter
public class KeyTest2 {
    private String name;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        KeyTest2 keyTest = (KeyTest2) o;

        return name != null ? name.equals(keyTest.name) : keyTest.name == null;
    }

    @Override
    public int hashCode() {
         return name != null ? name.hashCode() : 0;
    }
}

冲突的类

@Setter
@NoArgsConstructor
public class KeyTest {
    private String name;

    private Random random;

    public KeyTest(Random random){
        this.random = random;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        KeyTest keyTest = (KeyTest) o;

        return name != null ? name.equals(keyTest.name) : keyTest.name == null;
    }

    @Override
    public int hashCode() {
        // return name != null ? name.hashCode() : 0;
        return random.nextInt(1000);
    }
}

众所周知,hashmap在做put的时候,先根据key求hashcode,找到数组下标位置,如果该位置有元素,再比较equals,如果返回true,则替换该元素并返回被替换的元素;否则就是哈希冲突了,即hashcode相同但equals返回false。 哈希冲突的时候在冲突的数组处形成数组,长度达到8以后变成红黑树。

1.2 java的基准测试。

这里使用JMH进行基准测试.
JMH是Java Microbenchmark Harness的简称,一般用于代码的性能调优,精度甚至可以达到纳秒级别,适用于 java 以及其他基于 JVM 的语言。和 Apache JMeter 不同,JMH 测试的对象可以是任一方法,颗粒度更小,而不仅限于rest api.

jdk9以上的版本自带了JMH,如果是jdk8可以使用maven引入依赖。

点击查看JMH依赖
<dependency>
            <groupId>org.openjdk.jmh</groupId>
            <artifactId>jmh-core</artifactId>
            <version>${jmh.version}</version>
        </dependency>
        <dependency>
            <groupId>org.openjdk.jmh</groupId>
            <artifactId>jmh-generator-annprocess</artifactId>
            <version>${jmh.version}</version>
        </dependency>

2.测试初始化长度

点击查看初始化长度基本测试代码
/使用模式 默认是Mode.Throughput
@BenchmarkMode(Mode.AverageTime)
// 配置预热次数,默认是每次运行1秒,运行10次,这里设置为3次
@Warmup(iterations = 3, time = 1)
// 本例是一次运行4秒,总共运行3次,在性能对比时候,采用默认1秒即可
@Measurement(iterations = 3, time = 4)
// 配置同时起多少个线程执行
@Threads(1)
//代表启动多个单独的进程分别测试每个方法,这里指定为每个方法启动一个进程
@Fork(1)
// 定义类实例的生命周期,Scope.Benchmark:所有测试线程共享一个实例,用于测试有状态实例在多线程共享下的性能
@State(value = Scope.Benchmark)
// 统计结果的时间单元
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class HashMapPutResizeBenchmark {

    @Param(value = {"1000000"})
    int value;

    /**
     * 初始化长度
     */
    @Benchmark
    public void testInitLen(){
        HashMap map = new HashMap(1000000);
        Random random = new Random();
        for (int i = 0; i < value; i  ) {
            KeyTestConflict test = new KeyTestConflict(random, 10000);
            test.setName(i "");
            map.put(test, test);
        }
    }

    /**
     * 不初始化长度
     */
    @Benchmark
    public void testNoInitLen(){
        HashMap map = new HashMap();
        for (int i = 0; i < value; i  ) {
            Random random = new Random();
            KeyTestConflict test = new KeyTestConflict(random, 10000);
            test.setName(i "");
            map.put(test, test);
        }
    }


    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(HashMapPutResizeBenchmark.class.getSimpleName())
                .mode(Mode.All)
                // 指定结果以json结尾,生成后复制可去:http://deepoove.com/jmh-visual-chart/ 或https://jmh.morethan.io/ 得到可视化界面
                .result("hashmap_result_put_resize.json")
                .resultFormat(ResultFormatType.JSON).build();

        new Runner(opt).run();
    }
}

测试结果图

对测试结果图例做一个简单的说明:

以上基准测试,会得到一个json格式的结果。然后将该结果上传到官方网站,会得到一个上述图片的结果。 横坐标,红色驻图代表有冲突,浅蓝色驻图无冲突。 众坐标,ops/ns代表平均每次操作花费的时间,单位为纳秒,1秒=1000000000纳秒,这样更精准。
下同。

简单说,驻图越高代表性能越低。

我测了两次,分别是无哈希冲突和有哈希冲突的,这里只贴一种结果。

测试结果表明,hashmap定义时有初始化对比无初始化,有大约4%到12%的性能损耗。

足够的初始化长度下,有哈希冲突的测试结果:

足够的初始化长度下,没有哈希冲突的测试结果:

3.模拟一百万个元素put,get的差异。

众所周知,hashmap在频繁做resize时,性能损耗非常严重。以上是没初始化长度,无冲突和有冲突的情况下,前者性能是后者性能的53倍。

那么在初始化长度的情况下呢?

HashMap map = new HashMap(1000000);

同样的代码下,得到的测试结果 以上是有初始化长度,无冲突和有冲突的情况下,前者性能是后者性能的58倍。

大差不差,不管有无初始化长度,无冲突的效率都是有冲突效率的50倍以上。说明,这是哈希冲突带来的性能损耗。

4.模拟无红黑树情况下get效率

4.1 将random扩大,哈希冲突严重性大大减小,模拟大多数哈希冲突导致的哈希链长度均小于8,无法扩展为红黑树,只能遍历数组。

将KeyTest的hashcode方法改为:

@Override
    public int hashCode() {
        // return name != null ? name.hashCode() : 0;
        return random.nextInt(130000);
    }

这样1000000/130000 < 8,这样大多数的哈希链将不会扩展为红黑树。

测试结果为:

测试结果说明,**有冲突的效率反而比无冲突的效率要高**,差不多高出80%左右。 这其实有点违反常识,我们通常讲,hashmap要尽量避免哈希冲突,哈希冲突的情况下写入和读取性能都会受到很大的影响。 但是上面的测试结果表明,大数据量相对比较大的时候,适当的哈希冲突(<8)反而读取效率更高。 个人猜测是,适当的哈希冲突,数组长度大为减少。

为了证明以上猜想,直接对ArrayList进行基准测试。

4.1.1 ArrayList不同长度下get效率的基准测试

模拟一个哈希冲突非常严重下,底层数组长度较小的list,和哈希冲突不严重情况下,底层数组较大的list,再随机测试Get的效率如何。

点击查看测试代码
//使用模式 默认是Mode.Throughput
@BenchmarkMode(Mode.AverageTime)
// 配置预热次数,默认是每次运行1秒,运行10次,这里设置为3次
@Warmup(iterations = 3, time = 1)
// 本例是一次运行4秒,总共运行3次,在性能对比时候,采用默认1秒即可
@Measurement(iterations = 3, time = 4)
// 配置同时起多少个线程执行
@Threads(1)
//代表启动多个单独的进程分别测试每个方法,这里指定为每个方法启动一个进程
@Fork(1)
// 定义类实例的生命周期,Scope.Benchmark:所有测试线程共享一个实例,用于测试有状态实例在多线程共享下的性能
@State(value = Scope.Benchmark)
// 统计结果的时间单元
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class ArrayListGetBenchmark {

    //    @Param(value = {"1000","100000","1000000"})
    @Param(value = {"1000000"})
    int value;


    @Benchmark
    public void testConflict(){
        int len = 10000;
        Random random = new Random(len);
        for (int i = 0; i < 100; i  ) {
            int index = random.nextInt(len);
            System.out.println("有冲突,index = "   index);
            ConflictHashMapOfList.list.get(index);
        }
    }

    @Benchmark
    public void testNoConflict(){
        int len = 1000000;
        Random random = new Random(len);
        for (int i = 0; i < 100; i  ) {
            int index = random.nextInt(len);
            System.out.println("无冲突,index = "   index);
            NoConflictHashMapOfList.list.get(index);
        }
    }


    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(ArrayListGetBenchmark.class.getSimpleName())
                .mode(Mode.All)
                // 指定结果以json结尾,生成后复制可去:http://deepoove.com/jmh-visual-chart/ 或https://jmh.morethan.io/ 得到可视化界面
                .result("arraylist_result_get_all.json")
                .resultFormat(ResultFormatType.JSON).build();

        new Runner(opt).run();
    }


    @State(Scope.Thread)
    public static class ConflictHashMapOfList {
        volatile static ArrayList list = new ArrayList();
        static int randomMax = 10000;
        static {
            // 模拟哈希冲突严重,数组长度较小
            for (int i = 0; i < randomMax; i  ) {
                list.add(i);
            }
        }

    }

    @State(Scope.Thread)
    public static class NoConflictHashMapOfList {
        volatile static ArrayList list = new ArrayList();
        static int randomMax = 1000000;
        static {
            // 模拟没有哈希冲突,数组长度较大
            for (int i = 0; i < randomMax; i  ) {
                list.add(i);
            }
        }

    }
}

测试结果如下:

可以看到,间接证实了以上的猜想。 当然这里的代码可能并不严谨,也欢迎大家一起讨论。

4.2 jdk1.8版本,哈希冲突严重下的get效率测试

测试结果说明:在jdk8,无冲突效率是有有冲突的3倍左右。

4.3 将jdk版本降为1.7,在哈希冲突依然严重的情况下,get效率如何?

测试结果说明:在jdk7,无冲突效率是有有冲突的12倍左右。

结合4.1和4.2的测试对比,说明jdk1.8红黑树的优化效率确实提升很大。

5.总结

1.初始化的时候指定长度,长度要考虑到负载因子0.75.初始化的影响受到哈希冲突的影响,没有那么大(相对于倍数而言),但也不小。
2.哈希冲突严重时,put性能急剧下降。(几十倍级)
3.相同元素个数的前提下,在哈希冲突时,get效率反而更高。
4.相比之前的版本,哈希冲突严重时,jdk8红黑树对get效率有非常大的提升。

测试代码和测试结果在 这里

这篇好文章是转载于:学新通技术网

  • 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
  • 本站站名: 学新通技术网
  • 本文地址: /boutique/detail/tanfbega
系列文章
更多 icon
同类精品
更多 icon
继续加载