数据结构，HashCode为什么使用31作为乘数

建议配合小傅哥的面经手册使用！！！从今天开始我是小傅哥的布道师

8月1日说的要开始的打开，今天才真正有时间开始，终于是空了时间，这段时间也调整了下每天的时间
然后这个面试经的目的还是足够掌握Java基础，并能够在后面的JDK版本找到相关的内容给予面试官以惊喜
所以大体上面内容会分为：

• 预习
• 学习中的问题与解决
• 后期JDK版本相关内容扩展
• 总结
• 下一内容预习（递归）

然后每完成一个模块进行复盘总结

预习

• 主要还是为了了解String的HashCode算法中的乘数为什么是31，从理论和实践2个角度进行作证
• 实践方面又从两个维度进行细化（碰撞概率，散列分布）
• JDK9中的String HashCode算法发生改变

学习中的问题

• 乘数为 33， 39，41，199 的时候碰撞几率也很低，散列的时候怎么没有看 33， 39， 41的情况？
• 第33格子的散列数量怎么那么多？实际意义是什么？
• 2 ^ 32方分64个格子进行存放,没个格子不应该是2 ^(32-4) = 536870912 吗？ 咋成 67108864 了

问题解决

• 也做了数据看了图形，图形类似，39和41的时候有2个山包，也是会更分散，也不会像199一样会有数据丢视的问题，那为什么不使用 33， 39，41 呢？
• 67108864 ,第33格子的散列范围就是0~67108864，实际意义就是，大部分的String长度都会分部在这个区间
• 这个确实不理解

后期JDK版本相关内容扩展

• JDK9对String的实现进行了改变 从 char[] 到 byte[]，然后配合 Latin-1 的编码方式 节省了String的占用空间，间接的减少了GC次数（第一个支持的LTS版本是JDK11）
• 然后HashCode的算法，对应Latin-1的编码格式和UTF-16 都进行了改变，但是不变的是乘数31
• 拉丁编码的 HashCode 其实是将JDK8 中的 val[i] 替换成了 每个字节的低八位的ASCII码
• UTF-18编码的HashCode 是 双位字节的第一位的低八位作为char的取值的低八位，第二个的低八位左移八位后的高八位作为高八位
• 具体解析可参考 (一文说透String的hashCode)[https://www.icode9.com/content-4-854331.html]

总结

• 选择31作为计算哈希值的乘数是最佳的乘数。
• JDK9 对String的HashCode算法做了优化，其算法逻辑不变，实现方式有所变化，更改为字节数组后存储字符串所需的内存会进一步变小了。

预习

• 简单实现HashMap
• 扰动函数 的意义
• 初始化容量、负载因子 初始值的认识
• 扩容方法 解释
• 链表和红黑树 未说明
• 未来的JDK版本（截止JDK18）神奇的对HashMap没有更新，这也说明了目前为止，咱们学好JDK7 ，8的HashMap 足以应对
• TreeMap在JDK15 进行拓展了一些方法