hash

ArrayList、Vector、LinkedList的存储性能和特性 ArrayList 和Vector都是使用数组方式存储数据 ，此数组元素数大于实际存储的数据以便增加和插入元素，它们都允许直接按序号索引元素，但是插入元素要涉及数组元素移动等内存操作，所以索引数据快而插入数据慢，Vector中的方法由于添加了synchronized修饰，因此Vector是线程安全的容器，但性能上较ArrayList差，因此已经是Java中的遗留容器。 LinkedList使用 双向链表 实现存储（将内存中零散的内存单元通过附加的引用关联起来，形成一个可以按序号索引的线性结构，这种链式存储方式与数组的连续存储方式相比，内存的利用率更高）， 按序号索引数据需要进行前向或后向遍历 ，但是插入数据时只需要记录本项的前后项即可，所以插入速度较快。 TreeMap的底层实现 TreeMap 的实现就是红黑树数据结构，也就说是一棵自平衡的排序二叉树，这样就可以保证当需要快速检索指定节点。 红黑树的插入、删除、遍历时间复杂度都为O(lgN)，所以性能上低于哈希表。但是哈希表无法提供键值对的有序输出，红黑树因为是排序插入的，可以按照键的值的大小有序输出。红黑树性质： 性质1：每个节点要么是红色，要么是黑色。 性质2：根节点永远是黑色的。 性质3：所有的叶节点都是空节点（即 null），并且是黑色的。 性质4

存储类型 包含键值对的无序散列表。value只能是字符串，不能嵌套其他类型。 同样是存储字符串，Hash与String的主要区别？ 1、把所有相关的值聚集到一个key中，节省内存空间 2、只使用一个key，减少key冲突 3、当需要批量获取值的时候，只需要使用一个命令，减少内存/IO/CPU的消耗 Hash不适合的场景： 1、Field不能单独设置过期时间 2、没有bit操作 3、需要考虑数据量分布的问题（value值非常大的时候，无法分布到多个节点） 存储（实现）原理 Redis的Hash本身也是一个KV的结构，类似于Java中的HashMap。 外层的哈希（RedisKV的实现）只用到了hashtable。当存储hash数据类型时，我们把它叫做内层的哈希。内层的哈希底层可以使用两种数据结构实现： ziplist：OBJ_ENCODING_ZIPLIST（压缩列表） hashtable：OBJ_ENCODING_HT（哈希表） 执行命令 ziplist压缩列表 ziplist是一个经过特殊编码的双向链表，它不存储指向上一个链表节点和指向下一个链表节点的指针，而是存储上一个节点长度和当前节点长度，通过牺牲部分读写性能，来换取高效的内存空间利用率，是一种时间换空间的思想。只用在字段个数少，字段值小的场景里面。 ziplist的内部结构 ziplist.c源码第16行的注释：

博客地址： https://ainyi.com/69 三月来了，春天还会远吗、、 在这里，隆重宣布本博客告别 Vue 传统的 hash 路由，迎接好看而优雅的 history 路由~~ 映照官方说法 vue-router 默认 hash 模式 —— 使用 URL 的 hash 来模拟一个完整的 URL，于是当 URL 改变时，页面不会重新加载 如果不想要很丑的 hash，我们可以用路由的 history 模式，这种模式充分利用 history.pushState API 来完成 URL 跳转而无须重新加载页面 export default new Router({ mode: 'history', routes: [...] )} 当使用 history 模式时，URL 就像正常的 url，例如 https://ainyi.com/about ，好看又优雅！ 不过这种模式要玩好，还需要后台配置支持。因为我们的应用是个单页客户端应用，如果后台没有正确的配置，当用户在浏览器直接访问 https://ainyi.com/about 就会返回 404，因为后端没有 /about 相应的拦截器，自然 404 所以，要在服务端增加一个覆盖所有情况的候选资源：如果 URL 匹配不到任何静态资源，则应该返回同一个 index.html 页面，这个页面就是 app 依赖的页面 后端实现

