利用cpu cache、原子lock实现超高并发场景下hash设计附源码

在码界，最基础、最常用的数据结构出列几位，哈希表（又叫散列）理所当仁不让；

列几处哈希表这位重兵把守的地方：

1. 在linux os kernel，在四层UDP和TCP各有一个全局Hash表，报文经协议栈上送到四层后根据4元组算出哈希索引找到对应的socket表项，从而关联到对应的用户进程；
2. 全互联网都在用的缓存中间件Redis，就是一个Hash表上挂了各种各样的数据项，其他几位NoSql届的key-value翘楚Memcache、Cassandra、Etcd也无一例外。

Hash表既然这么基础、这么普通，能有什么好优化的地方？即便有，也早已路人皆知了吧！本文接下来讲述的优化方式也许早有大咖发表过，但是我真没看到过，这里实现纯属我个人的想法！

先晾几张常规实现方式和优化后的测试数据对比图：

1.单线程，一次查询、修改耗时，优化前后对比图：

2.同时并发16个线程操作Hash表（每个线程绑定cpu核，注意这里超线程核不参与），一次查询、修改耗时，优化前后对比图：

测试说明：
1.哈希桶长3