1.hashcode����Դ��
2.JDK成长记7：3张图搞懂HashMap底层原理！法分析
3.String源码分析(1)--哈希篇
4.HashMap实现原理一步一步分析(1-put方法源码整体过程)
hashcode����Դ��
分享一个关于IDEA的源码源码有趣问题。最近，法分析有朋友在使用Lombok的源码源码@Data注解时遇到了奇怪的现象，代码中一个布尔类型赋值给整型，法分析居然没有报错。源码源码侠剑江湖 源码他将问题发给了我，法分析我一开始也觉得不可思议。源码源码经过研究，法分析我发现原因可能出在IDEA上，源码源码而并非Lombok插件本身。法分析
为了验证我的源码源码猜想，我在本地环境中复现了问题。法分析在源文件中，源码源码我只添加了@Data注解。法分析经过编译，我发现Lombok自动为我们生成了无参构造函数、getter和setter方法、equals和hashCode方法等。这让我意识到@Data注解实际上是一个复合注解，包含了多个功能。
在深入研究中，我发现真正生成hashCode方法的注解应该是@EqualsAndHashCode。为了排除干扰，我将@Data注解替换为@EqualsAndHashCode。结果，生成的方法确实少了，而且我不关心这些方法。观察到hashCode方法的第一行代码是int PRIME = true;，我意识到这里可能存在问题。
通过使用反编译工具jd-gui和查看字节码，我发现hashCode方法的akaroa源码实现与预期不符。在jd-gui中，我看到的hashCode方法的第一个命令使用的是整型入栈指令，值为，而不是true。这个PRIME变量似乎没有被实际使用，这个问题暂且搁置。
在查看字节码时，我注意到hashCode方法的实现是通过整型入栈指令bipush生成的，值为。经过验证，我有理由怀疑IDEA在显示int PRIME = true时存在BUG。
尽管我在网络上进行了深入搜索，但并未找到与此问题相关的详细资料。我尝试了多种搜索策略，包括使用jd-gui工具进行反编译和直接查看字节码。虽然我未能找到权威证据证明这是IDEA的BUG，但基于上述发现，我确信这是IDEA的一个问题。
这个发现为我提供了丰富的素材，我感到非常兴奋。尽管没有找到直接的权威证据，但我的分析和验证过程让我确信这是一个值得记录的问题。关于这个现象背后的原因，我在网上也找到了一些线索，包括关于常量折叠的解释和Lombok源代码中的相关提交记录。
在深入探讨IDEA的BUG时，我还提到了另一个案例，即IDEA在Debug模式下对ConcurrentLinkedQueue的处理方式可能导致空指针异常。这个问题最终被确认为IDEA的特性，并提供了关闭相关配置的解决方案。
总的夜阑源码来说，这篇文章分享了我对这个问题的探索过程、发现的线索以及最后的分析结果。尽管没有找到绝对的证据，但基于我的研究和分析，我确信IDEA在这特定情况下存在BUG。
JDK成长记7：3张图搞懂HashMap底层原理！
一句话讲， HashMap底层数据结构，JDK1.7数组+单向链表、JDK1.8数组+单向链表+红黑树。
在看过了ArrayList、LinkedList的底层源码后，相信你对阅读JDK源码已经轻车熟路了。除了List很多时候你使用最多的还有Map和Set。接下来我将用三张图和你一起来探索下HashMap的底层核心原理到底有哪些？
首先你应该知道HashMap的核心方法之一就是put。我们带着如下几个问题来看下图：
如上图所示，put方法调用了putVal方法，之后主要脉络是：
如何计算hash值？
计算hash值的算法就在第一步，对key值进行hashCode()后，对hashCode的值进行无符号右移位和hashCode值进行了异或操作。为什么这么做呢？其实涉及了很多数学知识，简单的说就是尽可能让高和低位参与运算，可以减少hash值的冲突。
默认容量和扩容阈值是多少？
如上图所示，很明显第二步回调用resize方法，获取到默认容量为，这个在源码里是1<<4得到的，1左移4位得到的。之后由于默认扩容因子是0.，所以两者相乘就是扩容大小阈值*0.=。之后就分配了一个大小为的塑封源码Node[]数组，作为Key-Value对存放的数据结构。
最后一问题是，如何进行hash寻址的？
hash寻址其实就在数组中找一个位置的意思。用的算法其实也很简单，就是用数组大小和hash值进行n-1&hash运算，这个操作和对hash取模很类似，只不过这样效率更高而已。hash寻址后，就得到了一个位置，可以把key-value的Node元素放入到之前创建好的Node[]数组中了。
当你了解了上面的三个原理后，你还需要掌握如下几个问题:
还是老规矩，看如下图：
当hash值计算一致，比如当hash值都是时，Key-Value对的Node节点还有一个next指针，会以单链表的形式，将冲突的节点挂在数组同样位置。这就是数据结构中所提到解决hash 的冲突方法之一：单链法。当然还有探测法+rehash法有兴趣的人可以回顾《数据结构和算法》相关书籍。
但是当hash冲突严重的时候，单链法会造成原理链接过长，导致HashMap性能下降，因为链表需要逐个遍历性能很差。所以JDK1.8对hash冲突的算法进行了优化。当链表节点数达到8个的时候，会自动转换为红黑树，自平衡的一种二叉树，有很多特点，比如区分红和黑节点等，具体大家可以看小灰算法图解。红黑树的boosttree源码遍历效率是O(logn)肯定比单链表的O(n)要好很多。
总结一句话就是，hash冲突使用单链表法+红黑树来解决的。
上面的图，核心脉络是四步，源码具体的就不粘出来了。当put一个之后，map的size达到扩容阈值，就会触发rehash。你可以看到如下具体思路：
情况1:如果数组位置只有一个值：使用新的容量进行rehash，即e.hash & (newCap - 1)
情况2:如果数组位置有链表，根据 e.hash & oldCap == 0进行判断，结果为0的使用原位置，否则使用index + oldCap位置,放入元素形成新链表，这里不会和情况1新的容量进行rehash与运算了，index + oldCap这样更省性能。
情况3：如果数组位置有红黑树，根据split方法，同样根据 e.hash & oldCap == 0进行树节点个数统计，如果个数小于6，将树的结果恢复为普通Node，否则使用index + oldCap，调整红黑树位置，这里不会和新的容量进行rehash与运算了，index + oldCap这样更省性能。
你有兴趣的话，可以分别画一下这三种情况的图。这里给大家一个图，假设都出发了以上三种情况结果如下所示：
上面源码核心脉络，3个if主要是校验了一堆，没做什么事情，之后赋值了扩容因子，不传递使用默认值0.，扩容阈值threshold通过tableSizeFor(initialCapacity);进行计算。注意这里只是计算了扩容阈值，没有初始化数组。代码如下：
竟然不是大小*扩容因子？
n |= n >>> 1这句话，是在干什么？n |= n >>> 1等价于n = n | n >>>1; 而|表示位运算中的或，n>>>1表示无符号右移1位。遇到这种情况，之前你应该学到了，如果碰见复杂逻辑和算法方法就是画图或者举例子。这里你就可以举个例子：假设现在指定的容量大小是,n=cap-1=，那么计算过程应该如下：
n是int类型，java中一般是4个字节，位。所以的二进制： 。
最后n+1=，方法返回，赋值给threshold=。再次注意这里只是计算了扩容阈值，没有初始化数组。
为什么这么做呢？一句话，为了提高hash寻址和扩容计算的的效率。
因为无论扩容计算还是寻址计算，都是二进制的位运算，效率很快。另外之前你还记得取余(%)操作中如果除数是2的幂次方则等同于与其除数减一的与(&)操作。即 hash%size = hash & (size-1)。这个前提条件是除数是2的幂次方。
你可以再回顾下resize代码，看看指定了map容量，第一次put会发生什么。会将扩容阈值threshold，这样在第一次put的时候就会调用newCap = oldThr;使得创建一个容量为threshold的数组，之后从而会计算新的扩容阈值newThr为newCap*0.=*0.=。也就是说map到了个元素就会进行扩容。
除了今天知识，技能的成长，给大家带来一个金句甜点，结束我今天的分享：坚持的三个秘诀之一目标化。
坚持的秘诀除了上一节提到的视觉化，第二个秘诀就是目标化。顾名思义，就是需要给自己定立一个目标。这里要提到的是你的目标不要定的太高了。就比如你想要增加肌肉，给自己定了一个目标，每天5组，每次个俯卧撑，你看到自己胖的身形或者海报，很有刺激，结果开始前两天非常厉害，干劲十足，特别奥利给。但是第三天，你想到要个俯卧撑，你就不想起床，就算起来，可能也会把自己撅死过去......其实你的目标不要一下子定的太大，要从微习惯开始，比如我媳妇从来没有做过俯卧撑，就让她每天从1个开始,不能多，我就怕她收不住，做多了。一开始其实从习惯开始，先变成习惯，再开始慢慢加量。量太大养不成习惯，量小才能养成习惯。很容易做到才能养成，你想想是不是这个道理？
所以，坚持的第二个秘诀就是定一个目标，可以通过小量目标，养成微习惯。比如每天你可以读五分钟书或者5分钟成长记，不要多，我想超过你也会睡着了的.....
最后，大家可以在阅读完源码后，在茶余饭后的时候问问同事或同学，你也可以分享下，讲给他听听。
String源码分析(1)--哈希篇
本文基于JDK1.8，从Java中==符号的使用开始，解释了它判断的是对象的内存地址而非内容是否相等。接着，通过分析String类的equals()方法实现，说明了在比较字符串时，应使用equals()而非==，因为equals()方法可以准确判断字符串内容是否相等。
深入探讨了String类作为“值类”的特性，即它需要覆盖Object类的equals()方法，以满足比较字符串时逻辑上相等的需求。同时，强调了在覆盖equals()方法时也必须覆盖hashCode()方法，以确保基于散列的集合（如HashMap、HashSet和Hashtable）可以正常工作。解释了哈希码（hashcode）在将不同的输入映射成唯一值中的作用，以及它与字符串内容的关系。
在分析String类的hashcode()方法时，介绍了计算哈希值的公式，包括使用这个奇素数的原因，以及其在计算性能上的优势。进一步探讨了哈希碰撞的概念及其产生的影响，提出了防止哈希碰撞的有效方法之一是扩大哈希值的取值空间，并介绍了生日攻击这一概念，解释了它如何在哈希空间不足够大时制造碰撞。
最后，总结了哈希碰撞与散列表性能的关系，以及在满足安全与成本之间找到平衡的重要性。提出了确保哈希值的最短长度的考虑因素，并提醒读者在理解和学习JDK源码时，可以关注相关公众号以获取更多源码分析文章。
HashMap实现原理一步一步分析(1-put方法源码整体过程)
本文分享了HashMap内部的实现原理，重点解析了哈希(hash)、散列表(hash table)、哈希码(hashcode)以及hashCode()方法等基本概念。
哈希(hash)是将任意长度的输入通过散列算法转换为固定长度输出的过程，建立一一对应关系。常见算法包括MD5加密和ASCII码表。
散列表(hash table)是一种数据结构，通过关键码值映射到表中特定位置进行快速访问。
哈希码(hashcode)是散列表中对象的存储位置标识，用于查找效率。
Object类中的hashCode()方法用于获取对象的哈希码值，以在散列存储结构中确定对象存储地址。
在存储字母时，使用哈希码值对数组大小取模以适应存储范围，防止哈希碰撞。
HashMap在JDK1.7中使用数组+链表结构，而JDK1.8引入了红黑树以优化性能。
HashMap内部数据结构包含数组和Entry对象，数组用于存储Entry对象，Entry对象用于存储键值对。
在put方法中，首先判断数组是否为空并初始化，然后计算键的哈希码值对数组长度取模，用于定位存储位置。如果发生哈希碰撞，使用链表解决。
本文详细介绍了HashMap的存储机制，包括数组+链表的实现方式，以及如何处理哈希碰撞。后续文章将继续深入探讨HashMap的其他特性，如数组长度的优化、多线程环境下的性能优化和红黑树的引入。
