共 6 篇相关文章
这篇讲的是一个经典的Java面试题：为什么HashMap的桶中链表长度达到8才转为红黑树？作者从一个好友的阿里面试经历切入，直接打开了源码中的注释，发现它只记录了阈值，却未解释原因。 文章的核心在于对源码“Implementation notes”的深入解读。作者指出，红黑树节点占用的空间是普通节点的两倍，因此转换是一种空间与时间的权衡。更关键的是，文章引用了源码中一段关于泊松分布的注释：在随机哈希算法下，桶中节点数量遵循特定的概率分布，链表长度达到8的概率极低（仅约千万分之六）。这从统计学角度证明了阈值8的选取并非随意，而是经过严谨计算的。 此外，文章也驳斥了一种常见但不够严谨的“性能对比”解释，强调了设计背后的科学性。通过剖析源码与概率模型，这篇文章将一个常见面试考点还原成了其严谨的设计思想，适合所有想理解Java集合框架底层优化的开发者。
这是一篇将Java岗位面试高频知识点进行系统归类的汇总文章。作者从Java基础、IO、Web、JVM、开源框架、多线程、网络通信、数据库、设计模式、算法、并发与性能调优等十二个维度，梳理了上百个经典面试问题。 文章并非单纯罗列题目，而是将问题嵌入具体的技术场景中。例如，在基础部分会追问HashMap底层原理与Hash冲突解决，在多线程部分则围绕线程池、锁机制和并发容器展开，而在性能调优章节，则抛出“每秒5千请求如何设计”这样的实战架构题，引导读者思考从单机到集群的解决方案。 它清晰地勾勒出一名合格Java工程师需要掌握的知识图谱，覆盖了从理论概念到框架原理，再到系统设计的完整链条。对于准备面试或希望系统查漏补缺的开发者来说，这份归类清晰的清单，提供了一个扎实的复习与自检框架。
这篇讲的是JavaScript中如何创建真正的哈希映射。作者从日常使用对象字面量存储键值对的隐患出发，指出问题的根源在于对象默认继承自Object原型，导致`in`操作符等检查会污染原型链上的属性（比如`toString`），造成键值判断失误。即使尝试用`hasOwnProperty`方法，也可能因键名冲突而失效。 文章的核心解决方案是利用ES5引入的`Object.create(null)`来创建一个没有任何原型的“空对象”。这种对象彻底摆脱了原型链包袱，`in`操作符能可靠地只检查自身属性，`for...in`循环也不再需要过滤。同时，它依然支持常规的对象操作，如属性访问和JSON序列化。 简单来说，作者提供了一个清晰实用的思路：用`Object.create(null)`替代普通对象字面量，就能获得一个干净、安全的键值存储结构，避免一系列隐蔽的陷阱。对于更复杂的需求，文章也提到了ES6标准中的`Map`和`Set`。
这篇讲的是 HashMap 如何巧妙处理哈希冲突。作者直接从 put 方法的源码切入，展示了当不同 key 通过哈希算法映射到同一个数组索引（即“桶”）时，HashMap 采用的“链表法”解决方案。 核心思路很清晰：当发生冲突时，新的键值对并不会替换旧的，而是像插入单链表一样，通过 `addEntry` 方法被添加到该桶的链表头部。文章特别指出，这个新插入的 Entry 对象会指向原先位于该桶的 Entry，从而形成一条单向链表。这就解释了为什么在冲突严重时，get 操作会从直接定位退化为需要遍历链表，最坏情况下复杂度会达到 O(n)。 文章还点出了一个关键的设计权衡——负载因子。默认的 0.75 是空间与查询效率之间的折中：过大会节省内存但查询变慢，过小则查询更快但更耗内存。 总的来说，这篇分析没有停留在概念层面，而是通过源码把链表如何形成、负载因子如何影响性能这些细节讲透了，适合想弄懂 Java 集合框架底层原理的开发者阅读。
这篇讲的是如何绕过传统锁机制，实现一个能在多线程环境下高性能运行的HashMap。作者从Java中HashMap的线程安全痛点出发，指出常用的锁替代方案都存在性能或复杂性问题，从而引出了基于CAS（比较并交换）指令的无锁编程思路。 文章的核心是清晰地拆解了无锁HashMap的实现蓝图。它先带你理解了更基础的无锁链表如何利用CAS保证插入和删除操作的原子性，然后直面HashMap最大的挑战——ReHash（扩容）。作者巧妙地借鉴了“分裂有序链表”的思想，通过一种预先对节点哈希值进行位翻转排序并引入哨兵节点的方法，让整个链表在逻辑上始终有序。这样一来，数组扩容时节点只需要确认自己在新链表中的归属，而无需物理移动，从而破解了传统实现中需要同时原子修改多个指针的难题。 此外，文章还提到了为了提升效率而采用的数组懒加载、分块初始化等工程细节。整体而言，这是一篇从原理到实现都讲解得非常扎实的文章，把一个复杂的并发数据结构设计问题，梳理得条理分明。
这篇讲的是一个服务器在重启时，因配置文件加载异常缓慢而导致外网服务不可用的问题。作者团队发现，每次重启过程都要耗费整整5分钟，这个时间主要卡在配置文件的加载环节。 经过排查，他们将问题锁定在了哈希表（HashMap）的使用上。文章详细展示了抽象后的代码，并定位到了导致性能急剧下降的“罪魁祸首”——某种特定的使用方式（可能是扩容、哈希冲突处理不当，或数据分布不均等）让哈希表的插入或查找操作变得奇慢无比，从而拖垮了整个加载流程。最终，通过修正这一不当使用，配置文件的加载时间得以恢复正常，服务重启也重回迅速。这篇文章为遇到类似隐蔽性能陷阱的开发者提供了一个鲜活的排查案例。
