2020年1月零散笔记

最新推荐文章于 2025-12-17 15:38:53 发布

原创最新推荐文章于 2025-12-17 15:38:53 发布 · 299 阅读

0 ·

CC 4.0 BY-SA版权

本文深入探讨HashMap的工作原理，包括hash值的计算方法、数组下标确定的技巧以及数组大小为2的幂的原因。通过解析源码，理解HashMap如何避免hash冲突，确保数据分布均匀。

MySQL是如何对一条简单的更新语句加锁的？

https://mp.weixin.qq.com/s?__biz=MzIzMzgxOTQ5NA==&mid=2247490453&idx=2&sn=6e7f0476696432f267a045fcc31f5af8&chksm=e8fe879cdf890e8a1de182c26f1f8c7cd0d2babff8ea15df8c9d43a4f342c9219eb8e2a4d2ef&scene=0&xtrack=1&key=8f237c0dc626bf1e70a826b462e81cd6c7b6b60c255eb87f62ebfcbe59ee6629ecd47203f3ef8032379d4eddcdb4b6013be86b27d00753a9ac3a743e11c5b2b67494ce0b9a5faa86c579c8bfd41e887d&ascene=1&uin=MjUwOTQyMjQyMw%3D%3D&devicetype=Windows+10&version=62070158&lang=zh_CN&exportkey=AQhvnUCUuD4zRuTQBi8unj8%3D&pass_ticket=RawmsJr%2Fh2lBlekD%2FT9x%2FpicwRngQ7TB4lClgMykFSqQU0cuXi9Vri3LK5kVSO%2B%2B

宜信技术学院2019年度科技年货纯享版

https://mp.weixin.qq.com/s?__biz=MzAwNTAyNDU2OA==&mid=500510956&idx=1&sn=13b4ca30e16050ba5f15964bf64d8dd5&chksm=03036ebb3474e7ade124bb11655970dab2ec70488752495b11f2aef61439fd944fdf66567287&mpshare=1&scene=2&srcid=&sharer_sharetime=1579062501075&sharer_shareid=fe0977112279a582c6159515e87364da&from=timeline&key=1a442ff3048043444475245f3f75a121648a06f06d44e04bae7b2512212ab5a24f7e679b57b6b740d5e48180d580c388d77915c616d491fe41c4ed660e58dd2b030fe702bab61d1d468c36259f4d17da&ascene=14&uin=MjUwOTQyMjQyMw%3D%3D&devicetype=Windows+10&version=62070158&lang=zh_CN&exportkey=Ae5ZujAhm3zA3HD5LXKwOmo%3D&pass_ticket=0I2sCcaL0%2BfYL7DneqXCuO70cLxUrGzXySKF6154jZ1bzeSIqb1wYgFafKp%2F8G0q

HashMap 你真的了解吗？

https://blog.youkuaiyun.com/qq_32519415/article/details/87006982

每put一个node结点进HashMap中时，究竟该放入哪里呢？

hash(key)决定。实现如下：

static final int hash(Object key) { 
int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

为什么不仅仅是key.hashCode()拉倒？

因为hashcode容易重复，不同的元素存储时容易处在同一个数组的下标位置，还有一个问题，这个hashcode值较大，容易出现数组越界的问题。

如此这般，能尽量让Node落点分布均匀，减少碰撞的一个概率。

如何限制保证数组下标的位置在我们定义的数组大小之内呢？取余？NO。

n = (tab = resize()).length;
if ((p = tab[i = (n - 1) & hash]) == null)

为什么源码中取了(n-1)和hash值的与运算呢？

因为与运算要比取模运算速度快，效率高。

问题是：(n-1)&hash一定在数据大小范围内？例：

15 & 3812 === 3812 % 16
这个是否成立？

15用二进制表示是 001111，那么不管3812的二进制数是什么，他们的与运算的值也永远不会超过15，就是>=15，我们发现这和我们的取模运算的结果是一样的，这是hashmap源码里一个比较精妙的地方。

我们再回过头看一串代码

/** * The default initial capacity - MUST be a power of two. */
    static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

在这里，为什么要一定强调数组的大小必须是2的n次幂呢，举例来看，如果数组的自定义初始化大小为15

那么 15 -1 = 14 ，14用二进制表示就是001110，与hash值做与运算会怎样？大于数组大小的规定值？“0”增多，不论hash值的这位数字是0还是1，与“0”得到的这个位数总会是0，碰撞几率增加。所以，这个数组的大小强烈建议为2的n次幂。数组大小不够用了，我希望扩大数组的大小，也要 * 2 。

那么，2的n次幂减1的二进制数的后几位一定是1吗？我们验证一下

16 15 01111

32 31 011111

64 63 0111111，没有问题

阿里的一个hashmap的面试题