前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一道简单的HashMap面试题所想到的...

一道简单的HashMap面试题所想到的...

作者头像
一枝花算不算浪漫
发布2018-12-14 15:04:40
5140
发布2018-12-14 15:04:40
举报

前言

看到一个JDK1.7和JDK1.8中关于HashMap的一个面试题:

JDK1.7和1.8中HashMap中链表的插入的方式有什么不同?

原以为自己对HashMap的源码理解的还算可以了,应该足够应付面试了。但是看到这个问题自己确实也是懵逼了一下。 查了下资料,答案是JDK1.7是插入到首部,1.8改为了尾部。

既然有改变那么就想知道是为什么了,原因其实很简答,JDK1.7中经常面试会问 并发下put 为何会导致死循环? 其实这个死循环到了JDK1.8 就不会出现了,仅仅是因为 put的后的数据放到了链表的尾部。

这里再回顾下JDK1.7 的循环导致死循环的问题,下面的图是手画图,辅助文字说明: JDK1.7 扩容主要代码:

假设:HashMap中table的大小为2,有两个元素3.7,5 这时会进行扩容,图如下:

图画的很简陋,自己看着边看代码边想出来的。哈哈哈,总感觉用一些在线画图工作看着很别扭,而且是没有灵魂的。(不瞎扯了,扯远了) 这里主要是元素3,7形成了死循环,所以这里会出现问题。

而在JDK1.8 中,因为插入顺序变成了尾部插入,也就是说3的next一直都会为7,元素扩容的情况下不会改变元素的顺序,所以就可以避免这种死链了。

果然看似不起眼的设计都是有自己独特的道理,又加深了自己对HashMap的理解了,每天都能进步一点点,真好。 感谢掘金文章的帮助:HashMap为何从头插入改为尾插入

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018-11-21 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档