蜡笔小浩_CrayonTech-优快云博客

原创 [数据结构]并查集(系统整理版)

每次合并把元素少的连通块合并到元素多的去。维护一个size数组s 初始化为1。最后cnt即为最后的连通块个数。这样合并能时树的高度增长相对少。减少路径压缩次数提高查询效率。初始化cnt为元素个数n。因为并查集类似树形结构。每次合并时 cnt–

2025-03-29 10:24:51 748

原创【MySQL常见面试题 · 16】同样是写磁盘，为什么Redo日志能比写数据页快上千倍？

同样是把数据写进磁盘，为什么直接刷数据页吞吐只有几百，而写 Redo 日志却能飙到几万？本文从物理磁道寻道、组提交合并与崩溃恢复切入，彻底拆解 Redo 日志提速千倍的底层真相。同样是把数据写进磁盘，为什么 Redo 日志能比写数据页快上千倍？它用只有几十字节的物理紧凑增量，替代了沉重庞大且伴随严重写放大的 16KB 完整数据页；它用磁头单向滑动的纯粹顺序追加写，击碎了在物理扇区与闪存块之间剧烈漂移的离散随机写噩梦；它用精巧的组提交流水线，将成百上千个并发事务的物理fsync。

2026-10-12 09:36:02 394

原创【MySQL常见面试题 · 15】数据改了为什么不直接写磁盘？从BufferPool到Redo顺序写看透吞吐真相

数据改了为什么不直接写磁盘？没落盘凭什么敢返回成功？本文从磁盘随机写瓶颈切入，深入拆解 Buffer Pool 三大链表、WAL 预写与检查点刷脏，讲透高并发吞吐背后的底层真相。数据在内存中改了，为什么不直接写磁盘？这不是存储引擎在偷懒，而是面对现代硬件物理限制时，关系型数据库做出的一场极其精妙的算力与 I/O 权衡。如果每一次提交都把 16KB 的数据页同步砸向磁盘，数千倍的写放大与离散寻道将把整库吞吐封死在几百 TPS 的物理低位。

2026-10-12 09:28:14 174

原创【MySQL常见面试题 · 14】数据早被改了十次，为什么你查到的还是旧值？从Undo链看透MVCC并发读真相

很多人困惑：某行数据明明被并发事务改了十次且已提交，为什么你查到的依然是旧值？这个旧值究竟藏在哪？本文从串行化真相切入，彻底拆解 Undo 版本链、Read View 算法与快照读工程陷阱。数据早被改了十次，为什么你查到的依然是最初的旧值？这不是数据库发生了灵异故障，而是 InnoDB 存储引擎在物理聚簇索引与 Undo Log 历史链之间，用一致性 Read View 精心构筑的一场时空折叠。串行化通过物理互斥锁封冻了一切并发，带来绝对一致的同时也扼杀了吞吐；

2026-10-12 09:20:20 164

原创【MySQL常见面试题 · 13】MySQL默认选RR，为什么大厂生产环境全改成了RC？

很多同学背八股只记隔离级别概念，却不知 Oracle 默认 RC 而 MySQL 默认 RR。更反常识的是，一线大厂几乎全改回了 RC。这绝非随意跟风，而是权衡高并发吞吐与死锁代价后的深层架构抉择。技术的演进史，从来不是一部教条主义的照本宣科，而是一部在物理约束与吞吐渴求之间不断推演、权衡与突围的折中史。MySQL 之所以把 RR 设立为默认隔离级别，只是在二十年前面对 Statement 格式 Binlog 复制缺陷时做出的一次无奈妥协。

2026-10-11 11:04:05 175

原创【MySQL常见面试题 · 12】数据还没落盘怎么敢返回成功？从undo与redo日志看透ACID实现

很多开发者以为事务提交就是数据写进了磁盘文件。为了极致吞吐，修改往往只在内存中，磁盘数据页根本没动。数据还没落盘凭什么敢返回成功？从 undo 与 redo 日志看透 ACID 底层协同。在高性能数据库的工程进化史中，WAL 机制、双日志协同与环形缓冲区的设计，无一不是在“物理硬件的冷酷约束”与“业务系统对极致吞吐的渴求”之间所做出的天才折中。用顺序 I/O 规避随机 I/O：把高昂的随机数据页写入延后为内存脏页的批量异步合并，用低廉而高效的轻量级顺序追加写抢先守住持久性底线。物理与逻辑的清晰分工。

