数组+链表+散链表

复杂度分析

数据结构和算法本身解决的是“快”和“省”的问题，即如何让代码运⾏得更快，如何让代码更省存储空间。所以， 执⾏效率是算法⼀个⾮常重要的考量指标。那如何来衡量你编写的算法代码的执⾏效率呢？一般通过两个方面来说明：**时间复杂度和空间复杂度。关于此类文章很多，在这里我不做过多的描述，有兴趣的同学可以自行百度。

数组

数组概念：是一种线性表数据机构。它是由一组连续的内存空间，来存储一组相同类型的数据

大部分人都已经很熟悉了，我就简单说一下数组为什么查询快，增删慢：
从概念上可以看出 数组的特性：连续的内存空间以及存储的相同类型的数据 ，由于它的这个特性 所以
数组 基于下标的查找比较快(时间复杂度O(1)，这里要注意是基于下标)，但是增删的时候 为了保证内存的连续性 需要大量的迁移工作，所以比较耗时。

链表

链表概念：链表 是通过指针将一组 零散的内存块串联起来使用。所以链表对内存的要求要比数组低的多。

链表分为： 单链表， 双链表 ，循环链表。

我们把链表的一个个的内存块 叫做 节点 ，上图是单链表的结构，其中第一个节点和最后一个节点比较特殊，我们称之为 头结点 和 尾节点
其中尾结点指向的是一个null地址。

我们知道，在进⾏数组的插⼊、删除操作时，为了保持内存数据的连续性，需要做⼤量的数据搬移，所以时间复杂度是O(n)。 ⽽在链表中插⼊或者删除⼀个数据，我们并不需要为了保持内存的连续性⽽搬移结点，因为链表的存储空间本身就不是连续 的。所以，在链表中插⼊和删除⼀个数据是⾮常快速的。

从图中可以看出来，双向链表需要额外的两个空间来存储后继结点和前驱结点的地址。所以，如果存储同样多的数据，
双向链表要⽐单链表占⽤更多的内存空间。虽然两个指针⽐较浪费存储空间，但可以⽀持双向遍历，这样也带来了双向链表操 作的灵活性。

为什么说双向链表的操作，灵活行比单链表更高呢？其实这样说 是有歧义的，或者说有特殊情况的。下面我举个例子：
链表的删除操作，相信大家都很熟悉，当我们删除链表的一个数据时，有以下操作：

1.删除这个数据，也就是节点。
2.把前个节点的指针删除，并指向 要删除节点 的下一个节点。

首先第一步：要删除这个节点，首先要找到他，单链表和双链表的查找操作都是 O(n) ,这一点一样的。
期次第二步：单链表要删除这个节点的前一个节点的指针，因为 单链表 并没有prev指针，所以为了获取前一个节点，我们还是要从头
获取遍历链表，直到找到 p->next=q,即p就是q的前一个节点。

但是对于双链表：因为 双链表存储有prev指针，它可以直接获取到它的前一个节点，并不需要遍历，所以单说第二种情况时，双链表可以在O(1)的时间复杂度搞定，而单向链表需要O(n)的时间复杂度。这就是为什么在实际的软件开发中，双向链表尽管⽐较费内存，但还是 ⽐单链表的应⽤更加⼴泛的原因。如果你熟悉Java语⾔，你肯定⽤过LinkedHashMap这个容器。如果你深⼊研究 LinkedHashMap的实现原理，就会发现其中就⽤到了双向链表这种数据结构。

实际上 这里有一个空间换时间的设计思想。当内存空间充⾜的时候，如果我们更加 追求代码的执⾏速度，我们就可以选择空间复杂度相对较⾼、但时间复杂度相对很低的算法或者数据结构。相反，如果内存⽐ 较紧缺，⽐如代码跑在⼿机或者单⽚机上，这个时候，就要反过来⽤时间换空间的设计思路。

散列表

散列表的英⽂叫“Hash Table”，我们平时也叫它“哈希表”或者“Hash表”。
散列表⽤的是数组⽀持按照下标随机访问数据的特性，所以散列表其实就是数组的⼀种扩展，由数组演化⽽来。可以说，如果 没有数组，就没有散列表。

举子例子：

假如我们有89名选⼿参加学校运动会。为了⽅便记录成绩，每个选⼿胸前都会贴上⾃⼰的参赛号 码。这89名选⼿的编号依次是1到89。现在我们希望编程实现这样⼀个功能，通过编号快速找到对应的选⼿信息。你会怎么做 呢？
我们可以把这89名选⼿的信息放在数组⾥。编号为1的选⼿，我们放到数组中下标为1的位置；编号为2的选⼿，我们放到数组 中下标为2的位置。以此类推，编号为k的选⼿放到数组中下标为k的位置。

这就是典型的散列思想。其中，参赛选⼿的编号我们叫作键（key）或者关键字。我们⽤它来标识⼀个选⼿。我们把参赛编号 转化为数组下标的映射⽅法就叫作散列函数（或“Hash函数”“哈希函数”），⽽散列函数计算得到的值就叫作散列值（或“Hash 值”“哈希值”）。

散列表⽤的就是数组⽀持按照下标随机访问的时候，时间复杂度是O(1)的特性。 我们通过散列函数把元素的键值映射为下标，然后将数据存储在数组中对应下标的位置。当我们按照键值查询元素时，我们⽤ 同样的散列函数，将键值转化数组下标，从对应的数组下标的位置取数据。

