📝个人主页🌹：Eternity._
⏩收录专栏⏪：C++ “ 登神长阶 ”
🤡往期回顾🤡：模拟实现 map与set
🌹🌹期待您的关注 🌹🌹

前言：在数字世界的浩瀚宇宙中，哈希算法如同星辰般璀璨，以其独特的方式照亮了数据处理与信息安全的道路。它们不仅是现代计算体系中的基石，更是连接数据安全、高效检索与分布式系统的桥梁。然而，当我们谈论哈希时，往往更多地聚焦于其上层应用与宏观效果，而忽视了支撑这些奇迹的底层机制与实现细节

本文旨在揭开哈希算法的神秘面纱，带领读者深入哈希的底层世界。我们将从哈希函数的内部逻辑出发，探讨其如何通过一系列的数学变换与位操作，将任意长度的输入数据映射为固定长度的输出值。同时逐步探索哈希表的数据结构、冲突解决策略以及内存管理技巧。通过详细剖析哈希函数的内部逻辑与实现方式，我们将揭示那些隐藏在高效与安全背后的智慧与努力

通过本文的阅读，希望大家不仅能够深入理解哈希算法的底层机制与实现细节，还能够掌握其在实际应用中的关键技术与最佳实践

让我们一起踏上学习的旅程，探索它带来的无尽可能！

📚1. unordered系列关联式容器

在C++98中，STL提供了底层为红黑树结构的一系列关联式容器，在查询时效率可达到$lo{g}_{2}N$，即最差情况下需要比较红黑树的高度次，当树中的节点非常多时，查询效率也不理想。最好的查询是，进行很少的比较次数就能够将元素找到，因此在C++11中，STL又提供了4个unordered系列的关联式容器，这四个容器与红黑树结构的关联式容器使用方式基本类似，只是其底层结构不同

🧩unordered_map

unordered_map在线文档说明

• unordered_map是存储<key, value>键值对的关联式容器，其允许通过keys快速的索引到与其对应的value。
• 在unordered_map中，键值通常用于唯一地标识元素，而映射值是一个对象，其内容与此键关联。键和映射值的类型可能不同。
• 在内部,unordered_map没有对<kye, value>按照任何特定的顺序排序, 为了能在常数范围内找到key所对应的value，unordered_map将相同哈希值的键值对放在相同的桶中。
• unordered_map容器通过key访问单个元素要比map快，但它通常在遍历元素子集的范围迭代方面效率较低。
• unordered_maps实现了直接访问操作符(operator[])，它允许使用key作为参数直接访问value。
• 它的迭代器至少是前向迭代器

🌸接口说明

unordered_map的构造

unordered_map的容量

unordered_map的迭代器

unordered_map的元素访问

unordered_map的查询

unordered_map的修改操作

🧩unordered_set

unordered_set在线文档说明

• unordered_set 中的每个元素都是唯一的，因为它不允许有重复的元素
• 元素的存储顺序是不确定的，这取决于元素的哈希值和容器当前的哈希表的状态
• 由于使用了哈希表，unordered_set 提供了平均情况下常数时间复杂度的查找、插入和删除操作

🌺接口说明

unordered_set的构造

unordered_set的容量

unordered_set的迭代器

unordered_set的查询

unordered_set的修改操作

这里介绍的两个unordered系列的关联式容器和map和set还是有点相似的，我们再来几道题目来熟练掌握它们的使用
重复n次的元素
两个数组的交集

📜2. 底层结构

unordered系列的关联式容器之所以效率比较高，是因为其底层使用了哈希结构

🌈哈希概念

顺序结构以及平衡树中，元素关键码与其存储位置之间没有对应的关系，因此在查找一个元素时，必须要经过关键码的多次比较。顺序查找时间复杂度为O(N)，平衡树中为树的高度，即O($lo{g}_{2}N$)，搜索的效率取决于搜索过程中元素的比较次数

可以不经过任何比较，一次直接从表中得到要搜索的元素。如果构造一种存储结构，通过某种函数(hashFunc)使元素的存储位置与它的关键码之间能够建立一一映射的关系，那么在查找时通过该函数可以很快找到该元素，这就是最理想的搜索方法

