Java|阿里面试官：HashMap 熟悉吧？好的，那就来聊聊 Redis 字典吧！聊聊|阿里巴巴

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

最近，小黑哥的一个朋友出去面试，回来跟小黑哥抱怨，面试官不按套路出牌，直接打乱了他的节奏。
事情是这样的，前面面试问了几个 Java 的相关问题，我朋友回答还不错，接下来面试官就问了一句：看来 Java 基础还不错， Java HashMap 你熟悉吧？
我朋友回答。工作经常用，有看过源码。
我朋友本来想着，你随便来吧，这个问题之前已经准备好了，随便问吧。
谁知道，面试官下面一句：
【Java|阿里面试官：HashMap 熟悉吧？好的，那就来聊聊 Redis 字典吧！】那好的，我们来聊聊 Redis 字典吧。
直接将他整蒙逼。

小黑哥的朋友由于没怎么研究过 Redis 字典，所以这题就直接回答不知道了。
当然，如果面试中真不知道，那就回答不了解，直接下一题，不要乱答。
不过这一题，小黑哥觉得还是很可惜，其实 Redis 字典基本原理与 HashMap 差不多，那我们其实可以套用这其中的原理，不求回答满分，但是怎么也可以得个及格分吧~
面试过程真要碰到这个问题，我们可以从下面三个方面回答。

数据结构
元素增加过程
扩容

字典数据结构说起字典，也许大家比较陌生，但是我们都知道 Redis 本身提供 KV 查询的方式，这个 KV 就是其实通过底层就是通过字典保存。
另外， Redis 支持多种数据类型，其中一种类型为 Hash 键，也可以用来存储 KV 数据。
小黑哥刚开始了解的这个数据结构的时候，本来以为这个就是使用字典实现。其实并不是这样的，初始创建 Hash 键，默认使用另外一种数据结构-ZIPLIST(压缩列表) ，以此节省内存空间。
不过一旦以下任何条件被满足， Hash 键的数据结构将会变为字典，加快查询速度。

哈希表中某个键或某个值的长度大于 server.hash_max_ziplist_value （默认值为 64 ）。
压缩列表中的节点数量大于 server.hash_max_ziplist_entries （默认值为 512 ）。

Redis 字典新建时默认将会创建一个哈希表数组，保存两个哈希表。
其中

ht[0

哈希表在第一次往字典中添加键值时分配内存空间，而另一个

ht[1

将会在下文中扩容/缩容才会进行空间分配。

字典中哈希表其实就等同于Java HashMap ，我们知道 Java 采用数组加链表/红黑树的实现方式，其实哈希表也是使用类似的数据结构。