刚刚举的学校运动会的例⼦，散列函数⽐较简单，也⽐较容易想到。但是，如果参赛选⼿的编号是随机⽣成的6位数字，⼜或 者⽤的是a到z之间的字符串，该如何构造散列函数呢？我总结了三点散列函数设计的基本要求：

1. 散列函数计算得到的散列值是⼀个⾮负整数；
2. 如果key1 = key2，那hash(key1) == hash(key2)；
3. 如果key1 ≠ key2，那hash(key1) ≠ hash(key2)。

我来解释⼀下这三点。其中，第⼀点理解起来应该没有任何问题。因为数组下标是从0开始的，所以散列函数⽣成的散列值也 要是⾮负整数。第⼆点也很好理解。相同的key，经过散列函数得到的散列值也应该是相同的。 第三点理解起来可能会有问题，我着重说⼀下。这个要求看起来合情合理，但是在真实的情况下，要想找到⼀个不同的key对 应的散列值都不⼀样的散列函数，⼏乎是不可能的。即便像业界著名的MD5、SHA、CRC等哈希算法，也⽆法完全避免这 种散列冲突。⽽且，因为数组的存储空间有限，也会加⼤散列冲突的概率。

再好的散列函数也⽆法避免散列冲突。那究竟该如何解决散列冲突问题呢？我们常⽤的散列冲突解决⽅法有两类，开放寻址法 （open addressing）和链表法（chaining）。

1.开放寻址法

开放寻址法的核⼼思想是，如果出现了散列冲突，我们就重新探测⼀个空闲位置，将其插⼊。那如何重新探测新的位置呢？我 先讲⼀个⽐较简单的探测⽅法，线性探测（Linear Probing）。 当我们往散列表中插⼊数据时，如果某个数据经过散列函数散列之后，存储位置已经被占⽤了，我们就从当前位置开始，依次 往后查找，看是否有空闲位置，直到找到为⽌。我说的可能⽐较抽象，我举⼀个例⼦具体给你说明⼀下。这⾥⾯⻩⾊的⾊块表示空闲位置，橙⾊的⾊块表示已经存储了数据。

在散列表中查找元素的过程有点⼉类似插⼊过程。我们通过散列函数求出要查找元素的键值对应的散列值，然后⽐较数组中下 标为散列值的元素和要查找的元素。如果相等，则说明就是我们要找的元素；否则就顺序往后依次查找。如果遍历到数组中的 空闲位置，还没有找到，就说明要查找的元素并没有在散列表中。

我们不能单纯地把要删除的元素设置为空。这是为什么呢？
还记得我们刚讲的查找操作吗？在查找的时候，⼀旦我们通过线性探测⽅法，找到⼀个空闲位置，我们就可以认定散列表中不 存在这个数据。但是，如果这个空闲位置是我们后来删除的，就会导致原来的查找算法失效。本来存在的数据，会被认定为不 存在。这个问题如何解决呢？
我们可以将删除的元素，特殊标记为deleted。当线性探测查找的时候，遇到标记为deleted的空间，并不是停下来，⽽是继续 往下探测。

不管采⽤哪种探测⽅法，当散列表中空闲位置不多的时候，散列冲突的概率就会⼤⼤提⾼。为了尽可能保证散列表的操作效 率，⼀般情况下，我们会尽可能保证散列表中有⼀定⽐例的空闲槽位。我们⽤装载因⼦（load factor）来表示空位的多少。

散列表的装载因⼦=填⼊表中的元素个数/散列表的⻓度

2.链表法
链表法是⼀种更加常⽤的散列冲突解决办法，相⽐开放寻址法，它要简单很多。我们来看这个图，在散列表中，每个“桶 （bucket）”或者“槽（slot）”会对应⼀条链表，所有散列值相同的元素我们都放到相同槽位对应的链表中。

当插⼊的时候，我们只需要通过散列函数计算出对应的散列槽位，将其插⼊到对应链表中即可，所以插⼊的时间复杂度是 O(1)。当查找、删除⼀个元素时，我们同样通过散列函数计算出对应的槽，然后遍历链表查找或者删除。那查找或删除操作的 时间复杂度是多少呢？
实际上，这两个操作的时间复杂度跟链表的⻓度k成正⽐，也就是O(k)。对于散列⽐较均匀的散列函数来说，理论上 讲，k=n/m，其中n表示散列中数据的个数，m表示散列表中“槽”的个数。

散列表的弊端：

在极端情况下，有些恶意的攻击者，还有可能通过精⼼构造的数据，使得所有的数据经过散列函数之后，都散列到同⼀个槽 ⾥。如果我们使⽤的是基于链表的冲突解决⽅法，那这个时候，散列表就会退化为链表，查询的时间复杂度就从O(1)急剧退化 为O(n)。 如果散列表中有10万个数据，退化后的散列表查询的效率就下降了10万倍。更直接点说，如果之前运⾏100次查询只需要0.1 秒，那现在就需要1万秒。这样就有可能因为查询操作消耗⼤量CPU或者线程资源，导致系统⽆法响应其他请求，从⽽达到拒 绝服务攻击（DoS）的⽬的。这也就是散列表碰撞攻击的基本原理。

散列表的扩容：