2026-10-11 10:56:30 134

原创【MySQL常见面试题 · 11】纯查询方法到底要不要加事务？从InnoDB底层看透ACID实现

很多人以为只有增删改才配叫事务，被问到纯查询要不要加事务容易拿不准。事务从不只是写操作的专利。从 InnoDB 底层看透 ACID 的协同设计，才能厘清快照读、锁与只读事务在工程中的真实分工。业务场景分类事务配置模式ReadView 行为模式trx_id 分配与锁开销数据一致性能力Undo Purge 影响生产落地推荐结论单条 SELECT 点查默认语句级生成，语句结束即释放无全局 ID 分配，零额外锁开销单语句原子一致零阻碍，瞬时回收强烈推荐。架构最简，性能最高，禁止额外包事务。

2026-10-11 10:51:33 94

原创【MySQL常见面试题 · 10】千万级保单多级分销，为什么单靠加索引扛不住高并发？

很多团队在面对保单多级分销系统变慢时，第一反应总是加索引。在千万级保单与代理人裂变网络中，层级递归、高频聚合与热点行锁形成了三维算力风暴。单纯依靠单机索引调优，根本无法挽救高并发下崩溃的数据库。-- 代理人基础信息表agent_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '代理人唯一ID',agent_no VARCHAR(32) NOT NULL COMMENT '工号',

2026-10-11 10:44:53 80

原创【一起学AI · 06】为什么写生产级Agent选TS比Python更强？长耗时流式并发下的硬核对比

很多开发者刚上手做智能体，都是从 Python 和 LangChain 开始写 Demo，本地单用户跑起来十分顺手。但只要一接上前端界面、放进真实业务网关做压测，三十个流式并发长连接就能把服务直接拖垮。生产环境的 Agent 到底该选 TS 还是 Python，背后藏着长耗时 I/O、类型契约与交付链路的客观物理规律。技术选型的本质，是让工具匹配业务的真实物理规律。如果你的目标是跟进学术前沿、验证一个新的规划算法、或者在内部写一个跑完即弃的数据分析脚本，Python 依然是最顺手的利器。

2026-10-10 18:44:44 365

原创【MySQL常见面试题 · 09】大厂为什么严禁外键与存储过程？阿里MySQL核心军规深度推演

大学教材将物理外键与存储过程奉为数据完整性的基石，大厂规范却全面封杀，甚至对全模糊查询与 SELECT * 严加苛责。这不是规范洁癖，而是高并发海量数据下保全有状态数据库生存底线的必然抉择。软件工程的本质是在多方约束中寻找平衡。大学教科书展示的是关系模型的数学纯粹性，而大厂的工业级军规展现的则是系统在规模扩张百倍、千倍后，为了保全底层有状态存储生存而付出的必然代价。遵守这些军规，不是对教条的盲从，而是深刻理解了 B+ 树的寻道规律、行锁的扩散机制与现代硬件的价值梯度后，做出的最成熟的工程抉择。

2026-10-10 15:07:20 180

原创【MySQL常见面试题 · 08】为什么大厂宁可多查几次也不做JOIN？阿里严禁三表关联的底层真相

很多人直觉认为单次 JOIN 减少了网络交互，多次查询会增加开销。阿里规范却明令禁止三表以上关联。大厂宁可多查几次也不做复杂 JOIN，核心在于保护数据库单点算力，并适应分布式架构演进。架构设计的核心从来不是炫技，而是在脆弱资源与廉价资源之间寻找最优平衡。大厂之所以宁可多查几次单表也不做多表关联，本质上是在用极其廉价、能够秒级横向伸缩的应用层算力，全力护卫极其昂贵、处于全站单点咽喉位置的有状态数据库。让数据库回归其最擅长的事——专注于纯粹高效的物理数据存取，把繁琐多变的数据组装交还给弹性伸缩的业务层。

2026-10-10 14:59:15 151

原创【MySQL常见面试题 · 07】一条慢SQL为什么能拖垮整库？千万级复杂聚合30秒优化实战