在该结构中插入，查找元素时：

• 插入元素： 根据待插入元素的关键码，以此函数计算出该元素的存储位置并按此位置进行存放
• 搜索元素： 对元素的关键码进行同样的计算，把求得的函数值当做元素的存储位置，在结构中按此位置取元素比较，若关键码相等，则搜索成功

注意：哈希方法中使用的转换函数称为哈希(散列)函数，构造出来的结构称为哈希表(Hash Table)(或者称散列表)

示例：数据集合{1，7，6，4，5，9}；

哈希函数设置为：hash(key) = key % capacity; capacity为存储元素底层空间总的大小

用该方法进行搜索不必进行多次关键码的比较，因此搜索的速度比较快，但是有成千上万的数，总会有几个数，取余后相等，那我们该怎么存放值呢？

hash(5) = 5 % 10 = 5;
hash(55) = 55 % 10 = 5;

这时就要引入一个新的概念 -> 哈希冲突

🌞哈希冲突

对于两个数据元素的关键字$k_i$和 $k_j$(i != j)，有$k_i$ != $k_j$，但有：Hash($k_i$) == Hash($k_j$)，导致这两个不同的键被映射到同一个存储位置（桶或槽位）的现象，即：不同关键字通过相同哈希哈数计算出相同的哈希地址，该种现象称为哈希冲突或哈希碰撞

我们把把具有不同关键码而具有相同哈希地址的数据元素称为“同义词”

注意：哈希函数的设计目标是尽量减少冲突，但完全避免冲突几乎是不可能的

🌙哈希函数

引起哈希冲突的一个原因可能是：哈希函数设计不够合理

哈希函数设计原则

• 哈希函数的定义域必须包括需要存储的全部关键码，而如果散列表允许有m个地址时，其值域必须在0到m-1之间
• 哈希函数计算出来的地址能均匀分布在整个空间中
• 哈希函数应该比较简单

常见哈希函数

直接定址法–(常用)

取关键字的某个线性函数为散列地址：Hash（Key）= A*Key + B
优点：简单、均匀
缺点：需要事先知道关键字的分布情况
使用场景：适合查找比较小且连续的情况

除留余数法–(常用)

设散列表中允许的地址数为m，取一个不大于m，但最接近或者等于m的质数p作为除数，
按照哈希函数：Hash(key) = key% p(p<=m),将关键码转换成哈希地址

注意：哈希函数设计的越精妙，产生哈希冲突的可能性就越低，但是无法避免哈希冲突

⭐哈希冲突解决

解决哈希冲突两种常见的方法是：闭散列和开散列

🌄闭散列

闭散列： 也叫开放定址法，当发生哈希冲突时，如果哈希表未被装满，说明在哈希表中必然还有空位置，那么可以把key存放到冲突位置中的“下一个” 空位置中去

线性探测

如果和上面讲的一样，现在需要插入元素55，先通过哈希函数计算哈希地址，hashAddr为5，
因此55理论上应该插在该位置，但是该位置已经放了值为5的元素，即发生哈希冲突

线性探测：从发生冲突的位置开始，依次向后探测，直到寻找到下一个空位置为止

• 插入

• 通过哈希函数获取待插入元素在哈希表中的位置
• 如果该位置中没有元素则直接插入新元素，如果该位置中有元素发生哈希冲突，使用线性探测找到下一个空位置，插入新元素

• 删除

• 采用闭散列处理哈希冲突时，不能随便物理删除哈希表中已有的元素，若直接删除元素会影响其他元素的搜索。比如删除元素5，如果直接删除掉，5查找起来可能会受影响。因此线性探测采用标记的伪删除法来删除一个元素

// 哈希表每个空间三种状态
// EMPTY此位置空， EXIST此位置已经有元素， DELETE元素已经删除
enum State
{
	EMPTY, 
	EXIST, 
	DELETE
};

线性探测的实现

template<class K, class V>
struct HashData
{
	pair<K, V> _kv;
	Status _s;
};

template<class K, class V, class Hash = HashFunc<K>>
class HashTable
{
public:
	HashTable()
	{
		_tables.resize(10);
	}