概述 一致Hash在分布式应用中,是常见的负载均衡方式,多用于资源请求映射分散到具体某一台节点服务器,使得每一台服务器能固定处理部分请求,同时,能较小的减少由于动态增减服务器节点带来请求的失效，保证系统更好对外提供服务。 从问题的发展引入思考 图1.假设现在有200万张图片资源，需要随机的分配到3台服务器 除余法 很多人一下子就想到了除余法,通过给每个图片唯一编号(较少的情况),或者通过hash文件名(假设文件名不重复)得到唯一的数字串,然后除余就能随机存放到服务器。 hash ( 文件名 ) % n 正常情况下这个算法已经基本满足,因为每次除余之后必然会得到0,1,2三个数,分别对应三台服务器,下次需要找回这些图片资源只要按同样的方式hash之后就能在对应服务器找到。 但是当图片资源过多无法满足需要增加一台服务器的时候,因为除数的改变,带来余数的改变,也就是服务器数量的改变,带来存储位置的改变,之前存储的图片资源失去了意义,在缓存服务器中,这会导致大量缓存失效,造成缓存的雪崩,为了解决这些问题,一致性hash应运而生。 揭开一致性Hash神秘面纱 首先了解一下计算一致性hash时采用的方式和步骤： 在一个0~2^32区间的圆环上，计算服务器节点的hash值,。 用同样的方式计算存储数据的hash,并映射到相同的圆上。 然后从数据映射到的位置开始顺时针查找

【BZOJ4917】Hash Killer IV Description 有一天，tangjz造了一个Hash函数： unsigned int Hash(unsigned int v){ unsigned int t = v; t = t + (t << 10); t = t ^ (t >> 6); t = t + (t << 3); t = t ^ (t >> 11); t = t + (t << 16); return t; } 小Q发现这个函数非常不靠谱，对于任意的t，他可以随手构出个数字v使得Hash(v)=t。 小Q现在想考考你，他将给出Q个t，你需要构造出满足条件的v。 Input 第一行包含一个正整数Q(1<=Q<=100000)，表示询问的个数。 接下来Q行，每行一个整数t(0<=t<2^32)，表示询问的t。 输入数据保证对于每个t至少存在一组解。 Output 对于每组数据输出一行一个整数，即合法的v，若有多组可行解，输出任意一组。 Sample Input 4 614278301 1228622139 1841720774 2457244278 Sample Output 1 2 3 4 题解 ：发现每个操作都是能反过来的。对于操作1,3,5，可以看成是原数*一个数，因为乘的是奇数而模数是偶数，所以反过来做的话直接乘逆元就行了。对于2,4操作，首先最高的6

