这篇讲的是Java HotSpot虚拟机如何进行性能调优，核心是理解并优化其垃圾回收（GC）机制。作者从Java与C/C++的常见争论切入，指出Java在动态优化方面的特性，引出对JVM和GC进行研究的必要性。 文章首先详细图解了JVM的堆内存分区：Eden、Survivor、老年代和持久代，解释了各区域的用途。接着，重点剖析了GC的核心流程与算法，从经典的引用计数法和Java实际采用的根搜索法说起，对比分析了标记-清除、复制（用于新生代）、标记-整理（用于老年代）等回收算法的原理与优缺点，特别阐述了它们如何协同工作以平衡效率与内存碎片问题。 最后，文章落脚于实践，列举了如-XX:-DisableExplicitGC、-XX:+UseConcMarkSweepGC等一系列关键的JVM启动参数，并结合Full GC与Young GC的特点，提供了具体的调优方向与性能优化Tips，帮助开发者从理论到实践全面掌握GC调优。
这篇从分布式系统的基本构成讲起，将其拆解为节点、网络、存储三元组，并探讨了节点状态（有状态与无状态）及系统异常的基本分类。文章的核心在于剖析分布式环境与单节点系统的关键差异：例如，一次write()调用并不能保证对端成功接收数据；TCP协议虽可靠，但双方无法同时确认消息送达，这引出了经典的“拜占庭将军”问题。开发者必须面对多出的“超时”等第三种不可控状态，并将各种故障视为常态而非偶然。 在此基础上，文章重点解读了分布式系统的经典CAP理论（一致性、可用性、分区容忍性），阐明了强一致性与弱一致性的具体应用场景与权衡。最后，文章开始介绍应对这些挑战的设计策略，比如通过重试机制处理暂时性故障。对于希望构建健壮分布式系统的工程师而言，理解这些无法绕开的底层原理与固有约束，是进行可靠架构设计的第一步。
在分布式系统中，选主和高可用是常见挑战。作者从实际生产场景出发，探讨了在对一致性要求并非极致严格、且允许短暂不可用的情况下，一种利用现有基础设施实现简易选主的方案。 针对ZooKeeper在节点存活不足半数时无法工作的限制，文章提出了一种基于MySQL ACID特性与Lease（租约）协议的替代设计。核心思路是利用一张MySQL表的唯一记录来维护全局Master信息，其事务特性保障了数据一致性。集群中的每个节点持有一个唯一ID，并按照约定的Lease周期进行心跳维护和竞选。 具体运作上，Master节点需定期向MySQL更新心跳，确保Lease未过期。其他Slave节点则定期检查：若发现数据库中Master的Lease已过期，便发起竞争写入自己作为新主。通过Lease机制，即使原Master因网络分区而失联，它也会在租期耗尽后自动停止服务，有效避免了“双主”脑裂问题。方案也坦诚指出了在数据库访问时延等情况下，可能存在极短时间窗口内的极限冲突，但可通过后续选举自动恢复。 该方案特别适用于需要一主一备、且对秒级故障可容忍的系统，它在ZooKeeper集群规模受限或希望降低依赖复杂度的场景中，提供了一个轻量且实用的工程化思路。
这篇讲的是如何用极低的空间成本，高效判断一个元素是否存在于海量数据集合中。作者从一道常见的面试题出发，引出了两个核心数据结构：Bitmap与Bloomfilter。 文章首先剖析了Bitmap，它本质上就是一块连续的内存位图，每个bit（0/1）直接对应一个元素的“无/有”。作者展示了如何通过简单的位运算（`/8`和`%8`）定位到具体的bit位，并给出了一个完整的C++代码示例，用于在一个10万规模的集合中精确查找缺失的数字。Bitmap的优点是100%准确，但缺点是所需内存与元素值的范围直接相关。 接着，文章重点介绍了Bloomfilter。它通过多个哈希函数对同一个值进行多次哈希，将结果映射到不同的bit位上。这种设计能用远小于Bitmap的内存处理更海量的数据，但代价是存在理论上的误判——可能将不在集合的元素误判为“存在”。作者解释了误判率与哈希函数数量、内存大小的关系，并提供了包含三种经典哈希函数（BKDR、FNV、DEK）的实现代码。 文末，作者还留下了一个思考题：对于“从1到100万无序数中找出被随机取走的N个数”这个问题，除了这两种方法，还可以如何利用数学性质（如求和、求积）来间接求解？这展示了不同场景下算法选择的灵活性。