单条耗时数十秒的慢 SQL 能拖垮整库，根源在于有状态数据库的 CPU 与连接池无法秒级水平扩容。面对千万级订单多维聚合，单靠加索引绝非良策，必须借助预聚合、缓存分流与应用层组装完成系统级重构。单条多表复杂聚合之能够击垮数据库，本质不是某一行 SQL 语法写得不够漂亮，而是开发人员将沉重的分析型算力硬塞进了有状态的事务引擎中。数据库的长处在于严谨的持久化、强一致的事务保障与纳秒级的局部点查；系统的扩展性应当由具备天然横向扩展能力的分布式缓存与无状态应用层来承担。

2026-10-10 14:50:45 173

原创【MySQL常见面试题 · 06】为什么跳过第一列索引就失效？从B+树寻路到阿里三表JOIN军规

最左匹配不是死规矩，而是 B+ 树复合键值物理排序的必然结果。跳过首列，全局单调性断裂，二分寻路随即失效。看透这种物理机制，也就懂了为什么阿里军规严禁多表关联，全面转向应用层内存组装。拆透了 B+ 树的复合物理存储与多表关联的底层执行，我们能看清技术设计背后清晰的物理脉络。联合索引跳过第一列之所以失效，不是存储引擎的人为偏执，而是数据页内复合排序的纯粹数学事实：只有第一列具备整棵树的全局单调性，后续字段全是在前置条件约束下的局部产物。抽走首列，二分排他的罗盘瞬间崩解。

2026-10-10 14:39:54 168

原创【MySQL常见面试题 · 05】线上慢SQL别瞎猜，教你用EXPLAIN顺藤摸瓜揪出性能元凶

线上接口突然变慢、数据库 CPU 飙高，排查慢 SQL 绝不能凭直觉乱猜。EXPLAIN 执行计划就是优化器交出的底牌。本文顺着核心指标展开，带你理清慢查询从定位到索引调优的完整排查思路。EXPLAIN绝不是排查慢 SQL 时用来走过场的展示命令，而是 MySQL 优化器向我们亮出的真实底牌。看执行计划千万不要只盯一个key是不是空。单纯走上了某个单列索引并不能保证高枕无忧，type的访问深度、key_len的实际利用字节、Extra里的临时表与额外排序标记，才是决定线上系统吞吐上限的真正命门。

2026-10-09 14:44:30 127

原创【MySQL常见面试题 · 04】别死背最左匹配，从B+树复合排序看透联合索引底层存储

很多同学背八股文张口就是最左前缀匹配，可一旦被追问“为什么跳过第一列就走不了索引二分”，往往答不上来。最左匹配绝不是死规矩，而是联合索引在数据页内复合排序的物理必然。本文我们顺着数据页存储，把联合索引底层结构与匹配机制彻底拆透。拆解完联合索引的底层物理结构，最左匹配原则不再是一串需要死记硬背的八股文规则。它只是一条朴素的物理事实：MySQL 没有魔法，在磁盘数据页里，计算机只能按照既定的顺序一列一列比对大小。第一列决定了全局的单调方向，后续列只有在前列相等的前提下才有局部的有序性。

2026-10-09 13:13:50 232

原创【MySQL常见面试题 · 03】为什么你的查询总在回表？彻底搞懂聚集索引、覆盖索引与索引下推

上一篇我们算清了 B+ 树的扇出能力，也看懂了 MyISAM 与 InnoDB 在磁盘文件上的分家与合一。很多同学在面试中能背出 B+ 树，可一旦被追问“为什么你的 SQL 在频繁回表、覆盖索引和索引下推到底省了什么”，就容易卡壳。本文我们顺着数据检索的真实链路，把聚集索引、二级索引、回表与索引下推彻底拆透。梳理完这一整套流程，你会发现 MySQL 的索引设计有一种极其清晰的克制感。聚集索引把数据直接挂在主键叶子上，省去了二次寻址，但一张表只能享受一次这个待遇；

2026-10-09 12:55:23 238

原创【MySQL常见面试题 · 02】B树明明已经是多叉树了，为什么MySQL偏偏只认B+树？

