共 3 篇相关文章
这篇讲的是 HashMap 如何巧妙处理哈希冲突。作者直接从 put 方法的源码切入，展示了当不同 key 通过哈希算法映射到同一个数组索引（即“桶”）时，HashMap 采用的“链表法”解决方案。 核心思路很清晰：当发生冲突时，新的键值对并不会替换旧的，而是像插入单链表一样，通过 `addEntry` 方法被添加到该桶的链表头部。文章特别指出，这个新插入的 Entry 对象会指向原先位于该桶的 Entry，从而形成一条单向链表。这就解释了为什么在冲突严重时，get 操作会从直接定位退化为需要遍历链表，最坏情况下复杂度会达到 O(n)。 文章还点出了一个关键的设计权衡——负载因子。默认的 0.75 是空间与查询效率之间的折中：过大会节省内存但查询变慢，过小则查询更快但更耗内存。 总的来说，这篇分析没有停留在概念层面，而是通过源码把链表如何形成、负载因子如何影响性能这些细节讲透了，适合想弄懂 Java 集合框架底层原理的开发者阅读。
这篇从Java源码中常见的“乘以31”现象切入，详细探讨了为什么在实现hashCode方法时，开发者普遍选择31这个特定系数。作者没有停留在“它是质数”的简单结论上，而是深入剖析了31在计算机二进制表示下的独特优势：它不仅是质数，能减少哈希冲突，更关键的是31 * i 可以被编译器优化为 (i << 5) - i 的位运算操作，在保证分布均匀的同时，显著提升了计算效率。 文章进一步对比了其他可能的质数（如17、33），用数据和理论说明了31在“性能”与“冲突概率”之间取得的绝佳平衡点。通过阅读String类等核心库的hashCode实现，我们可以看到这个设计选择背后的工程智慧。对于想深入理解哈希表底层优化的开发者来说，这篇文章提供了一个非常扎实的微观视角。
这篇讲的是一个在实现 memoize（记忆化）优化时极易被忽略的问题。许多开发者在封装缓存函数时，可能都以为只要实现“相同参数返回相同结果”就行，但实际代码里隐藏着不少陷阱。 文章作者从一个具体场景出发，揭示了 memoize 函数在实际使用中的几处典型漏洞。例如，如果缓存键仅仅使用参数的字符串或简单哈希值进行比较，那么当传入对象或数组等复杂引用类型时，哪怕内容相同但引用不同，也会导致缓存失效，从而产生预期外的重复计算。另一个常见的陷阱是，对于异步函数的缓存处理不当，可能引发竞态条件或回调错误。 更深入一层，文章还探讨了如何通过设计更健壮的键生成策略（如序列化+严格比较），以及利用闭包妥善管理缓存的作用域，来避免内存泄漏和污染全局状态。这些细节上的考量，直接决定了 memoize 工具是真正可靠的性能优化，还是埋下了隐蔽的 Bug。文章通过剖析这些“小陷阱”，提醒读者在追求代码效率的同时，务必对底层实现保持审慎的思考。
