共 7 篇相关文章
这篇讲的是哈希函数的核心概念与各类算法的应用对比。作者从哈希函数作为关键字到存储地址的“映射”本质出发，重点解析了哈希应用中需要解决的“冲突”问题。 文章的核心在于系统梳理了几类主流的加密哈希算法。它介绍了MD5、SHA-1、SHA-2、SHA-3及RIPEMD-160的基本原理，并结合Node.js代码示例，直观展示了它们的输出。关键点在于对比了它们的安全状态与适用场景：例如，MD5因碰撞问题已不适合安全用途，更多用于文件校验；SHA-1正被各大厂商逐步弃用；而SHA-2与SHA-3则代表了当前更安全的选择。 除加密算法外，文章也简要提及了用于高速查找的非加密算法，如MurmurHash，拓宽了“哈希”的应用图景。整体上，文章清晰地梳理了“为何用哈希”以及“如何根据场景选择不同哈希算法”这两个核心问题。
这篇讲的是如何用哈希技巧解决一个经典的算法问题：在二叉树中找出所有结构完全相同的子树。 文章从一道大厂面试题切入。问题要求给定一棵二叉树，找出所有彼此完全相等的子树对。作者分享了自己的通过面试的解法，核心思路正是借助哈希。通过后序遍历整棵树，为每个节点计算一个哈希值——叶子节点用一个固定值（比如 md5("")），非叶子节点则将其左右子树的哈希值拼接后再次哈希。这样，任何子树都能被映射为一个唯一的哈希指纹。 计算出所有子树的哈希后，将它们放入哈希表。哈希值相同的子树，其结构“有可能”完全相同，但需要二次验证以排除哈希冲突。验证过程是递归地同时遍历两棵树，检查所有节点的左右子树存在状态是否一致。文章还提到了一个关键的优化：通过记录子树深度，在验证前就能排除掉大量哈希值相同但深度不同的“伪匹配”，极大地减少了不必要的递归检查。 整个过程清晰地展示了哈希作为一种“指纹”技术，在加速查找与比对操作中的强大作用，将复杂问题的复杂度显著降低。
这篇深度技术文章从源码层面拆解了 Redis 的核心数据结构——字典（dict）。作者首先指明，Redis 的每个数据库（db）本质上由两个哈希表（dictht）构成，真正存储键值对的是这两个表。文章重点剖析了 Redis 哈希表设计最精妙的部分：为何需要两个哈希表，以及如何利用它们实现 **渐进式 rehash（重哈希）**，从而在服务不中断的前提下完成表的扩容。 具体实现上，当触发扩展时，Redis 会为第二个哈希表分配新空间，并在后续的每次增删改查操作中，分批次地将数据从旧表迁移至新表。文章结合源码（`dictRehash` 函数）展示了这一“逐步搬家”的过程，并点明了其背后的设计考量：在服务器空闲时，定时任务会推进 rehash；在高负载时，操作本身的开销也会承担部分 rehash 工作，以此平衡性能。 此外，文章还分析了这种设计带来的“副作用”：由于查找操作需同时兼顾两个表，加上写操作本身包含多次查找，导致 Redis 在执行 SET 等写命令时效率并不高，这也从底层解释了其“重读轻写”的特性。最后，文章简要介绍了在涉及持久化（如 RDB/AOF）遍历哈希表时，也需要正确处理这两个表的过渡状态。全文逻辑清晰，从结构定义到核心算法，再到其对上层行为的影响，层层递进，非常适合想深入理解 Redis 高性能背后实现细节的开发者。
这篇讲的是如何绕过传统锁机制，实现一个能在多线程环境下高性能运行的HashMap。作者从Java中HashMap的线程安全痛点出发，指出常用的锁替代方案都存在性能或复杂性问题，从而引出了基于CAS（比较并交换）指令的无锁编程思路。 文章的核心是清晰地拆解了无锁HashMap的实现蓝图。它先带你理解了更基础的无锁链表如何利用CAS保证插入和删除操作的原子性，然后直面HashMap最大的挑战——ReHash（扩容）。作者巧妙地借鉴了“分裂有序链表”的思想，通过一种预先对节点哈希值进行位翻转排序并引入哨兵节点的方法，让整个链表在逻辑上始终有序。这样一来，数组扩容时节点只需要确认自己在新链表中的归属，而无需物理移动，从而破解了传统实现中需要同时原子修改多个指针的难题。 此外，文章还提到了为了提升效率而采用的数组懒加载、分块初始化等工程细节。整体而言，这是一篇从原理到实现都讲解得非常扎实的文章，把一个复杂的并发数据结构设计问题，梳理得条理分明。
这篇讲的是哈希表在真实世界中遭遇的“隐形危机”。作者没有停留在基础概念，而是直指一个具体而致命的问题——哈希碰撞攻击。文章从互联网服务频繁遭受的“散列洪水”（Hash Flooding）拒绝服务攻击事件切入，揭示了其根本原理：当攻击者能精心构造大量哈希值相同的数据时，会迫使哈希表从O(1)退化成O(n)的线性链表，导致服务器CPU资源被耗尽。 文章深入分析了为什么许多经典数据结构在理论上效率极高，在实际安全场景下却如此脆弱。它对比了不同哈希表实现（如链地址法与开放寻址法）在面对恶意输入时的表现差异，并点明了问题的核心在于哈希函数的确定性和可预测性。更值得关注的是，文中梳理了主流语言和框架（如Java、PHP）是如何通过引入随机化种子（如Java的红黑树阈值转换、PHP的HT_DJBX33A哈希算法）来缓解这一攻击的，这些方案本质上都是在向攻击者引入不确定性。 最终，文章提供的不仅是一个技术点的剖析，更是一种重要的安全设计思维：在构建系统时，必须超越理想模型，将不可信的用户输入纳入考量，并为底层组件选择具备抗干扰能力的实现。
这篇讲的是 Linux 内核如何高效管理和查找海量路由条目的核心机制——哈希路由表。 作者从网络子系统中的路由表基础概念出发，深入剖析了内核采用哈希表作为底层数据结构的具体实现。文章没有停留在理论，而是紧扣内核源码，拆解了关键数据结构的设计，比如哈希桶的组织方式、路由条目节点的定义，以及如何通过特定的哈希函数（如 `fib_hash`）将 IP 目标地址映射到桶中。 其巧妙之处在于，内核并非简单套用通用哈希表，而是针对路由查找“精确匹配”的特性和高并发场景做了专门优化。例如，通过合理的哈希函数减少冲突，并结合锁机制（如 RCU）来平衡查找性能与并发更新时的开销。文章分析了这些设计如何共同作用，使得即使面对数十万条路由规则，内核依然能快速完成查找，这是保障网络设备转发性能的关键。 作者通过解读源码，揭示了内核开发者在性能与复杂性之间所做的权衡，让读者能理解这一基础设施背后的工程智慧。
这篇讲的是作者如何尝试实现一个线程安全的LRU缓存结构——ConcurrentHaspLRUHashMap。面对高并发场景下，既需要快速存取、又需要自动淘汰最久未使用数据的需求，现有的解决方案可能各有局限。作者的出发点很明确，就是探索一种能兼顾并发性能与LRU淘汰策略的全新实现。 文章的核心在于拆解这个混合结构的设计思路。它不像传统的ConcurrentHashMap那样只考虑并发存取，也不像简单的LRU列表那样忽略线程安全。作者需要在两者间找到平衡，比如如何用锁或CAS机制保证并发修改时链表顺序的正确性，又如何让哈希表与双向链表高效协作。文中可能会展示一些关键的同步控制技巧，或是性能权衡的具体考虑。 这种自定义容器的实现往往在框架或中间件中很关键。作者通过这次初探，不仅分享了具体代码，更传递了一种解决问题的思路：在复杂约束下，如何拆解需求、组合基础数据结构，并处理好并发细节。对于需要设计高性能缓存或理解Java并发容器原理的开发者来说，其中的实现考量具有直接的参考价值。
