HashMap小记

本文深入解析了HashMap在JDK 1.8版本中的实现细节,包括初始化过程、扩容机制、hash碰撞处理及并发场景下的问题。重点介绍了HashMap如何通过调整容量和负载因子来优化存储效率。

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

HashMap小记
基于jdk1.8版本的

初始化

默认初始化参数是16,负载因子是0.75的情况下,初始化的容量就是
16*0.75= 12
也就是说在放入第13个数据的时候,就会进行扩容到16*2等于32


    static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

    transient Node<K,V>[] table; //table.length =16 ->32

自定义初始化参数的情况下,初始化的值是2的n次方

如果设置参数为5,那么初始化的是8;

如果设置参数为1,那么初始化的是2;

如果设置参数是9,那么初始化的是16;

put

如果table容量为0,resize到默认(扩容2倍)

然后开始放数据,if hash不冲突,直接new Node放进去;

else hash冲突:
如果是树状结构,就直接放树里,

或者 取出旧的node(第一个)然后循环往下走,把数据加到最末尾(或者把数据加到hash值和key都相同的那个数据覆盖)->
如果数据长度(node深度?)大于等于7(一共有8个node节点),就走treeifyBin()逻辑

treeifyBin()逻辑:如果整个hashMap小于64,就进行扩容操作,
,else把链表转换成红黑树结构。

然后最后判断一下,put一个以后,size+1了,是不是大于负载因子*当前容量了,如果是,就进行resize()扩容

resize()扩容

1,判断新的容量和真实的存储量
然后按照新容量来new一个全新的node数据
把旧的数据的地址通过旧数组遍历,赋值过去,并且把旧数组里旧数据的地址置为空
如果在新的容量下,hash模数后不一样了,就放到新的位置去,(不在一个链表node里了)

hash碰撞

之所以hash值取模的时候要取容量-1是因为,如果是双数,最后得到的hash值最后一位一定是0,因为双数是0,0模任何数都是0,就会出现0,2,4,8,10结尾的hash位被用,单数的用不了

如果是取-1,变成单数,那么最后一位是1,hash值的最后一位是0还是1就取决于key本身的最后一位了,这样利用率要比双数高1倍,就会是1,2,3,4,5,6,7,8,9,10

死循环

hashmap在并发中可能会死循环,所以要用concurrentHashMap

死循环是因为在put的时候,如果同时做put,在扩容的时候,可能会因为e.next这种步骤出问题,比如有两个线程在同时扩容
把table1的数据put到table2(newTable)
oldTable = [0,a][1,b][2,c]
线程一 t1
t1.e =a,[o,null]
t1.next = e.next = b,[1,b]

线程二 t2
这时候进来,0已经是null了,直接跳过
把t2.e设置成b[1,null]
t2.next = e.next =c,[2,c]

e.next =newTable[i] //上的原值 e.next = null
newTable[i]=e; //newTable[i] = b
e = next; //因为是往头部加数据,原来的头就跑到了新数据的后面,说白了就是把a和b对调,然后另一个线程还在按照旧模式去继续做a.next(b)往前加,就变成了babababa死循环

参考
https://www.cnblogs.com/dongguacai/p/5599100.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值