如何正确的重写hashcode()？

发表于

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

本文已参与 「掘力星计划」 ，赢取创作大礼包，挑战创作激励金。

  • 备战2022春招或暑期实习，祝大家每天进步亿点点！Day4
  • 本篇总结的是 《如何正确重写JDK的equals方法》，后续会每日更新~
  • 关于《Redis入门到精通》、《并发编程》等知识点可以参考我的往期博客
  • 相信自己，越活越坚强，活着就该逢山开路，遇水架桥！生活，你给我压力，我还你奇迹！

751a8ffe445fbc514b868f41fb1efccd.jpeg

1、简介

不知道大家有没有在开发中重写过hashcode方法，或者在面试中遇到相关的问题。比如一些比较基础的Java工作岗位可能会问：你有使用过对象作为HashMap的key吗？

这个问题其实考察的就是程序员对应hashcode方法重写的相关知识点，如下HashMap的put方法截图可以看出，往容器中添加元素计算hash值时，调用了key对象的hashcode方法。

如何正确的重写hashcode方法？

这其实是一个非常常见而又看似非常简单的问题，但是真正能写的很完善的程序员小捌见得确实不多。（往往越迷人的越危险，越简单的越复杂！！！）

大家往下瞅，看看自己属不属于那个写的很完善的程序员！

2、正文

2.1 什么时候重写

在深入研究如何重写hashcode方法之前，必须要先明白什么时候需要重写hashcode？

关于这个问题，总结起来就一句话：需要重写equals方法的类，都需要重写hashcode方法！

那这个时候你肯定会问，什么时候需要重写equals方法呢？

关于这个问题小捌已经在上一篇文章中讲过啦，需要的兄弟们可以去我的专栏《Java小知识100例》系列看看，顺便点波订阅，关注小捌学习Java不迷路哦！

2.2 如何重写

hashcode方法是Java的java.lang.Object提供的本地方法，这个方法在jvm中实现，它能返回当前对象在内存中地址。

1
2
csharp复制代码// 返回对象在内存中的地址
public native int hashCode();

所以当我们的类未重写hashcode方法，且类的其余超类也未重写；那么我们在调用hashcode方法时，它将永远返回的是对象的内存地址。这可能不是你想要的结果，那我们如何来重写它呢？

思路

首先我们需要知道，我们是通过对象的域来计算hash的， 在对象中域无非数组、引用类型、基本数据类型，有这么多类型的域，我们肯定不能选择某一个域的hash值来作为对象的hashcode方法的返回值；因此我们考虑将域的hash值累加起来返回！

  • 基本数据类型，大家可以参考其对应的包装类型的hashcode方法
  • 引用类型则直接调用hashcode()
  • 数组类型则需要遍历数组，依次调用hashcode()

通用实现

这是java.util.Objects提供的hash方法，用于计算hashcode。虽然这个不是一个计算hashcode的银弹，但是我们可以借鉴这种实现，而且Java JDK源码中大部分类的hashcode都是类似这种实现方式！

1
2
3
typescript复制代码public static int hash(Object... values) {
    return Arrays.hashCode(values);
}
1
2
3
4
5
6
7
8
9
10
11
ini复制代码public static int hashCode(Object a[]) {
    if (a == null)
        return 0;

    int result = 1;

    for (Object element : a)
        result = 31 * result + (element == null ? 0 : element.hashCode());

    return result;
}

这个方法大致可以分为两步：

  1. 如果a==null，则返回hashcode为0
  2. 如果a != null，则遍历每一个域，域不为null，则调用域的hashcode方法并累加

这其中有一个非常显眼的数字 31， 每次循环时会将当前result*31，这是为什么呢？

其实每次计算result*31的作用是为了，防止hash冲突！因为如果不设置一个乘积因子，result计算的结果比较小，非常容易在累加的过程后出现相同的hash值，这种情况不是我们想见到的！

那为什么是31呢？ 31为什么能成为JDK计算团队选中的真命天子 ，就不能是2？不能是1001？

其实使用31作为乘积因子是有原因的，其原因小捌觉得有三点：

  1. 31是一个不大不小的数，它不会过小导致hashcode计算的结果容易发生冲突；因为返回值是一个int整数类型也不至于过大，导致hashcode返回值溢出。
  2. 31是一个奇数，一个数与奇数相乘，不容易丢失低位；因为乘以2相当于无符号左移一位，这样会在低位补0，这样的话hashcode计算的值，就非常容易冲突了。
  1. 31对虚拟机的识别非常友好，对于虚拟机来说31 = 2^5 - 1，他能针对这种数字做优化并转换为位运算，因此相乘的时候性能较好

小捌在这里分别用乘积因子2和乘积因子31做个测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
java复制代码package com.liziba.part2;

import org.apache.commons.lang3.RandomStringUtils;

import java.util.ArrayList;
import java.util.Comparator;
import java.util.List;
import java.util.Objects;

/**
 * <p>
 * HashCode方法测试
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/10/24 11:54
 */
public class HashCodeMethodDemo {

    /**
     * 计算hashcode
     *
     * @param value         需计算hashcode字符串
     * @param capacity      乘数因子
     * @return
     */
    public static int hashCode(String value, int capacity) {

        int hash = 0;
        if (Objects.nonNull(value) && value.length() > 0) {
            char[] chars = value.toCharArray();
            for (int i = 0; i < chars.length; i++) {
                hash = capacity * hash + chars[i];
            }
        }

        return hash;
    }


    /**
     * hash值冲突比较
     *
     * @param capacity
     * @param hashValues
     */
    public static void conflictCompare(int capacity, List<Integer> hashValues) {

        Comparator<Integer> comparator = (x, y) -> (x > y) ? 1 : ((x < y) ? -1 : 0);
        Integer max = hashValues.stream().max(comparator).get();
        Integer min = hashValues.stream().min(comparator).get();
        long conflictNum = hashValues.size() - hashValues.stream().distinct().count();
        double conflictRate = conflictNum * 1.0 / hashValues.size() ;

        System.out.println(String.format("乘数因子capacity=%d 冲突数=%d 冲突率：%.4f%% 最大值：%d 最小hashCode：%d",
                capacity, conflictNum, conflictRate * 100, max, min));
    }

    
   
    public static void main(String[] args) {

        int num = 100000;
        int capacity2 = 2;
        int capacity31 = 31;
        List<Integer> hashValues2 = new ArrayList<>(num);
        List<Integer> hashValues31 = new ArrayList<>(num);
        for (int i = 0; i < num; i++) {
            // 生成随机数 org.apache.commons.lang3.RandomStringUtils
            String value = RandomStringUtils.randomAlphabetic(15);
            hashValues2.add(hashCode(value, capacity2));
            hashValues31.add(hashCode(value, capacity31));
        }

        conflictCompare(capacity2, hashValues2);
        conflictCompare(capacity31, hashValues31);

    }

}

一共测试10万个15位长的随机字符串

  • 当乘数因子为2时，冲突率接近4%
  • 当乘数因子为31时，冲突率只有0.0010%

那是不是重写hashcode方法的时候，都需要乘上31呢？

这肯定不是这样的啦！ 乘积因子31只是为了减小hash冲突的一种解决方案，当你用不上的时候肯定不需要使用乘积因子啦！

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%