数据结构，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 进行拓展了一些方法