首先明确几点： 1.unsigned int为4个字节32位 2.异或操作中0是单位元，任何数与1异或相当于取反 3.unsigned无符号类型的数据右移操作均是执行逻辑右移（左高位自动补0） 4.ELFhash算法的核心在于“影响“ 先附上代码： unsigned int ELFhash(char *str) { unsigned int hash=0; unsigned int x=0; while(*str) { hash=(hash<<4)+*str; //1 if((x=hash & 0xf0000000)!=0) //2 { hash^=(x>>24); //影响5-8位，杂糅一次 3 hash&=~x; //清空高四位 4 } str++; //5 } return (hash & 0x7fffffff); //6 } int ELFHash(char *key) { unsigned long h=0; while(*key) { h=(h<<4)+(*key++); unsigned long g=h&0Xf0000000L; if(g) h^=g>>24; h&=~g; } return h%M; } 解释： 首先我们的hash结果是一个unsigned int类型的数据： 0000 0000 0000 0000 1.hash左移4位，将str插入

JDk1.8HashMap的源码分析 HashMap用数组存放数据（总结） 调用键的hashCode()获得键的哈希值 用哈希值，计算一个下标值 i 新建Entry对象来封装键和值 Entry对象放在 i 位置 空位置，直接放入 有数据，依次用equals()比较是否相等 找到相等的，覆盖值 没有相等的，链表连接在一起 负载率、加载因子到0.75 新建翻倍容量的新数组 所有数据，重新哈希，放入新数组 jdk1.8 链表长度到8，转成红黑树 红黑树数据量减少到6，转回成链表 hashCode() Object的方法 Object中默认实现是使用内存地址，作为哈希值 如果对象作为键，放入HashMap，应该重写hashCode()，使用属性数据，来计算哈希值 HashMap中根据hash值求得index的 // 先用key求得hash值 static final int hash ( Object key ) { // h = key.hashCode() 为第一步 取hashCode值 // h ^ (h >>> 16) 为第二步 高位参与运算 int h ; return ( key == null ) ? 0 : ( h = key . hashCode ( ) ) ^ ( h >>> 16 ) ; } JDK1.8HashMap的put方法源码如下 /** * (1)

一、论述题（10分） 1)简述DBMS对SQL解析执行的步骤（2） 1语法分析：分析语句的语法是否符合规范,衡量语句中各表达式的意义 2语义分析：检查语句中涉及的所有数据库对象是否存在，且用户有相应的权限 3视图转换：将涉及视图的查询语句转换为相应的对基表查询语句。 4表达式转换：将复杂的SQL表达式转换为较简单的等效连接表达式 5选择优化器：不同的优化器一般产生不同的“执行计划” 6选择连接方式 Oracle有三种连接方式、对多表连接Oracle可选择适当的连接方式 7选择连接顺序：对多表连接Oracle选择哪对表先连接，选择这两表中哪个表做为源数据表 8选择数据的搜索路径：根据以上条件选择合适的数据搜索路径，如是选用全表搜索还是利用索引或是其他的方式。 9运行“执行计划” 运行执行计划,返回执行结果。运行执行计划的代价根据sql语句的不同可大可小。 1：语法分析 2：权限与对象检查 3： 在共享池中检查是否有完全相同的之前完全解析好的. 如果存在，直接跳过4和5，运行Sql, 此时算soft parse. 4：选择执行计划 5：产生执行计划 2)解释硬解析和软解析的含义和区别（3） 解析:分为硬解析和软解析。 若在共享池中没有找到已有的执行计划,则进行硬解析,否则为软解析。 硬解析指使用优化器对sql语句进行优化,将sql转化为一些等价语句,并选择代价最小的语句生成执行计划;

基于 jdk1.8 Java并发包中提供的一个线程安全且高效的HashMap实现，可以完全替代HashTable，在并发编程的场景中使用频率非常之高。 可能大多人只是知道它使用了多个锁代替HashTable中的单个锁，也就是锁分离技术（Lock Stripping） 实现原理 1.8之前ConcurrentHashMap是使用Segment段来进行，一个段就相当于一个HashMap的数据结构，每个段使用一个锁 1.8之后Segment虽保留，但已经简化属性，仅仅是为了兼容旧版本，使用和HashMap一样的数据结构每个数组位置使用一个锁 再学习中始终要考虑多线程的情况 一.类加载 主要知道以下的一些初始化值 private static final int MAXIMUM_CAPACITY = 1 << 30; //数组最大大小 同HashMap private static final int DEFAULT_CAPACITY = 16;//数组默认大小 static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; private static final int DEFAULT_CONCURRENCY_LEVEL = 16; //兼容旧版保留的值，默认线程并发度，类似信号量 private static final float

HashMap底层原理 hashMap底层原理主要是jdk1.7和1.8以上的区别。 jdk1.7中底层是由数组（也有叫做“位桶”的）+链表实现；jdk1.8中底层是由数组+链表/红黑树实现。 参考学习： https://blog.csdn.net/jswd_50x/article/details/86542240 HashMap面试题 1.谈一下HashMap的特性？ 2.谈一下HashMap的底层原理是什么？ 3.谈一下hashMap中put是如何实现的？ 4.谈一下hashMap中什么时候需要进行扩容，扩容resize()又是如何实现的？ 5.谈一下hashMap中get是如何实现的？ 6.谈一下HashMap中hash函数是怎么实现的？还有哪些hash函数的实现方式？ 7.为什么不直接将key作为哈希值而是与高16位做异或运算？ 8.为什么是16？为什么必须是2的幂？如果输入值不是2的幂比如10会怎么样？ https://blog.csdn.net/sidihuo/article/details/78489820 https://blog.csdn.net/eaphyy/article/details/84386313 9.谈一下当两个对象的hashCode相等时会怎么样？ 10.如果两个键的hashcode相同，你如何获取值对象？ 11.