hashmap源码

Java的HashMap在设计时选择不缩容主要是为了保持性能,避免频繁的缩容操作。0.75的扩容因子导致在达到64长度时才会考虑树化,以处理链表过长的情况。尾插法用于处理拉链,确保在添加元素时能检测到链表是否需要转为红黑树。尽管存在极端情况下的不均匀分布风险,但这种设计是基于概率统计和工程实践的平衡。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  1. 为什么没有hashmap缩容
    java语言在使用hashmap就是空间换时间, 就是为了时间.
    缩容划不来, 缩容换不来时间, 还要防止扩缩容反复横跳, 不如不缩, 让用户尽量初始化个大小
    其他更讲究空间的编程语言使用环境下会缩容

  2. 为什么要转红黑树, 不是有0.75扩容因子吗
    树化treeifyBin 前提是长度达到64 , 不然不会转树而是扩一倍.
    拉链减少一半(不管是扩容因子还是小于64造成的), 但是万一一半还是过长呢, 极限情况下的不均匀 (因为64取模 和 64* 0.75 和 8的上限 已经达到数据取样的边界了, 如果这个数据规模下还是其他槽位是空的, 就个别正常hashcode, 泊松分布统计, 千万分支一的概率. 不然只能吐槽说 用户复写的hashcode散列函数复写的太烂了. 同理 非树化 的前提是树 化, 概率更小)
    作为一个工程级的hash数据结构还是要考虑这个情况, 如果发现拉链过长, 转树 (按数学统计, 千万分支一的概率)

  3. 为什么要用尾插法
    原因一: 拉链的大小只能遍历, 没有缓存. 也就尾插的时候遍历等到size, 再判断是否需要变树, 不然没法知道 (当然删除元素的时候)

  4. 树转链表的源码 如何感知链表大小

  5. 死循环到底怎么解决的

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值