本文围绕离职后前同事请教问题、积攒人脉关系和Java相关知识点等方面展开，介绍了如何处理前同事的请求、为何需要积攒人脉以及Java中HashMap的相关知识，包括其扩容机制、默认负载因子和初始容量的选择原因。
在职场中，积攒人脉关系非常重要，因为未来可能会得到别人的帮助或推荐。即使离职，也可能会有合作或求职的机会。
当键值对数量超过阈值（容量*负载因子）时，HashMap会进行扩容。默认负载因子为0.75，初始容量为16。使用位运算可以快速计算元素的索引。
大家好，我是二哥呀。
公众号后台有读者私信说，“二哥，离职有一个月了，但有个前同事隔三差五问我问题，热心肠回答吧，这我已经离职了；不回答吧，又怕他多想，之前关系还可以。”
这么说吧，如果前同事找你解决问题的时候会主动发红包，请你喝咖啡或者奶茶（😄），离得不远线下请你吃个饭。
那表明这个前同事能处，有情商的，那就尽量帮一帮。
没准这一帮，就成了好朋友。很多时候，关系也都是这么处出来的。
但如果就是不管不顾，心眼很多，只想白嫖你，不管问题繁琐不繁琐，不管你有没有时间，不管你烦不烦，舔着脸就是要你帮忙，那就赶紧拉黑，这种人不值得。
一是这种人基本的情商都没有，二是
真的，不是谁都会离职后还回消息的
。
不用不好意思，要学会说不，毕竟你还有自己的工作要处理，你还有自己的生活要兼顾，没有义务做别人的免费劳动力（😁）。
当然了，如果关系很铁，也就不存在这种困惑了，肯定是乐意帮忙的。
毕竟人都是有情感的，
离职后还愿意和你保持联络的，除了迫不得已，就是真情流露
。
熟悉我的老读者应该知道，我第一份工作是一家外企。工作的第二年，有个一直带我的领导突然离职了，我接手了他的部分工作，遇到一些棘手的问题真的是束手无策，就经常请教这位领导，领导就很热心肠，不厌其烦给我解答，耐心地帮助我，这让我一直心怀感恩。
后来我有了一些技术影响力，就总有一些需要开发的老板找我做项目，我就推荐了一些给这位领导，帮他解决了不少燃眉之急。
互联网是一个高速发展的行业，也许今天是你的下属，可能过三五年就成了某公司的高管，到时候拉你一把也是有很大可能性的。
即便是前同事没有做高管，那当你有求职需求的时候，帮你内推一下，也是会帮上很大忙的。比你去 Boss直聘上投简历靠谱多了。
工作时间越久，就越应该积攒更多的人脉关系，因为总有一天会用得上。
面渣逆袭
另外多说一句，最近很多小伙伴在后台催三分恶面渣逆袭的第二版 PDF，说第一版已经是 2022 年的事情了，那我最近也是在加大力度进行修改。
第二版的 Java 基础篇已经更新完成了，目前正在更新集合框架篇。所以，后面我打算每天都给大家汇报一下，这样也好鞭策我加快进度。
今天刚好优化到第 20 题，大家可以感受一下，描述更加的口语化了，更符合面试时的场景。
改动非常大，几乎重写了
20.HashMap扩容发生在什么时候呢？
当键值对数量超过阈值，也就是容量 * 负载因子时。
二哥的 Java 进阶之路：HashMap 扩容
默认的负载因子是多少？
0.75。
初始容量是多少？
16。
1 左移 4 位，
0000 0001 → 0001 0000
，也就是 2 的 4 次方。
static final int DEFAULT_INITIAL_CAPACITY = 1 <4; // aka 16
为什么使用 1 << 4 而不是直接写 16？
写
1<<4
主要是为了强调这个值是 2 的幂次方，而不是一个完全随机的选择。
无论 HashMap 是否扩容，其底层的数组长度都应该是 2 的幂次方，因为这样可以通过位运算快速计算出元素的索引。
为什么选择 0.75 作为 HashMap 的默认负载因子呢？
这是一个经验值。如果设置得太低，如 0.5，会浪费空间；如果设置得太高，如 0.9，会增加哈希冲突。
二哥的 Java 进阶之路：为什么选择 0.75
0.75 是 JDK 作者经过大量验证后得出的最优解，能够最大限度减少 rehash 的次数。
-
Java 面试指南
收录的小米春招同学 K 一面面试原题：为什么是 2 次幂 到什么时候开始扩容 扩容机制流程