	bool Insert(const pair<K, V>& kv)
	{
		if (Find(kv.first))
		{
			return false;
		}
		// 负载因子 -> 哈希表扩容
		if (_n * 10 / _tables.size() == 7)
		{
			size_t newSize = _tables.size() * 2;
			HashTable<K, V, Hash> newHT;
			newHT._tables.resize(newSize);

			// 遍历旧表
			for (size_t i = 0; i < _tables.size(); i++)
			{
				if(_tables[i]._s == EXIST)
				{
					// 复用Insert
					newHT.Insert(_tables[i]._kv);
				}
			}
			// 交换两个表的数据
			_tables.swap(newHT._tables);
		}
		Hash hf;
		// 线性探测
		size_t hashi = hf(kv.first) % _tables.size();
		while (_tables[hashi]._s == EXIST)
		{
 			hashi++;
			hashi %= _tables.size();
		}
		_tables[hashi]._kv = kv;
		_tables[hashi]._s = EXIST;
		++_n;

		return true;
	}
	HashData<K, V>* Find(const K& key)
	{
		Hash hf;
		size_t hashi = hf(key) % _tables.size();
		while (_tables[hashi]._s != EMPTY)
		{
			if (_tables[hashi]._kv.first == key)
			{
				return &_tables[hashi];
			}

			hashi++;
			hashi %= _tables.size();
		}

		return NULL;
	}

	// 伪删除法
	bool Erase(const K& key)
	{
		HashData<K, V>* ret = Find(key);
		if (ret)
		{
			ret->_s = DELETE;
			--_n;
			return true;
		}
		else
		{
			return false;
		}
	}
private:
	vector < HashData<K, V>> _tables;
	size_t _n = 0; // 储存的关键字数据的个数
};

关于哈希表的取余
当我们的key不是整形的时候(常见的是string)，我们该怎么计算它的hashi? 这里又得依靠我们的仿函数HashFunc，又因为我们string也是很常见的，我们将模板特化一下

template<class K>
struct HashFunc
{
	size_t operator()(const K& key)
	{
		return (size_t)key;
	}
};
template<>
struct HashFunc<string>
{
	size_t operator()(const string& key)
	{
		size_t hash = 0;
		for (auto e : key)
		{
			// 避免因为顺序不一样而产生一样的值 BKDR
			// 避免 abc,acb同值不同意
			e *= 31;
			hash += e;
		}
		return hash;
	}
};

关于哈希表的扩容

• 线性探测优点：实现非常简单
• 线性探测缺点：一旦发生哈希冲突，所有的冲突连在一起，容易产生数据“堆积”，即：不同关键码占据了可利用的空位置，使得寻找某关键码的位置需要许多次比较，导致搜索效率降低

🏞️开散列

开散列： 又叫链地址法(开链法)，首先对关键码集合用散列函数计算散列地址，具有相同地址的关键码归于同一子集合，每一个子集合称为一个桶，各个桶中的元素通过一个单链表链接起来，各链表的头结点存储在哈希表中

注意：开散列中每个桶中放的都是发生哈希冲突的元素

开散列实现

template<class K, class V>
struct HashNode
{
	HashNode* _next;
	pair<K, V> _kv;
	
	HashNode(const pair<K, V>& kv)
		:_kv(kv)
		,_next(nullptr)
	{}
};

template<class K, class V, class Hash = HashFunc<K>>
class HashTable
{
	typedef HashNode<K, V> Node;

public:
	HashTable()
	{
		_tables.resize(10);
	}

	~HashTable()
	{
		for (size_t i = 0; i < _tables.size(); i++)
		{
			Node* cur = _tables[i];
			while (cur)
			{
				Node* _next = cur->_next;
				delete cur;
				cur = _next;
			}
			_tables[i] = nullptr;
		}
	}

