首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

Redis_字典[通俗易懂]

阅读本文之前要了解的两件事情,第一,Redis是一种Key-Value数据库,第二,字典是一种保存键值对的抽象数据结构。所以不难猜出字典在Redis中应用一定很广泛,实际上,Redis数据库的底层实现就是字典,对数据库的增删查改也是构建在对字典的操作上。那么想要深入理解Redis,字典的解密是不可缺少的。接下来,就让我们一层一层解开指点的面纱,看看它的真面目。 首先看看Redis中有哪些地方使用到了字典 一, 数据库键空间 Redis是一个键值对数据库server,server中的每一个数据库都是一个RedisDB结构,当中RedisDb结构的dict字典保存了数据库中的全部键值对。我们将这个字典称为键空间(key space),键空间和用户直接所见的数据库是直接相应的 二。 Expires字典 Redis数据库结构是一个RedisDb结构,有一个属性expires也是字典,这个字典中保存了数据库中全部键的过期时间,我们称这个字典叫做过期字典 以下贴出RedisDb的数据结构。加深了理解。

03

深入理解JDK8 HashMap

上一篇文章提到,HashMap在JDK7或者JDK8中采用的基本存储结构都是数组+链表形式,可能有人会提出疑问,HashMap在JDK8中不是数组+链表+红黑树吗?本文的回答是。至于为什么JDK8在一定条件下将链表转换为红黑树,我相信很多人都会回答:为了提高查询效率。基本答案可以说是这样的,JDK7中的HashMap对着Entry节点增多,哈希碰撞的概率在慢慢变大,这就直接导致哈希表中的单链表越来越长,这就大大降低了HashMap的查询能力,且时间复杂度可能会退化到O(n)。针对这种情况,JDK8做出了优化,就是在一定的条件下,链表会被转换为红黑树,提升查询效率。 HashMap在JDK8中基本结构示意图如下所示:

01

hashmap底层原理

HashMap 是一个散列表,它存储的内容是键值对(key-value)映射。 HashMap 继承于AbstractMap,实现了Map、Cloneable、java.io.Serializable接口。 HashMap 的实现不是同步的,这意味着它不是线程安全的。它的key、value都可以为null。此外,HashMap中的映射不是有序的。 HashMap 的实例有两个参数影响其性能:“初始容量” 和 “加载因子”。容量 是哈希表中桶的数量,初始容量 只是哈希表在创建时的容量。加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时,则要对该哈希表进行rehash 操作(即重建内部数据结构),从而哈希表将具有大约两倍的桶数。 通常,默认加载因子是 0.75, 这是在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销,但同时也增加了查询成本(在大多数 HashMap 类的操作中,包括 get 和 put 操作,都反映了这一点)。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子,以便最大限度地减少 rehash 操作次数。如果初始容量大于最大条目数除以加载因子,则不会发生 rehash 操作。

03

八、JDK1.8中HashMap扩容机制

前面文章一、深入理解-Java集合初篇 中我们对Java的集合体系进行一个简单的分析介绍,上两篇文章二、Jdk1.7和1.8中HashMap数据结构及源码分析 、三、JDK1.7和1.8HashMap数据结构及源码分析-续 中我们分别对JDK1.7和JDK1.8中HashMap的数据结构、主要声明变量、构造函数、HashMap的put操作方法做了深入的讲解和源码分析。 四、深入理解Java中的HashMap「网易面试快答」文章中主要针对面试中常见的面试问题进行简单解答。 五、深入理解JDK1.7中HashMap哈希冲突解决方案 和 六、深入理解JDK1.8中HashMap哈希冲突解决方案 中对HashMap中哈希冲突及减少哈希冲突的解决方案做详细的介绍,并通过源码加深大家的理解。 七、JDK1.7中HashMap扩容机制 中介绍了JDK1.7中HashMap的扩容机制及扩容过程中可能出现的死锁及数据丢失问题。 本篇文章我们将要介绍JDK1.8中HashMap的扩容机制,并通过一个实例来展示链表的哈希扩容。

02
领券