上一篇我们聊透了为什么红黑树镇不住千万级数据表。把单个节点做大、从二叉改成多叉后，B 树明明已经解决了树高问题，为什么 MySQL 还是不用它，非要再改造成 B+ 树？这篇我们直接算清这笔底层账。回过头来看，B+ 树之所以能成为数据库索引的事实标准，核心就在于它克制住了“在非叶子节点存数据”的诱惑。把所有数据载荷赶到叶子节点，换来了非叶子节点 1170 倍的扇出能力，硬生生把两千万级数据表的树高钉死在 3 层以内；而在叶子节点之间加上双向链表，又顺手把数据库最高频的范围扫描和排序变成了顺畅的顺序遍历。

2026-10-08 13:32:59 326

原创【MySQL常见面试题 · 01】千万级数据表查得慢，为什么不能用红黑树当索引？

聊到 MySQL 索引，很多同学张口就是 B+ 树。但如果面试官追问一句：“红黑树在内存里查找那么快，数据量到了一千万，为什么 MySQL 偏偏不用它做索引？”本文就顺着真实的存储与检索脉络，把二叉树、红黑树到多叉树的推演过程彻底拆透。技术选型的背后，从来没有脱离物理现实的空中楼阁。红黑树在算法题和内存集合里近乎完美，但在大型数据库面前，它的致命伤就在于漠视了磁盘块设备的 I/O 延迟特征。

2026-10-08 13:20:16 203

原创【一起学AI · 05】大模型根本不会自己干活，带你手写一个简易Agent搞懂ReAct机制

