皮皮网
皮皮网

【图种java源码】【seata源码详解】【rpm源码制作】hashcode 源码

时间:2024-12-26 00:39:08 来源:rpc通讯协议源码

1.String源码分析(1)--哈希篇
2.原创|如果懂了HashMap这两点,源码面试就没问题了
3.JDK成长记7:3张图搞懂HashMap底层原理!源码
4.我怀疑这是源码IDEA的BUG,但是源码我翻遍全网没找到证据!
5.HashMap实现原理一步一步分析(1-put方法源码整体过程)

hashcode 源码

String源码分析(1)--哈希篇

       本文基于JDK1.8,源码从Java中==符号的源码图种java源码使用开始,解释了它判断的源码是对象的内存地址而非内容是否相等。接着,源码通过分析String类的源码equals()方法实现,说明了在比较字符串时,源码应使用equals()而非==,源码因为equals()方法可以准确判断字符串内容是源码否相等。

       深入探讨了String类作为“值类”的源码特性,即它需要覆盖Object类的源码equals()方法,以满足比较字符串时逻辑上相等的源码需求。同时,强调了在覆盖equals()方法时也必须覆盖hashCode()方法,以确保基于散列的集合(如HashMap、HashSet和Hashtable)可以正常工作。解释了哈希码(hashcode)在将不同的输入映射成唯一值中的作用,以及它与字符串内容的关系。

       在分析String类的hashcode()方法时,介绍了计算哈希值的公式,包括使用这个奇素数的原因,以及其在计算性能上的优势。进一步探讨了哈希碰撞的概念及其产生的影响,提出了防止哈希碰撞的有效方法之一是扩大哈希值的取值空间,并介绍了生日攻击这一概念,解释了它如何在哈希空间不足够大时制造碰撞。

       最后,总结了哈希碰撞与散列表性能的关系,以及在满足安全与成本之间找到平衡的重要性。提出了确保哈希值的最短长度的考虑因素,并提醒读者在理解和学习JDK源码时,可以关注相关公众号以获取更多源码分析文章。

原创|如果懂了HashMap这两点,面试就没问题了

       HashMap在后端面试中经常被问及,比如默认初始容量、加载因子和线程安全性等问题。通常,这些问题能对答如流,表明对HashMap有较好的理解。然而,seata源码详解近期团队的技术分享中,我从两个角度获得了一些新见解,现在分享给大家。

       首先,让我们探讨如何找到比初始容量值大的最小的2的幂次方整数。通常,使用默认构造器时,HashMap的初始容量为,加载因子为0.。这样做可能导致在数据量大时频繁进行扩容,影响性能。因此,通常会预估容量并使用带容量的构造器创建。通过分析源码,我们可以得知HashMap数组部分长度范围为[0,2^]。要找到比初始容量大的最小的2的幂次方整数,我们需重点关注tableSizeFor方法。此方法巧妙地设计,当输入的容量本身为2的整数次幂时,返回该容量;否则,返回比输入容量大的最小2的整数次幂。此设计旨在确保容量始终为2的整数次幂,从而优化哈希操作,避免哈希冲突。在获取key对应的数组下标时,通过key的哈希值与数组长度-1进行与运算,这种方法依赖于容量为2的整数次幂的特性,以确保哈希值的分散性。

       容量为2的整数次幂的关键在于,它允许通过与运算高效地定位key对应的数组下标。容量不是2的整数次幂时,与运算后的哈希值可能会导致位数为0的冲突,影响数据定位的准确性。tableSizeFor方法在计算过程中,首先对输入的容量进行-1操作,以避免容量本身就是2的整数次幂时,计算结果为容量的2倍。接着,通过连续的移位与或操作,找到比输入容量大的最小的2的整数次幂。这种方法确保了内存的有效利用,避免了不必要的rpm源码制作扩容。

       下面,让我们通过一个示例来详细解释算法中的移位与或操作。假设初始容量n为一个位的整数,例如:n = xxx xxxxxxxx xxxxxxxx xxxxxxxx(x表示该位上是0还是1,具体值不关心)。首先,执行n |= n >> 1操作,用n本身与右移一位后的n进行或操作,可以将n的最高位的1及其紧邻的右边一位置为1。接下来,重复此操作,进行n |= n >> 2、n |= n >> 4、n |= n >> 8和n |= n >> 。最后,将n与最大容量进行比较,如果大于等于2^,则返回最大容量;否则,返回n + 1,找到比n大的最小的2的整数次幂。

       在实践中,这确保了在给定容量范围内高效地找到合适的容量值。例如,输入时,输出为,即比大的最小的2的整数次幂。

       接下来,我们探讨HashMap在处理key时进行哈希处理的特殊操作。在执行put操作时,首先对key进行哈希处理。在源码中,可以看到执行了(h = key.hashCode()) ^ (h >> )的操作。这个操作将key的hashCode值与右移位后的值进行异或操作,将哈希值的高位和低位混合计算,以生成更离散的哈希值。通过演示,我们可以发现,当三个不同的key生成的hashCode值的低位完全相同、高位不同时,它们在数组中的下标会相同,导致哈希冲突。通过异或操作,网孤源码我们解决了这个问题,使得经过哈希处理后的key能被更均匀地分布在数组中,提高了数据的分散性,减少了哈希冲突。

       总结来说,这两个点揭示了HashMap在容量和哈希处理上的一些巧妙设计,这些设计提高了数据结构的效率和性能。理解这些原理不仅有助于解决面试问题,还能在实际工作中借鉴这些思想,优化数据存储和访问效率。希望我的讲解能帮助大家掌握这两个知识点,如有任何疑问,欢迎留言或私聊。通过深入研究和实践,我们可以更好地理解和利用HashMap这一强大的数据结构。

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个的时候,会自动转换为红黑树,自平衡的一种二叉树,有很多特点,比如区分红和黑节点等,具体大家可以看小灰算法图解。红黑树的遍历效率是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分钟成长记,不要多,我想超过你也会睡着了的.....

       最后,大家可以在阅读完源码后,在茶余饭后的时候问问同事或同学,你也可以分享下,讲给他听听。

我怀疑这是IDEA的BUG,但是我翻遍全网没找到证据!

       分享一个关于IDEA的有趣问题。最近,有朋友在使用Lombok的@Data注解时遇到了奇怪的现象,代码中一个布尔类型赋值给整型,居然没有报错。他将问题发给了我,我一开始也觉得不可思议。经过研究,我发现原因可能出在IDEA上,而并非Lombok插件本身。

       为了验证我的猜想,我在本地环境中复现了问题。在源文件中,我只添加了@Data注解。经过编译,我发现Lombok自动为我们生成了无参构造函数、getter和setter方法、equals和hashCode方法等。这让我意识到@Data注解实际上是一个复合注解,包含了多个功能。

       在深入研究中,我发现真正生成hashCode方法的注解应该是@EqualsAndHashCode。为了排除干扰,我将@Data注解替换为@EqualsAndHashCode。结果,生成的方法确实少了,而且我不关心这些方法。观察到hashCode方法的第一行代码是int PRIME = true;,我意识到这里可能存在问题。

       通过使用反编译工具jd-gui和查看字节码,我发现hashCode方法的实现与预期不符。在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。

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的其他特性,如数组长度的优化、多线程环境下的性能优化和红黑树的引入。

更多内容请点击【探索】专栏