	bool Insert(const pair<K, V>& kv)
	{
		Hash hf;

		if (Find(kv.first))
		{
			return false;
		}

		// 负载因子
		if (_n == _tables.size())
		{

			vector<Node*> newTables;
			newTables.resize(_tables.size() * 2);

			// 遍历旧表
			for (size_t i = 0; i < _tables.size(); i++)
			{
				Node* cur = _tables[i];
				while (cur)
				{
					Node* next = cur->_next;

					// 挪动到新表
					size_t hashi = hf(cur->_data) % newTables.size();
					cur->_next = newTables[hashi];
					newTables[hashi] = cur;

					cur = next;
				}

				_tables[i] = nullptr;
			}

			_tables.swap(newTables);
		}

		size_t hashi = hf(kv.first) % _tables.size();
		Node* newnode = new Node(kv);

		// 头插
		newnode->_next = _tables[hashi];
		_tables[hashi] = newnode;
		++_n;
			
		return true;
	}

	Node* Find(const K& key)
	{
		Hash hf;

		size_t hashi = hf(key) % _tables.size();
		Node* cur = _tables[hashi];
		while (cur)
		{
			if (cur->_kv.first) == key)
			{
				return cur;
			}

			cur = cur->_next;
		}

		return nullptr;
	}

	bool Erase(const K& key)
	{
		Hash hf;
		size_t hashi = hf(key) % _tables.size();
		Node* cur = _tables[hashi];
		Node* prev = nullptr; // 记录上一个节点

		while (cur)
		{
			if (cur->_kv.first == key)
			{
				if (prev == nullptr)
				{
					_tables[hashi] = cur->_next;
				}
				else
				{
					prev->_next = cur->_next;
				}
				delete cur;

				return true;
			}
			prev = cur;
			cur = cur->_next;
		}
		return false;
	}

private:
	vector<Node*> _tables;
	size_t _n = 0;
};

开散列增容

桶的个数是一定的，随着元素的不断插入，每个桶中元素的个数不断增多，极端情况下，可
能会导致一个桶中链表节点非常多，会影响的哈希表的性能，因此在一定条件下需要对哈希
表进行增容，那该条件怎么确认呢？开散列最好的情况是：每个哈希桶中刚好挂一个节点，
再继续插入元素时，每一次都会发生哈希冲突，因此，在元素个数刚好等于桶的个数时，可
以给哈希表增容

代码示例：

if (_n == _tables.size())
{
	vector<Node*> newTables;
	newTables.resize(_tables.size() * 2);

	// 遍历旧表
	for (size_t i = 0; i < _tables.size(); i++)
	{
		Node* cur = _tables[i];
		while (cur)
		{
			Node* next = cur->_next;

			// 挪动到新表
			size_t hashi = hf(cur->_data) % newTables.size();
			cur->_next = newTables[hashi];
			newTables[hashi] = cur;

			cur = next;
		}

		_tables[i] = nullptr;
	}

	_tables.swap(newTables);
}

⛰️开散列与闭散列比较

• 应用链地址法处理溢出，需要增设链接指针，似乎增加了存储开销。事实上：由于开地址法必须保持大量的空闲空间以确保搜索效率，如二次探查法要求装载因子a <=0.7，而表项所占空间又比指针大的多，所以使用链地址法反而比开地址法节省存储空间

📖3. 总结

随着技术的不断进步，哈希表作为数据处理领域的基石，其重要性日益凸显。通过本文的探讨，我们深入剖析了哈希表的底层实现原理，从哈希函数的选择、冲突解决策略到动态扩容机制，每一个细节都展现了人类智慧在数据处理领域的卓越成就

然而，哈希表的设计并非一成不变，随着应用场景的不断变化，新的挑战与需求层出不穷。因此，作为开发者与系统架构师，我们不仅要掌握哈希表的基本原理与实现方式，更要具备根据实际需求灵活调整与优化哈希表结构的能力。只有这样，我们才能在复杂多变的数据处理环境中，始终保持高效、稳定、安全的性能表现

希望各位在未来的学习与工作中，保持对知识的渴望与追求，勇于挑战自我，不断探索未知领域。相信在不久的将来，你们定能在数据处理的广阔舞台上大放异彩！

希望本文能够为你提供有益的参考和启示，让我们一起在编程的道路上不断前行！
谢谢大家支持本篇到这里就结束了，祝大家天天开心！