很多初学者以为大模型能自主做决定、自动跑任务，实际上一旦断了人的干预，模型连当天的天气都查不到。大模型本质上只是文本生成器，真正让它动起来的是一套 ReAct 循环调度机制。手写一个简易 Agent，就能把这套运行逻辑看明白。首先定义一个通用的工具契约AgentTool。每个工具必须明确自己的名称、一段给大模型阅读的功能说明，以及强类型的执行入口。/*** Agent 外部工具统一契约/*** 工具唯一标识名称 (大模型在 Action 中引用的标识)/**

2026-10-05 13:37:40 864

原创【一起学AI · 04】做Agent别一上来就动态规划，三层编排怎么搭才不崩

很多团队做 Agent，一上来就让大模型动态规划每一步，结果死循环、Token 暴涨、接口报错不断。其实工业级 Agent 从底到顶分三层：工具中台、工作流图和动态 Agent。搞清各层职责，系统才稳得住。技术方案从来不是越复杂、越动态就越好。很多 Agent 项目之所以在线上跑不稳，往往是把原本该用几十行代码写死的工作流，硬塞给了不可控的提示词。能够在中台用代码串联的多源查询，坚决收进 Tool 内部；具备明确先后依赖与合规要求的流程，老老实实用 Workflow 和 Circle 环路锁死；

2026-10-04 11:04:06 216

原创【一起学AI · 03】Agent 总把请求派错？先把意图识别拆成三层

用户一句话进来，系统要先判断这句话该交给哪个 Agent、还缺什么参数。这一步判错了，后面的 Agent 再聪明也白干。本文用一个售后助手，把意图识别从分层到兜底讲一遍。假设我们在做一个电商售后助手，背后挂了三个 Agent：查订单的、处理退款的、开发票的。这是本文的教学场景，不对应某个已上线的系统。用户不会按接口格式说话。他可能说“我的快递到哪了”，也可能说“先把上周那单退了，然后开张发票”。意图识别要做的，是把这种自然语言转成结构化的任务，再决定进哪个 Agent。

2026-10-03 10:08:23 320

原创【一起学AI · 02】Agent 三种编排怎么选？有些流程根本不需要模型规划

同样是查订单、查物流、解释延迟，为什么有的系统把步骤藏在 Tool 里，有的画成 Workflow，有的让 Agent 临时决定？看清执行顺序由谁决定，就能少做不少无用的动态规划。选择编排层次时，先把“下一步由谁决定”写清楚，再用真实任务比较完成质量和开销。一个有条件分支的固定流程如果已经够用，我会先把它做好。如果这篇帮你理清了 Tool、Workflow 和 Agent 的关系，记得点个关注，后续一起学 AI 时也欢迎继续来交流具体问题。

2026-10-03 10:06:29 300

原创【一起学AI · 01】多 Agent 越多越好？五种架构怎么选才不乱

Agent 多了，任务就能做得更好吗？一旦涉及跨部门数据和多轮决策，谁派活、谁保存进度、谁能修改业务数据，都会影响结果。本文用经营分析串起五种架构，再运行一个小例子，看看编排器如何派发任务和停下。选架构时，先画出任务依赖和控制权。一次分类够用就用 Router；固定步骤交给顺序流程；需要根据新证据改变计划时用 Supervisor。分层和对等协作则要有明确的拆分理由，以及可执行的汇总与停止规则。我更建议从一条能检查结果的业务路径开始，再看哪一步确实需要第二个 Agent。

2026-10-03 09:45:35 199

原创【RAG常见面试题 · 11】面试官问RAG怎么结合微调，别再回答二选一

很多同学在面试中遇到“垂直领域项目到底选 RAG 还是微调”时，经常会陷入二选一的纠结。其实工业界落地往往是两者结合，微调负责教会模型领域内的思考逻辑与行话风格，RAG 负责提供最新、精准的事实依据。在垂直领域大模型落地的过程中，RAG 与微调绝对不是针锋相对的技术路线，而是各司其职的双引擎。微调决定了模型像不像这个行业的专家，RAG 决定了专家说出来的每一句话准不准。

2026-10-02 13:23:12 25

原创【RAG常见面试题 · 09】RAG查一次等好几秒？三大环节耗时拆解与针对性优化

很多人把 RAG 系统搭好之后，一上线测试就发现不对劲：用户提一个问题，页面常常要转上三五秒甚至更久才出结果。在面试中，面试官也很喜欢抓着“延迟瓶颈”来深挖候选人的工程底子。本文把 RAG 全链路的耗时环节逐一拆开，聊聊每个环节的真正瓶颈与落地优化手段。优化 RAG 延迟的过程，本质上是一场算力成本、架构复杂度与用户心理感知的工程平衡。没有必要在第一天就把全套分布式 GPU 向量分片和模型蒸馏全堆上去。

2026-10-02 12:28:58 94

原创【RAG常见面试题 · 08】用户全是口语大白话，RAG怎么精准搜出专业文档

做智能客服或企业知识库 RAG 时，最让人头疼的往往不是冷僻术语，而是用户天马行空的大白话。“电脑崩了”、“这玩意坏了咋弄”和知识库里严肃规范的文档天差地别。本文深入拆解如何穿透口语表象，让 RAG 系统稳稳搜出专业文档。面对口语大白话与专业知识库之间的鸿沟，寄希望于通用 Embedding 模型拥有“读心术”往往是不切实际的。最扎实的工程实践永远是组合拳：在入口端，用同义词映射与轻量改写消除无意义干扰；在理解端，用槽位提取穿透表象直达核心诉求；在召回端，靠多路容错与重排序稳稳托底。

2026-10-02 12:20:25 65

原创【RAG常见面试题 · 07】优化Embedding模型，别一上来就搞微调

做 RAG 检索时，一旦召回不准或者回答答非所问，很多人第一反应就是：“是不是该拿自己的数据去微调 Embedding 模型了？其实在工业界真实的工程实践中，微调通常是最后的手段。盲目微调不仅成本高、容易破坏模型原本的通用泛化能力，还经常收益甚微。本文结合大模型面试高频考点，拆解优化 Embedding 模型的真正路线图。在 RAG 架构中，优化 Embedding 模型绝不等于一上来就写训练脚本做微调。把精力按优先级分配，才能少走弯路：第一优先级是构建业务基准集，挑出最适合自身领域的开源底模；

2026-10-02 12:12:35 95

原创【RAG常见面试题 · 06】面试官问RAG文本分块怎么做，别只会按512字符硬切

做 RAG 检索增强，很多人以为核心是换个更好的 Embedding 模型或堆 Rerank。但如果源头文本分块切得稀碎或杂乱无章，后续检索再怎么折腾也是徒劳。本文带你拆解文本分块的核心策略与工程权衡。文本分块绝不是调个切分函数那么轻巧。切大还是切小，从来没有放之四海皆准的最优解。直接按固定长度硬切基本是行不通的。用递归字符切分作为打底基础，在格式规范的文档中尊重 Markdown 层次，在严肃业务场景中引入父子块架构解耦检索与生成，才是把 RAG 召回精度拉上一个台阶的正确姿势。

2026-10-02 11:35:26 255

原创【RAG常见面试题 · 05】面试官问如何设计高质量检索语料库，别只聊切块和向量化

很多人做 RAG 遇到召回不准、模型胡说，第一反应就是换 Embedding 模型、调 Rerank 参数或者改 Prompt。但如果原始语料库本身充满脏数据和事实冲突，后续做再多算法调优也是在沙滩上建楼。本文带你拆解高质量检索语料库的设计维度与工程落地。聊到这里，面试官如果再问你“如何设计一个高质量的检索语料库”，别再只是机械地背诵“先切块再做 Embedding”。能不能做好底层数据治理，才真正决定了工业级 RAG 系统的上限。光靠换几个时髦模型根本解决不了根本问题。

2026-10-02 11:31:27 69

原创【RAG常见面试题 · 04】面试官问RAG多轮对话怎么优化，别只会把聊天记录塞进Prompt

单轮测试准得很，一进多轮对话就答非所问、前后矛盾。很多同学被面试官问到多轮 RAG 优化，嘴里往往只有一句“做个指代消解”或者“把历史记录拼进 Prompt”。本文带你从 Query 改写、历史加权、分层记忆到动态检索，看透工业级多轮 RAG 的完整落地解法。很多团队习惯等对话攒到十几轮了，再调用一次总结接口。这样成本高、延迟大，而且中间轮次依然在忍受冗长上下文。更稳妥的方法是增量滚动摘要（Rolling Summary）每产生一轮新的问答，就由后台异步任务或轻量小模型对现有摘要进行增量更新。

2026-10-02 11:09:03 134

原创【RAG常见面试题 · 03】做RAG还在只用向量检索？难怪专有名词总搜不准

很多同学一聊到 RAG 检索，脑子里就只有向量数据库和余弦相似度。但在实际业务中，单靠向量检索常常连型号和专有名词都搜不准。本文把稀疏检索、稠密检索到混合检索的演进逻辑与选型权衡彻底讲透。/*** 检索切片结果载体} }Map;/*** 检索切片结果载体*/) {做 RAG 不要迷信单一的先进模型。检索是整套系统的眼睛，眼睛看不清，后面的 LLM 再聪明也是瞎子。在工业落地中，踏踏实实做好 BM25 倒排索引和向量检索的双路融合，往往比你死磕 Prompt 调优有效得多。

2026-10-02 11:05:34 167

原创【RAG常见面试题 · 02】多轮对话一拉长，为什么RAG就开始答非所问？

单轮测试准确率很高，可一到多轮对话，RAG 就频繁出现答非所问、前后矛盾。面试官问起多轮对话下的 RAG 优化，很多人只知道说一句指代消解。本文把多轮 RAG 性能劣化的根因与工业级解法彻底拆透。不要指望把十轮、二十轮的纯文本对话记录完整丢给模型。这不仅浪费带宽和算力，还会稀释注意力。短程滑动窗口（Sliding Window）：只保留最近 2 到 3 轮未经压缩的原汁原味交互。绝大部分指代消解和上下文衔接，只需要依赖最近 2 轮信息。

2026-10-02 11:01:20 240

原创【RAG常见面试题 · 01】面试官问RAG怎么解决大模型幻觉，别只回答外挂知识库

在面试中聊到大模型幻觉，不少同学脱口而出就是“做个 RAG 外挂知识库就行”。但如果追问一句：为什么纯生成模型一定会胡编？RAG 具体靠什么机制把模型按在事实里？这篇文章把这套链条彻底拆开。回到最开始的那个面试题：RAG 是怎么解决大模型幻觉的？千万不要只轻描淡写地回答一句“外挂个知识库”。真正能打动面试官的回答，是讲清楚知识固化在参数里的局限，讲清楚从“检索召回、Rerank 提纯、提示词边界死守”的三层防御，再讲清主动检索与忠实度校验的进阶手段，最后客观指出切片断章取义可能带来的检索型幻觉与延迟代价。

2026-10-02 10:43:02 223

原创【从0到1学习JVM · 27】号称停顿可控的G1为什么比CMS还多了一次STW

上一篇我们聊了老年代低停顿代表 CMS，它虽然把标记和清理搬到了后台，却留下了内存碎片和容易退化成卡死状态的硬伤。为了在大内存下彻底解决碎片问题并实现停顿时间可控，JVM 推出了 G1（Garbage-First）收集器。有趣的是，号称低延迟、停顿可控的 G1，在最后回收阶段竟然比 CMS 还多了一次全局停顿。本文我们就来拆解 G1 颠覆传统的 Region 内存布局、四阶段工作流，以及为什么把停顿时间设得太短反而会引发系统的灾难性卡死。

2026-10-01 11:45:44 287

原创【从0到1学习JVM · 26】号称低停顿的CMS为什么生产上反而容易卡死

CMS（Concurrent Mark Sweep）是很多老系统上耳熟能详的老年代垃圾收集器，主打的卖点就是低停顿。但不少线上项目上了 CMS 之后，发现平时确实挺快，可一旦遇到流量高峰，系统偶尔不仅不停顿，反而直接卡死几分钟。本文就来把 CMS 的执行阶段、并发设计的代价，以及退化成单线程 Serial Old 的根本原因彻底讲清楚。CMS 展现了一种非常惊艳的设计妥协：它首次把复杂的标记和清除过程搬到了后台，把几十秒的大停顿切碎成几毫秒的短停顿，为早期的 Java 交互系统立下了汗马功劳。

2026-10-01 11:25:37 58

原创【从0到1学习JVM · 25】同样都要停顿所有线程，Parallel比Serial到底强在哪

学完垃圾回收算法后，很多同学一看到 Serial 和 Parallel 收集器就容易困惑：既然都是停顿整个应用，多线程到底强在哪？多核时代单线程为什么还没被淘汰？本文对比这两代经典收集器的底层机制与选型权衡。垃圾收集器的演进并不是简单的“新架构碾压旧架构”。从 Serial 的单线程单打独斗，到 Parallel 的多核并行冲锋，背后反映的是底层硬件多核化、内存海量化与业务需求多元化的必然结果。单线程的 Serial 凭借纯粹的结构与零同步损耗，在微型容器和单核受限设备中依然保有一席之地；

2026-10-01 11:21:30 222

原创【从0到1学习JVM · 24】JVM搞出这么多垃圾收集器到底图什么

学完垃圾回收算法后，翻开 JVM 文档往往会被一长串收集器名字绕晕：Serial、Parallel、CMS、G1、ZGC……为什么 JVM 搞出这么多收集器？本文顺着垃圾收集器的演进主线，讲清楚它们各自的取舍与核心特点。学垃圾收集器，最忌讳的是死记硬背那一串冗长的参数。早期追求多核算力，Parallel 成了 JDK 8 的绝对主力；后来互联网业务怕卡顿，CMS 靠并发标记撕开了一道口子，但终究受制于内存碎片；

2026-10-01 11:16:21 170

原创【从0到1学习JVM · 23】一种算法管到底不行吗？为什么JVM垃圾回收非要搞分代收集

学完标记-清除、复制和标记-整理后，很多刚接触 JVM 的同学都会好奇：既然各有短板，为什么不干脆全堆选一个算法管到底？本文通过三个思想实验，拆解分代收集这套工程理念诞生的物理必然。当面对复杂的工程现实时，寻找一个包打天下的万能方案往往是徒劳的。复制算法有速度无耐力，标记-清除有空间无秩序，标记-整理有秩序无敏捷。分代收集跳出了微观算法互相较劲的怪圈，直接敏锐地顺应了程序运行期对象寿命的两极规律。把物理内存切分成代，让速度去匹配短命，让稳健去服务长生，最终以最低的系统开销达成了整体内存治理的平衡。

2026-10-01 11:11:38 384

原创【从0到1学习JVM · 22】三大垃圾回收算法深度对比，为什么JVM选不出最优解？

学完三大经典垃圾回收算法后，很多同学会好奇：为什么 JVM 不直接挑一个最好的通吃全场？本文从速度、空间与对象移动三大维度横向盘点它们的设计取舍，讲透分代收集背后的工程妥协。回顾这三大垃圾回收算法，没有任何一种算法是平白无故被发明出来的，也没有任何一种算法能狂妄地宣称自己天下第一。复制算法用空间去换取极速，标记-清除用碎片去换取短暂停顿，标记-整理则用漫长的对象移动去换取纯粹的规整空间。

2026-10-01 10:54:12 784

空空如也

空空如也