咕咕咕 Hexo https://cooooing.github.io/ All rights reserved 2026, 咕咕咕 咕咕咕的小破站 2026-03-06T14:08:00.000Z 咕咕咕 智能体经典范式构建

大语言模型（LLM）具备强大的推理与语言生成能力，但将其转化为能够与物理或数字环境交互的“智能体（Agent）”，需要一套严密的架构范式来组织其“感知-思考-行动”的控制流。
本章聚焦于三种最具代表性的智能体构建范式：ReAct、Plan-and-Solve 与 Reflection。通过从零手写这些架构的运行时逻辑，旨在剥离高层框架（如 LangChain）的抽象，深入理解智能体决策回路的底层机制。

基础环境与工具抽象机制

在构建复杂智能体范式之前，必须首先建立标准化的模型通信接口与外部工具注册中心。这是实现业务逻辑与底层基础设施解耦的关键工程步骤。

LLM 客户端封装

为了保证核心调度逻辑的纯粹性，需将 API 密钥管理、网络超时处理、请求重试策略以及流式响应（Streaming）的拼接逻辑封装在一个独立的 LLM 客户端类（如 HelloAgentsLLM）中。
这使得智能体的主循环仅需关注 messages 的构造与返回文本的解析。

工具执行器（ToolExecutor）的注册机制

工具是智能体干预外部世界的接口。一个标准化的工具执行系统必须具备以下设计：

  • 工具的元数据定义： 包含唯一的 Name、功能实现 func，以及极其关键的 Description。大模型缺乏对函数的硬编码认知，完全依赖 Description 中的自然语言描述来触发调用决策（Tool Routing）。
  • 注册与调度引擎： 统一的 ToolExecutor 类用于将多个孤立的工具函数注册进一个哈希表，暴露统一的 getAvailableTools 方法供 Prompt 动态渲染，并暴露 getTool(name) 供执行引擎动态调用。

范式一：ReAct（思考与行动的动态交替）

ReAct (Reasoning and Acting) 是由 Shunyu Yao 等人于 2022 年提出的经典范式。它打破了传统模型“纯推理（易产生幻觉）”或“纯行动（缺乏长远规划）”的二元对立，将逻辑推理与环境探测深度耦合。

ReAct 的状态机与控制流

ReAct 的核心是一个“走一步，看一步”的马尔可夫决策过程（MDP）。其运行轨迹被严格约束为交替出现的三个节点：

  • Thought（思考）： 智能体的内部认知过程。用于分析当前观察到的状态，反思上一步的结果，并决策下一步该调用什么工具。
  • Action（行动）： 智能体输出的一段结构化指令（如 Search[keyword]），该指令被外部解析器截获并映射为真实的 API 调用。
  • Observation（观察）： 外部 API 执行后返回的真实世界反馈。该反馈将作为新的上下文注入，触发智能体的下一轮 Thought。

数学形式化：
在时间步 ，智能体策略 依据初始问题 和历史轨迹 生成当前的思考和行动：

随后环境 返回观察：。该循环持续进行，直至模型输出表示任务完成的 Finish 指令。

ReAct 的 Prompt 工程与解析器设计

实现 ReAct 的难点在于强制 LLM 遵循严格的格式输出，以便代码解析。

  • Prompt 模板结构： 必须包含系统角色声明、可用工具列表的动态注入区、严格格式约束（如 Action: ToolName[Input]）、以及不断累积的 History 记录区。
  • 正则表达式解析器： 运行时引擎通过正则匹配（如 r"Thought:\s*(.*?)(?=\nAction:|$)"）剥离文本，切分出控制流（Thought）与执行流（Action）。

范式特性评估

  • 优势： 极高的可解释性（思维链可见）；强大的动态纠错能力（若某次搜索无果，模型可基于 Observation 自主变更搜索词重新尝试）；天然缓解了模型基于参数化知识的“事实性幻觉”。
  • 局限： 陷入局部最优（缺乏全局视野）；极高的网络请求开销（由于串行依赖，完成一个任务需经历多次 LLM 轮询）；解析脆弱性（模型格式稍有偏离即导致整个循环崩溃）。

范式二：Plan-and-Solve（先谋后动的两阶段架构）

针对 ReAct 在长链路复杂任务中容易“迷失方向”的缺陷，Plan-and-Solve（规划与求解） 引入了人类软件工程中的“瀑布流”思想，将任务解耦为明确的静态规划与依序执行两个独立阶段。

两阶段工作流解构

  • 阶段一：静态全局规划（Planner）
    由独立的 Planner 模块（或独立 Prompt）接管。输入原始问题，不进行任何工具调用，仅输出一个高度结构化的子任务队列（如 JSON 或 Python List）。此阶段强制模型进行宏观的、上帝视角的思维链拆解。
  • 阶段二：状态机递进执行（Executor）
    由 Executor 模块接管。引擎遍历任务队列 。在执行子任务 时，Prompt 必须同时注入全局计划 （以防止偏离主旨）以及历史执行结果集合 （提供前置依赖数据）。

范式特性评估

  • 优势： 目标一致性极强，有效遏制了复杂推理链的中途断裂；模块化程度高，规划器与执行器可分别挂载不同参数规模的 LLM 以优化成本。
  • 局限： 缺乏鲁棒性。一旦阶段一生成的计划存在根本性谬误，或者执行阶段某个前置任务失败，后续流程将产生灾难性的错误累积（Error Propagation），且标准架构下缺乏“重规划（Re-planning）”的异常中断机制。

范式三：Reflection（自我批判与迭代进化）

前两种范式本质上是“单次通过（One-pass）”的执行流。Reflection（反思机制） 则引入了后验（Post-hoc）的自我校正回路，使智能体具备元认知（Meta-cognition）能力，通过试错与自我批判逼近最优解。

反思机制的核心循环（Execution-Reflection-Refinement）

Reflection 范式依赖于多角色的提示词切换与短期记忆模块的管理。

  1. 初始执行（Execution）： 生成 Baseline 方案（如初版低效代码）。
  2. 自我批判（Reflection）： 切换系统提示词（如赋予“极其严格的资深评审员”角色）。传入原始任务与初版结果，强制 LLM 进行高维度的缺陷诊断（如时间复杂度分析、逻辑漏洞盘点），输出结构化的优化建议（Feedback）。
  3. 对齐优化（Refinement）： 再次切换提示词。输入包含原始任务、上一版输出 及评审员的负反馈 ，强制模型依据反馈生成补丁或重构结果 。

短期记忆（Memory）的生命周期管理

Reflection 强依赖上下文的完整回溯。需设计独立的 Memory 组件，严格按时序序列化存储 Execution_Record 与 Reflection_Record。这使得模型在第 轮优化时，不仅能看到上一轮的结果，还能“记住”自己之前犯过的错误，避免陷入相同的逻辑死胡同。

范式特性评估

  • 优势： 突破单次生成的质量天花板；将“一次性预测失败”转化为“持续优化的台阶”；极大提升了复杂任务（如数学推理、工业级代码生成）的最终可靠性。
  • 局限： 时间复杂度与成本双高（串行等待，Token 消耗呈倍数级增加）；存在 过度优化（Over-thinking） 或在两个错误版本间 震荡（Oscillation） 的风险，对终止条件（Stopping Criteria）的设定要求极高。

课后习题解析

智能体基础范式的组织架构与场景选型

【原问题】
现代智能体架构主要包含 ReAct、Plan-and-Solve 和 Reflection 三种经典范式。

  1. 请从底层控制流的角度分析，这三种范式在处理“思考（Reasoning）”与“行动（Acting）”的组织维度上有什么本质的区别？
  2. 假设需要设计一个“智能家居控制助手”（需统筹控制灯光、空调、窗帘等多个设备，并应对突发状态），作为架构师，你会选择哪种范式作为基础架构？为什么？
  3. 在现实的复杂工程中，单一范式往往存在短板。请尝试设计一种将上述范式组合使用的“混合智能体架构”，并阐述其流转机制及适用场景。

【解析】

  • 控制流组织方式的区别：
    • ReAct（交错试探型）： 思考与行动在极细的粒度上交替（Micro-level Interleaving）。思考的唯一目标是决策当前的单一行动，高度依赖外部环境的即时观察（Observation）来修正下一步推理。属于启发式搜索闭环。
    • Plan-and-Solve（宏观解耦型）： 思考与行动在时间轴上被强制物理隔离。思考阶段垄断了全局的规划与解构，行动阶段退化为基于给定列表的机械执行引擎。属于确定性有限状态机。
    • Reflection（后验嵌套型）： 并不改变前向的执行逻辑，而是在整个“思考-行动”链路外部嵌套了一层后验的“再思考（批判）”循环。属于强化优化与反馈控制。
  • 智能家居管家的架构选型：
    应采用 ReAct 架构为核心。 智能家居属于高度动态且部分可观察的物理环境。设备状态极易发生突变（如“拉窗帘”指令发出后，电机可能因卡顿报错）。Plan-and-Solve 无法预见未来的执行异常，会导致后续的依赖计划全盘崩溃；而 ReAct 的“行动 -> 观察异常 -> 重新思考策略”闭环天然具备对物理环境扰动的快速响应与动态纠错能力。
  • 混合架构设计方案（Plan-and-ReAct 融合框架）：
    • 机制设计： 引入全局规划器（Planner），首先生成宏观步骤树（如 [提取航班, 预订机票, 预订酒店]）。但在执行节点（Executor）层面，不再使用死板的执行脚本，而是为每一个宏观子任务实例化一个局部的 ReAct Agent。局部的 Agent 自主调用 API 并处理偶发错误。若局部 Agent 彻底失败，则向上层抛出异常，触发全局 Planner 进行重新规划。
    • 适用场景： 处理时间跨度大、涉及多个异构环境且极易发生中断的复合任务（如自动化的软件集成测试、长周期的自动化旅行日程编排）。

ReAct 引擎的鲁棒性优化与工具库扩容

【原问题】
在构建 ReAct 智能体时，常规做法是依赖正则表达式来解析大语言模型的自然语言输出（如提取 Thought 和 Action），并通过简单的字典哈希表注册工具。

  1. 依赖正则表达式提取输出流的做法在工程上存在哪些潜在的脆弱性？
  2. 除了正则表达式，现代工程框架中有什么更鲁棒的输出解析替代方案？试对比两者的优缺点。
  3. 若需为该系统添加一个“计算器”工具，并处理智能体多次调用错误参数引发的崩溃，系统应如何设计“工具选择失败”的引导纠错机制？
  4. 当业务膨胀，智能体的可用工具库从 5 个暴增至 100 个时，将所有工具描述硬编码进 Prompt 会导致什么工程灾难？应如何优化工具的组织和检索机制？

【解析】

  • 正则解析的脆弱性与替代方案：
    • 脆弱性分析： LLM 的自回归生成存在概率波动，极易在输出格式上产生微小的偏离（例如输出 Action :Search... 多了一个空格，或在闭合括号前增加了换行）。这会导致正则匹配直接返回 None，引发系统死锁或主循环崩溃。
    • 鲁棒替代方案： 采用 Function Calling（原生工具调用 API） 或 JSON Schema 结构化输出（Structured Outputs）。
    • 优缺点对比： 正则解析兼容性极强，适用于任何开源的基础模型，但容错率极低；JSON Schema / Function Calling 直接在模型推理的底层算子或解码阶段强制约束词表概率，实现了 100% 的格式对齐，但强依赖于模型服务商底层的接口支持。
  • 计算器工具接入与异常引导纠偏机制：
    • 工具实现： 封装一个安全的数学表达式求值引擎（如使用 Python 的 ast.literal_eval 配合预设的安全算符库），禁止直接使用原生的 eval() 以防注入攻击。
    • 失败纠偏机制设计： 在工具执行的 try-except 捕获块中，绝不能向外层直接抛出代码异常。应将异常堆栈信息封装为人类可读的提示语（如 Observation: 错误 - 计算公式格式不合法，请检查括号是否闭合。），并将其作为普通的观测结果送回给 LLM。LLM 会在下一轮的 Thought 中读取该错误反馈，并触发自我认知：“我上一步参数写错了，我需要修正表达式并重试”。
  • 超大规模工具库的路由重构（Tool Retrieval）：
    面对海量工具，早期的静态绑定与简单检索方案在工业级场景下已不再适用。其工程灾难与现代重构方案分析如下：
    1. 传统工具组织方案的致命缺陷
      • Prompt 静态硬编码的灾难： 将上百个工具 Schema 塞入上下文，不仅带来极其高昂的 Token 计费，更会引发大模型的“注意力弥散（Lost in the Middle）”，导致模型频繁调用无关工具或产生严重幻觉。
      • Top-K 向量检索的逻辑断裂： 仅按用户 Query 语义检索 3-5 个工具，会破坏工具链的隐式依赖。例如复杂任务需按序调用 获取用户ID -> 查询订单 -> 取消订单，语义检索往往只召回最后一个工具，导致前置参数缺失，任务直接崩溃；此外，Top-K 极易被字面相似的同质化工具占满名额。
    2. 现代工业级工具调度机制重构
      现代架构不再把所有底层 API 扁平化暴露给单一 Agent，而是通过协议解耦、领域路由与主动检索来实现高维管控：
      • 标准化接入与动态发现（基于 MCP 协议）：
        引入 MCP（Model Context Protocol）协议，将工具库从 Prompt 中剥离，封装至独立的 MCP Servers 中。
        LLM 作为 Client，通过标准化接口（如 list_tools()）进行动态发现与按需加载。这种 Client-Server 架构彻底打破了框架层面对工具数量的静态绑定。
      • 分层路由与技能簇抽象（Skills Routing）：
        摒弃“全能单体 Agent”，引入多智能体分层路由机制。
        • 语义网关（Semantic Router）： 前置极速分类模型，判断用户意图所属领域。
        • 领域技能分发： 将 1000 个工具按业务抽象为多个高内聚的“技能簇（Skill Pods）”，分发给对应的专家智能体（如 Finance_Agent 只需挂载 15 个财务工具）。在垂直领域内，模型能够完美进行注意力分配，彻底消灭漏召回问题。
      • 元工具寻址（Meta-Tool 机制）：
        将工具检索的主动权交还给大模型。系统初始仅向智能体注入 1~2 个元工具（如 search_skills(keyword, category)）。
        智能体在推理（Thought）时，若发现缺乏相关能力，需主动调用元工具查询 API 文档并拼装工具链。这使得智能体具备了在开放环境下的微观自治能力。

Plan-and-Solve 的状态流转与分层动态重规划

【原问题】
Plan-and-Solve 范式通过预先规划和机械执行解决了复杂任务的逻辑连贯性问题。

  1. 在标准实现中，生成的计划是一次性且静态的。如果在执行中途发现某个前置步骤无法完成，整个系统将陷入停滞。应该如何为该系统引入“动态重规划（Dynamic Re-planning）”机制？
  2. 在处理“预订一次从北京到上海的商务旅行（包含机票、酒店、租车）”任务时，Plan-and-Solve 与 ReAct 哪种范式更合适？为什么？
  3. 针对极度宏大的任务，设计一种“分层规划（Hierarchical Planning）”系统，先生成高层次抽象计划，再拆解详细子计划。这种设计相较于扁平的一维计划有何压倒性优势？

【解析】

  • 动态重规划（Re-planning）机制设计：
    需要将单向的瀑布流重构为带反馈回路的状态机。
    • 状态标定： Executor 在执行子任务时，强制 LLM 返回执行状态的枚举值（如 SUCCESS, FAILED_DUE_TO_ENV）。
    • 异常回退： 若捕获到 FAILED 状态，立即中断顺序执行链。系统将“原始总计划”、“失败的步骤坐标”以及“外部 API 报错原因”打包，重新拉起 Planner 模块。
    • 增量修正： 触发特殊的重规划提示词：“原计划的步骤 2 执行失败。请保持步骤 1 的既定成果不变，对步骤 2 及其后续依赖步骤进行重新编排”。
  • 商务旅行预订任务的范式选型：
    两者均有缺陷，但强行对比下 ReAct 的生存率更高。 预订场景高度依赖外部数据库的实时状态（例如原计划预订上午 9 点的航班，但查询后发现已售罄）。
    Plan-and-Solve 会因为死板地执行“预订 9 点航班”而导致整个任务流产；ReAct 能够在遭遇“售罄”的 Observation 后，即时转而搜索上午 10 点的替代航班。
    然而，最完美的方案是两者的结合（宏观采用 P&S 确保机酒车不遗漏，微观调用 ReAct 处理票务变动）。
  • 分层规划（Hierarchical Planning）系统的优势：
    • 突破上下文注意力瓶颈： 将任务从 扁平复杂度转化为 的树状结构。每个中层或底层的模型只需要获取其父节点的上下文，有效防止模型在生成长文本时遗忘最初的核心目标。
    • 高度可并发性： 一旦高层级的接口契约设计完毕，底层的微观任务（例如分别实现“酒店检索子模块”和“租车询价子模块”）可以被派发给多个 LLM 线程进行并发处理，极大地压缩了工程耗时。

Reflection 的元认知闭环与迭代策略优化

【原问题】
Reflection 机制通过“执行-反思-优化”的后验循环打破了初次生成的质量天花板。

  1. 在反思与执行阶段，如果我们在架构上使用两个不同的模型（例如用极其强大的模型做反思，用速度快的轻量模型做执行），这种非对称设计会带来什么深远影响？
  2. 当前 Reflection 机制的终止条件是“反馈中包含无需改进”或“达到最大迭代次数”。这种硬性设计存在哪些弊端？能否设计一个更智能的终止条件防范模型震荡？
  3. 假设需搭建一个“学术论文写作助手”，请设计一个多维度的 Reflection 机制，从段落逻辑性、方法创新性、语言表达、引用规范等不同角度进行综合反思和改进。

【解析】

  • 异构模型矩阵（Actor-Critic 非对称架构）的影响：
    • 经济学与延迟优化： 机械的代码生成或初稿书写可交由廉价且高吞吐的端侧小模型（Actor）完成；而发现逻辑漏洞、提供全局视野的“反思”任务，则交由昂贵的千亿参数顶级模型（Critic）完成。这在保证输出下限的同时，将总 API 成本与延迟大幅降低。
    • 破除自我证实偏差： 大模型极难发现自己刚刚生成的文本漏洞。使用权重分布不同的模型进行交叉审查，能提供真正的“外部视角”，显著提升 Bug 或逻辑谬误的检出率。
  • 智能终止机制（防震荡与收敛设计）：
    • 弊端分析： LLM 可能在两种等价的代码实现之间反复修改（震荡），或者因为过度苛求完美而耗尽迭代次数。
    • 优化方案： 引入外部评估标量（Scoring Function）。每次反思后强制输出一个量化评分（1-10分）。若连续 轮迭代评分未见提升，或出现评分倒退，立即触发熔断机制，回滚至历史最高分的版本并强行终止。
  • 多维度学术反思（Multi-perspective Reflection）设计：
    • 并行审稿专家池（Mixture of Experts）： 实例化四个独立的“反思代理（Reflector Agent）”。
      • Agent A（逻辑审查员）： 专职检查章节间的连贯性与论证的因果关系。
      • Agent B（创新评估员）： 评估方法论与前人研究的差异性。
      • Agent C（语言修饰员）： 检查学术用语的客观性与词汇丰富度。
      • Agent D（合规审查员）： 校验引用格式（APA/IEEE）与数据溯源。
    • 共识聚合机制： 四个代理并行生成反馈报告，交由一个“主编 Agent（Meta-Reflector）”进行冲突消解和去重，最终输出一份统一的修订清单供执行层进行定稿优化。

提示工程的结构化设计与微调策略

【原问题】
提示词工程（Prompt Engineering）直接影响智能体的底层决策逻辑。

  1. 对比 ReAct 和 Plan-and-Solve 的提示词模板，它们在结构设计上有何根本性差异？这些差异是如何服务于各自范式的核心逻辑的？
  2. 在 Reflection 的提示词中，如果将角色设定从“极其严格的代码评审专家”修改为“注重代码可读性的开源项目维护者”，会对智能体的输出产生什么实质性改变？
  3. 在复杂的格式化要求中，加入 Few-shot（少样本示例）为何能显著提升模型对特定格式的遵循能力？

【解析】

  • 范式提示词的结构性差异：
    • ReAct 提示词： 强调用分隔符与步骤标签（如 Thought:, Action:）强制约束模型的输出轨迹，以服务于逐帧切分、交替执行的微观控制流。它强调的是“当前状态”与“下一步动作”的映射。
    • P&S 提示词： 强调全局数据结构的输出（如包裹在 ```python 中的列表）。它隔离了环境交互，迫使模型将计算算力集中在“高维任务降维拆解”上，服务于宏观隔离的静态执行管道。
  • 角色扮演（Role-playing）对搜索空间的约束：
    修改角色设定本质上是改变了模型在隐空间中的“概率激活分布”。
    • “严格的算法专家”会激活底层权重中与“时间复杂度”、“内存泄漏”、“数据结构优化”相关的高维特征，使得输出代码趋向于极致的执行效率（如牺牲内存换取时间的空间换时间算法）。
    • “开源项目维护者”则会激活与“PEP-8 规范”、“详尽的 Docstring 撰写”、“变量命名清晰度”相关的特征，使得输出代码可能在算法上中规中矩，但工程可维护性极强。
  • Few-shot（少样本示例）的隐式对齐机制：
    大语言模型是强大的模式匹配引擎（Pattern Matcher）。Zero-shot 仅仅依靠语义指导，极易在输出格式上出现概率漂移。而加入 Few-shot 相当于在推理时（In-context Learning）提供了一个局部的、高权重的梯度锚点，使模型无需改变底层权重，即刻对齐到开发者期望的句法结构（如精确的 JSON 键值对或 Markdown 排版）中，极大降低了外围代码的解析崩溃率。

复杂业务落地：企业级电商客服智能体架构

【原问题】
某电商初创公司希望构建“全自动客服智能体”，需具备：理解用户长文退款诉求、查询数据库及物流状态、根据政策智能裁决、生成邮件，并在置信度较低（争议件）时触发自我反思。
作为产品技术架构师：

  1. 你会选择哪种范式（或组合）作为系统的核心骨架？
  2. 该系统必须具备哪些外部工具？（至少列举 3 个并定义其接口语义）。
  3. 应如何设计系统提示词，以确保智能体的决策在“保护公司利润”与“维持用户友好体验”之间取得平衡？
  4. 系统上线后将面临哪些高危风险？应如何通过底层技术手段进行兜底防御？

【解析】

  • 混合架构选型（SOP-Guided Agentic Workflow）：
    • 主控骨干： 采用 Plan-and-Solve（工作流版本）。因为客服处理是一个合规性极强的标准操作程序（SOP：查单 -> 判责 -> 回复），不可随意改变顺序。
    • 微观执行： 在“查单”环节嵌套 ReAct，应对物流单号格式错误时的自动纠错查询。
    • 争议兜底： 在“判责”环节嵌套 Reflection。模型强制输出决策置信度，若置信度低于阈值，激活“审计员”角色进行交叉盘问，确保裁决公正。
  • 核心工具集定义：
    1. query_order_status(user_id: str, order_id: str)：数据库直连工具。返回订单购买时间、签收状态、金额及历史客诉率。
    2. fetch_refund_policy(item_category: str)：RAG 政策检索引擎。传入商品类目（如“生鲜”或“数码”），返回企业规章中对应的退换货边界约束。
    3. draft_and_send_email(user_email: str, subject: str, body: str)：执行器工具。调用企业邮局系统向客户发送处理结果。
  • 系统提示词的对抗性约束设计：
    在 System Prompt 中设置分层权重的指令体系：
    “你是一个代表企业形象的高级客服仲裁官。
    【第一原则-合规底线】：所有退款决策必须严格以 fetch_refund_policy 检索出的条款为准，绝不允许私自豁免（极高权重）。
    【第二原则-柔性沟通】：无论裁决结果是通过还是驳回，你在生成邮件时必须展现极高的同理心，对用户的困扰表示遗憾，并使用温和、不带评判色彩的职业话术（中高权重）。”
  • 高危风险预判与兜底防御体系（Guardrails）：
    • 风险 1：恶意套现与错误退款（财务损失）。
      • 防御： Human-in-the-loop（人工介入） 机制。系统只赋予大模型审批 100 元以下退款的物理权限。高客单价或涉及复杂争议的决策，系统仅生成“建议方案”，必须触发审批流转交人工点击最终确认。
    • 风险 2：模型陷入工具调用的无限死循环（算力枯竭）。
      • 防御： 硬件与代码级别的强制死锁断路器。设定 MAX_TOOL_CALLS = 5。一旦查询工具调用失败超过 5 次，强制切断大模型上下文，向用户抛出降级预案：“抱歉，您的订单数据当前系统拉取超时，已为您转接人工专员处理。”

这是一份为您精心整理的学术级专业学习笔记。笔记严格遵循了层级标题结构，去除了偏向科普的冗余修辞，将其转化为逻辑严密、结构清晰的专业技术笔记，并对课后习题进行了无上下文依赖的重构与深度的逻辑推导解析。

第五章 - 基于低代码平台的智能体搭建

在前序章节中，我们通过了解了智能体的经典架构（如 ReAct、Plan-and-Solve 等）。这虽有利于深刻理解底层状态机与控制流，但在复杂的工业落地中，面临着极高的代码维护成本与调试难度。
本章聚焦于智能体工程化中的“平台化范式（Platformization）”，探讨如何利用低代码平台实现从“硬核代码构建”向“业务逻辑编排”的工程跃迁。

平台化构建的核心驱动力

低代码（Low-Code）平台并非对代码的摒弃，而是在更高维度上建立的一层抽象。其在 MAS（多智能体系统）开发中的核心价值体现在：

  • 技术门槛降维与敏捷验证： 平台将底层繁琐的 API 轮询、并发线程控制、上下文状态管理封装为可视化的“节点（Node）”。开发者可借此在极短时间内完成业务原型（Prototype）的闭环验证。
  • 端到端的可观测性（Observability）： 复杂的 Agent 工作流极易出现逻辑断裂或死循环。图形化编排提供了天然的数据流追踪链路，开发者可直观监控 Token 消耗、各个节点的耗时瓶颈以及工具调用的异常堆栈。
  • 最佳实践的范式沉淀： 成熟的平台内置了工业级标准的 ReAct 模板、高性能的 RAG（检索增强生成）检索引擎以及鉴权机制，避免了开发者重复踩坑。

主流低代码平台在产品定位上存在显著的分野：

  1. Coze（扣子）： 极致的低门槛与 C 端生态。提供极简的拖拽体验、海量开箱即用的插件，以及向微信、飞书等社交/办公平台的一键多渠道分发能力。
  2. Dify： 偏向后端的 LLMOps（大语言模型运维）平台。主打极其灵活的模型兼容性、企业级的高级 RAG 编排、多智能体协同路由以及深度的二次开发与私有化部署。
  3. n8n： 强流程驱动的业务自动化枢纽。其核心是异构系统间的互联互通（连接数百种 SaaS 服务），AI Agent 仅作为其工作流中的一个高级计算/决策节点存在。

平台一：Coze（插件生态与极速应用分发）

Coze 的架构哲学是“搭积木”，其业务重心在于降低智能体开发与分发的摩擦力。

Coze 的核心组件映射

如果将 Coze 视为一个游戏引擎：

  • 工作流（Workflow）/ 对话流： 定义 Agent 处理复杂任务的静态路径或动态交互逻辑。
  • 插件（Plugins）： Agent 干预外部环境的技能卡（如 RSS 订阅、GitHub 数据抓取）。
  • 知识库（Knowledge）： 提供特定领域事实的 RAG 挂载点。
  • 发布渠道（Publish）： 平台级的分发出口。

工程实践：聚合式 AI 简报助手

通过一个“每日 AI 简报”案例，展示 Coze 的聚合能力：

  • 多源异构数据抓取： 同步接入 36 氪/虎嗅的 RSS 插件、GitHub 热门项目拉取插件、arXiv 论文检索插件。
  • 角色与 Prompt 约束： 通过设定 System Prompt 强制模型执行结构化输出（如限制新闻条数、强制要求 Markdown 格式并附带原链接）。
  • 一键工程化部署： 将配置完成的 Agent 经过调试后，直接映射并发布至外部聊天工具（如飞书或微信生态）中提供服务。

平台特性评估

  • 优势： 零代码起步；极其庞大的插件生态与聚合分发能力，缩短了 GTM（Go-to-Market）时间。
  • 局限： 在复杂工程下，对代码级逻辑（如复杂的 JSON 结构重组）支持疲软；且当前节点尚未接入标准的 MCP 协议（Model Context Protocol），限制了企业级深度定制的上限；工作流导出受限。

平台二：Dify（企业级 LLMOps 与多智能体编排）

Dify 旨在弥合“原型玩具”与“生产级应用”之间的鸿沟，提供全栈式的 LLM 应用开发体验。

平台架构与核心能力

  • 模型中立与接入调度： 统一的抽象接口层，兼容国内外数百种闭源/开源模型，允许针对不同的子节点无缝切换性价比最高的大模型。
  • 高阶 RAG 管道： 提供可视化的文档分块（Chunking）、多路召回（Hybrid Search）及重排（Rerank）配置引擎。
  • 基于 MCP（模型上下文协议）的工具拓展： Dify 深度整合 MCP，允许开发者将外部私有系统封装为标准 MCP Server，Agent 可通过统一协议动态发现并调用这些工具（如连接企业内部 OA 或特定垂类 API）。

工程实践：多模态超级个人助手

展示 Dify 在构建复杂 MAS 架构时的强大能力，采用**“意图路由（Semantic Router） + 领域专家智能体”**的分层架构：

  • 意图分类器节点： 接收用户输入，利用极速小模型或关键字规则，将流量分发给对应的下游执行模块。
  • 并发专家网络：
    • 文案优化模块： 通过 Prompt 限定语气和篇幅。
    • 多模态生成模块： 串联外部文生图（如豆包生图）和视频生成工具链。
    • 数据洞察模块： 挂载数据库读取权限，结合 Text-to-SQL 工具生成数据概览，再通过图表生成插件将数据转化为可视化仪表盘。
    • MCP 外部服务： 通过 SSE（Server-Sent Events）模式直连外部 MCP 市场（如高德地图、实时新闻 API）。

平台特性评估

  • 优势： 极高的可玩性与企业级安全性（支持本地容器化私有部署、RBAC 权限管控）；海量的 Marketplace 生态；优异的高级 RAG 性能表现。
  • 局限： 学习曲线相对陡峭；核心后端基于 Python 使得其在超高并发场景下的吞吐量存在物理瓶颈。

平台三：n8n（业务流程驱动的自动化引擎）

与前两者“以大模型为绝对中心”不同，n8n 是一个泛用的工作流自动化平台（Workflow Automation）。在此平台中，LLM 被视为强化现有业务流流转的“认知中间件”。

节点（Node）与事件驱动模型

  • Trigger Nodes（触发器）： 监听外部事件以唤醒工作流（如 Webhook 钩子、定时任务 Cron、特定邮箱收到新邮件）。
  • Regular Nodes（处理节点）： 包含数据清洗、API 请求、逻辑分支（IF/Switch）等。
  • 数据载体： 节点间强制通过标准化的 JSON 报文进行上下文传递。

工程实践：基于 Agent 节点的智能邮件中枢

有别于传统的硬编码邮件回复，该实践利用了 n8n 最新的集成式 AI Agent 节点，将记忆、工具与模型收束为一个整体。

  • 内存 RAG 的注入： 创建一个独立的辅助工作流，将特定的业务规则（如“工作时间表”、“默认回复策略”）通过 Embedding 向量化并持久化存储。
  • 主工作流编排：
    1. 触发： Gmail Trigger 监听到新邮件，提取发件人、主题及正文体。
    2. Agent 决策中心： 将邮件数据打入 AI Agent 节点。挂载 Simple Vector Store（用于读取上述内部规则）和 SerpAPI（用于解答邮件中未知的外部事实）。
    3. 执行： Agent 根据自身推理输出结构化的回复 JSON（包含状态前缀与回复正文），并驱动下游的 Gmail Sender 节点执行物理发送动作。

平台特性评估

  • 优势： “流程连通性”天下无敌，支持极其复杂的异步、分支和鉴权逻辑；支持完全私有化部署。
  • 局限： 默认的轻量级 Memory 和 Vector Store 是基于内存的非持久化存储，重启即丢失，生产环境必须外挂重型数据库（如 Redis/Pinecone）；工作流版本管控（Version Control）较弱，调试长链路的 JSON 穿透时较为繁琐。

课后习题解析

大规模数据库查询的 Schema 动态注入机制

【原问题】
在构建数据分析智能体（Text-to-SQL）时，需要为大模型提供清晰的表结构（DDL）信息。
如果企业数据库极其庞大（例如包含 50 张表，每张表 20 个字段），将所有的 DDL 语句全部静态硬编码进提示词中，会瞬间耗尽大模型的上下文窗口，并引发严重的“注意力弥散”。
请设计一套更智能的工程方案来解决超大数据库的 Schema 注入问题。

【解析】
面对海量表结构的注入，必须摒弃“全量静态注入”的暴力做法，引入 检索增强表结构（Schema-RAG / 动态路由注入） 架构：

  • 离线向量化阶段（Schema Embedding）：
    将数据库中 50 张表的 DDL 语句、字段注释以及表之间的外键关系（Foreign Keys），以“单张表”或“高内聚表簇”为基本切分单位。利用 Embedding 模型将这些元数据向量化，存入独立的轻量级向量数据库中。
  • 在线动态路由阶段（Dynamic Retrieval）：
    • 意图召回： 当用户提出自然语言查询（如“统计上个月华东区销售额最高的商品”）时，系统首先利用该 Query 去向量数据库中进行 Top-K 相似度检索，精准召回相关的表（例如仅召回 sales_record 和 product_info 两张表的 DDL）。
    • 上下文按需拼接： 将召回的 2-3 张表的 DDL 动态拼接到 SQL 生成 Agent 的系统提示词中。
  • 多轮渐进式探测（Agentic Schema Exploration）：
    除了 RAG，还可以赋予智能体直接执行数据库元数据查询工具（如 SHOW TABLES, DESCRIBE table_name）的权限。
    让智能体像真实的数据分析师一样，先查询表名，再查询感兴趣表的结构，通过 ReAct 循环逐步获取所需上下文。这种方式彻底解除了数据库规模对上下文窗口的限制。

企业级平台部署模式的多维评估

【原问题】
Dify 等企业级大语言模型开发平台通常同时提供本地私有化部署（Local Deployment）和云端 SaaS 部署（Cloud Deployment）两种模式。
请从数据安全、运营成本、系统性能、维护难度等维度深度对比这两种模式，并说明它们各自适用的商业场景。

【解析】
两种部署模式在 IT 架构与商业考量上存在本质差异：

  • 数据安全与隐私合规：
    • 本地部署： 极高。数据流转闭环于企业内网防火墙内，适合处理机密文件、金融流水或医疗病历，满足严格的行业数据不出域审计要求。
    • 云端部署： 较低。数据需上传至第三方云服务商，安全性依赖于服务商的合规承诺（如 SOC2 / GDPR）。
  • 基础设施与运营成本：
    • 本地部署： 前期资本支出（CapEx）高昂。需自行采购 GPU 算力集群或租赁高配云主机资源。
    • 云端部署： 按需付费的运营支出（OpEx）。零硬件采购成本，适合初期预算有限的团队。
  • 系统性能与并发弹性：
    • 本地部署： 性能受限于本地硬件上限。面对突发的超高并发请求（如营销活动），扩容周期长，容易造成系统拥塞。
    • 云端部署： 依托云原生架构的弹性伸缩能力，可实现毫秒级的算力扩缩容，吞吐量和高可用性（SLA）更具保障。
  • 维护难度与迭代效率：
    • 本地部署： 极高。需要专业的 DevOps 团队负责容器编排、数据库备份、版本升级以及漏洞修复。
    • 云端部署： 极低。开箱即用，由服务商兜底系统运维和新特性的无感热更新。
  • 适用场景论断： 本地部署是大型政企、金融/医疗机构以及拥有成熟 IT 团队的必然选择；云端部署则是初创企业、中小规模敏捷团队进行 MVP（最小可行性产品）验证和轻量级业务落地的首选。

业务自动化总线的状态持久化改造

【原问题】
在使用 n8n 平台构建“智能邮件助手”的工作流时，基础教程通常使用 Simple Vector Store（简单向量库）和 Simple Memory（简单记忆）节点。
但这些节点是基于进程内存的，一旦 n8n 服务重启或容器销毁，所有的知识库与对话历史将彻底丢失。
请说明如何通过配置将其替换为工业级的持久化存储方案（如 Pinecone、Redis）。

【解析】
在生产环境中，必须将瞬时状态剥离出执行节点，实现计算与存储的物理分离：

  • 向量知识库持久化改造（以 Pinecone 为例）：
    1. 节点替换： 在 n8n 画布中删除 Simple Vector Store，拖入 Pinecone Vector Store 节点。
    2. 凭证配置： 创建 Pinecone 外部账户，获取 API Key 与 Environment/Host 地址，在 n8n 节点内部配置鉴权（Credentials）。
    3. 索引映射： 指定目标 Index Name，并确保前置的 Embeddings 节点输出的向量维度（如 OpenAI 的 1536 维）与 Pinecone 数据库中的索引维度严格一致。
  • 对话记忆持久化改造（以 Redis 为例）：
    1. 节点替换： 将 Agent 节点的记忆模块替换为 Redis Chat Memory 或 Postgres Chat Memory 节点。
    2. 网络连通： 配置 Redis 服务器的 Host、Port 及 Password。
    3. 会话隔离映射（Session ID Routing）： 极其关键的一步。必须在 Memory 节点中设置动态的 Session ID。
      例如针对邮件助手，需使用表达式 {{ $json.threadId }} 或 {{ $json.From }} 作为 Key。这样系统在处理并发邮件时，才能精准从 Redis 召回对应用户的历史上下文，防止不同用户的记忆发生串话。

自动化工作流的多模态认知扩展

【原问题】
当前的邮件助手仅具备文本解析能力。在实际业务中，用户发送的客诉邮件往往附带了 PDF 发票凭证或损坏商品的实拍图片。如何扩展现有的 n8n 工作流，使得智能体能够感知并理解这些多模态附件内容，并做出融合性回复？

【解析】
扩展多模态能力的核心在于在触发器与 Agent 节点之间，建立**“附件提取与异构解析路由”**流水线：

  • 步骤一：附件捕获与数据清洗。 在 Gmail Trigger 节点中开启 Download Attachments（下载附件）功能，将附件实体转为 n8n 的 Binary Data（二进制数据流）。
  • 步骤二：多模态路由分发（Switch Node）。 利用节点的条件判定功能，依据附件的 MIME Type（如 application/pdf, image/jpeg）进行分流处理。
  • 步骤三：异构格式降维解析。
    • 对于 PDF 附件： 引入 Read PDF 节点，将二进制流反序列化为长文本。若为扫描版，需进一步串联 OCR（光学字符识别）API 节点。
    • 对于图像附件： 引入具备视觉能力的 LLM 节点（如 OpenAI (Vision) 或 Claude 3.5 Sonnet），将图片数据转换为 Base64 编码送入视觉模型，提示词设定为“详细描述此商品损坏的部位与程度”，将其降维为文本描述。
  • 步骤四：上下文融合（Context Merging）。 利用 Merge 或 Set 节点，将原始邮件正文、PDF 解析文本、图像诊断文本组装成一个结构化的 JSON 对象，统一作为 Input 打入最终的 AI Agent 决策中心。

复杂电商业务链的网状自动化设计

【原问题】
n8n 的核心壁垒是极强的 API “连接”能力。假设需设计一个全链路电商后处理场景：当客户在 Shopify 下单后，系统需自动执行：发送确认邮件、更新 MySQL 库存、通知 ShipStation 物流系统生成面单、并在 Salesforce CRM 中记录客户购买行为。
请梳理该复杂工作流的节点连接拓扑图与关键参数映射逻辑。

【解析】
该工作流摒弃了单线流转，需采用扇出（Fan-out）与并行处理架构提升执行吞吐量：

  • 触发层（Trigger Layer）：
    • 节点： Shopify Trigger 或通用的 Webhook 节点。
    • 配置： 监听 Order Created 事件，捕获包含 Order_ID, Customer_Info, Items_List 的全局 JSON 负载。
  • 编排与并行分发层（Orchestration Layer）：
    通过连线将 Trigger 节点的输出同时指向下游的四个独立业务节点，实现并发执行：
    • 分支 A（触达）：Gmail / SendGrid Node -> 动作：Send Email。参数映射：To 填入 {{ $json.customer.email }}，Body 注入订单号。
    • 分支 B（库存）：MySQL Node -> 动作：Execute Query。参数映射：编写 UPDATE inventory SET stock = stock - {{ $json.items[0].quantity }} WHERE SKU = '{{ $json.items[0].sku }}' 的动态 SQL。
    • 分支 C（履约）：HTTP Request Node (对接物流) -> 动作：POST。向物流系统 API 发送建单请求，Body 中映射订单详细地址信息。
    • 分支 D（客户资产）：Salesforce Node -> 动作：Upsert Contact/Record。依据客户邮箱判断是否存在，不存在则新建线索，并追加本单消费金额。
  • 异常捕获与死信队列（Error Handling）：
    为 MySQL 或 HTTP 节点挂载 Error Trigger，若出现网络波动导致物流推单失败，将失败的 Payload 推送至 Slack 告警节点，提醒人工介入。

平台级提示词工程的语义与结构对比

【原问题】
Coze、Dify 和 n8n 均大量依赖提示词工程（Prompt Engineering），但对比这三者的典型提示词设计，其在句法结构、约束风格和业务侧重点上存在明显差异。请分析这些差异的根源及其与底层平台特性的内在关联。

【解析】
提示词的形态是平台底层调度哲学的显性折射：

  • Coze（C 端交互与人设驱动）：
    • 风格： 极度注重“角色扮演（Role-playing）”与富文本排版（如频繁要求使用 Markdown、加粗和 Emoji 表情）。
    • 关联解析： Coze 的最终载体多为微信、飞书等社交/办公对话框。它本质上是一个对话式交互代理（Conversational UI），因此提示词的重心在于打磨输出的“可读性”、“语气拟人化”与“视觉排版呈现”。
  • Dify（企业级规则与严谨流控）：
    • 风格： 结构极其森严（如使用 # 一、角色, # 四、限制提示 (Limit) 的公文格式），侧重于列举不可触碰的边界红线（Negative Prompts）。
    • 关联解析： Dify 面向复杂的企业级业务流（如合同审查、数据清洗）。其内核是确定性规则引擎。提示词设计的核心诉求是压制大模型的发散性“幻觉”，确保其输出在商业合规和逻辑严密性上绝对受控。
  • n8n（数据管道与机器语言约束）：
    • 风格： 编程化色彩浓厚，充斥着大量的动态变量插值（如 {{ $json.Subject }}），并且极其严苛地约束大模型必须以纯净的 JSON 格式输出。
    • 关联解析： 在 n8n 中，大模型只是流水线上的一个加工节点。其输出不直接给人看，而是要被下游节点（如数据库节点）直接解析执行。因此，它本质上是一个结构化数据转换器，提示词的唯一目的是确保输出格式 100% 符合机器序列化标准。

长度硬性约束的逻辑困境与弹性设计

【原问题】
在 Dify 文案优化模块的提示词中，硬性规定了“优化后的文案文本须超过 500 字”。在现代提示词工程理论中，这种对输出长度的硬性物理限制是否合理？在何种业务场景下应该严格锁死长度，又在何种场景下应当释放大模型的自由生成能力？

【解析】
采用物理字数（如“严格 500 字”）作为约束边界，在绝大多数场景下是不合理且存在极大副作用的。

  • 副作用剖析： 大语言模型是概率生成器，缺乏全局的字数规划意识。强制要求长度会导致模型在字数不足时疯狂堆砌毫无意义的车轱辘话（废话填充），或在逻辑未阐述完毕时戛然而止，严重破坏文本的信息密度和内在逻辑。
  • 应当限制长度的场景（前端规约驱动）： 只有在下游系统存在物理截断限制时才应限制长度。例如：Twitter 自动发文 Agent（严格限制 280 字符）、短信营销推送（限制 70 字）、UI 卡片展示摘要。此时应使用“请压缩在 50 个 token 以内”或“一句话总结”的软约束。
  • 应当自由发挥的场景（内容质量驱动）： 逻辑推理（如 CoT）、深度学术调研、文案创作。
  • 工程改良方案（维度替代法）： 不应限制字数，而应限制 “内容信息量”。应将“超过 500 字”的提示词修改为：“文案必须包含以下三个维度的论述：1. 痛点共鸣；2. 核心技术差异化分析；3. 紧迫的行动号召（Call-to-Action）。请充分展开论述，确保逻辑丰满。”

跨平台自定义工具扩展的底层逻辑

【原问题】
尽管 Coze 拥有海量插件商店，Dify 拥有 8000+ 插件市场，n8n 提供数百个预置节点，但在企业级落地的深水区，必然会遇到平台市场中不存在的“特定内部私有 API”（如连接公司内网的自研考勤系统）。面对这种标准平台无法覆盖的盲区，作为开发者应如何通过底层扩展机制解决此问题？

【解析】
所有成熟的低代码平台均提供了“逃生舱（Escape Hatch）”机制，以支撑协议级的自定义扩展：

  • Coze / Dify：基于 OpenAPI 规范的声明式接入。
    不需要编写胶水代码。开发者只需将内网 API 的接口定义提取为标准的 OpenAPI Schema（YAML 或 JSON 格式），导入平台。平台底层的解析引擎会自动根据 Schema 中的 description 字段将该 API 注册为一个 LLM 可理解的 Tool。
  • n8n：底层通信节点的降维使用。
    摒弃寻找现成的具象化节点，直接拖入图灵完备的底层节点：
    • 使用 HTTP Request 节点，手工配置 Method、Headers 与 Body，直接对内网 API 发起原生 RESTful/GraphQL 调用。
    • 若内网 API 的鉴权逻辑极度复杂（如特殊的哈希签名验签），直接使用 Code 节点编写原生的 JavaScript 或 Python 脚本，以纯代码硬核突围。

协议革命：MCP 对传统 Tool Calling 的降维打击

【原问题】
在 Dify 案例中，我们接入了基于 MCP（Model Context Protocol）的高德地图与新闻服务。请从底层架构的视角深刻剖析：MCP 协议与传统的 RESTful API 以及平台专有的 Tool Calling 机制存在哪些本质的代差？为什么行业公认 MCP 是未来智能体工具调用的“新标准”？

【解析】
MCP 引发了工具接入架构的解耦革命。

  • 传统的 RESTful API：数据中心化。 它只是一套网络接口规范，大模型根本“看不懂”接口的意义。必须由人类工程师编写大量的代码将其组装，无法实现大模型的自主调用。
  • 传统的 Tool Calling：平台深度耦合的孤岛。 OpenAI、Anthropic、Dify 等平台各自为战。开发者如果开发了一个“机票查询”插件，必须按照 OpenAI 的 JSON Schema 格式写一遍，再按 Dify 的规范改写一遍。工具与平台底层绑定，形成严重的生态壁垒。
  • MCP（模型上下文协议）：Client-Server 标准化解耦。
    • 它类似于电脑外设的“USB-C 接口协议”。外部系统（如高德地图、本地文件系统）只需实现一次标准的 MCP Server。
    • 任何支持 MCP 的框架（Claude 桌面端、Dify 等）作为 MCP Client，通过标准握手协议即可动态枚举（List Tools）和动态挂载这些能力。
    • 新标准的意义： 彻底打破了平台墙。企业只需在内网架设一个连接敏感数据库的 MCP Server，未来无论前端的大模型技术如何迭代，都可以实现即插即用、动态拉取能力，实现了 AI 时代真正的底层能力基础设施化。

Dify 自定义私有知识库插件的开发链路

【原问题】
假设企业内部拥有一个高度定制化的 Elasticsearch 知识库系统，现需为 Dify 开发一个自定义插件，使 Agent 能够动态查询该系统。请依据 Dify 的插件开发哲学，概述该开发的生命周期与关键技术锚点。

【解析】
在 Dify 中开发自定义插件，本质上是定义一套标准的数据通信契约：

  1. 接口标准化抽象（Schema 定义）： 审查企业 Elasticsearch 系统的查询接口。按照 OpenAPI 规范（Swagger）编写一份极度精确的 YAML/JSON 文件，着重打磨接口描述（Description）与入参说明，这是大模型准确进行路由的前提。
  2. 鉴权策略配置（Authentication）： 在 Dify 的插件配置台中，设定接口的鉴权机制（如 API Key 注入 Headers、OAuth2 等），确保 Dify 云端调用内网服务时的安全性。
  3. 开发与打包（Manifest）： 如果接口逻辑直接可用，单凭 OpenAPI 规范即可零代码生成插件；若涉及复杂的内网请求签名或结果后处理（如提取庞大的 JSON 树中的摘要字段），则需使用 Dify SDK 编写 Python 代码，打包为标准的插件结构（包含 .yaml 声明文件）。
  4. 本地联调与发布（Remote Debugging）： 利用 Dify 提供的本地调试隧道，打通云端 Dify 与本地插件环境，观察 LLM 的 Tool Calling JSON 负载是否能正确打入内网系统。调试无误后发布至私有 Workspace 供智能体挂载使用。

复杂业务场景的架构级选型决策博弈

【原问题】
作为技术负责人，公司计划开发以下三款 AI 应用。请在（Coze、Dify、n8n、纯代码开发）中为每个应用挑选最优技术栈，并从“技术可行性、开发与运营成本、可维护性、合规安全性”等维度详细阐述你的架构推演逻辑。

  • 应用 A： 面向 C 端的“AI 写作辅助”小程序。需抢占市场极速上线，预算紧缺，团队仅有 1 名产品与 1名前端。
  • 应用 B： 面向政府/金融客户的“智能合同审查系统”。涉密程度极高（数据不出域），需深度嵌入客户老旧的本地 OA 系统。
  • 应用 C： 公司内部的“研发效能中枢”。需全自动串联 GitLab 代码审查、生成测试报告、同步 Jira 进度等长链路研发流。

【解析】
技术选型的本质是**“用最小的系统复杂度覆盖业务需求的核心短板”**。

  • 应用 A（C 端写作小程序）：绝对倾斜于 Coze。
    • 推演逻辑： 核心痛点是“资金匮乏与试错速度”。缺乏后端与运维资源使得纯代码和 Dify 私有化部署直接出局。
      Coze 提供了极致的零代码画布，产品经理可独立完成提示词调优；其云端免费算力与一键生成 API/小程序的特性，将开发周期从数周压缩至数天，完美实现了敏捷 MVP 的低成本跨端分发。
  • 应用 B（企服合同审查中枢）：采用 Dify（本地私有化部署）+ 局部纯代码。
    • 推演逻辑： 核心痛点是“涉密数据的物理隔离与长文本解析的严谨度”。数据绝对不能上公有云，Coze 和云端 n8n 无法过合规审计。Dify 提供了完善的 Docker 本地私有化方案，并内置了业界顶尖的文档解析策略与高级 RAG 工作流（合同条款检索极其依赖 RAG 精度）。
      针对对接老旧 OA 系统的痛点，可通过纯代码编写定制化的 Dify 插件（或 MCP Server）作为桥梁，实现现代 AI 引擎与遗留系统（Legacy System）的平滑对接。
  • 应用 C（研发长链路自动化流）：绝对倾斜于 n8n。
    • 推演逻辑： 核心痛点是“多重异构系统的事件监听与状态穿透”。这不是一个对话应用，而是一个底层事件总线。GitLab PR 提交、Jira 状态变更均需要强悍的 Webhook 监听与路由分发。
    • n8n 天生具备几百个第三方系统的鉴权凭证和无缝对接节点，技术团队可以像画流程图一样，将代码拉取、大模型审查、Bug 单回写等一系列异步动作编排在同一个画布上。相较于用纯 Python 代码维护几百个乱如乱麻的异步回调函数，n8n 在系统可维护性与拓展性上构成了压倒性的降维打击。

这是一份为您深度整理的学术级专业学习笔记。笔记严格遵循了层级标题结构，去除了偏向科普的冗余修辞，将其转化为逻辑严密、结构清晰的专业技术笔记，并对课后习题进行了无上下文依赖的重构与深度的逻辑推导解析。

第六章 - 框架开发实践

在前序阶段，通过原生脚本（如 Python）实现智能体，有助于深刻理解底层的状态机与控制流。
然而，当业务复杂度上升时，原生脚本在状态持久化、并发调度以及多智能体协同（Multi-Agent System, MAS）方面往往面临极高的维护成本。
智能体框架（Agentic Frameworks）的引入，标志着从“一次性脚本”向“工程化产品”的思维跃迁。

智能体框架的工程跃迁与价值

智能体框架的本质是提供一套工业级的“规范与抽象层”，以解决复杂系统开发的工程痛点：

  • 架构解耦与高扩展性： 强制隔离模型层（Model Layer）、工具层（Tool Layer）与记忆层（Memory Layer）。开发者可在不侵入核心业务逻辑的前提下，热替换底层大模型或数据检索引擎。
  • 标准化状态管理： 框架接管了复杂的上下文生命周期，自动处理 Token 截断、多轮会话状态持久化以及长程记忆的滑动窗口机制，消除了手动维护全局变量的风险。
  • 深度的可观测性（Observability）： 内置事件钩子（Hooks）和回调系统（Callbacks），在智能体生命周期的关键节点（如 on_llm_start, on_tool_error）自动触发日志记录，为复杂决策树的断点调试提供了标准化手段。

AutoGen：对话驱动的多智能体协同

AutoGen 的核心设计哲学是将一切复杂的软件工程或业务流程，映射为多角色之间的“自动化群聊通信”。

核心组件与演进架构

在新版架构中，AutoGen 引入了“底层异步 + 上层组件化”的分层设计：

  • 分层与异步优先： 底层 autogen-core 负责 I/O 密集型的模型通信与事件分发（完全基于 asyncio 重写）；上层 autogen-agentchat 负责高阶对话逻辑。异步设计彻底消除了并发场景下的线程阻塞。
  • 智能体基类分离：
    • AssistantAgent（思考引擎）： 挂载大语言模型，依靠系统提示词（System Message）进行角色化（Role-playing）与逻辑推理。
    • UserProxyAgent（执行/网关引擎）： 作为代码沙盒执行器，或充当人类介入（Human-in-the-loop）的代理节点，明确剥离了“思考决策”与“物理执行”的系统边界。

控制流机制：群聊状态机

AutoGen 摒弃了硬编码的工作流，采用群聊控制器（Team/GroupChatManager）驱动状态流转：

  • RoundRobinGroupChat（轮询拓扑）： 适用于顺序固定的流水线任务（如：PM -> Engineer -> Reviewer）。智能体按预设顺序依次被激活，并共享全局聊天上下文。
  • 文本级终止信号（Termination Condition）： 协作的退出依赖于特定智能体输出预设信号（如 TERMINATE），框架捕获该信号后自动销毁当前会话。

AgentScope：消息驱动与工业级工程架构

AgentScope 是由阿里巴巴达摩院开源的、面向高并发与分布式企业级 MAS 设计的平台，其核心差异在于用“结构化消息”彻底取代了传统的“函数调用”。

消息总线驱动（Message-Driven Architecture）

  • MsgHub（消息中枢）： 框架摒弃了点对点的强耦合调用，所有的上下文传递均被封装为标准化的 Msg 对象。MsgHub 扮演分布式消息队列的角色，负责动态的路由分发（广播、组播、单播）。
  • 时空解耦与分布式原生： 消息发送方与接收方在时间（异步非阻塞）和物理空间（位置透明）上彻底解耦，底层通过 RPC（远程过程调用）处理跨节点通信。

并发管线与强类型约束

  • 结构化输出验证（Structured Output）： 在复杂博弈场景（如“三国狼人杀”），深度结合 Pydantic 模型，将业务规则转化为数据验证模型（Schema Validation），在解析层自动拦截非法输出，保障逻辑树不崩溃。
  • Fanout 异步并发拓扑： 提供 fanout_pipeline 语法糖，支持向多个智能体并行分发请求并在异步等待后进行状态规约，极大提升了系统在群体决策阶段的吞吐量。

CAMEL：基于角色扮演的对齐与涌现

CAMEL 致力于在最少的人工干预下，通过互补专家的思维碰撞，涌现出解决复杂任务的最优解。

引导性提示与控制协议（Inception Prompting）

  • 双螺旋角色模型： 强制将宏大任务拆分为需求方的 AI User（发包者/主导者）与供给方的 AI Assistant（执行者/专业顾问）。
  • 元提示注入（Meta-Prompt）： 系统底层动态生成一套严苛的交互契约，强制双方：一次只推进一个微小步骤；接收方必须给出审核意见；达成共识前禁止跳出当前逻辑。这种设计在“学术科普写作”等发散性创作中，能够自动形成高度拟人化的流水线。

LangGraph：图计算抽象与确定性状态机

LangGraph 采用了与对话驱动截然不同的技术路线，它将 MAS 退化并重构为一个极度严密的有向图（Directed Graph），赋予开发者对控制流的绝对掌控权。

图论视角的组件重构

  • 全局状态张量（State）： 摒弃杂乱的聊天历史，定义严格的、单例的 TypedDict。所有节点仅对该状态字典中的特定字段进行增量读写。
  • 节点与路由（Nodes & Edges）：
    • 执行节点（Nodes）： 纯粹的 Python 函数，接收状态、执行模型或工具调用，并返回增量状态。
    • 条件边（Conditional Edges）： 通过判别函数动态改变流转拓扑。这是实现状态机循环（如“评估-重试”机制）的核心基础设施。
  • 工程优势： 天然支持复杂循环（Cycles）、状态的细粒度可观测性，以及工业级的断点续传（Checkpointing）能力。

课后习题解析

智能体框架的底层哲学辨析

【原问题】
智能体开发框架呈现出多样的设计思路。

  1. 请对比 AutoGen 和 LangGraph 两个框架，从“协作模式”、“控制方式”以及“适用场景”三个核心维度进行深度的架构剖析。
  2. 软件系统设计中常存在“涌现式协作（Emergent Collaboration）”与“显式控制（Explicit Control）”的权衡。请结合大语言模型的非确定性，阐述这两种设计哲学在智能体工程落地中的利弊。

【解析】

  1. AutoGen VS LangGraph 架构深度对比：
    • 协作模式： AutoGen 是“去中心化的社会学模拟”，多主体共享上下文沙盒，依靠阅读他人的自然语言触发自身动作；LangGraph 是“中心化的车间流水线”，其本质上不存在具备自主意识的独立智能体，只有被图结构串联的“处理工序”，共同读写一个中心化的全局黑板（State）。
    • 控制方式： AutoGen 是“语义驱动路由（Semantic-driven）”，控制边界模糊，下一步的走向高度依赖大模型的意图理解与预设轮询；LangGraph 是“图逻辑驱动路由（Graph-driven）”，流转路径被代码中的条件边（Conditional Edges）硬性卡死，控制边界绝对清晰。
    • 适用场景： AutoGen 适合“探索性强、需要头脑风暴”的发散型任务（如剧本共创、代码攻防）；LangGraph 适合“SOP（标准作业程序）严苛、零容错”的收敛型业务流（如金融核保、自动化运维排障）。
  2. “涌现”与“控制”的架构博弈：
    • 涌现式协作（如 CAMEL / AutoGen）： 承认并利用 LLM 跨维度的解题能力。优势： 能够跳出人类程序员预设的思维定势，找到创新解。代价： 系统的非确定性（Non-deterministic），极易在生产环境中引发主题漂移、死循环等幻觉崩溃，且几乎无法编写确定性的单元测试。
    • 显式控制（如 LangGraph）： 将模型视作高级的非结构化数据处理器，关进有限状态机的牢笼。优势： 在工业界落地时具有极高的可预测性、可审计性和商业安全性。代价： 牺牲了模型的高维发散智慧，系统的能力上限被架构师画流程图的能力所死死锁住。

对话驱动协同（AutoGen）的动态调度重构

【原问题】
在 AutoGen 框架中，通过 RoundRobinGroupChat 构建的模拟软件开发团队（产品经理、工程师、代码审查员）是按固定顺序发言的。

  1. 如果在代码审查环节发现需求存在偏差，需要将代码打回给产品经理重新规划，应如何修改协作流程，设计一个支持“动态回退”的机制？
  2. 为该团队引入一个“测试工程师（QA）”角色，请设计其 System Message，使其能在代码审查后介入执行自动化测试。
  3. 对话式协作极易陷入逻辑死循环或偏离主题。在工程设计上，如何构建一套“对话质量监控”机制进行及时干预？

【解析】

  1. 突破轮询，设计动态回退机制（FSM 路由重构）：
    放弃僵化的 RoundRobinGroupChat，改用底层的 GroupChat 并自定义发言人选择策略（Speaker Selection Method）。
    通过注入有限状态机（FSM）的转移图机制：正常情况下 Engineer -> Reviewer；当状态机捕获到 Reviewer 的输出中包含特定标识（如“需求歧义”或“架构错误”）时，转移概率发生突变，状态强制跃迁回 ProductManager，实现流程回溯。
  2. 测试工程师角色的 System Message 设计：
    1
    2
    3
    4
    5
    6
    7
    你是一位严谨的软件测试工程师（QA）。
    你的职责是在接收到审查通过的代码后，设计并执行自动化测试用例。
    工作流约束：
    1. 阅读工程师的代码与审查员的意见。
    2. 编写覆盖正常路径与异常边界的 Python pytest 代码。
    3. 若测试发现 Bug，请详细输出 Error Trace，并明确回复“测试未通过，请工程师修复”。
    4. 若测试全部通过，请明确回复“测试通过，允许交付”。
  3. 对话质量监控机制（System-level Interruption）：
    • 隐形监督者（Supervisor Agent）： 在系统中植入一个具有极高权限的后台监控钩子。
    • 轮次熔断（Timeout Circuit Breaker）： 设定硬性阈值（如连续 5 轮未产出有效代码，直接熔断并抛出异常）。
    • 语义偏移检测： 监督者定期抽取最近的会话窗口，计算其与初始 Task Prompt 的特征向量余弦相似度。
      若相似度跌破安全阈值，认定发生“主题漂移”，系统自动向群聊中注入一条高权重 Meta-Message：“System Alert: 讨论已偏离核心任务，请立即终止发散，回归到代码实现环节！”以强制纠偏。

消息驱动（AgentScope）的并发与分布式挑战

【原问题】
AgentScope 利用消息总线（MsgHub）和结构化输出支撑了复杂的“三国狼人杀”游戏场景。

  1. 相比传统框架中直接使用函数调用，MsgHub 消息驱动架构的本质优势是什么？
  2. 游戏中通过定义 Pydantic 模型约束输出。请设计一个新的游戏角色“猎人”的结构化输出模型（含字段定义与验证规则）。
  3. 在实时博弈场景中，将不同智能体进行分布式部署会引发哪些技术挑战？如何保证全局消息的时序一致性？

【解析】

  1. 消息驱动架构的降维打击：
    传统的函数调用是同步且强耦合的（Call-and-Wait），某个 Agent 响应慢会导致整个主线程阻塞。MsgHub 实现了计算与通信在时间（异步非阻塞）和空间（位置透明）上的彻底解耦。
    它天然支持事件广播（Broadcast）和并发收集（Fanout），是实现大规模“多智能体并发运作”的基础设施。
  2. 猎人角色的强类型输出模型设计（Pydantic Schema）：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    from pydantic import BaseModel, Field, validator
    from typing import Optional

    class HunterActionModel(BaseModel):
        trigger_skill: bool = Field(description="当前出局时，是否发动猎人技能开枪")
        target_player: Optional[str] = Field(description="若发动技能，目标玩家的名称", default=None)

        @validator("target_player")
        def validate_target(cls, v, values):
            if values.get("trigger_skill") and not v:
                raise ValueError("发动技能时必须指定合法的目标玩家")
            return v
  3. 分布式 MAS 的并发时序挑战与解决（CAP 定理投影）：
    • 技术挑战： 网络延迟抖动与时钟漂移。若玩家 A 的“反驳消息”因网络拥塞，晚于玩家 B 的“投票消息”到达裁判节点，会引发“因果逻辑倒置”，导致大模型基于错乱的时序生成违背规则的推演。
    • 时序一致性保障设计： 摒弃物理时间戳，引入逻辑时钟（Logical Clocks，如 Lamport 时间戳）。MsgHub 核心调度器为每个生成的事件打上绝对递增的 Sequence ID。
      在分布式接收端设置因果组装缓冲区（Causal Buffer Barrier），必须等待消息齐备并按 Sequence ID 排序后，再将有序的上下文推入 LLM。

角色扮演协同（CAMEL）的死锁与架构拓展

【原问题】
CAMEL 框架通过“引导性提示”实现双智能体（如心理学家与作家）的自治协作。当检测到 <CAMEL_TASK_DONE> 标志时强制终止。

  1. 如果两个智能体意见分歧（一位认为已完成，一位拒不接受），导致陷入逻辑死锁，系统应如何设计仲裁机制？
  2. 查阅 CAMEL 的多智能体协作模块（Workforce），说明其在协作拓扑图上与 AutoGen 的群聊模式有何根本不同？

【解析】

  1. 死锁破除与仲裁设计（Conflict Resolution）：
    纯粹依赖 LLM 内部和解极不可靠，必须引入系统级干预。
    • 非递增驳回熔断： 维护一个连续拒绝计数器，若 User 连续驳回 Assistant 的产出超过 3 次，挂起当前对话线程。
    • 引入仲裁者（Moderator Agent）： 激活一个拥有系统级权限的独立模型。将僵持的上下文抛入，由 Moderator 判定 Assistant 的产出是否已实质满足初始 Task Prompt。
      若满足，Moderator 代发强行终止指令；若不满足，由 Moderator 给出具体的强制修改锚点。
  2. 协作拓扑差异（群聊 vs 层级委派）：
    • AutoGen 的群聊： 属于“扁平化网状拓扑”，所有节点在一个大沙盒中共享全量的广播上下文，容易产生信息噪音。
    • CAMEL 的 Workforce： 采用了树状分层委派架构（Hierarchical Task Delegation）。
      定义了一个 Coordinator（主节点）和多个底层的 Worker。主节点负责将大任务解耦并点对点分发给特定 Worker，Worker 完成后仅向主节点汇报，彼此间不交叉。这种结构有效隔离了上下文噪音，更适合处理多级复杂业务流。

状态机与图计算（LangGraph）的循环拓扑设计

【原问题】
LangGraph 将智能体流程建模为有向图。

  1. 请绘制出“三步问答助手（理解 -> 搜索 -> 回答）”的图结构，精确标注节点、有向边和状态转换条件。
  2. 为打破单向线性流程，请增加一个“深度反思（Reflection）”节点：在回答后进行质量评估，若不合格则回退重新搜索。说明条件边的路由逻辑。
  3. 结合原生循环特性，设计一个“代码生成 -> 编译测试 -> 异常修复”的复杂应用场景，说明核心流转机制。

【解析】

  1. 线性有向图拓扑映射：
    [START] –(常规边)–> [Node: Understand (提取搜索词)] –(常规边)–> [Node: Search (调用API更新状态)] –(常规边)–> [Node: Answer (生成最终文本)] –(常规边)–> [END]
  2. 带循环的反思拓扑重构（Cyclic Reflection Graph）：
    切断 Answer 通向 END 的边，插入新节点 [Node: Evaluator]。
    • 新增节点： Evaluator 读取状态中的 final_answer 进行评分，更新布尔状态 state["is_qualified"]，并递增 state["retry_count"]。
    • 条件边（Conditional Edge）路由逻辑： 从 Evaluator 拉出条件边。判定函数逻辑：
      if state["is_qualified"] == True or state["retry_count"] >= 3:
      return "end_workflow" -> 路由指向 [END]
      else:
      return "need_research" -> 路由跳回 [Node: Search]。
  3. “生成-测试-修复”复杂循环设计：
    • 节点一：[Node: Coder]（接收需求或报错日志，生成代码片段）。
    • 节点二：[Node: Sandbox_Tester]（在隔离沙盒中物理执行代码。若成功，记录状态 PASS；若失败，提取 stderr 写入状态，记为 FAIL）。
    • 核心流转（条件边）： 挂载于 Sandbox_Tester 之后。判定 state.status，若为 PASS，流向 [END]；若为 FAIL，流回 [Node: Coder]。
      此时 Coder 节点读取增量状态中上一次失败的代码和终端报错栈，进行针对性 Patch 修复，再次流入 Tester 进行验证。

企业级业务架构：框架选型深度推演

【原问题】
作为 AI 公司的技术架构师，请为以下三个应用选择最合适的底层开发路径（AutoGen, AgentScope, CAMEL, LangGraph, 或纯代码开发），并从技术可行性、并发性能、可控审计等维度详细阐述推演逻辑：

  • 应用A：智能客服系统。需处理 1000+ QPS，响应延迟 < 2s，支持水平无状态扩容。
  • 应用B：科研论文辅助写作平台。要求“研究员”与“写作”智能体进行多轮深度辩论，高度自主推进任务。
  • 应用C：金融风控审批系统。包含资料审核、风险评估等严格分支逻辑，要求流程百分百可追溯、可审计。

【解析】
架构选型的本质是评估系统的“确定性容忍度”与“工程吞吐量”。

  • 应用 A（高并发极速客服）：必须选用原生代码重构（或极度裁剪的 AgentScope）。
    • 推演逻辑： 1000 QPS 的并发量是极其严苛的工程红线。
      依赖繁重聊天历史拼接的 AutoGen / CAMEL，其框架层级的状态序列化开销、以及冗长的 Prompt 包装，会引发灾难性的 CPU 负载与 Token 延迟，彻底违背 <2s 的 SLA。
      必须剥离一切抽象，采用基于 FastAPI/Go 的纯异步原生代码，搭配 Redis 外置记忆，实现极致精简的无状态（Stateless）流式 RPC 调用，以支撑 Kubernetes 的水平弹性扩容。
  • 应用 B（高度自主的学术涌现）：绝对倾斜于 CAMEL（或 AutoGen）。
    • 推演逻辑： 学术科研的核心诉求是突破信息茧房，引发“群体智能的涌现（Emergent Intelligence）”。解题路径在初始阶段是未知的，真理诞生于苏格拉底式的辩论中。
      CAMEL 极简的双角色对齐协议（Inception Prompting）天然为这种发散-收敛推演而生。这类产品追求探索的逻辑张力而非流转的确定性，因此赋予模型极高自治权的对话驱动框架是首选。
  • 应用 C（金融级刚性风控中枢）：唯一指定方案为 LangGraph。
    • 推演逻辑： 金融风控对 LLM 的“自由发挥（幻觉）”零容忍，它需要的是“戴着镣铐跳舞的组件”。LangGraph 底层是一个强类型的“有向图状态机（FSM）”，能够将信贷的数十个 SOP 死死钉在图节点上。
      最关键的是，LangGraph 拥有原生的 Checkpointing（断点检查）机制，每次节点流转的状态增量都能落盘数据库。这为金融合规提供了不可篡改的时间旅行追踪（Time Travel）与全量审计日志能力，一举击穿监管痛点。
]]> https://cooooing.github.io/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E3%80%8Ahello%20agents%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-%E6%9E%84%E5%BB%BA%E4%BD%A0%E7%9A%84%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E6%99%BA%E8%83%BD%E4%BD%93/ 2026-03-06T14:08:00.000Z 智能体经典范式构建

大语言模型（LLM）具备强大的推理与语言生成能力，但将其转化为能够与物理或数字环境交]]>

《hello agents》读书笔记 - 构建你的大语言模型智能体 2026-03-06T14:08:00.000Z 咕咕咕 第一章 - 初识智能体

本章从人工智能的发展脉络出发，系统阐述了智能体（Agent）的本质定义、演进路线，以及在大语言模型（LLM）驱动下产生的新范式。通过探讨其内部架构、交互机制与协作模式，为理解多智能体系统（MAS）奠定了核心理论基础。

什么是智能体？

在探讨前沿 AI 之前，必须先明确智能体的本体论定义。智能体并非单纯的代码脚本，而是一个具备环境感知与干预能力的闭环系统。

  • 四大核心要素：
    • 环境（Environment）： 智能体所处的外部动态世界（如自动驾驶的道路、量化交易的市场）。
    • 传感器（Sensors）： 智能体获取环境状态的途径（如摄像头、雷达、API 数据流）。
    • 执行器（Actuators）： 智能体对环境施加影响的物理或虚拟载体（如机械臂、代码执行器、服务调用）。
    • 自主性（Autonomy）： 智能体的灵魂，即不依赖被动指令，而是基于内部状态和感知数据进行独立决策并达成目标的能力。
  • 交互闭环： “感知 -> 决策 -> 行动”构成了所有智能体存在的底层逻辑。

传统视角下的智能体演进路线

在 LLM 爆发前，符号主义与早期机器学习主导了智能体的设计，其演进呈现出从“被动反应”到“主动规划与学习”的阶梯式发展：

  • 简单反射智能体（Simple Reflex Agent）： 基于“条件-动作”规则（If-Then）运行。无记忆、无预测，极度依赖当前瞬间的感知（如老式恒温器）。
  • 基于模型的反射智能体（Model-Based Reflex Agent）： 引入了“内部世界模型”以维持状态记忆，能够处理部分不可见的环境信息，实现上下文连贯的决策。
  • 基于目标的智能体（Goal-Based Agent）： 从“被动反应”转向“主动预测”。通过搜索与规划算法（如 A* 算法），探索达成特定未来状态的最优路径（如 GPS 导航）。
  • 基于效用的智能体（Utility-Based Agent）： 面对多重且冲突的目标时，通过引入“效用函数”来量化各个状态的满意度，以最大化期望效用为决策导向，更贴近理性经济人假设。
  • 学习型智能体（Learning Agent）： 突破了人类预设规则的瓶颈。由“性能元件”（决策）和“学习元件”（优化）组成。通过与环境互动（如强化学习 RL），利用奖励机制自我进化（如 AlphaGo）。

大语言模型驱动的新范式

LLM 的出现颠覆了传统智能体的构建逻辑。传统智能体依赖显式编程与边界清晰的规则，而 LLM 智能体则依赖海量预训练数据中涌现的隐式知识与通用推理能力。

  • 范式对比的核心维度：
    • 核心引擎： 传统（规则/逻辑搜索/强化学习） vs 新范式（大语言模型神经网络）。
    • 知识来源： 传统（人工注入先验知识） vs 新范式（海量语料预训练得到的隐式世界模型）。
    • 任务拆解： 传统（开发者硬编码） vs 新范式（模型自主进行链式推理与逻辑分解）。
    • 交互方式： 传统（结构化数据/指令） vs 新范式（高层级、模糊的自然语言）。
  • LLM 智能体的三大涌现特征：
    1. 规划与推理： 能够将宏大的自然语言目标自主降维分解为可执行的子任务树。
    2. 工具使用： 识别能力边界，主动调用外部 API（如查天气、日历）弥补信息缺口。
    3. 动态修正： 具备基于环境反馈或用户约束（如“超出预算”）进行自我纠错与路径重规划的能力。

智能体的多维分类体系

智能体可以从以下三个互补的学术维度进行深度剖析：

  • 基于时间与反应性的权衡：
    • 反应式（Reactive）： 决策延迟极低，基于直接映射行动。优势是速度快、计算开销小；劣势是短视，易陷入局部最优（如高频交易、安全气囊）。
    • 规划式（Deliberative）： 行动前进行深度前瞻探索。优势是具战略远见；劣势是计算成本极高，在动态环境中易错失良机（如复杂路线规划）。
    • 混合式（Hybrid）： 现代 LLM 智能体的主流形态。在宏观层面通过大模型进行审慎规划（Reasoning），在微观层面通过调用工具获取即时反馈（Acting & Observing），实现长远规划与敏捷反应的统一。
  • 基于知识表示的流派（AI 哲学的核心分野）：
    • 符号主义 AI（Symbolic AI）： 知识表现为显式的逻辑规则（如知识图谱）。透明、可解释，但存在“知识获取瓶颈”，对模糊现实的鲁棒性差。
    • 亚符号主义 AI（Sub-symbolic AI / 连接主义）： 知识内隐于神经网络的权重中。擅长模式识别、抗噪性强，但属于“黑盒”，缺乏严密的因果解释能力。
    • 神经符号混合主义（Neuro-Symbolic AI）： 对应卡尼曼的“双系统理论”。系统 1（神经网络）负责快速直觉与模式识别，系统 2（符号逻辑）负责慢速审慎推理。LLM 智能体正是此范式的绝佳体现：内核为神经网络（系统 1），但输出为结构化的思考步骤和工具调用参数（系统 2）。

智能体的构成与运行原理

要使智能体在真实场景中落地，必须对其所处的环境约束及内部运行调度机制进行严密的工程化定义。

任务环境的 PEAS 规约

设计智能体的第一步是使用 PEAS 模型对其边界进行结构化描述：

  • P (Performance): 性能度量（评估任务成功与否的客观指标）。
  • E (Environment): 运行环境（应用场景及约束条件）。
  • A (Actuators): 执行器（改变环境状态的工具/接口）。
  • S (Sensors): 传感器（接收反馈信息的通道）。

数字环境的复杂特性挑战：
LLM 智能体常面临部分可观察（需记忆与探索）、随机性（需处理不确定结果）、多智能体环境（存在动态博弈）以及序贯且动态（决策影响未来，环境实时突变）的复杂挑战。

智能体的感知、思考与行动闭环

智能体通过 Agent Loop（智能体循环） 不断向目标收敛。在现代框架中，这一过程被严谨的 交互协议（Interaction Protocol） 所规范，最典型的是 Thought-Action-Observation 范式：

  1. 感知 (Perception / Observation): 环境反馈的原始数据通过传感器被解析器“清洗”并转化为 LLM 易于理解的自然语言上下文。
  2. 思考 (Thought):
    • 规划 (Planning): LLM 基于 Observation 和内部记忆，更新对当前状态的理解。
    • 工具选择 (Tool Selection): 从工具库中匹配最佳能力，并提取相关参数。这一步是不可见的内部张量运算转化为可见的逻辑表述的过程。
  3. 行动 (Action): 输出结构化指令（如 function_name(args)），通过执行器触发外部真实世界的改变，进而引发下一轮循环。

智能体应用的协作模式

随着自主性程度的跃升，智能体在人类生产流中扮演的角色正在发生本质迁移。

Workflow 与 Agent 的核心差异辨析

这是理解现代自动化的核心。

  • Workflow（工作流）： 静态的、基于预设规则的编排系统。高度可控、结果确定，但极其僵化，无法处理流程图之外的边缘情况（如硬编码的审批流）。
  • Agent（智能体）： 动态的、以目标为导向的自主系统。LLM 充当大脑，能够实时推理、处理非结构化信息，并动态生成“执行路径”。具备极高的灵活性，但牺牲了部分确定性。

两种主流应用范式

  • 作为开发者工具（Human-in-the-loop）： 深度嵌入现有工作流，扮演“副驾驶”（Copilot）。例如 GitHub Copilot、Cursor，通过代码补全、重构建议增强人类创造力。人类下达微观指令，系统被动响应。
  • 作为自主协作者（Autonomous Teammate）： 人类转变为“目标下达者”与“结果验收者”。智能体自主完成复杂任务。
    • 单智能体闭环： 自主规划与反思（如 AutoGPT）。
    • 多智能体协作（MAS）： 模拟人类组织架构，通过明确的角色分配（Role-playing）或标准作业程序（SOP）进行协同。例如 MetaGPT 模拟整个软件公司流程，不同智能体分别扮演 PM、架构师、工程师，通过消息总线进行复杂的网状通信与协作。

课后习题解析

智能体概念与分类辨析

【原问题】
在人工智能领域，智能体被定义为能够通过传感器感知环境，并自主地通过执行器采取行动以达成特定目标的实体。同时，智能体可以根据决策架构、反应时间、知识表示等维度进行分类。请基于此定义和分类维度，分析以下四个案例中的主体是否属于智能体。如果是，请说明其属于哪种类型并给出理由：

  • Case A： 一台符合冯·诺依曼结构的超级计算机，拥有高达每秒 2EFlop 的峰值算力。
  • Case B： 特斯拉自动驾驶系统在高速公路上行驶时，突然检测到前方有障碍物，需要在毫秒级做出刹车或变道决策。
  • Case C： AlphaGo 在与人类棋手对弈时，需要评估当前局面并规划未来数十步的最优策略。
  • Case D： ChatGPT 扮演的智能客服在处理用户投诉时，需要查询订单信息、分析问题原因、提供解决方案并安抚用户情绪。

【解析】

  • Case A：不是智能体。 超级计算机仅是一个硬件实体或算力工具。它缺乏“自主性”和“特定目标”，没有感知环境并主动决策的闭环，仅仅是被动执行人类输入的程序。
  • Case B：是智能体。
    • 决策架构： 属于基于模型/效用的反射型智能体。它拥有外部道路的内部模型，并基于安全效用做出决策。
    • 时间与反应性： 属于典型的反应式智能体（Reactive）。在毫秒级约束下，系统优先选择极低延迟的条件映射而非深思熟虑的长远规划。
    • 知识表示： 属于亚符号主义。其视觉感知高度依赖底层深度神经网络对障碍物模式的快速提取。
  • Case C：是智能体。
    • 决策架构： 属于学习型智能体与基于效用/目标的智能体的结合。通过强化学习自我进化，并以“赢棋”为终极效用。
    • 时间与反应性： 属于典型的规划式智能体（Deliberative）。利用蒙特卡洛树搜索（MCTS）在内部世界模型中模拟未来数十步的状态空间。
  • Case D：是智能体。
    • 决策架构： 属于 LLM 驱动的新范式智能体。
    • 时间与反应性： 属于混合式智能体（Hybrid）。既有宏观的解决步骤规划，又能在查询订单 API 时进行即时的微观观察和反馈。
    • 知识表示： 属于神经符号主义的实践。底层依赖神经网络（直觉、安抚情绪的语言生成），表层输出结构化的工具调用指令（符号化的 API 查询）。

任务环境边界界定（PEAS）

【原问题】
评估智能体运作的核心是精确描述其任务环境。通常使用包含性能度量(Performance)、环境(Environment)、执行器(Actuators)和传感器(Sensors)的 PEAS 模型来进行规约。
同时，环境具有部分可观察、随机性、动态性等特征。假设你需要为一个”智能健身教练”设计任务环境：它能够监测生理数据、动态调整计划、提供实时语音指导并给出饮食建议。请使用 PEAS 模型完整描述，并深度分析其环境特性。

【解析】
1. PEAS 模型描述：

  • 性能度量 (P): 用户的各项生理指标改善幅度（体脂率下降、心肺功能提升）、用户留存率/活跃度、训练过程中的安全指标（无过劳或受伤预警）。
  • 环境 (E): 用户的物理锻炼场所（室内/户外）、用户的当前身体状况、饮食环境。
  • 执行器 (A): 智能耳机的语音合成模块（发声指导）、App 屏幕界面（展示动作视频/饮食清单）、推送通知系统。
  • 传感器 (S): 智能手表/手环（心率、血氧传感器）、手机摄像头（动作捕捉与姿态识别）、麦克风（接收用户喘息声或语音反馈）。

2. 环境特性分析：

  • 部分可观察性（Partially Observable）： 智能体无法完全感知用户的内部生理状态（如肌肉酸痛程度、昨晚的睡眠质量、心理疲劳度），只能通过心率等外部特征进行推断。
  • 高度随机性（Stochastic）： 即便提供完全相同的训练计划，用户每天的执行效果、体能消耗乃至突发事件（如突然抽筋）都是不可精准预测的。
  • 高动态性（Dynamic）： 用户的生理状态（如心率飙升）在智能体进行语音播报时仍在实时变化，要求系统必须具备极低的延迟和实时介入能力。
  • 序贯性（Sequential）： 今天的超负荷训练会直接影响明天的体能状态，智能体的决策必须具有长远的连贯性规划。

系统架构选型（Workflow vs Agent）

【原问题】
在实现任务自动化时，存在两种截然不同的底层逻辑：一种是基于预设规则和结构化编排的工作流（Workflow），另一种是基于大模型自主推理、动态制定计划的智能体（Agent）。某电商公司正在考虑两种方案来处理售后退款申请：

  • 方案 A（Workflow）： 设计固定规则树。例如：7天内+低于100元自动退款；100-500元客服审；超500元或超7天或特殊商品转主管审。
  • 方案 B（Agent）： 搭建智能体，让其摄入退款政策，综合分析用户历史信用、商品耗损情况的图片文字描述，自主决策退款额度或驳回。
    请分析两种方案的优缺点及适用场景，并作为架构师提出一种融合两者优势的“方案 C”。

【解析】
1. 方案评估：

  • 方案 A (Workflow):
    • 优点： 确定性极高（0% 幻觉），执行成本低，审计溯源极其清晰。
    • 缺点： 僵化。一旦出现复杂纠纷（如“商品虽然在7天内且便宜，但用户恶意退款”），系统无法识别上下文，极易被钻漏洞。
    • 适用场景： 业务逻辑清晰、条件可严格量化的标准化流水线。
  • 方案 B (Agent):
    • 优点： 极具柔性和智能化。能处理非结构化数据（如用户长篇幅的情绪投诉），能识别潜在欺诈模式（推理能力）。
    • 缺点： 存在“幻觉”风险（可能误判高客单价商品给公司造成损失），每次处理的 Token 推理成本高，不可解释性强。
    • 适用场景： 需要大量上下文阅读、情感分析和模糊判断的个性化服务场景。

2. 方案 C（混合架构 / 神经符号分层路由）：
作为负责人，我将采用 “Workflow 为主干，Agent 为特种节点” 的混合路由分发架构：

  • 第一层（规则初筛 / Workflow）： 所有请求先进入工作流。对于低风险、金额小且符合政策的请求（如单价30元的日用品），直接无感知秒退。降低计算成本，提升用户体验。
  • 第二层（Agent 智能审核节点）： 当 Workflow 触发“异常条件”（如金额>500、用户退货率异常、或者含有长篇文字诉求）时，将数据打包转发给 Agent 节点。Agent 阅读政策并分析截图，给出判定建议并列出推导逻辑（Thought）。
  • 第三层（Human-in-the-loop）： Agent 的高风险决策（如驳回高价值用户的退款）必须生成工单，由人工主管（Agent 作为辅助工具）点击最终确认，确保商业安全性。

核心机制优化（Thought-Action-Observation 闭环扩展）

【原问题】
现代大语言模型智能体通常依赖于一个持续的“感知(Observation) - 思考(Thought) - 行动(Action)”循环机制来推进任务。
假设现有一个基于此机制构建的“智能旅行助手”（具备查询天气和搜索景点的工具），请思考如何通过修改或扩展其内部的 Thought-Action-Observation 循环，来为其添加以下三个高级功能：

  1. 记忆功能（如记住用户偏好）。
  2. Fallback（备选方案）功能（如门票售罄时自动调整）。
  3. 自我反思机制（如连续被用户拒绝 3 次后改变策略）。

【解析】
这涉及对 Agent 内部状态机和 Prompt 工程的深度改造：

  • 1. 注入长期/短期记忆：
    • 改造点： 发生在 Thought 之前的上下文拼装阶段。
    • 实现思路： 引入向量数据库（如 ChromaDB）。每次用户发起请求前，检索历史偏好（如“预算500内”、“讨厌爬山”），将其动态注入到 System Prompt 或当前轮次的初始 Observation 中。LLM 在生成 Thought 时就会强制将这些边界条件纳入规划体系。
  • 2. 实现环境异常拦截（Fallback）：
    • 改造点： 强化 Observation 解析与新一轮 Thought 的纠错逻辑。
    • 实现思路： 当执行 Action: book_ticket 时，如果 API 返回“已售罄”，解析器将此结果封装为明确的警告 Observation: [Error] 门票已售罄。并在提示词中增加规则：“当 Observation 提示失败时，不要结束任务，你的下一个 Thought 必须分析失败原因，并生成调用 get_attraction 寻找附近替代景点的 Action”。
  • 3. 元认知与自我反思（Reflection）：
    • 改造点： 增加外部状态追踪，并引入“双层 Thought”机制。
    • 实现思路： 维护一个外部计数器 reject_count。当用户回复“不喜欢”时计数加一。当 reject_count == 3 时，拦截常规循环，强行触发一个预设的 Meta-Thought (自我反思) 步骤。
    • Prompt 示例注入： “你已连续 3 次推荐失败。现在的 Thought 必须停止盲目搜索，先分析前三次被拒绝的景点的共性（如是不是都太累了？），并主动向用户生成一个提问（Action: ask_user）以重新对齐偏好。”

神经符号主义的商业落地

【原问题】
诺贝尔经济学奖得主丹尼尔·卡尼曼提出的双系统理论为理解神经符号主义 AI 提供了绝佳类比：系统 1 是快速、凭直觉的模式识别（类似神经网络）；系统 2 是缓慢、有条理、基于逻辑的推理（类似符号逻辑）。
请构思一个具体的智能体落地应用场景（如医疗诊断、法律咨询等），并详细说明在此场景中，哪些任务应由系统 1 处理？哪些应由系统 2 处理？二者如何形成完美的协同闭环？

【解析】
应用场景：智能医疗急诊分诊与初步诊断系统

  • 系统 1（亚符号/神经网络）的任务域 —— 负责“感知与直觉”：
    • 医学影像初筛： 瞬间读取患者的 X 光片或 CT 扫描，识别潜在的阴影或出血点病灶模式。
    • 非结构化病史提取： 倾听急诊患者焦急、混乱的口述（语音识别与 NLP），瞬间提取出关键症状（如“撕裂样胸痛”、“放射到后背”）。
    • 情绪安抚与拟人化交互： 生成带有同理心的自然语言回复，安抚患者情绪。
  • 系统 2（符号主义/逻辑规则）的任务域 —— 负责“严谨与安全”：
    • 医学图谱验证： 系统 1 提取出症状后，系统 2 必须在庞大的医学知识图谱（确定性的关系数据库）中进行严格的图谱遍历，确保“主动脉夹层”的推断符合严密的医学排他逻辑。
    • 禁忌症硬性拦截： 在生成用药建议（Action）前，必须通过符号逻辑计算，交叉比对患者的过敏史与药物相互作用库。这是零容错的步骤，绝不能交给带有概率性的神经网络处理。
  • 协同工作闭环机制：
    患者上传资料 -> 系统 1（神经网络）瞬间完成“多模态感知”，将混乱的音频和图像转化为结构化的症状标签（Symbol） -> 这些符号被送入 系统 2（知识图谱引擎与专家规则系统）进行严密的逻辑链条推理，计算出风险评级与鉴别诊断方案 -> 方案送回 系统 1，由大语言模型将其润色为通俗易懂、温和的医疗建议输出给医生和患者。
    这种协同既保证了交互的温度与对复杂数据的宽容，又守住了医疗安全的严密底线。

局限性与系统评估

【原问题】
尽管由大语言模型驱动的智能体系统展现出了强大的规划和工具调用能力，但其底层机制依然存在局限性。请结合智能体的运行机制分析以下三个问题：

  1. 为什么智能体在推理或合成结果时会产生”幻觉”？
  2. 智能体的交互依赖于持续的“循环”机制，如果不对循环次数进行强制限制，系统可能会陷入什么风险？
  3. 仅依靠“任务准确率”来评估一个智能体的智能程度是否足够？如果不足，还应引入哪些维度的评估指标？

【解析】

  • 1. 幻觉的底层根源：
    LLM 驱动的智能体其核心引擎本质上依然是基于概率分布的下一个 Token 预测机器。它试图拟合语言的连贯性，而非物理世界的真实客观规律。
    当任务超出其预训练知识边界，或由于工具返回的 Observation 含有歧义时，模型内部缺乏绝对的“真理锚点”（Grounding），只能用高度自信的语言概率模型拼凑出符合语法但违背事实的伪逻辑（如瞎编 API 参数或捏造不存在的景点）。
  • 2. 无限循环的死锁风险：
    Agent Loop 极易陷入“执行焦油坑”。常见情况包括：
    • API 连续故障： 工具报错，智能体在 Thought 中决定“重试”，从而形成无休止的 Error -> Retry 死循环，瞬间耗尽巨量 Token 额度。
    • 推理死胡同（Logic Loop）： 智能体的规划逻辑形成闭环，例如在网页中寻找特定按钮，未找到 -> 滚动屏幕 -> 重新搜索 -> 依然未找到 -> 再次滚动，完全无法产生跳出框架的创新思路（Meta-thinking）。
    • 强制截断的必要性： 设定 Max_Loops 是一种工程上的“防故障保险”，强制打断可能失控的系统并交由人工介入。
  • 3. 多维评估体系的构建：
    仅依靠“准确率”是极其单薄的，因为它无法衡量达成任务所付出的代价与系统的鲁棒性。综合评估应引入：
    • 规划效率（Efficiency of Trajectory）： 完成同一任务，优秀的智能体只需 3 轮循环，劣质的可能需要 10 轮盲目的试错。步骤冗余度是核心指标。
    • 自主度（Degree of Autonomy）： 在执行长程任务时，需要人类介入修正（Human Intervention）的频率有多高。
    • 工具掌握度（Tool-use Mastery）： 面对未见过的全新 API 说明书，智能体能否一次性正确理解其参数规范并成功调用（Zero-shot Tool Use）。
    • 错误恢复力（Error Recoverability）： 当故意给智能体注入错误的 Observation 时，它能否敏锐察觉异常、反思（Reflect）并自主修正路径，这是衡量其系统强健性的金标准。

第二章 智能体发展史

理解现代智能体（Agent）的底层逻辑，必须回溯其历史演进。人工智能的发展并非一蹴而就，而是一场由“痛点驱动”的范式革命：从试图用纯粹逻辑定义智能的古典时代，到反思集中式架构并走向分布式协作，再到最终确立通过大规模数据与交互进行“学习”的现代体系。

基于符号与逻辑的早期智能体

早期人工智能研究深受数理逻辑影响，形成了第一个核心流派——符号主义（Symbolicism）（亦称传统 AI 或逻辑 AI）。
该流派坚信，人类的高级认知能力完全可以通过形式化的符号操作来完美复刻。此时的智能体，其“智慧”不源自学习，而是完全依靠人类专家的心血浇筑与硬编码。

物理符号系统假说

这是符号主义的理论基石，由图灵奖得主艾伦·纽厄尔（Allen Newell）与赫伯特·西蒙（Herbert A. Simon）提出。该假说将抽象的“心智”降维为工程上可实现的计算问题。

  • 核心构成： 智能被抽象为由“符号”（表征外部世界）与“过程”（对符号进行创建、修改、组合的逻辑操作）组成的物理实体系统。
  • 两大论断：
    • 充分性论断： 只要拥有完备的物理符号系统，就足以产生通用智能。
    • 必要性论断： 任何展现出通用智能的实体，其底层必定是一个物理符号系统。

专家系统的崛起与巅峰

在物理符号系统假说的指引下，专家系统（Expert System） 成为 20 世纪 70-80 年代最璀璨的应用成果。其核心思想是“知识与推理相分离”，试图在特定垂直领域达到人类专家水平。

  • 经典架构拆解：
    • 知识库（Knowledge Base）： 通过“IF-THEN”的产生式规则（Production Rules）存储人类专家的先验知识。
    • 推理机（Inference Engine）： 独立的计算引擎，分为“数据驱动”的正向链（由已知推结果）和“目标驱动”的反向链（由假设反推所需证据）。
  • 里程碑案例 MYCIN：
    • 用于诊断细菌性血液感染。
    • 采用反向链推理，通过向医生提问收集证据。
    • 核心创新： 引入了置信因子（Certainty Factor, CF），突破了经典布尔逻辑的非黑即白，使机器具备了处理医学界普遍存在的“不确定性与模糊性”的能力。

综合性微观世界智能体：SHRDLU

如果说专家系统代表了符号 AI 的“深度”，由 Terry Winograd 开发的 SHRDLU 则展示了其“广度”。

  • 核心成就： 在一个名为“积木世界”的封闭三维虚拟环境中，SHRDLU 首次将自然语言解析、上下文指代消解、动作规划与记忆问答整合进一个统一的系统。
  • 历史意义： 它验证了“感知-思考-行动”闭环的可行性，是现代智能体架构的最早雏形。但其成功也暴露出一个致命弱点——它的智能仅在这个规则绝对清晰、没有例外的“玩具世界”中有效。

符号主义的根本性挑战

当符号系统试图走出实验室迈向真实的、开放的物理世界时，遭遇了不可逾越的理论柏林墙：

  • 知识获取瓶颈（Knowledge Acquisition Bottleneck）： 人类的常识与直觉往往是内隐的（如“水是湿的”），无法被穷举并转化为“IF-THEN”规则。人工编码成本极高且无法规模化。
  • 框架问题（Frame Problem）： 在动态世界中，智能体执行一个动作后，机器很难通过逻辑推演来高效判断“哪些事物没有发生改变”，这会导致计算量爆炸。
  • 系统脆弱性（Brittleness）： 极度依赖预设边界，面对规则库外的新情况毫无泛化能力，系统会瞬间崩溃。

基于规则的对话系统实践

为了直观理解符号主义的运作机制与局限，早期自然语言处理的代表作——ELIZA，提供了一个极佳的研究样本。

ELIZA 的设计思想与核心机制

ELIZA 是一个模拟心理治疗师的聊天机器人程序。它的惊人之处在于：它完全不“理解”用户在说什么，却通过巧妙的错觉引发了著名的“ELIZA 效应”（让人类对其产生情感投射）。

  • 模式匹配与文本替换： ELIZA 的算法本质是一个巨大的正则表达式匹配引擎。
    • 触发机制： 扫描输入，匹配优先级最高的关键词（如 mother）。
    • 分解与代词转换： 将句子拆解，并执行简单的第一/第二人称反转（如 I 转为 You）。
    • 重组输出： 将转换后的文本填入预设的开放式提问模板中（如“告诉我更多关于你母亲的事”），从而将对话责任重新抛回给用户。

规则驱动的根本局限性

从 ELIZA 的工程实现中可以清晰总结出早期 AI 的致命弱点：

  • 缺乏语义锚点： 只是形式上的字符串替换，对否定语境、复杂从句毫无理解力。
  • 无状态性（Stateless）： 没有上下文记忆机制，无法维持连贯的深度对话。
  • 组合爆炸： 试图通过增加规则来覆盖所有人类对话场景，最终会导致规则库庞大到无法维护，规则间的冲突无法调和。

分布式智能的启蒙：心智社会

面对符号系统“大一统”中央推理引擎的僵化，马文·明斯基（Marvin Minsky）提出了颠覆性的理论，将 AI 研究的视角从“单体巨兽”转向了“群体生态”。

对单一整体智能模型的反思

明斯基质疑了构建全知全能中央处理器的可行性。他指出，自然智能并非基于一套完美的逻辑原理，而是由视觉、情感、推理等无数个异构的子过程拼凑而成的“大杂烩”。

作为协作体的智能与涌现机制

在《心智社会》中，明斯基重新定义了智能的产生方式：

  • 无心的智能体： 底层 Agent（如“寻找线条”的视觉 Agent）本身是极度愚蠢且没有意识的，仅执行极简指令。
  • 机构（Agency）与激活链： 这些底层 Agent 组成机构，通过相互之间的激活与抑制信号传递控制流。
  • 涌现（Emergence）： 高级智能（如“搭积木塔”的目标）并非由最高指挥官写明步骤，而是由无数底层无心 Agent 在局部交互、彼此竞争与协作中自发涌现出来的宏观现象。

对多智能体系统（MAS）的理论启发

这一哲学思考直接孕育了今天的多智能体系统（MAS）理论：

  • 去中心化控制： 彻底抛弃中央大脑，研究基于局部状态的自组织协同。
  • 社会性抽象： 将人类社会的沟通协议（如契约网、协商机制）引入计算实体的交互中，AI 从“单兵作战”进化为“虚拟社会”。

学习范式的演进与现代智能体

既然复杂的规则无法被人类完美设计出来，智能体就必须具备“自主学习”的能力。这引发了长达数十年的学习范式革命。

从符号逻辑到联结主义

联结主义（Connectionism）（即深度学习的前身）从仿生学汲取灵感，主张自下而上的智能构建路径。

  • 分布式权重表示： 知识不再是清晰的 IF-THEN 规则，而是被隐晦地分布在成千上万个人工神经元的连接权重之中。
  • 自适应优化： 机器通过接触海量样本，利用反向传播等算法自主迭代权重，在模式识别（如视觉、语音）上彻底击败了脆弱的符号系统。

强化学习与序贯决策

如果说联结主义解决了“感知环境”的问题，那么强化学习（Reinforcement Learning, RL） 则解决了智能体如何“行动”的问题。

  • 试错机制： 智能体在未知环境中通过不断试错（Trial and Error）来积累经验。
  • 核心循环： 智能体在特定状态（State）下采取行动（Action），环境随之改变并反馈一个延迟的奖励信号（Reward）。
  • 远见规划： 智能体优化的目标不是眼前的蝇头小利，而是全局累积回报最大化（如 AlphaGo 为了最终赢棋可以牺牲局部棋子），从而赋予了机器序贯决策的能力。

大规模预训练与通用基础模型

强化学习面临着“冷启动”的难题：如果让智能体从零开始试错，效率极低且缺乏常识。NLP 领域的“预训练-微调”范式提供了最终的解法。

  • 知识的隐式压缩： 通过在万亿级 Token 的互联网语料上进行“预测下一个词”的自监督学习，庞大的世界知识、语法逻辑与常识被压缩进了神经网络的参数中。
  • 涌现能力（Emergent Abilities）： 当模型规模突破临界点，LLM 突然具备了未被直接训练过的高级能力，如少样本学习（Few-shot learning）和通过“思维链（CoT）”进行的逻辑推理。

大语言模型驱动的现代智能体架构

历史的支流最终汇聚。现代 LLM Agent 是符号主义的逻辑规划能力与联结主义的感知学习能力的集大成者（神经符号混合）。

  • 感知模块： 将多模态的环境反馈转化为自然语言文本。
  • 记忆与思考模块（LLM 核心）： LLM 充当中枢大脑，结合记忆历史，通过思维链将复杂任务拆解为子任务（规划与反思）。
  • 执行模块： 将 LLM 的决策转化为结构化的工具调用（API、代码执行器），从而对外部物理或数字世界施加实质性影响，完成动态闭环。

课后习题解析

物理符号系统假说的当代审视

【原问题】
物理符号系统假说（PSSH）由纽厄尔和西蒙提出，认为智能的本质是物理实体对符号的计算与处理，这成为了符号主义时代的理论基石。请分析：

  1. 该假说的“充分性论断”和“必要性论断”分别包含什么深刻含义？
  2. 结合智能体演进史，符号主义在尝试构建复杂系统时遭遇的哪些实际阻碍，直接对该假说的“充分性”提出了致命挑战？
  3. 当前由大语言模型（LLM）驱动的现代智能体，是否仍然符合这一物理符号系统假说？请结合神经符号主义进行辨析。

【解析】

  1. 论断拆解：
    • 充分性论断意味着“算力+正确的符号操作系统 = 智能”。它给出了工程上的乐观承诺：只要规则够完备，机器必能产生智能，无需依赖任何神秘的生物灵魂。
    • 必要性论断意味着“人类大脑的本质也是一台符号处理机”。它是一种哲学还原论，认为即使是直觉、情感，底层也是符号的物理运算。
  2. 充分性的现实破产：
    在封闭的“积木世界（SHRDLU）”中充分性看似成立，但在真实世界遭遇了常识获取瓶颈与框架问题。
    因为真实世界的知识是连续的、高度上下文依赖的，甚至包含不可言传的默会知识。这证明了：试图用离散的、有限的符号规则来“充分”表征连续、无限的物理世界，在计算复杂性上是一条死胡同。
  3. LLM 与 PSSH 的辩证关系：
    这是一个经典的“神经符号主义”前沿议题。
    • 在微观/底层架构上（不符合）： LLM 的内核是人工神经网络（联结主义）。其内部运作依赖于连续的浮点数矩阵乘法和非线性激活，不存在明确定义的离散符号和“IF-THEN”逻辑分支，知识是高度弥散且分布式的。
    • 在宏观/应用表现上（符合）： 当 LLM 被封装为 Agent 时，它的输入和输出（自然语言、代码、API 调用参数）都是极其严密的“符号体系”。Agent 展现出的“思维链（CoT）”推理，本质上就是对语言符号的创造、重组与逻辑推演。
    • 结论： 现代 LLM Agent 是 PSSH 在更高维度的复兴。它用联结主义的黑盒代替了脆弱的人工知识库，但依然依靠符号（语言）来实现高级认知和逻辑控制。

专家系统的商业化困境与系统重构

【原问题】
在 20 世纪 70 年代，MYCIN 专家系统通过“IF-THEN”规则和置信因子，在血液感染的诊断上达到了人类专家的水平。然而，尽管技术指标优异，MYCIN 最终并未被大规模部署于临床。请思考：

  1. 除了技术层面的“知识难以获取”和“系统脆弱性”，还有哪些非技术因素（如伦理、法律、交互）阻碍了专家系统在医疗等高风险领域的落地？
  2. 如果现在由你主导设计一款医疗辅助诊断智能体，你会如何融合现代架构来克服 MYCIN 当年的局限？
  3. 在大模型横行的今天，是否还有特定垂直领域，基于纯规则的专家系统依然是优于深度学习的最佳选择？请举例论证。

【解析】

  1. 非技术因素：专家系统落地受阻的关键原因：
    • 责任归属与法律真空： 在医疗场景中，如果系统给出的诊断建议导致误诊或治疗失误，责任应由谁承担并不清晰。在缺乏明确法律框架的情况下，医疗机构往往倾向于避免引入可能带来额外法律风险的系统。
    • 与医疗工作流的不匹配： MYCIN 运行在早期终端环境中，医生需要手动输入大量病理指标和实验数据。这种交互方式与临床工作节奏并不匹配，增加了医生的操作负担，也降低了门诊效率，从而影响了系统的接受度。
    • 医生对系统建议的信任问题： 尽管 MYCIN 能够提供推理过程，但其输出形式通常是概率或置信度数值。相比医生在临床实践中依赖的综合观察、经验判断和直觉，这种抽象的数值结果较难建立直观信任，因此在实际决策中很难成为主要依据。
  2. 现代医疗 Agent 的架构设计：
    如果在当前技术条件下重新设计类似系统，可以采用神经符号融合（Neuro-Symbolic）架构，将大模型与结构化知识系统结合。
    • 感知与交互层（LLM）： 使用多模态 LLM 作为前台。医生只需用语音口述，或系统直接扫描电子病历（EMR）及化验单图像，LLM 负责将非结构化信息自动提取为结构化数据，彻底消除输入痛点。
    • 知识推理层（规则与知识图谱）： 将提取的数据送入后端的医学知识图谱与现代专家规则引擎进行严格的逻辑推演和禁忌症拦截。可以降低模型幻觉带来的风险，并提高系统的可验证性。
    • 解释输出： LLM 进行语言组织，将规则推理结果转化为：易读的诊断建议、清晰的推理依据、相关医学证据或指南引用。医生仍然是最终决策者，系统主要提供结构化的信息支持和辅助判断。
  3. 纯规则系统的当代优势领域：
    在 零容错、强监管、需绝对可解释性 的领域，专家系统依然不可替代。
    • 金融反洗钱与合规审查： 必须基于央行下发的死规定（如某类交易金额触发红线必须冻结）。深度学习的概率输出和不可解释性（无法向监管机构提供数学证明）在这里是致命缺陷。
    • 工业核心安全控制系统： 如核电站冷却系统监控，必须遵循严苛的物理定律 IF-THEN 熔断机制，不能容忍幻觉。

规则驱动引擎的“组合爆炸”与架构对比

【原问题】
ELIZA 是早期著名的规则驱动聊天机器人，通过正则匹配、代词反转和模板重组来伪装心理医生。但其处理开放域对话时极具局限性。请基于此机制：

  1. 构思如何从工程代码层面为其扩展“上下文记忆”功能（例如让系统记住用户的名字并用于后续回复）。
  2. 从知识表示、状态管理和泛化能力三个维度，深度对比你扩展后的规则引擎与当代基于大语言模型的对话系统（如 ChatGPT）。
  3. 为什么基于规则的方法在应对开放域对话时必然走向“组合爆炸”的死局？能否用简单的数学逻辑来证明这种不可维护性？

【解析】

  1. 扩展记忆的工程思路：
    引入全局字典变量（如 user_memory = {}）。增加特定的实体抽取规则：
    • 触发规则：当正则匹配到 I am (.*) 时，将捕获的组存入 user_memory['name']。
    • 模板修改：在其它重组模板中注入该变量。例如匹配到 I feel sad 时，返回 Why do you feel sad, {user_memory['name']}?。
  2. 多维度的代差级对比：
    • 知识表示： ELIZA 知识是显式的字符串（硬编码正则）；ChatGPT 的知识是隐式高维向量权重（包含人类语言的潜在概率分布）。
    • 状态管理： ELIZA 是短时变量存储，遇到变量冲突极难处理；ChatGPT 基于自注意力机制（Self-Attention），能够在极长上下文窗口内综合考量所有对话历史的依赖关系。
    • 泛化能力： ELIZA 对未在正则规则库中的句式完全抓瞎（Zero-generalization）；ChatGPT 可以基于语义张量空间，完美理解并回应从未在训练集中出现过的生僻组合句型。
  3. “组合爆炸”的数学论证：
    假设人类语言中常用的意图有 种，表达情绪的副词有 种，对话可能发生的历史轮次（上下文深度）为 。
    在规则引擎中，为了实现完美的上下文连贯，程序员必须穷举所有的组合可能。系统需要的 IF-THEN 规则数量大致与 呈指数级相关。
    自然语言的词汇组合趋于无限大，一旦引入上下文约束，规则树的分支将呈几何级数膨胀。这导致任何微小的规则修改，都会在庞大的树状逻辑中引发蝴蝶效应式的冲突（Rule Conflict），使得系统从工程角度上彻底不可维护。

心智社会与现代多智能体网络（MAS）的碰撞

【原问题】
马文·明斯基在《心智社会》中提出，高级智能并非源于单一完美的中央处理核心，而是由海量“无心（Mindless）”的、极其简单的子智能体（如专门负责识别线条或执行抓握的模块）通过动态的激活与抑制信号协作涌现而成的。

  1. 在其描述的“搭建积木塔”场景中，如果底层的 GRASP（抓握）智能体发生硬件或逻辑损坏，整个心智社会系统会呈现出怎样的状态？这种去中心化架构的根本利弊是什么？
  2. 将明斯基的构想与当前主流的生成式多智能体协作框架（如 MetaGPT 中的产品经理、架构师、工程师角色扮演）进行对比，两者在“节点智能度”与“协作拓扑”上有何异同？
  3. 既然现代大模型（LLM）已经具备了极其强大的中央推理能力，这是否宣告了“智能由无心模块涌现”的心智社会理论在当代已经被证伪？

【解析】

  1. 节点失效与架构利弊：
    如果 GRASP 损坏，上层的 ADD-BLOCK 机构会被无限期挂起（无法完成），但系统不会像集中式程序那样直接抛出致命异常并崩溃。系统的其他机构（如 VISION 视觉机构）依然可以正常运作，这展现了去中心化架构的优雅降级（Graceful Degradation） 能力。
    • 优势： 极高的鲁棒性、高并发处理能力，以及自下而上的强泛化涌现能力。
    • 劣势： 系统的宏观行为极度不可控，调试（Debug）极其困难。由于缺乏中央指令，很难预测局部规则修改会对全局造成何种混沌的影响。
  2. 古典心智理论 VS 现代 MAS 框架：
    • 差异（节点智能度）： 明斯基系统中的 Agent 是“极瘦”的（Thin Agent），只能执行极简的布尔逻辑；而 MetaGPT 中的 Agent 是“极胖”的（Fat Agent），每个节点（如虚拟产品经理）背后都有庞大 LLM 支撑，具备极高的个体认知带宽与自然语言推理能力。
    • 关联（协作拓扑）： 宏观的协作思想一脉相承。都不依赖硬编码的工作流图（Workflow），而是依赖个体间的协议传递（如明斯基的抑制信号，现代 MAS 的自然语言消息总线），最终“涌现”出复杂的成果（如搭好积木，或写出一个完整的软件工程）。
  3. 对心智社会理论的当代重构：
    并没有被证伪，反而以更深层的方式被印证了。我们可以从两个尺度来看：
    • 微观尺度（LLM 内部）： 一个 LLM 的内核（Transformer 架构）极具“心智社会”特征。数十亿个神经元、成百上千个注意力头（Attention Heads），它们每一个都没有意识，只做简单的向量点乘（Mindless）。但当它们在深层网络中相互组合、激活与抑制时，强大的宏观逻辑推理能力就“涌现”了。
    • 宏观尺度（MAS 外部）： 随着任务复杂度超越单一 LLM 的上下文极限，人类又开始将多个 LLM 组成“社会”（如不同角色的 Agent），在更高维度上重演了明斯基的去中心化协作理念。

学习范式演进：RL 的试错机制与预训练的世界模型

【原问题】
智能体的能力获取经历了从“人工硬编码”到“从交互中学习”，再到“从海量静态数据中预训练”的范式跃迁。请分析：

  1. 以训练一个能通关“超级马里奥”游戏的智能体为例，如果分别采用监督学习（SL）和强化学习（RL），在数据需求形态和核心驱动机制上有何本质差异？为何强化学习天然适合此类序贯决策任务？
  2. 预训练-微调（Pre-training & Fine-tuning）范式是如何通过自监督学习彻底打破符号时代的“知识获取瓶颈”的？它所构建的世界模型在知识表示上与专家系统的知识库有何根本区别？
  3. 在当前构建顶尖大语言模型（如 GPT-4）的完整流程中，强化学习（如 RLHF）扮演了怎样不可或缺的“修剪者”角色？

【解析】

  1. 马里奥通关：SL 与 RL 的殊途：
    • 监督学习（SL）： 极度依赖离线的高质量人类标注数据。你需要录制人类高手的游玩视频，提取每一帧画面（特征 X）及人类当时按下的手柄按键（标签 Y）。机器只是在拟合“在这个画面下，人类会怎么按”。一旦遇到人类未遇到过的画面，机器瞬间失能。
    • 强化学习（RL）： 不需要人类教。只需提供一个游戏模拟器（环境）。机器随机乱按（Action），模拟器返回游戏画面（状态 S）和分数增减/死亡（奖励 R）。机器通过“试错机制”自行摸索，甚至能发现人类从未想过的高分捷径。
    • 为何适合序贯决策： 马里奥是一个极度依赖时间纵深的场景（现在按起跳，是为了两秒后踩死怪物）。RL 优化的目标是最大化未来累积期望回报，天然具备时间上的“深谋远虑”，这是仅关注当前静态映射的 SL 无法做到的。
  2. 预训练对知识瓶颈的粉碎式打击：
    • 突破瓶颈： 预训练最伟大的成就在于采用了“自监督”。它不再需要人类知识工程师去苦心编撰规则，也不需要昂贵的人工标注。它直接将互联网海量文本作为自己的老师，“挖掉一句话的最后一个词，让模型猜”，通过无限算力暴力汲取人类文明的知识。
    • 表示维度的降维打击： 专家系统的知识是离散的、图谱式的、清晰边界的，极度脆弱；而预训练模型的知识是连续的、分布式的隐性特征（高维稠密张量），具备强大的语义容错性与泛化重组能力。
  3. RLHF（基于人类反馈的强化学习）的关键作用：
    纯粹通过预训练得到的 LLM 只是一个“词语接龙”的概率生成器，它可能满口脏话，也可能在用户询问“如何制作炸弹”时提供详细教程。
    强化学习（RLHF）在预训练后介入，扮演了 “社会规范对齐者” 的角色。通过建立人类偏好的奖励模型（Reward Model），并使用 RL 算法（如 PPO）不断惩罚模型的不当输出，奖励符合人类价值观和指令意图的回答。它将一个狂野的“百科全书引擎”最终打磨成了一个安全、有用、可控的现代智能助理（Agent Brain）。

第三章 - 大语言模型基础

现代多智能体系统（MAS）的认知中枢是大语言模型（LLM）。理解智能体如何处理指令、进行规划与推理，必须深入语言模型的底层架构、交互机制及其能力边界。

语言模型演进：从统计学到神经网络

语言模型的核心数学任务是估计特定词序列（句子）的联合概率分布，借此评估文本的自然度与合理性。

统计语言模型与马尔可夫假设

在深度学习普及之前，统计方法是主流。基于概率链式法则，计算整个句子的概率需要庞大的条件概率连乘，这在现实语料中极易遇到数据稀疏问题。

  • 马尔可夫假设（Markov Assumption）： 引入局部性近似，假设当前词的出现概率仅依赖于其前有限的 个词。由此衍生出 N-gram 模型（如 Bigram, Trigram）。
  • 最大似然估计（MLE）： N-gram 的条件概率通过语料库中的频次直接统计估算。
  • 根本局限：
    • 数据稀疏性（Sparsity）： 未在训练集中出现的词元组合概率为零，无法处理长尾表达。
    • 语义泛化缺失： 词被视为孤立的离散符号（One-hot），模型无法捕捉“同义词”或“近义词”之间的内在语义关联。

词嵌入与前馈神经网络

为解决离散符号的泛化问题，前馈神经网络语言模型引入了连续向量空间表征。

  • 分布式语义表示（Word Embedding）： 将高维稀疏的词汇映射为低维稠密的连续向量。在此空间内，语义相似度可通过几何关系（如余弦相似度）直接度量。
  • 网络拟合： 神经网络通过反向传播调整词向量权重，使其在预测任务中捕获丰富的上下文语义（如抽象的类比关系）。
  • 局限： 依然受限于固定的上下文窗口大小，无法处理任意长度的序列。

循环神经网络（RNN）与长短时记忆（LSTM）

为打破固定窗口限制，模型引入了时序递归结构。

  • 隐藏状态（Hidden State）： RNN 引入状态向量作为“短期记忆”，当前输出依赖当前输入与上一时刻的隐藏状态，实现了信息的时序传递。
  • 长期依赖危机： 由于序列深度等同于网络深度，标准 RNN 在反向传播时极易发生梯度消失或梯度爆炸，导致长程上下文记忆丢失。
  • LSTM 的门控机制： 通过引入独立的“细胞状态（Cell State）”主干道，并辅以遗忘门、输入门、输出门，使网络能够显式学习“保留什么”与“遗忘什么”，大幅缓解了长程梯度衰减问题。

Transformer 架构深度剖析

RNN 强依赖时序步骤，导致无法利用 GPU 进行大规模并行矩阵运算。Transformer 架构彻底抛弃了循环结构，代之以全局注意力机制，奠定了大模型时代的硬件加速与规模化基础。

编码器-解码器全局框架

Transformer 最初为机器翻译等端到端任务设计，包含两个核心解耦模块：

  • 编码器（Encoder）： 负责并行提取输入序列的全局上下文特征，生成富含语境的表征矩阵。
  • 解码器（Decoder）： 采用自回归方式，结合自身已生成的上文与编码器提供的特征矩阵，逐词生成目标序列。

自注意力与多头注意力机制（Self-Attention）

自注意力机制是架构的核心，允许序列中的每一个词元直接与序列中所有其他词元进行交互，计算复杂度与序列物理距离无关。

  • Q-K-V 机制： 对每个输入向量进行线性映射，生成查询向量（Query）、键向量（Key）和值向量（Value）。
  • 缩放点积注意力： 计算 与 的点积评估词元相关性，除以维度缩放因子 （防止 Softmax 梯度溢出），最后乘以 进行加权聚合。
  • 多头机制（Multi-Head）： 将特征空间切分为多个子空间，允许模型并行捕捉多种复杂的语义关联（如同时关注语法指代与主谓关系），最后拼接融合。

逐位置前馈网络（Position-wise FFN）

在注意力层完成序列维度的空间交互后，FFN 负责在特征维度上进行非线性特征提取。

  • 通常采用“先升维再降维”的瓶颈结构配合 ReLU 激活函数。所有序列位置共享同一套 FFN 权重，保持了平移不变性并降低了参数量。

残差连接与层归一化（Add & Norm）

  • 残差连接（Add）： 允许特征与梯度绕过非线性层直接传递（），解决极深网络中的梯度消失问题。
  • 层归一化（Norm）： 对单个样本的特征维度进行标准化处理，缓解内部协变量偏移，确保深层网络各层输入分布的稳定性。

位置编码（Positional Encoding）

自注意力机制本质上是集合运算，缺乏序列顺序感知能力。

  • 通过预设的三角函数（正弦与余弦）生成绝对位置向量，直接叠加在底层词嵌入上。这使得模型能够在并行计算时隐式推导出词元的相对距离和先后顺序。

Decoder-Only 架构与自回归生成

在探索大规模预训练时，研究界发现完整的编解码架构存在结构冗余。以 GPT 系列为代表的 Decoder-Only 架构 凭借其极致的简洁性成为了当今模型的主流。

  • 自回归生成（Autoregressive）： 将一切自然语言任务统一抽象为“预测下一个词”。模型持续将生成的词元回填至输入序列末尾，循环迭代。
  • 掩码自注意力（Masked Self-Attention）： 为了防止模型在预测第 个词时“偷看”未来的真实文本，系统在注意力分数矩阵的右上角施加负无穷掩码。经过 Softmax 后，未来信息的权重强制归零，严格保证了因果逻辑的单向性。
  • 工程优势： 训练目标极其纯粹，模型结构高度同质化，极易利用分布式集群进行参数规模的横向扩展，天然契合生成式任务。

大语言模型交互与工程化处理

大模型作为智能体的底层计算单元，开发者需要通过特定的工程手段（如提示工程和分词器管理）来对其输入输出进行精确编码与控制。

模型采样参数的数学干预

大模型的输出本质上是基于 Logits 的概率分布。修改采样参数等同于干预模型的概率输出策略：

  • Temperature（温度 T）： 调节 Softmax 函数的平滑程度。低温度分布趋于尖锐，生成确定性强的事实文本；高温度分布趋于平滑，低概率词被激活，适合发散性创意写作。
  • Top-k 截断： 强制将每一步的候选集限制在概率最高的 个 Token 内，消除极端低概率词引起的乱码或崩坏风险。
  • Top-p（核采样）： 按概率降序累加，当累加值达到阈值 时截断候选集。相比 Top-k，它能根据当前上下文的概率置信度动态调整候选池大小。

提示工程与认知引导

  • 指令调优（Instruction Tuning）： 将预训练的“无条件续写模型”转化为“助理模型”的关键步骤，使其具备服从自然语言指令的能力。
  • 样本提示策略： 利用模型强大的上下文学习（In-context Learning）能力，涵盖零样本（Zero-shot）、单样本（One-shot）到少样本（Few-shot）。
  • 思维链（Chain-of-Thought, CoT）： 解决复杂系统推理问题的核心技巧。通过在提示中注入“请逐步思考”的显式指令，迫使模型将高维度的复杂逻辑坍缩为低维度的线性子步骤，大幅降低中间计算的逻辑跳跃与错误率。

文本分词（Tokenization）与 BPE 算法

计算机无法直接处理字符串，分词是将连续文本映射为离散张量的桥梁。

  • 按词/按字符分词的困境： 单字符分词丧失词法语义且序列过长；单词分词面临词表爆炸及未登录词（OOV）困境。
  • 字节对编码（BPE）： 一种数据驱动的贪心压缩算法。初始化单字符词表，反复统计语料中相邻字符对的最高频组合并进行合并（如 u + g -> ug）。既保留常见词的完整语义，又利用子词片段拼凑生僻词，彻底消灭了 OOV 问题。
  • 工程约束： 分词规则直接决定了模型的上下文窗口消耗速度与 API 计费成本，且是导致模型出现特定算术或代码排版“低级错误”的潜在因素。

模型生态、缩放法则与局限性

在为智能体选择“大脑”时，必须深刻理解当前模型体系的发展规律及其物理与逻辑层面的局限。

模型选型多维评估

  • 闭源模型（GPT, Gemini, Claude）： 提供顶级的通用推理性能和超长上下文，开箱即用，适合高复杂度智能体的云端调用。
  • 开源模型（Llama, Mistral, Qwen）： 提供最高的数据隐私隔离、权重微调（Fine-tuning）自由度以及端侧部署能力。
  • 评估指标： 逻辑推理性能、推理延迟（TTFT）、上下文窗口容量、综合成本、生态工具链兼容性。

缩放法则（Scaling Laws）与能力涌现

  • 幂律关系： 研究证实，模型的交叉熵损失与模型参数规模、训练数据量、计算 FLOPs 之间存在平滑的幂律递减关系。
  • Chinchilla 定律修正： 反驳了早期单纯堆砌参数的做法，指出在给定计算预算下，参数量与训练 Token 数应保持同比例的最优配比增长。
  • 能力涌现（Emergent Abilities）： 复杂技能（如隐式代码解释、多步推理）并非随参数增加线性增长，而是在跨越某个规模阈值后突然解锁。这要求高级 MAS 必须依托足够规模的基座模型。

模型幻觉（Hallucination）的诱因与治理

模型在过度自信下生成的违背事实或逻辑的虚假内容，是智能体落地的最大阻碍。

  • 分类： 事实性幻觉（违背客观现实）、忠实性幻觉（违背给定上下文）、内在幻觉（逻辑自相矛盾）。
  • 根源剖析： 训练语料的脏数据污染、知识时效性滞后，以及自回归生成本质上是“概率序列接龙”而非严谨的“关系数据库查询”。
  • 治理策略：
    • 检索增强生成（RAG）： 利用外部向量数据库提供实时客观上下文，强迫模型基于检索事实生成。
    • 工程化外挂： 赋予智能体调用外部工具（计算器、搜索引擎）的能力，将需要确定性的计算交还给符号系统。

课后习题解析

统计概率计算与架构跃迁

【原问题】
自然语言处理中，语言模型经历了从统计方法到神经网络的深刻演进。在统计语言模型时代，N-gram 模型通过马尔可夫假设简化了概率计算。
假设存在一个微型语料库仅包含两句话：datawhale agent learns 和 datawhale agent works。

  1. 请根据该语料库，手动计算短语 agent works 在 Bigram 模型下的联合概率。
  2. 解释马尔可夫假设的理论含义，并指出 N-gram 模型因此产生的根本性局限。
  3. 从架构机制出发，RNN/LSTM 和 Transformer 分别是如何克服 N-gram 局限的？二者在处理机制上有何核心优劣差异？

【解析】

  1. Bigram 概率计算：
    根据 Bigram 的链式法则近似：。
    • 语料库总词数 = 6。agent 出现 2 次，故 。
    • 在 agent 出现的 2 次中，其后接 works 的次数为 1 次，故最大似然估计下 。
    • 联合概率：。
  2. 马尔可夫假设与局限：
    • 理论含义： 将全局序列概率降维为局部条件概率，假设当前状态（词）仅依赖于前 个历史状态，使得高维概率计算在工程上可行。
    • 根本局限： 彻底割裂了长程依赖（无法处理跨越数十个词的语法指代）；采用离散符号统计，导致极高的“数据稀疏性”（未出现的组合概率直接为零），毫无语义泛化能力。
  3. 架构机制的克服与对比：
    • 克服局限： RNN 引入了连续向量空间（词嵌入解决泛化问题）和“隐藏状态”（打破固定 N 窗口，隐式传递长程历史）。Transformer 进一步通过“全局自注意力”让任意两个词直接发生信息交互，彻底消除了距离对特征提取的削弱。
    • 核心优劣差异： RNN 依赖时序递归（必须等 步算完才能算 步），难以并行训练，且存在梯度衰减；Transformer 采用矩阵一次性并发计算，极大地提升了训练效率，但计算复杂度随序列长度呈平方级增长（）。

Transformer 架构与 Decoder-Only 演进

【原问题】
Transformer 是支撑现代大语言模型的基础架构。在其内部机制与后续演进中存在诸多精妙设计。

  1. 剥离掉复杂的矩阵公式，请阐述自注意力机制（Self-Attention）的核心认知思想是什么？
  2. 为什么 Transformer 能够颠覆 RNN 实现大规模并行处理序列？在彻底抛弃循环结构后，位置编码（Positional Encoding）为何成为必不可少的组件？
  3. 既然 Transformer 最初是包含 Encoder 和 Decoder 的完整架构，为什么当前主流的生成式大语言模型（如 GPT、Llama 系列）却集体转向了 Decoder-Only 架构？

【解析】

  1. 自注意力的核心思想：
    本质上是一种“基于内容的动态信息检索与聚合”机制。对于句子中的每个词，它主动发出查询（Query），去评估序列中所有其他词的特征标签（Key）。根据相关性得分，为当前词动态地吸纳相关度高的内容（Value）。它实现了词义的“语境化（Contextualized）”重构。
  2. 并行计算与位置编码的必然性：
    • 并行原理： RNN 的计算图是线性依赖的。Transformer 的自注意力计算依赖的是 与 的全矩阵乘法，由于不需要等待历史状态，输入序列的所有特征提取可以被丢进 GPU 的 Tensor Core 中一次性并行计算完毕。
    • 位置编码的必要性： 矩阵乘法本身具有“置换不变性”。如果没有位置编码，打乱句子的语序，模型计算出的注意力权重分配毫无变化，沦为纯粹的“词袋模型”。通过注入位置向量（三角函数或旋转位置编码），强制让模型在向量空间中感知到词与词的相对物理距离。
  3. 转向 Decoder-Only 的理论动机：
    • 训练范式的统一： Encoder-Decoder 适用于输入输出不对等的任务（翻译、摘要）。但 Decoder-Only 将一切自然语言任务统一抽象为了单一的自回归目标：“预测下一个 Token”。
    • 规模化（Scaling）的工程便利： Decoder-Only 移除了负责交叉注意力的组件，网络结构高度单一且同质化，极大地降低了超大参数规模下的流水线并行和显存分配难度，完美契合缩放法则（Scaling Laws）的暴力美学。

分词算法（Tokenization）的工程约束

【原问题】
在将文本输入大语言模型之前，必须经过文本子词分词算法（如 BPE）的切分。

  1. 为什么在现代模型设计中，不能简单粗暴地以英文字母（字符级）或按空格划分的单词（词级）作为底层输入单元？
  2. BPE（Byte Pair Encoding）算法是如何在字符级与词级之间取得平衡，并解决上述痛点的？

【解析】

  1. 双重绝境：
    • 按字符分词： 单个字母毫无独立语义（如字母 a 必须组合才能表意），这导致模型的输入序列极度冗长，迅速耗尽昂贵的 Transformer 上下文窗口限制。
    • 按单词分词： 人类语言存在无限的词法变体（时态、复数形式）。这会导致模型词表（Vocabulary）呈指数级爆炸，使得最后一层分类器参数过大；且一旦遇到未在训练集中出现的专业词汇，模型只能输出无意义的 [UNK] 标记，即未登录词（OOV）问题。
  2. BPE 算法的平衡策略：
    BPE 基于统计学贪心压缩。它从单字符词表开始，不断统计语料中最高频相邻的字符组合并进行合并压缩。
    • 平衡点： 高频的、具有独立语义的基础词汇（如 the, agent）会在合并中成为一个完整的 Token，保留词汇级语义；而低频词或罕见新词（如 Tokenization）则被保留为多个高频的词根、词缀片段（如 Token + ization）。
    • 解决痛点： 彻底消灭了 OOV 问题（任何生僻词都能回退到单字符拼凑）；同时将词表大小严格限制在工程可控范围（如 10 万以内），兼顾了序列长度压缩率与底层语义丰富度。

提示工程与企业级智能体选型

【原问题】
假设你需要为一家跨国企业构建一个核心的“退换货政策解答与流程引导客服智能体”。

  1. 按照本章对开源与闭源大语言模型的阐述，从性能、成本、可控性、隐私等维度进行对比。针对该企业级客服场景，你会倾向于选择哪种模型部署路线？
  2. 在模型推理时，如果你希望模型在解答企业制度时严谨死板，而在安抚客户情绪时自然流畅，你应如何干预 Temperature 等采样参数？
  3. 在具体的任务执行中，如果模型在处理复杂的退货退款计算逻辑时频繁出错，你将如何利用 Few-shot 与 Chain-of-Thought（CoT）策略重构你的 Prompt 以提升其准确率？

【解析】

  1. 企业场景选型决策：
    • 对比： 闭源 API（如 GPT-4）具备最强性能和极低前期接入成本，但按 Token 计费长期成本高，且存在将客户聊天数据传至外部服务器的严重隐私合规风险；开源模型（如 Qwen-72B/Llama-3）前期需要高昂的算力集群采购成本，但单次调用边际成本趋零，数据绝对物理隔离，且支持深度的垂直知识微调（SFT）。
    • 决策倾向： 针对企业客服场景，优先选择开源模型本地私有化部署。因为退换货政策涉及企业内部规定与客户订单隐私，数据安全是硬性红线。且客服场景逻辑相对固定，通过注入企业知识库（RAG）配合开源模型足以达到业务标准。
  2. 采样参数的分层控制：
    • 针对“政策解答”节点，将 Temperature 降至趋近于 0，Top-p 设为 0.1。此时模型采取贪心解码策略，输出确定性极高，杜绝在制度问题上“自由发挥”产生幻觉。
    • 针对“情绪安抚”节点，将 Temperature 调高至 0.6 - 0.7。引入概率平滑，使得模型生成的问候语、安抚话术更具多样性和“人情味”。
  3. Prompt 策略重构（Few-shot + CoT）：
    • 仅仅通过 Zero-shot 抛出问题会导致计算跳步。需要在 Prompt 中前置注入 2-3 个标准的历史退款计算案例（Few-shot）。
    • 在这些案例中，不仅要给出最终退款金额，必须显式地写出计算过程（CoT）。例如加入引导语：“在得出结果前，请逐步思考：第一步，判断商品是否在7天内；第二步，计算商品原价减去已使用的优惠券金额；第三步，核对是否需要扣除运费”。通过强制模型输出中间逻辑链，降低复杂计算的误差。

治理模型幻觉：学术辅助智能体设计

【原问题】
模型幻觉（Hallucination）是大语言模型落地的最大阻碍。假设你需要设计一个“学术论文辅助阅读智能体”，帮助科研人员快速总结数十页的论文并对比多篇文献的观点。由于科研场景极度严谨，不容忍任何事实偏差。

  1. 针对学术论文普遍较长，极易突破模型上下文窗口限制的问题，在系统架构上你将采取何种工程手段解决？
  2. 除了本章提到的检索增强生成（RAG），结合前沿的大模型研究，还有哪些机制可以被引入到该智能体中以进一步压制幻觉？请说明其工作原理。
  3. 为了确保智能体生成的摘要和对比严格忠于原文，在系统的工作流设计中，你将如何部署审查约束机制？

【解析】

  1. 突破超长上下文约束的架构：
    • 传统的直接输入会导致 Token 溢出。可采用 基于向量检索的 RAG 机制：将长论文切割为按段落划分的文本块（Chunks），向量化后存入知识库。当用户询问特定细节时，仅检索 Top-K 相关的文本块喂给模型。
    • 针对需要通读全文的“全局总结”任务，采用 Map-Reduce 范式：让模型并行对论文的各个章节生成局部摘要（Map），最后将局部摘要汇总给模型进行二次提炼（Reduce）。
  2. 前沿缓解幻觉的对抗机制：
    • 多智能体交叉验证（Multi-Agent Debate/Verification）： 引入独立的“审查者 Agent（Reviewer）”。当生成者 Agent 输出文献对比后，强制流转给审查者。审查者被赋予“挑刺”的 System Prompt，专门比对生成文本与原文检索块，若发现过度引申即打回重写。
    • 知识图谱增强（GraphRAG）： 纯语义向量检索（Dense Retrieval）容易丢失学术论文中严密的实体逻辑关系。引入知识图谱提取论文中的实体关系（如“算法A -> 改进了 -> 缺陷B”），结合图谱路径进行事实性约束。
    • 验证链（Chain-of-Verification, CoVe）： 强制模型在生成初步答案后，自行提取出答案中的关键事实陈述，自我生成核查问题，并重新独立查询上下文进行验证，最后输出修正后的答案。
  3. 严格忠实原文的工作流部署：
    • 强制溯源（Attribution Requirement）： 在 Prompt 中下达强指令：“你的每一句学术总结，必须附带原文的段落引用”。通过代码层面的后处理正则校验，拒绝任何没有对应 [Reference: Section X] 的输出。
    • 忠实度置信度阈值： 引入自然语言推理（NLI）判别模型作为最后一道防线，计算生成的摘要与检索到的原文块之间的蕴含关系得分。若得分低于设定阈值，则判定为发生内在幻觉（Intrinsic Hallucination），向用户抛出警告而非错误答案。
]]> https://cooooing.github.io/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E3%80%8Ahello%20agents%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-%E6%99%BA%E8%83%BD%E4%BD%93%E4%B8%8E%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E5%9F%BA%E7%A1%80/ 2026-03-05T13:21:27.000Z 第一章 - 初识智能体

本章从人工智能的发展脉络出发，系统阐述了智能体（Agent）的本质定义、演进]]>

《hello agents》读书笔记 - 智能体与语言模型基础 2026-03-05T13:21:27.000Z 咕咕咕 前言

这本书前四章篇幅超过三分之一
五到十二章共八章 和 十三到二十一共九章 大约各占三分之一
这章节内容量差的有点大

第三部分是关于 Zinx 框架的，跳过。

第五章 - 有关Goroutine⽆限创建的分析

进程、线程与协程的本质区别

进程 (Process) —— 资源分配的最小单位

  • 内存空间**：每个进程拥有独立的虚拟地址空间（32位系统为 4GB，64位更大）。
  • 组成部分**：拥有独立的堆、栈、全局变量区、代码区等。
  • 调度机制**：直接由操作系统内核调度，通过 PCB（进程控制块）管理。
  • 特点**：隔离性强，一个进程崩溃不影响其他进程；但资源消耗最重。

线程 (Thread) —— CPU 调度的最小单位

  • 轻量级进程 (Light Weight Process，LWP)**：线程是“寄生”在进程之上的执行流。
  • 资源共享**：线程拥有独立栈空间，但共享所属进程的堆区、全局区等内存。
  • 通信与风险**：通信简单（加锁访问共享内存），但由于关联性强，一个线程的非法操作可能导致整个进程崩溃。

执行单元与 CPU 调度原理

  • 调度策略**：Linux 内核不严格区分进程和线程，统一视为执行单元。CPU 会平均分配时间片。
  • 性能欺骗**：增加线程数可以获得更多 CPU 时间片比例（如进程 A 1个线程，进程 B 3个线程，B 获得的 CPU 资源更多），但这并非无限制。
    切换内核栈和切换硬件上下⽂都会触发性能的开销，切换时会保存寄存器中的内容，将之前的执⾏流程状态保存，也会导致CPU⾼速缓存失效。

切换成本

协程（Goroutine）之所以在并发表现上远超传统线程，核心原因在于其切换效率极高。其快的主要原因可归纳为两点：

  1. 空间差异：协程切换完全在用户空间完成；而线程切换涉及特权模式切换，必须进入内核空间。
  2. 工作量差异：协程切换需要保存和恢复的数据量极小。

协程切换成本

协程的上下文切换过程非常精简，仅涉及最核心的寄存器操作：

  • 切换机制**：
    1. 保存当前协程的 CPU 寄存器状态。
    2. 将即将执行的协程的寄存器状态加载到 CPU 中。
  • 执行环境**：完全在用户态进行，不触发系统调用（System Call）。
  • 性能表现**：一次典型的协程上下文切换耗时仅需 几十纳秒 (ns)。

线程切换成本

线程是操作系统内核调度的基本单元，其切换过程沉重得多：

  • 权限切换**：线程调度由具有最高权限的内核空间完成。因此，线程切换必然涉及用户态与内核态的切换（即特权模式切换）。
  • 复杂流程**：
    1. 触发系统调用过程。
    2. 由操作系统调度模块介入。
  • 上下文负载**：除了和协程相同的 CPU 寄存器状态外，还包含线程私有的栈、硬件上下文以及更多内核管理数据。
  • 间接影响**：频繁的内核切换会导致 CPU 高速缓存（Cache）失效，页表查找变慢，从而拖慢程序整体运行速度。

为什么不能无限创建 Goroutine？

尽管 Goroutine 轻量，但“无限”创建会导致：

  1. CPU 飙升：大量协程即使在切换时开销小，但由于基数过大，调度器压力激增，导致 CPU 满负荷。
  2. 内存占用上涨：虽然每个协程占用内存很小，但协程量大后容易触发 OOM（内存溢出）。
  3. 主进程崩溃：操作系统感知到资源异常，发送 kill 信号，或触发 Go 运行时 Panic。

控制 Goroutine 数量的方案

使用带缓冲的 Channel
  • 逻辑**：创建容量为 N 的 Channel，开启协程前向其写入，结束后读取。
  • 优点**：能利用 Channel 的阻塞特性天然限制并发速率。
  • 缺点**：若主进程退出太快，未完成的协程会随之销毁，导致结果不准确。
使用 sync.WaitGroup
  • 逻辑**：Add() 增加计数，Done() 减少。
  • 失败分析**：虽然能保证所有协程执行完，但无法限制创建瞬间的并发量。如果任务生产极快，系统会瞬间因创建过多协程而崩溃。
Channel + sync.WaitGroup 组合
  • 逻辑**：
    1. 用缓冲 Channel 限制最大并发数。
    2. 用 sync.WaitGroup 确保主进程在所有任务完成后才退出。
  • 结论**：这是最常用的基础并发控制手段。
发送/执行分离方式
  • 逻辑**：将“生产任务”和“消费任务”解耦。
  • 结构**：
    1. 固定 M 个 Worker 协程长期运行。
    2. 任务通过无缓冲 Channel 发送。
    3. 当 M 个 Worker 全忙时，发送端自然阻塞。
  • 优点**：灵活性最高，是Worker 工作池的设计蓝本。

小节

  • Go 的垃圾回收只能回收不再被引用的内存，无法回收正在阻塞运行或逻辑泄漏的 Goroutine。
  • Goroutine 泄漏是内存泄漏的一种严重表现形式。必须从代码逻辑上确保协程能正常退出。

第六章 - Go 语言中的逃逸现象：变量“何时在栈、何时在堆”

Go 语言中的逃逸现象

Go 语言中访问子函数的局部变量

在 Go 语言中，函数可以安全地返回局部变量的地址（指针），供外部函数使用。
程序能正常运行并输出正确值，不会报编译错误或运行错误。

Go 编译器会自动检测变量生命周期，如果发现局部变量在函数退出后仍被引用，会将其从“栈”转移到“堆”上。

C/C++ 中访问子函数的局部变量

在 C/C++ 中，局部变量分配在栈上，函数退出后栈空间被回收。如果返回局部变量地址，外部访问将指向已销毁的内存。
编译器会发出警告（Returning address of local variable），运行后通常会导致 段错误（Segmentation Fault） 或获取到随机垃圾值。
Go 通过“逃逸分析”机制，消除了开发者手动管理堆栈内存的负担。

逃逸分析过程示例

示例过程

  • 逃逸分析定义**：Go编译器在编译阶段通过静态分析，判断变量的作用域。若变量生命周期超过函数范围，则产生“逃逸”。
  • 检测工具**：
    1. 编译分析：使用 go tool compile -m pro.go。若看到 moved to heap: x，说明变量发生了逃逸。
    2. 汇编分析：使用 go tool compile -S pro.go。搜索 runtime.newobject 关键字。在堆上开辟空间必须调用此内核函数，而栈空间分配通常只是简单的地址偏移。
  • 成本考量**：分配在堆上的变量需要由 GC（垃圾回收）进行跟踪、标记和回收，会消耗额外的计算资源。

new 的变量在栈还是堆

在C++中 new 一定在堆上，但在Go中，new 出来的变量不一定在堆上。

  • 判断准则**：
    • 即使使用 new 申请内存，如果变量没有逃逸（仅在函数内部使用且未返回地址），编译器仍会将其分配在栈上。
    • 只有当编译器分析出该变量被外部引用时，才会将其分配到堆。

普遍的逃逸规则

逃逸的普遍的规则就是如果变量需要使⽤堆空间，就应该进⾏逃逸。

多级间接赋值（引用对象中的成员又是引用类型）极易导致逃逸。
引用类型包括 func、interface、slice、map、channel 和 指针 等。

常见逃逸范例清单：

  1. []any 类型：给切片元素赋值必定逃逸（如 data[0] = 100）。
  2. map[string]any 类型：赋值时对应的 value 必定逃逸。
  3. map[any]any 类型：赋值时 key 和 value 均会发生逃逸。
  4. map[string][]string 类型：赋值时内部的切片 []string 会发生逃逸。
  5. []*int 类型：切片内存储的是指针，赋值时该指针指向的原始变量会发生逃逸。
  6. func(*int) 类型：作为函数参数传递指针时，形参对应的实参会逃逸。
  7. func([]string) 类型：作为函数参数传递切片时，实参切片会逃逸。
  8. chan []string 类型：向管道中发送切片数据，该切片会发生逃逸。

小结

  • 变量在堆还是栈，完全由编译器根据逃逸分析决定，与变量是否通过 new 创建无关。
    1. 减少指针使用：多级间接访问（指针嵌套）会增加逃逸概率。在高性能场景下，应有意识地减少不必要的指针传递。
    2. 关注引用类型：map、slice、any 等类型本身就是引用类型，结合赋值操作时要留意其逃逸行为。
  • 逃逸分析并非完美。有时编译器会“保守”地将本可以留在栈上的变量移动到堆中。
  • 深入理解逃逸分析，可以写出更高效的代码，减轻GC压力，提升程序整体性能。

第七章 - interface 剖析与 Go 语言面向对象思想

interface 的基本概念与赋值问题

  1. interface 的核心特征
    • 方法集合**：interface 是一组方法声明的集合。
    • 隐式实现**：无需 implements 关键字。只要一个类型实现了接口要求的所有方法，就自动实现了该接口（Duck Typing 思想）。
    • 多态性**：接口变量可以存储任何实现了该接口的实例。
  2. interface 赋值中的多态要素，实现多态需满足：
    1. 定义 interface 接口及方法。
    2. 子类（结构体）重写接口中的所有方法。
    3. 父类指针（接口变量）指向子类对象。

接口的内部构造

Go 根据接口是否包含方法，将其底层结构分为两种：eface 和 iface。

空接口 eface

空接口 interface{} 不包含任何方法。

  • 结构定义：
    1
    2
    3
    4
    type eface struct {
        _type *_type          // 类型信息
        data  unsafe.Pointer  // 指向具体实例数据的指针
    }
  • 可以指向任何类型。_type 决定了如何解释 data 里的内容。

非空接口 iface

带有一组方法的接口。

  • 结构定义**：
    1
    2
    3
    4
    type iface struct {
        tab  *itab            // 核心：存放接口类型、具体类型及方法地址
        data unsafe.Pointer   // 具体实例数据的指针
    }
    1
    2
    3
    4
    5
    6
    type ITab struct {
        Inter *InterfaceType  // 接口自身元数据信息
        Type  *Type
        Hash  uint32     // copy of Type.Hash. Used for type switches.
        Fun   [1]uintptr // variable sized. fun[0]==0 means Type does not implement Inter.
    }
  • itab 结构**（占32字节）：
    • interfacetype：接口本身的定义信息。
    • type：具体实现类的类型信息。
    • hash：具体类型的哈希值，用于快速判断类型是否一致。Go 语⾔的 interface 的 Duck-typing 机制也依赖这个字段实现。
    • fun：函数指针数组。保存具体实现方法的地址。是⼀个动态⼤⼩的数组，虽然声明时固定⼤⼩为 1，但在使⽤时会直接通过 fun 指针获取其中的数据，并且不会检查数组的边界，所以该数组中保存的元素数量是不确定的。

接口为 nil 的判定陷阱

一个接口变量只有在 类型(type/tab) 和 数据(data) 同时为 nil 时，才等于 nil。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
package test

import "testing"

type People1 interface {
Name() string
}

type People2 interface {
}

type Student struct {
}

func (s *Student) Name() string {
return "Student"
}

func live1() People1 {
var s *Student
return s
}
func live2() People2 {
var s People2
return s
}

func TestNil(t *testing.T) {
if live1() == nil {
t.Log("live1() is nil")
} else {
t.Log("live1() is not nil")
}
if live2() == nil {
t.Log("live2() is nil")
} else {
t.Log("live2() is not nil")
}
}

输出：

1
2
3
4
5
=== RUN   TestNil
    test_test.go:32: live1() is not nil
    test_test.go:35: live2() is nil
--- PASS: TestNil (0.00s)
PASS

interface{} 与 *interface{}

  • interface{}**：万能类型，可以接收任何值。
  • *interface{}**：指向接口变量的 指针。它不再是万能类型，只能接收 *interface{} 类型的地址。在开发中极少使用，通常是逻辑错误。

小结

  • 区分 eface 和 iface 是理解 Go 内存管理和类型系统的基础。
  • 警惕“接口不为 nil 但底层指向 nil 指针”的问题。
  • 尽量面向抽象编程。
  • 遵循开闭原则（通过扩展而非修改来应对需求变化）。
  • 遵循依赖倒转原则（高层不依赖低层，两者都依赖抽象）。

第八章 - defer 践行中必备的要领

defer 是 Go 语言中极具特色的关键字，用于确保资源回收、状态重置或业务闭环在函数结束前执行。
虽然语法简单，但在复合场景（如配合 return、panic、有名返回值）下存在特定逻辑。

defer 的执行顺序：栈结构

多个 defer 语句遵循 后进先出 (LIFO) 的原则。

  1. 遇到 defer：将表达式压入栈中（不立即执行）。
  2. 函数结束（遇到 return 或执行完毕）：从栈顶弹出 defer 表达式并依次执行。

defer 与 return 的顺序关系

return 后的表达式先执行，defer 后面的语句后执行。

  • 触发时机：defer 触发的出栈时机是函数作用域结束。由于 return 语句是函数内部的最后一条指令，它必须先于函数销毁前完成计算和赋值。
  • 简单理解：return 负责“设定返回值”，defer 负责“清理工作”，最后函数彻底退出。

函数返回值的初始化

Go 允许在函数定义时为返回值命名（有名返回值）。

  • 初始化时机：有名返回值（如 t int）会在函数起始处被自动初始化为对应类型的零值（如 0）。
  • 作用域：该变量的生命周期贯穿整个函数，并在函数结束时作为最终结果返回。

有名函数返回值遇见 defer

由于有名返回值的变量作用域覆盖了整个函数，且 defer 执行晚于 return 的赋值动作，因此 defer 里的逻辑可以直接修改已设定的返回值内容。

示例分析：

1
2
3
4
5
6
func test() (t int) {
    defer func() {
        t *= 10 
    }()
    return 1 
}
  1. t 初始化为 0
  2. 先 return，t 赋值为 1
  3. 再 defer ，t 赋值为 10
  4. 最后函数返回 10

defer 遇见 panic

panic 会触发当前协程已压栈的所有 defer。

  • 处理流程：
    1. 发生 panic。
    2. 逆序遍历并执行本协程的 defer 链表。
    3. 捕获：若某个 defer 包含 recover()，则 panic 停止，程序恢复。
    4. 未捕获：遍历完所有 defer 后，向 stderr 抛出异常信息并崩溃。
  • 关键点**：在 panic 语句之后定义的 defer 不会被压栈，因此也就不会执行。

defer 中包含 panic

  • 冲突规则**：如果在执行 defer 过程中产生新的 panic，它会覆盖之前的 panic。
  • 捕获原则**：recover() 仅能捕获到最后一个发生的 panic。

defer 下的函数参数包含子函数

  • 求值规则**：defer 函数的参数在压栈时就会被立即求值，而不是在函数最终执行时。
  • 示例流程**：defer func1(arg1, func2())
    1. 计算 func2() 的值（立即执行）。
    2. 将结果和 func1 的地址压栈。
    3. 函数结束时再弹出并执行 func1。

章节小结

  1. 栈序：后进先出。
  2. 先赋值，后 defer：return 设置返回值的动作早于 defer 执行。
  3. 参数立即求值：传给 defer 函数的参数在压栈那一刻就确定了。
  4. 保活功能：defer 配合 recover 是防范程序因 panic 崩溃的最后防线。
  5. 变量影响：能否修改返回值，取决于该返回值是否有名字（有名返回值）以及 defer 是如何引用该变量的（传参还是闭包）。

第九章 - Go 语言常用问题及性能调试实践方法

如何分析程序运行时间与 CPU 利用率

Shell 内置 time 指令

在 Linux/Unix 中直接使用 time 命令运行程序。

指标说明：

  1. real：实际消耗时间（从开始到结束）。
  2. user：程序在用户态消耗的 CPU 时间。
  3. sys：程序在内核态消耗的 CPU 时间（系统调用等）。

通常 real >= user + sys，差值部分是系统调度其他进程的时间。

/usr/bin/time 指令

使用绝对路径调用可以获得更丰富的信息，建议配合 -v 参数。
除了三种时间外，还提供 CPU 占用率、内存使用峰值、页错误 (Page Fault)、进程切换次数、文件 I/O 和 Socket 使用情况等。

如何分析 Go 语言内存使用情况

系统层查看：top 命令

通过 top -p $(pidof 程序名) 查看进程的内存占用。
有时程序逻辑执行完，top 显示内存依然很高。这不一定是泄露，可能是 Go 垃圾回收后尚未将内存归还给操作系统。

GODEBUG 与 gctrace（追踪 GC）

通过设置环境变量启动程序：GODEBUG='gctrace=1'。
设置gctrace=1会使垃圾回收器在每次回收时汇总所回收内存的⼤⼩及耗时，并将这些内容汇总成单⾏内容打印到标准错误输出中。

输出：gc 1 @0.010s 1%: 0+0.53+0 ms clock, 0+1.0/2.6/0+0 ms cpu, 3->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 20 P

输出格式解读：

  • gc 1：GC 编号。
  • @0.010s：程序开始后的时间。
  • 1%：GC 占用的时间比例。
  • 3->4->1MB：GC 开始前堆大小 -> GC 结束后堆大小 -> 当前活跃堆大小。

如果 top 很高但 gctrace 显示活跃堆很小，说明内存已在应用层回收，但仍被 Go 进程持有。

runtime.ReadMemStats

在代码中主动读取内存状态，适合自动化监控。

  1. 基础统计 (General Statistics) 这部分反映了程序内存分配的宏观数据。
    • Alloc / HeapAlloc: 当前堆上活跃对象占用的字节数。该值会随 GC 释放对象而减小。反映业务数据量
    • TotalAlloc: 累计分配的堆内存字节数。只增不减，即使对象被释放，该值也记录总量。
    • Sys: 从操作系统获取的虚拟内存总额。包含堆、栈、及其它内部数据结构。注意：这是虚拟地址空间，不一定全部对应物理内存。
    • Mallocs: 累计分配的对象总数。
    • Frees: 累计释放的对象总数。
    • 活跃对象数** = Mallocs - Frees。
  2. 堆内存详情 (Heap Statistics) Go 将堆内存划分为 Span（8K 或更大的连续区域），Span 分为：空闲(Idle)、使用中(In-use)、栈(Stack)。
    • HeapSys: 为堆申请的虚拟内存字节数。包括已使用、未使用（Idle）以及已归还给系统的内存。
    • HeapInuse: 正在使用的 Span 占用的字节数（至少包含一个对象）。
      • 碎片估算：HeapInuse - HeapAlloc 是已预留给特定大小对象但当前未使用的字节数（内部碎片）。
    • HeapIdle: 空闲 Span 占用的字节数。可以被重新用于分配对象、转为栈内存，或归还给 OS。
    • HeapReleased: 已归还给操作系统的物理内存。这些内存属于空闲 Span，OS 可以回收其物理页面。
      • 待回收内存估算：HeapIdle - HeapReleased 表示运行时保留的、用于未来扩展堆的空闲内存，尚未归还给 OS。
    • HeapObjects: 当前堆上的对象总数。
  3. 栈与内部结构 (Stack & Off-heap)
    • StackInuse: 协程栈（Goroutine Stacks）占用的字节数。
    • StackSys: 从 OS 获取的用于栈的内存（通常等于 StackInuse，但在 CGO 环境下包含线程栈）。
    • MSpanInuse / MSpanSys: 用于存放 mspan 结构体（元数据）的内存。
    • MCacheInuse / MCacheSys: 用于存放 mcache 结构体（元数据）的内存。
    • GCSys: 垃圾回收元数据（如位图、标记位）占用的内存。
    • OtherSys: 运行时内部其它分配（如 profiling 记录）占用的内存。
  4. 垃圾回收统计 (GC Statistics)
    • NextGC: 下一次触发 GC 的目标堆大小。目标是保持 HeapAlloc ≤ NextGC。
    • LastGC: 上次 GC 完成的时间戳（纳秒）。
    • PauseTotalNs: 程序启动以来 GC 累计导致的 STW（Stop-The-World）总时间。
    • PauseNs [256]: 循环缓冲区，存储最近 256 次 GC 的 STW 停顿时间。衡量程序卡顿（抖动）的关键
    • PauseEnd [256]: 循环缓冲区，存储最近 256 次 GC 结束的时间戳。
    • NumGC: 已完成的 GC 次数。
    • NumForcedGC: 用户手动调用 runtime.GC() 触发的次数。
    • GCCPUFraction: GC 消耗的 CPU 时间占总可用 CPU 时间的比例（0.0 到 1.0）。反映 GC 对业务性能的侵占程度
  5. 分级分配统计 (Size Class Statistics)
    • BySize [61]: 一个数组，记录了 Go 内部 61 种不同“大小级别”（Size Class）的分配情况。
      • Size: 该级别对象的最大字节数。
      • Mallocs / Frees: 该特定大小级别累计的分配/释放次数。

pprof 工具（Web 界面查看内存）

在代码中引入 _ "net/http/pprof" 并启动一个 HTTP 监听。
可以直观展示当前的堆内存分配详情。

如何获取 CPU 性能情况

性能分析的前置条件（环境稳定性）

  1. 机器必须闲置，关闭省电和过热模式。
  2. 避免在虚拟机或共享云主机上进行高精度的测试。
  3. 多次测试以取相对一致的结果。

使用 go tool pprof 分析数据

两种方式获取 Profile 文件：

  1. 访问 http://127.0.0.1:端口/debug/pprof/profile，默认等待 30s 后会下载一个采样文件。
  2. go tool pprof http://localhost:端口/debug/pprof/profile?seconds=60（采样 60 秒）。

命令行格式：go tool pprof [二进制文件] [profile文件]。

  • 常用内部指令：
  • top：列出最耗 CPU 的函数。
    • flat：当前函数本身的耗时。
    • cum：当前函数及其调用的子函数总耗时。
  • list [函数名]**：定位到代码具体的某一行。

第十章 - make 和 new 的原理性区别

变量的声明与初始化基础

零值机制：使用 var 声明变量而不指定初始值时，Go 会自动赋予其“零值”。

  • int -> 0
  • string -> ""
  • 引用类型/指针 -> nil

对于引用类型（指针、切片、映射、通道），仅声明而不分配内存就进行操作，会导致 panic: runtime error: invalid memory address or nil pointer dereference。
值类型声明即分配空间；引用类型必须经过显式内存分配才能使用。

new 与 make 的深度区别

new 函数

  • 函数原型：func new(Type) *Type
    1. 参数：只接受一个参数，即类型。
    2. 动作：在堆上分配一块该类型的内存，并将内存置零（设为该类型的零值）。
    3. 返回值：返回指向该内存地址的指针（即 *Type）。
  • 应用场景：常用于结构体。由于 new 会自动初始化零值，结构体中的同步锁（如 sync.Mutex）或其它字段无需额外初始化即可直接使用，不会出现无效引用的异常。

make 函数

  • 函数原型：func make(t Type, size ...IntegerType) Type
    1. 限定类型：仅用于 slice（切片）、map（映射）和 chan（通道）。
    2. 动作：内存分配并进行初始化（分配底层数据结构，如设置切片的长度、容量，创建 map 的哈希桶等）。
    3. 返回值：返回类型本身（Type），而不是指针。
  • 为什么不返回指针？ 因为这三种类型本身就是引用类型（内部封装了指针），返回指针没有意义。

扩展：Map 使用中的经典坑点

  1. Value 赋值问题：
    • 如果 map 的值是结构体（如 map[string]Student），不能直接修改 map["key"].Name。因为 map 的元素不可寻址（只读引用）。
    • 解决方案：将 map 定义为指针类型 map[string]*Student，这样修改指针指向的结构体内容是合法的。
  2. 遍历赋值问题：
    • 在 for range 循环中，循环变量（如 stu）是一个副本。
    • 如果在循环内取 &stu 存入 map，会导致 map 中所有的 key 最后都指向同一个地址（即循环变量的地址，其值为遍历的最后一个元素）。
    • 解决方案：使用索引直接取原数组元素的地址，如 &students[i]。

make 与 new 的异同点总结

特性newmake
适用范围任意类型仅限 slice, map, channel
分配空间堆空间堆空间
内存状态置零（Zeroed）初始化（Initialized）
返回值指针 (*T)类型本身 (T)
常用替代短变量声明 i := 0 或字面量 u := user{}必须使用 make 初始化这三类引用类型

特殊情况：用 new 初始化切片

  • 代码现象：执行 list := new([]int) 得到的是一个切片指针（指向 nil 切片的指针）。
  • 编译错误：不能直接 append(list, 1)，因为 append 的第一个参数必须是切片而非指针。
  • 解决建议：除非业务明确需要切片指针，否则应统一使用 make([]int, 0)。

小结

  • new 是为了“分配内存并置零”，返回指针。虽然它能分配任何类型的内存，但在实际编程中，对于普通变量或结构体，更倾向于使用字面量初始化。
  • make 是为了“创建并初始化”引用类型，返回对象。它是使用切片、映射和通道前的强制性步骤。

第十一章 - 精通 Go Modules 项目依赖管理（过时，可略）

GOPATH 工作模式

什么是 GOPATH

在 Go 1.11 之前，所有的开发工作必须在 GOPATH 环境变量指定的目录下进行。其目录结构包含：

  • bin：存放编译后的二进制可执行文件。
  • pkg：存放预编译的目标文件（.a 文件），加速编译。
  • src：存放源代码（项目必须存放在 $GOPATH/src 下）。

GOPATH 模式的弊端

  1. 无版本控制概念：执行 go get 总是拉取最新代码，无法指定特定版本。
  2. 无法同步第三方库版本：不同开发者的本地环境可能依赖了不同版本的库，导致编译结果不一致。
  3. 引用路径冲突：无法在同一环境中处理同一个库的不同大版本（如 v1 和 v2）。

Go Modules 核心配置

常用命令 (go mod)

命令作用
go mod init初始化当前文件夹，创建 go.mod 文件
go mod download下载依赖包到本地缓存
go mod tidy增加缺失的模块，移除未使用的模块（常用）
go mod edit编辑 go.mod 文件（如替换版本）
go mod graph打印模块依赖图
go mod vendor创建 vendor 目录，将所有依赖包复制到该目录下
go mod verify校验依赖是否被篡改
go mod why解释为什么需要依赖某个模块

关键环境变量

  1. GO111MODULE：
    • off：禁用模块支持，沿用 GOPATH。
    • on：强制开启模块支持（推荐）。
    • auto：默认值，根据目录下是否有 go.mod 自动决定。
  2. GOPROXY：
    • 设置代理以加速依赖下载。
    • 推荐：https://goproxy.cn,direct。
    • direct：特殊指示符，当代理返回 404 等错误时，强制回源（如 GitHub）抓取。
  3. GOSUMDB：
    • 校验和数据库，确保拉取的代码未被篡改。
  4. GOPRIVATE：
    • 设置私有仓库路径（如公司 GitLab）。
    • 设置后，匹配的路径将不经过代理和校验数据库。

项目初始化与管理

初始化流程

  1. 开启模块：go env -w GO111MODULE=on
  2. 创建项目并进入：mkdir project && cd project
  3. 初始化模块：go mod init <模块路径> (如 github.com/user/repo)

go.mod 文件结构

  • module：定义当前模块的路径。
  • go：标识初始化时的 Go 版本。
  • require：列出项目依赖的具体模块及版本。
  • //indirect：间接依赖（当前项目未直接 import，但依赖的库引用了它）。

go.sum 文件的作用

  • 详细罗列所有直接和间接依赖的 SHA-256 哈希值。
  • h1 hash：包内所有文件的总哈希，用于检测代码是否被篡改。
  • go.mod hash：仅对 go.mod 文件进行哈希。

版本修改与替换 (replace)

更新依赖

使用 go get 可以拉取或更新版本：

  • go get <path>@v1.2.3：指定特定版本。
  • go get <path>@latest：拉取最新版本。

使用 replace 关键字

在某些特殊情况下（如无法访问某个库，或需要调试本地库），可以使用 replace：

  • 语法：go mod edit -replace=旧模块@版本=新模块/路径@版本
  • 场景：
    1. 替换因网络问题无法下载的模块。
    2. 强制锁定某个具体的补丁版本。
    3. 将依赖指向本地磁盘的开发代码。

第十二章 - ACID、CAP、BASE 分布式理论推进

事务的基本概念

分布式研究的核心起点是事务（Transaction）。

  • 定义：将一组操作纳入一个不可分割的执行单元。
  • 机制：“要么全做，要么全不做” (All or Nothing)。
  • 回滚：任一操作失败，整个单元的操作全部撤销，恢复到初始状态。

ACID 理论（本地事务的基石）

数据库事务正确执行的四个基本特性：

  1. 原子性 (Atomicity)：事务中的操作是不可分割的整体，要么全部成功，要么全部失败。
  2. 一致性 (Consistency)：事务前后，数据库的完整性约束不被破坏（如转账前后总金额不变）。
  3. 隔离性 (Isolation)：并发事务之间互不干扰，未提交的修改对其他事务不可见。
  4. 持久性 (Durability)：一旦事务提交，对数据的修改是永久性的，即使系统故障也不会丢失。

CAP 理论（分布式系统的抉择）

在大规模分布式环境下，三个特性无法同时满足，只能三选二。

三大特性定义

  1. 一致性 (Consistency)：所有节点在同一时间看到相同的数据。写操作后，任何节点读取到的都是最新值。
  2. 可用性 (Availability)：每个请求都能在合理时间内获得正常响应（不是错误或超时）。
  3. 分区容错性 (Partition Tolerance)：当网络分区（节点间通信失败）发生时，系统仍能继续运行。

“三选二”的必然性

在分布式系统中，P（分区容错性）是必须保证的基础，因此设计者通常在 C 和 A 之间权衡：

  • CA (放弃 P)：不拆分分区。传统的单机关系型数据库。不是严格意义上的分布式系统。
  • CP (放弃 A)：追求强一致性。网络故障时，为了保证数据一致，系统会拒绝服务或阻塞。典型应用：Redis、HBase、Zookeeper。
  • AP (放弃 C)：追求高可用性。网络故障时，节点使用本地旧数据提供服务。典型应用：12306 买票、淘宝订单、多数 NoSQL。

分布式 BASE 理论

BASE 是对 CAP 中一致性和可用性权衡的结果，是大型互联网分布式实践的总结。

核心内容

  1. 基本可用 (Basically Available)：在故障发生时，损失部分性能或功能。
    • 响应时间妥协：由 0.5s 增加到 2s。
    • 功能损失妥协：高峰期引导至“降级页面”。
  2. 软状态 (Soft State)：允许数据存在中间状态（数据同步延迟），且不影响系统整体可用性。
  3. 最终一致性 (Eventually Consistent)：经过一段时间后，所有副本数据最终都能达到一致状态。

ACID vs BASE

  • ACID：追求强一致性模型，适合传统金融交易。
  • BASE：通过牺牲强一致性获得高可用性，适合互联网高并发大规模系统。

综合案例：电商系统的 CAP 设计

电商系统不同模块对 CAP 的要求不同：

模块CAP 选择原因
用户/搜索/收藏夹AP短时间数据不一致不影响核心体验，高可用更重要。
订单/扣减库存CP / CA核心业务，必须保证数据准确，极端下可牺牲可用性。
商品上下架CP保证库存管理和状态的同步准确。
支付模块C 必选金钱相关必须强一致，AP 中 A 也很重要，通常由第三方保证。

小结

  • 分布式核心：在不可避免的网络分区（P）下，通过 BASE 理论牺牲强一致性（C），追求基本可用（BA）和最终一致性（E）。
  • 架构建议：不要盲目追求全系统强一致性，应根据业务场景（如电商不同模块）灵活配置不同的分布式策略。
]]> https://cooooing.github.io/uncategorized/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E3%80%8A%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Go%E8%AF%AD%E8%A8%80%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-Go%E8%AF%AD%E8%A8%80%E7%89%B9%E6%80%A7%E7%9A%84%E8%BF%9B%E9%98%B6%E7%9F%A5%E8%AF%86/ 2026-01-08T14:27:01.000Z 前言

这本书前四章篇幅超过三分之一
五到十二章共八章 和 十三到二十一共九章 大约各占三分之一
这章节内容量差的有点大

]]>

《深入理解Go语言》读书笔记 - Go 语言特性的进阶知识 2026-01-08T14:27:01.000Z 咕咕咕 第四章 深入理解 Linux 网络 I/O 复用并发模型

基本概念

流 (Stream)

在开发中,流通常具有以下三个特征:

  1. 可以进行 I/O 操作的内核对象。
  2. 数据传输的载体,如文件、管道、套接字(Socket)等。
  3. 数据的入口通过文件描述符 (fd) 来进行描述和识别。

I/O 操作

所有对“流”的读写行为都称为 I/O 操作。

  • 写阻塞:当传输媒介已满(如缓冲区满)时,继续写入会导致阻塞。
  • 读阻塞:当传输媒介为空(如没有新数据)时,尝试读取会导致阻塞。

阻塞等待 (Blocking)

在等待某个资源(如数据到达)时,程序执行逻辑完全暂停。

非阻塞忙轮询 (Non-blocking Busy Polling)

不间断地询问资源是否就绪。

阻塞与非阻塞对比

  1. 阻塞等待:
    • 优点:不占用 CPU 时间片,节省系统资源(小 G 可以去睡觉)。
    • 缺点:无法同一时刻处理多个 I/O 请求(同一时间只能等一个快递)。
  2. 非阻塞忙轮询:
    • 优点:宏观上能同时监控多个 I/O。
    • 缺点:极度浪费 CPU 资源和通信成本(反复打电话)。

解决阻塞等待缺点的办法

阻塞死等待的缺点

主要矛盾在于:无法在同一时刻解决多个 I/O 的读写请求。当处理一个请求时,其他请求会被拒绝或等待。

办法 1:多线程 / 多进程

  • 策略:通过增加资源,为每个 I/O 请求开启一个独立的线程或进程。
  • 局限性:
    • 资源消耗大(进程占内存高)。
    • 系统线程/进程数量有上限,无法应对超高并发。

办法 2:非阻塞忙轮询(伪代码实现)

  • 策略:通过 while(true) 循环不断遍历所有流。
  • 伪代码逻辑:
    1
    2
    3
    4
    5
    6
    7
    while(true) {
        for (stream : all_streams) {
            if (stream has data) {
                process(stream);
            }
        }
    }
  • 缺点:即便没有任何流有数据,CPU 也会不停地执行循环判断,导致 CPU 占用率过高。

办法 3:select (I/O 多路复用)

  • 原理:引入一个代理(管理员 select)。select 会阻塞等待,直到监听的多个流中至少有一个变得可读写。
  • 伪代码逻辑:
    1
    2
    3
    4
    5
    6
    7
    8
    while(true) {
        select(all_streams); // 阻塞点:直到有流就绪才返回
        for (stream : all_streams) { // 遍历全量流集合
            if (stream has data) {
                process(stream);
            }
        }
    }
  • 缺点:
    1. 全量返回:select 只告诉你有流就绪,但不告诉你是哪一个。开发者必须手动 for 循环遍历所有流来确认。
    2. 数量限制:select 能够监听的 fd 数量通常较小且固定(如 1024)。

办法 4:epoll (进阶版 I/O 多路复用)

  • 原理:升级版的代理模式。它不仅通知有数据到达,还会明确告知哪些流是可以操作的。
  • 伪代码逻辑:
    1
    2
    3
    4
    5
    6
    while(true) {
        active_streams = epoll_wait(all_streams); // 阻塞点
        for (stream : active_streams) { // 只遍历就绪的流
            process(stream);
        }
    }
  • 优点:
    1. 高效率:只返回就绪的流,减少了无效遍历。
    2. 高性能:监听的 I/O 数量上限由操作系统内存决定(非常大)。
    3. 系统开销小:在大规模并发下,性能优势极其明显。

epoll

epoll 是 Linux 下高性能的 I/O 多路复用技术,其核心优势在于只关心活跃连接,无需像 select/poll 那样遍历整个描述符集合。

epoll 的三步开发流程与内核原理

  1. 创建 epoll (epoll_create)
    • 接口:int epoll_create(int size);
    • 内核动作:在内核中创建一棵红黑树 (Red-Black Tree)。
    • 作用:红黑树的根节点对应 epfd,用于高效管理(增删改)数以万计的文件描述符 (fd)。
  2. 控制 epoll (epoll_ctl)
    • 接口:int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
    • 内核动作:向红黑树中添加、删除或修改 fd 及其对应的事件(如 EPOLLIN 读事件)。
  3. 等待 epoll (epoll_wait)
    • 接口:int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
    • 机制:这是一个阻塞调用。当内核检测到红黑树中有 fd 触发了 I/O 事件,会将其移入一个就绪链表,并抛给用户态。
    • 结果:开发者直接得到一个“活跃事件集合”,只需遍历这个集合即可处理,效率极高。

epoll 的触发模式

水平触发 (Level Triggered, LT) —— 默认模式

  • 机制:只要内核缓冲区中有数据,epoll_wait 就会不断通知用户。
  • 优点:安全。即使一次没读完,下次还会提醒,不容易丢数据。
  • 缺点:若数据未及时处理,会产生大量重复的内核到用户态的切换,影响性能。

边缘触发 (Edge Triggered, ET) —— 高性能模式

  • 机制:仅在状态发生变化时(如数据从无到有)通知一次。
  • 优点:高性能。减少了 epoll_wait 的触发次数。
  • 缺点:风险高。开发者必须一次性将缓冲区数据读完(通常配合非阻塞 I/O 使用循环读取),否则未读完的数据可能永远不会再通知。

Linux 常见网络 I/O 复用并发模型

模型 1:单线程 Accept(无 I/O 复用)

这是最原始的服务器模型,所有操作都在一个线程内线性执行。

  • 详细步骤:
    1. 初始化:主线程创建 ListenFd,绑定(Bind)IP和端口,调用 Listen 进入监听状态。
    2. 阻塞监听:主线程调用 accept() 函数,线程进入阻塞状态,死等客户端连接。
    3. 建立连接:客户端 Connect 请求到达,accept() 返回一个新的 ConnFd。
    4. 业务处理:主线程继续执行 read() 读取数据,进行逻辑计算,最后 write() 返回结果。
    5. 循环:业务处理完后,主线程回到步骤 2,处理下一个请求。
  • 致命伤:串行化。如果 Client 1 正在处理业务,Client 2 的连接请求会被挂起,无法响应。

image

模型 2:单线程 Accept + 多线程读写(无 I/O 复用)

为了解决模型 1 的串行问题,引入了多线程。

  • 详细步骤:
    1. 初始化:主线程创建 ListenFd 并监听。
    2. 主线程阻塞:主线程调用 accept() 等待连接。
    3. 分发任务:一旦 accept() 返回 ConnFd,主线程立即 pthread_create 创建一个新线程(或从池中取),并将 ConnFd 交给新线程。
    4. 并发执行:
      • 子线程:负责该 ConnFd 的全部生命周期(Read -> 业务 -> Write -> Close)。
      • 主线程:立即回到步骤 2,继续等待下一个客户端连接。
  • 优缺点:实现了并发,但 1:1 的线程开销在面对成千上万连接时,会因内存耗尽和 CPU 上下文切换频繁而崩溃。

image
image

模型 3:单线程多路 I/O 复用

不使用多线程,而是利用内核提供的 select/epoll 同时监控多个连接。

  • 详细步骤:
    1. 初始化:创建 ListenFd,并将其加入 epoll 监听集合。
    2. 事件阻塞:调用 epoll_wait(),线程进入阻塞,等待内核通知。
    3. 响应分发:当 epoll_wait 返回活跃 fd 集合时:
      • 如果是 ListenFd:执行 accept(),并将新生成的 ConnFd 也加入 epoll 集合。
      • 如果是 ConnFd:在当前线程执行 Read -> 业务处理 -> Write。
    4. 循环:处理完当前所有活跃 fd 后,回到步骤 2。
  • 局限:虽然能监听万级连接,但业务逻辑仍在主线程。如果某个业务逻辑(如复杂计算)太慢,会导致所有其他连接的 I/O 被阻塞。

image
image
image

模型 4:单线程多路 I/O 复用 + 业务工作池

将模型 3 的业务处理部分剥离出来,交给专门的线程池。

  • 详细步骤:
    1. 初始化:主线程创建 epoll,并启动一个 Worker Pool(工作线程池)。
    2. I/O 监听:主线程通过 epoll_wait 监控所有 fd。
    3. 读写分发:
      • 连接事件:主线程 accept。
      • 读事件:主线程 read 完整的数据包,封装成一个“任务(Task)”,丢进 Worker Pool 的任务队列。
    4. 并行计算:Worker 线程池中的某个空闲线程取出 Task,执行业务逻辑,计算出结果。
    5. 回写数据:Worker 线程处理完后,通知主线程(或直接)通过 ConnFd 将结果 write 给客户端。
  • 进步点:业务逻辑不再阻塞 I/O 监控。但所有读写操作仍由主线程一人承担,读写带宽存在瓶颈。

image
image
image
image

模型 5:单线程 I/O 复用 + 多线程 I/O 复用(连接线程池)—— 主流方案

这就是著名的 Reactor 多线程模型(如 Netty 的 Boss/Worker 机制)。

  • 详细步骤:
    1. 初始化:主线程(MainReactor)建立,同时开启 线程池(SubReactors),每个子线程都有自己的 epoll 实例。
    2. 主线程监听:主线程只负责监听 ListenFd,执行 accept。
    3. 连接分发:主线程将 accept 得到的 ConnFd 轮询分发给某个子线程(SubThread)。
    4. 子线程监听:子线程将分配到的 ConnFd 加入自己的 epoll 集合,负责该连接后续的所有读、写、业务。
  • 核心优势:读写并行通道从 1 扩展到了 N(线程数),极大地提升了吞吐量。

image
image
image

模型 5(进程版):多进程 I/O 复用 —— 稳定方案

典型代表:Nginx。

  • 详细步骤:
    1. Master 初始化:主进程创建 ListenFd,但不 accept。
    2. Fork 进程池:创建多个 Worker 进程。
    3. 竞争 Accept:
      • 所有 Worker 进程通过 Accept_Mutex(互斥锁) 或内核的 SO_REUSEPORT 竞争处理新连接。
      • 胜出的 Worker 执行 accept 得到 ConnFd。
    4. 独立监听:该 Worker 进程将 ConnFd 加入自己的 epoll 集合,独立处理读写业务。
  • 特点:进程间内存隔离,稳定性极强,一个 Worker 挂了不影响整体。

image
image
image

模型 6:单线程 I/O 复用 + 多线程 I/O 复用 + 临时多线程

这是模型 5 的极端增强版。

  • 详细步骤:
    1. 前三步同模型 5(主线程分发给子线程)。
    2. 动态触发:子线程在 epoll_wait 收到某个 ConnFd 的读写事件。
    3. 即时开辟:子线程不亲自读写,而是立即开启(或调度)一个临时线程来专门处理这次读写。
    4. 任务结束:读写和业务完成后,该临时线程销毁或回池。
  • 评价:这是理论上的“最大并发”,但在目前的硬件下,频繁创建/调度线程的开销远大于其带来的并发收益,容易导致系统负载过高,属于“过度设计”。

总结对比表

模型并发点核心角色适用场景
模型 1无主线程教学示例
模型 2业务+读写每连接一线程低频长连接
模型 3I/O 监听单 epoll简单请求(如 Redis)
模型 4业务逻辑epoll + Worker池逻辑复杂的计算型服务
模型 5I/O 读写 + 业务多 epoll (Reactor)主流高性能服务器
模型 6全流程极致并行动态线程极高性能的特殊硬件环境
]]> https://cooooing.github.io/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E3%80%8A%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Go%E8%AF%AD%E8%A8%80%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Linux%E7%BD%91%E7%BB%9CIO%E5%A4%8D%E7%94%A8%E5%B9%B6%E5%8F%91%E6%A8%A1%E5%9E%8B/ 2026-01-08T12:22:26.000Z <]]> 《深入理解Go语言》读书笔记 - 深入理解 Linux 网络 I/O 复用并发模型 2026-01-08T12:22:26.000Z 咕咕咕 第三章 Go 语言内存管理洗髓经

内存为什么需要管理

当存储的东⻄越来越多,也就发现物理内存的容量依然不够用,提高对物理内存的利用率和合理地分配内存,管理就变得非常重要了。

  1. 操作系统会对内存进行非常详细的管理。
  2. 基于操作系统的基础上,不同语言的内存管理机制也应运而生,有一些语言并没有提供自动的内存管理模式,有的语言却提供了自身程序的内存管理模式。

为了降低内存管理的难度,像 C、C++ 这样的编程语言会完全将分配和回收内存的权限交给开发者,而Rust则通过生命周期限定开发者对非法权限内存的访问并以此来自动回收,因而并没有提供自动管理的一套机制。
但是像 Go、Java、Python 这类为了完全让开发者关注代码逻辑本身, 语言层提供了一套管理模式。

在理解 Go 语言层内存管理之前,应该先了解操作系统针对物理内存提供了哪些管理方式。

操作系统是如何管理内存的

对计算机来讲内存真正的载体是物理内存条,这个是实打实的物理硬件容量,所以在操作系统中定义的这部分容量叫物理内存。

物理内存的布局实际上就是一个内存大数组

每个元素都会对应一个地址,称为物理内存地址。CPU 在运算的过程中,如果需要从内存中取1字节的数据,就需要基于这个数据的物理内存地址去运算,而且物理内存的地址是连续的,可以根据一个基准地址进行偏移来取得相应的连续内存数据。
一个操作系统是不可能只运行一个程序的,这个大数组物理内存势必要被多个程序分成多份,供每个程序使用,但是程序是活的,一个程序可能一会需要 1MB 的内存,一会又需要 1GB 的内存。
操作系统只能取这个程序允许的最大内存极限来将内存分配给这个进程,但这样会导致每个进程都会多要去一部分内存,而这些多要的内存却大概率不会被使用。
当 N 个程序同时使用同一块内存时,产生读写的冲突也在所难免。这样就会导致这些昂贵的 物理内存条,几乎运行不了几个程序,内存的利用率也就提高不上来。

这就引出了操作系统的内存管理方式,操作系统提供了虚拟内存来解决这件事。

虚拟内存

虚拟内存地址是基于物理内存地址之上凭空而造的一个新的逻辑地址,而操作系统暴露给用户进程的只是虚拟内存地址,操作系统内部会对虚拟内存地址和真实的物理内存地址建立映射关系,来管理地址的分配,从而使物理内存的利用率提高。

这样用户程序(进程)只能使用虚拟的内存地址获取数据,系统会将这个虚拟地址翻译成实际的物理地址。
这里每个程序统一使用一套连续虚拟地址,例如0x00000000~0xffffffff。从程序的⻆度来看,它觉得自己独享了一整块内存,并且不用考虑访问冲突的问题。系统会将虚拟地址翻译成物理地址,从内存上加载数据。

但如果仅仅把虚拟内存直接理解为地址的映射关系,那就低估虚拟内存的作用了。

虚拟内存的目的是解决以下几件事:

  1. 物理内存无法被最大化利用。此外还实现了“读时共享,写时复制”的机制,“写时复制”(Copy-on-Write)多见于 fork() 子进程或加载动态链接库时。它确实让多个虚拟地址指向同一物理地址,只有在数据被修改时才分配新物理页,极大节省了空间。
  2. 程序逻辑内存空间使用独立。进程隔离。每个进程都以为自己拥有连续的地址空间,互不干扰,提高了系统的安全性。
  3. 内存不够,继续虚拟磁盘空间。Swap(交换分区)。虚拟内存将暂时不用的数据置换到磁盘上,让有限的物理内存能运行更大的程序。

MMU 内存管理单元

虚拟地址是如何映射到物理内存地址上的呢?
如果采用简单的线性固定映射,物理内存的碎片化将导致无法为每个进程分配连续的地址空间。
为了解决这个问题,操作系统引入了页表映射机制,并由硬件层面的 MMU(Memory Management Unit,内存管理单元) 负责具体执行。
MMU 集成在 CPU 内部,其核心逻辑如下:

image

这种设计使得进程可以拥有独立且连续的虚拟空间,而底层的物理内存则可以被离散、动态地高效利用。

虚拟内存本身怎么存放

虚拟内存本身是通过一个叫⻚表(Page Table)的东⻄实现的。

  1. ⻚
    ⻚是操作系统中用来描述内存大小的一个单位名称。一个⻚的含义是大小为 4KB(1024×4=4096字节)的内存空间。操作系统对虚拟内存空间是按照这个单位来管理的。
  2. ⻚表
    ⻚表实际上就是⻚的集合,即基于⻚的一个数组。⻚只表示内存的大小,而⻚表条目(PTE)才是⻚表数组中的一个元素。

image

虚拟内存的实现方式,大多数是通过⻚表实现的,实则是一个数组。
操作系统虚拟内存空间被分成一⻚一⻚来管理,每⻚的大小为 4KB(当然这是可以配置的,不同操作系统不一样)。
磁盘和主内存之间的置换也是以⻚为单位来操作的。4KB 算是通过实践折中出来的通用值,太小了会出现频繁置换,太大了又会浪费内存。

image

⻚是一次读取的内存单元,但是真正到虚拟内存寻址的是PTE,也就是⻚表中的一个元素。
可以看出每个 PTE 是由一个有效位和一个物理⻚号或者磁盘地址组成,有效位表示当前虚拟⻚是否已经被缓存在主内存中(或者CPU的高速缓存Cache中)。

虚拟⻚为何会有是否已经被缓存在主内存中一说?
虚拟⻚表(简称⻚表)虽然作为虚拟内存与物理内存的映射关系,但是本身也需要存放在某个位置上,所以自身也占用一定内存,所以⻚表本身也被操作系统放在物理内存的指定位置。
CPU 把虚拟地址给 MMU,MMU 去物理内存中查询⻚表,得到实际的物理地址。当然 MMU 不会每次都去查询,它自己也有一份缓存,叫作 快表 Translation Lookaside Buffer(TLB),是为了加速地址翻译。

image

内存访问完整流程:当 CPU 需要读取一个虚拟地址的数据时,遵循以下逻辑路径:

  1. 请求阶段:CPU 发出虚拟地址请求给 MMU。
  2. 一级缓存查找 (TLB):MMU 首先在 TLB 中查找。
    • 命中 (Hit):直接获取物理地址,返回给 CPU。
    • 缺失 (Miss):进入下一步,查询主存页表。
  3. 主存查找 (Page Table):MMU 访问物理内存中的页表。
    • 有效位 = 1:查询成功,获取物理地址,并更新到 TLB 中备用。
    • 有效位 = 0:触发 缺页异常 (Page Fault),此时操作系统介入,从磁盘加载数据到内存。

根据 PTE 的状态,虚拟内存空间中的页可以归纳为以下三类:

状态有效位描述
未分配 (Unallocated)0进程未申请该段地址,不占用内存,也不占用磁盘。
已分配未缓存 (Uncached)0进程已申请,数据在磁盘上,但尚未加载到物理内存。
已缓存 (Cached)1数据已在物理内存中,虚拟地址已映射到具体的物理页。

CPU 内存访问过程

在访问开始前,CPU 生成的虚拟地址 (VA) 被拆分为两个部分:

image

正常访问流程(命中路径:Steps 1-9)

这是最快的一条路径,完全由硬件(CPU, MMU, TLB)完成:

  1. 指令发出:CPU 寄存器加载指令,生成虚拟地址。
  2. TLB 快速查找:MMU 提取 VPN,首先在 TLB (快表) 中查询对应的 PTE (页表项)。
  3. 地址翻译:
    • MMU 获取 PTE 中的 PPN (Physical Page Number,物理页号)。
    • 关键组合逻辑:物理地址 (直接串联,不需要加法运算)。
  4. 内存访问:CPU 通过生成的物理地址 (PA) 直接访问主存并获取数据。

异常处理流程(缺页路径:Steps 10-14)

当 PTE 有效位为 0 时,说明数据不在内存中,触发“缺页异常”:

性能核心指标:命中率 (Hit Rate),内存访问的效率极大程度上取决于命中率。

场景耗时级别影响因素
TLB 命中纳秒 (ns)程序局部性(数据的连续性)
主存页表命中几十纳秒内存访问延迟
缺页异常毫秒 (ms)磁盘 I/O 速度、物理内存容量

缺页处理涉及磁盘访问,其速度比内存慢 10,000 倍以上。如果物理内存不足,系统会频繁在内存与磁盘间交换数据,这种现象称为 “内存颠簸” (Thrashing),会导致程序性能断崖式下跌。

内存的局部性

什么是局部性?

局部性是指程序在执行时,往往倾向于引用最近引用过的数据,或者引用与最近引用过的数据在空间地址上相邻的数据。

局部性与系统性能的关系

现代计算机体系结构利用局部性特征设计了多级缓存(Cache)和缓冲层:

缓存的有效性完全依赖于程序的局部性。局部性越好,缓存命中率越高,程序运行越快;反之则会导致频繁的缺页或缓存失效。
所以在设计程序或者业务的时候应该多考虑增强程序局部性的特征,这样的程序执行起来会更快。

实验分析:步长 (Step) 对性能的影响

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
package test

import "testing"

func CreateSource(len int) []int {
nums := make([]int, 0, len)
for i := 0; i < len; i++ {
nums = append(nums, i)
}
return nums
}

// 遍历数组,将每个值都设置为4,但使用 step 规定每次遍历的跨度
func Loop1(nums []int, step int) {
l := len(nums)
for i := 0; i < step; i++ {
for j := i; j < l; j += step {
nums[j] = 4 // 访问内存 并写入值
}
}
}

// Loop1 step 取1时的等价代码
func Loop2(nums []int) {
l := len(nums)
for i := 0; i < l; i++ {
nums[i] = 4
}
}

// step 跨度越小,则表示访问 nums 相邻内存的局部性越好,step 越大则相反。

func BenchmarkLoopStep1(b *testing.B) {
source := CreateSource(10000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
Loop1(source, 1)
}
}
func BenchmarkLoopStep2(b *testing.B) {
source := CreateSource(10000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
Loop1(source, 2)
}
}
func BenchmarkLoopStep4(b *testing.B) {
source := CreateSource(10000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
Loop1(source, 4)
}
}
func BenchmarkLoopStep8(b *testing.B) {
source := CreateSource(10000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
Loop1(source, 8)
}
}
func BenchmarkLoopStep16(b *testing.B) {
source := CreateSource(10000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
Loop1(source, 16)
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
goos: windows
goarch: amd64
pkg: script/test
BenchmarkLoopStep1
BenchmarkLoopStep1-20       831439      1291 ns/op
BenchmarkLoopStep1-20       972572      1225 ns/op
BenchmarkLoopStep1-20       974499      1227 ns/op
BenchmarkLoopStep2
BenchmarkLoopStep2-20       557046      2130 ns/op
BenchmarkLoopStep2-20       555843      2160 ns/op
BenchmarkLoopStep2-20       572308      2096 ns/op
BenchmarkLoopStep4
BenchmarkLoopStep4-20       309943      4200 ns/op
BenchmarkLoopStep4-20       293374      4277 ns/op
BenchmarkLoopStep4-20       301840      4022 ns/op
BenchmarkLoopStep8
BenchmarkLoopStep8-20       148774      7666 ns/op
BenchmarkLoopStep8-20       156615      7872 ns/op
BenchmarkLoopStep8-20       155821      7639 ns/op
BenchmarkLoopStep16
BenchmarkLoopStep16-20      118401     10422 ns/op
BenchmarkLoopStep16-20      110496     10108 ns/op
BenchmarkLoopStep16-20      121336     10222 ns/op
PASS
  1. BenchmarkLoopStep1-20 中的 20 表示 GOMAXPROCS(线程数)为 20,这个在此处不需要过度关心。
  2. 831439 表示一共执行了 831439 次,即代码中 b.N 的值,这个值不是固定不变的。实际上是通过循环调用 831439 次 Loop() 函数得到的最后性能结果。
  3. 1291 ns/op 表示平均每次执行 Loop() 函数所消耗的时间是 1291 ns。

通过上述结果可以看出,随着 Step 参数的增加,内存访问的局部性就越差,执行 Loop() 的性能也就越差。
如果要设计出一个更加高效的程序,则提高代码的局部性访问是非 常有效的程序性能优化手段之一。

思考题:Go GPM 调度器中的局部性:为什么一个 G (Goroutine) 开辟的子 G 优先放在当前的本地 P 队列中,而不是其他 P 队列?

这是 “调度局部性” 的体现,因为:

  1. 数据局部性:子 G 往往会继承或共享父 G 的数据(闭包捕获、Channel 通讯)。如果它们在同一个 P(即同一个 M/线程)上运行,这些数据更有可能已经存在于该 CPU 的 L1/L2 缓存中,避免了跨核心同步的开销。
  2. 减少竞争:每个 P 拥有本地队列,M 访问本地队列不需要加全局锁。如果新 G 总是随机分配,会产生大量的锁竞争和上下文切换。
  3. 栈与状态预热:同一个 P 上的任务切换,可以最大限度地保持 CPU 流水线和分支预测器的“热度”。

日常开发中如何优化程序性能?

伪共享是多核编程中一种隐蔽的性能杀手。它发生在多个 CPU 核心同时修改同一个缓存行 (Cache Line) 中的不同变量时。虽然从逻辑上看,多个线程操作的是互相独立的变量,但在底层硬件看来,它们在争夺同一块缓存区域,导致缓存系统不断失效,性能急剧下降。

为了提高效率,CPU 并不是按字节从内存读取数据的,而是以缓存行为单位。在现代 x86 和 ARM 架构中,一个缓存行通常是 64 字节。
当你读取一个 int64 变量时,CPU 会顺便把它相邻的另外 7 个 int64 变量也加载进缓存行。
缓存一致性协议 (MESI):如果核心 A 修改了某个缓存行的数据,核心 B 缓存中对应的该行就会被标记为“无效”。核心 B 下次访问时必须重新从主存(或 L3 缓存)加载。

假设有两个全局变量 A 和 B(例如两个计数器),它们在内存中是紧挨着的,正好被加载到了同一个 64 字节的缓存行中:
核心 1 正在频繁修改变量 A。
核心 2 正在频繁修改变量 B。
由于硬件以缓存行为单位管理一致性,即使核心 2 根本没动过 A,但因为核心 1 修改了该行,核心 2 的整个缓存行都会失效。
两个核心就像在玩一场“接力赛”,不断地让对方的缓存失效,迫使数据在核心之间来回“颠簸”(Ping-ponging)。

真共享:多个线程真的需要访问同一个变量,锁竞争是不可避免的。
伪共享:多个线程访问的是完全无关的变量,仅仅是因为它们在内存位置上靠得太近,被“误杀”了。

如何用 Go 语言实现手动内存管理与内存池设计(简略,不带书中 CGO 代码)

在高性能场景(如网关、游戏服务器)中,Go 原生的 GC(垃圾回收)扫描可能会带来延迟抖动。为了解决这个问题,我们可以手动管理内存。

Cgo 与指针逻辑

手动管理的核心是绕过 Go Runtime,直接与内核对话。

这是所有高性能内存库(包括 Go 源码本身)处理连续内存块偏移的唯一标准方式。

明白,这节内容确实需要适度的深度,因为它不仅是代码实现,更是理解 Go 内存管理(TCMalloc)的逻辑跳板。

以下是为您重新整理的 3.4 节:手动内存管理与内存池设计 深度精简笔记。我们跳过语法细节,重点拆解地址运算、状态转换和池化架构。

Buf (内存缓冲单元)

Buf 是对原始内存块的封装。它的精髓在于三个核心索引对地址空间的划分。

关键内存操作

  1. 逻辑弹出 (Pop):
    不涉及数据移动。只需 head += n。这意味着前 n 个字节在逻辑上被“删除了”,极大地提高了处理速度。
  2. 内存平移 (Adjust):
    • 由于频繁 Pop,head 会不断右移,导致前端出现大量“过期数据”占据空间。
    • 调用 memmove(支持内存重叠的拷贝),将 [head : length] 之间的数据整体搬运回 0 偏移位置,并将 head 重置为 0。

这是解决内存碎片、提高空间利用率的典型手段。

BufPool (内存池管理)

如果每次 Buf 申请都找内核要(malloc),系统调用的成本太高。

分级管理 (Size-Classing)

内存池不是一个大仓库,而是按规格分成的多个“专柜”:

借与还 (Alloc & Revert)
  1. Alloc (分配):
    • 根据所需大小计算出所属的 Bucket(桶)。
    • 从链表头部摘除一个 Buf (LIFO 原则)。如果链表为空,则触发 malloc 补充。
  2. Revert (回收):
    • 调用 Clear():仅仅是将 head 和 length 归零,不释放物理内存。
    • 挂回链表:将 Buf 插回对应 Bucket 链表的头部,等待下一次分配。

Zbuf (安全适配层)

为了防止业务代码直接操作指针,最后封一层 Zbuf:

TCMalloc 内存管理

TCMalloc (Thread Cache Malloc) 是 Go 内存管理设计的逻辑蓝图。

TCMalloc 核心理念

全局共享内存池的缺陷
传统的内存池(如之前实现的 BufPool)通常是所有线程共享的。

缺点:所有线程申请内存都要与全局池交互,为了保证并发安全,必须加互斥锁。在高并发下,锁竞争会成为严重的性能瓶颈。

TCMalloc 的改进:ThreadCache
TCMalloc 为每个线程预分配独立缓存。其结构包含三层:

  1. ThreadCache (线程缓存):每个线程独立维护,申请内存时无需加锁,性能极高。
  2. CentralCache (中心缓存):所有线程共享。当 ThreadCache 内存不足时,从这里补给;内存过多时,退还给这里。由于共享,访问需加锁。
  3. PageHeap (页堆):最底层的全局共享缓存,负责中大对象分配及向操作系统申请内存。

image

TCMalloc 基础结构

在深入流程前,必须理解三个基本名词:

  1. Page (页):TCMalloc 的最小存储单元。默认为 8KB。整个虚拟内存被划分为数万个同等大小的 Page。
    • 优点:通过内存地址和固定算法,可以快速算出该地址属于哪个 Page ID。
  2. Span (内存块):多个连续 Page 的集合。
    • TCMalloc 以 Span 为单位向系统申请内存。
    • Span 记录了起始 Page 编号 (Start) 和连续 Page 的数量 (Length)。
    • 多个 Span 以双向链表形式组织,方便管理。
  3. Size Class (尺寸等级):
    • 对于小对象,TCMalloc 将其划分为多个刻度(如 8B, 16B…)。
    • 每个 Size Class 对应一个由多个等空间 Page 组成的 Span。

image

TCMalloc 缓存结构

ThreadCache

image

CentralCache

image

PageHeap

image

对象分配流程

小对象分配流程 (≤ 256KB)
  1. 计算申请内存对应的 SizeClass。
  2. 访问 ThreadCache 的 FreeList。
  3. 命中:返回第一个空闲对象,流程结束。
  4. 未命中:加锁请求 CentralCache。
  5. CentralCache 若有空闲,返回一批对象给 ThreadCache,并将其中一个返回给线程。
  6. CentralCache 若无空闲,向 PageHeap 申请 Span,拆分成对应规格填入 CentralFreeList。

image

中对象分配流程 (256KB ~ 1MB)
  1. 绕过 ThreadCache 和 CentralCache,直接请求 PageHeap。
  2. PageHeap 在 128 个 Page 以内的小 Span 链表中向上取整查找。
  3. 若对应的 个 Page 链表为空,则继续向下遍历(最多到 128),找到第一个非空链表。
  4. 切分:将找到的 个 Page 拆分为 (返回用户)和 (退还给 PageHeap 对应链表)。

image

大对象分配流程 (> 1MB)
  1. 直接向 PageHeap 发起申请。
  2. 计算所需 Page 数量 。
  3. 在 Large Span Set 中通过最佳适配算法找到不小于 的最小 Span 。
  4. 若找不到,向系统申请新内存并重试。
  5. 切分:返回 个 Page,剩余的 退还。若 退回 Large Set,否则退回小 Span 链表。

一些问题

中对象和大对象不会在 ThreadCache 和 CentralCache 中缓存吗

在 TCMalloc 的设计中,ThreadCache 和 CentralCache 仅服务于小对象(≤ 256KB)。
小对象靠“缓存”换取并发性能,中大对象靠“页管理”换取空间利用率。

为什么中/大对象不进 Cache?
  1. 内存碎片与利用率
    ThreadCache 和 CentralCache 的核心是 Size Class(尺寸分级)。
    • 小对象:规格固定(如 8B, 16B),在一个 Span 里可以切分出成百上千个小格子。即便某个格子空闲,浪费的空间也极小。
    • 中/大对象:如果也按固定规格缓存(比如专门开辟一个 1MB 的缓存位),一旦这个位置长期不被使用,就会造成严重的内部碎片。对于大额内存,直接按需向 PageHeap 申请“页(Page)”级别的内存块(Span)更加灵活高效。
  2. 缓存命中率与锁开销
    • 小对象:申请频率极高。如果每次都找 PageHeap 加锁申请,性能会因锁竞争崩溃,所以必须要在 ThreadCache 里搞“私产”。
    • 大对象:申请频率相对较低。直接去 PageHeap 加锁申请带来的性能损耗,相比于其庞大的内存分配动作,是可以接受的。

内存分配路径对比

对象类别大小区间第一站第二站终点站 (数据源)
小对象ThreadCache (无锁)CentralCache (有锁)PageHeap (有锁)
中对象PageHeap (小 Span 链表)-PageHeap / OS
大对象PageHeap (Large Set)-PageHeap / OS
PageHeap 是如何处理中/大对象的?

由于中/大对象不经过前两层,PageHeap 承担了全部的重任,但它的处理逻辑也有精细的区别。

中对象:利用“页刻度”链表

PageHeap 内部维护了 128 个单向链表。

对于中对象,PageHeap 会尝试从最匹配的链表中直接摘取一个 Span。

当对象超过 128 个 Page 时,链表就不够用了。

Go 语言堆内存管理

Go 的内存管理在逻辑上分为三层,与 TCMalloc 极其相似,但与 Go 的调度模型(GPM)进行了深度耦合。

image

核心概念与单位

Go 延续并细化了 TCMalloc 的 Page、Span 等概念。

  1. Page (页):与 TCMalloc 的 Page 一致。Go 与虚拟内存交互的最小单位,固定为 8KB。
  2. mSpan:与 TCMalloc 中的 Span 一致。内存管理的基本单元,由一组连续的 Page 组成。
  3. Object (对象):
    • 定义:mSpan 初始化时会被切割成多个 Object。它是内存分配给应用的最终基本单元。
    • 关系:NumOfObject = mSpanSize / ObjectSize。
      image
  4. Size Class:Object 大小的级别(如等级 1 对应 8B,等级 2 对应 16B …)。
  5. Span Class (Go 额外定义):
    • 每个 Size Class 对应两个 Span Class。
      image
    • scan:存放包含指针的对象(GC 需扫描)。
    • noscan:存放不含指针的对象(GC 无需扫描,提速)。
    • 计算公式:SpanClass = SizeClass << 1 | (noscan ? 1 : 0)。
  6. Size Class 明细 (66个级别):
    Go 固定划分了 66 种规格。其中 Max Waste (最大浪费比) 的计算是优化的关键。
    • 浪费来源:Object 尺寸对齐产生的浪费 + mSpan 末尾无法整除产生的浪费(tail waste)。

Todo

MCache (本地缓存)

MCentral (中心缓存)

image

MHeap (全局堆)

image
image

对象分配流程

Tiny 微小对象分配流程 ( ≤ 16B )

为了解决极小对象(如 bool)频繁申请导致的浪费,Go 引入了 Tiny 分配器。

image

小对象分配流程 ( 16B ~ 32KB )
  1. 计算对象 Size,匹配对应的 Size Class。
  2. 定位 Span Class(考虑是否有指针)。
  3. 尝试从 MCache 提取 Object。
  4. 若 MCache 耗尽,向 MCentral 申请一个 mSpan。
  5. 若 MCentral 耗尽,向 MHeap 申请 Page 组成新的 mSpan。

image

大对象分配流程 ( > 32KB )

大对象不经过 MCache 和 MCentral,直接由 MHeap 分配。

  1. 计算所需 Page 数量。
  2. 绕过缓存,直接向 MHeap 的 Arenas 申请。
  3. 若 Arenas 不足,向操作系统(OS)申请新的虚拟内存。

image

]]> https://cooooing.github.io/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E3%80%8A%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Go%E8%AF%AD%E8%A8%80%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-Go%E8%AF%AD%E8%A8%80%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86/ 2026-01-04T12:09:23.000Z 第三章 Go 语言内存管理洗髓经

第二章 Go 语言混合写屏障的 GC 全场景分析

垃圾回收(Garbage Collection,GC)是编程语言中提供的自动内存管理机制,GC 能够自动释放不需要的内存对象,让出存储器资源,其释放过程中无须程序员手动执行。
GC 机制在现代很多编程语言得到支持,针对 GC 性能的优劣程度,也是不同语言之间的对比指标之一。

Go 语言在 GC 的演进过程中也经历了几次重大改变,如下:

  1. Go V1.3之前的STW的标记和清除(SWT Mark Sweep)。
  2. Go V1.5的三色并发标记法。“强-弱”三色不变式、插入屏障、删除屏障。
  3. Go V1.8混合写屏障机制。

Go V1.3 标记-清除算法

此算法主要有两个步骤:

  1. 标记(Mark Phase)。
  2. 清除(Sweep Phase)。

找到需要被清除的内存数据,然后一次性清除。

标记清除(Mark and Sweep)算法的详细过程

  1. 暂停程序业务逻辑,对可达和不可达的对象进行分类,然后做上标记。
  2. 开始标记。程序找出它所有可达的对象,并做上标记。
  3. 标记完了之后,开始清除未标记的对象。
    Mark and Sweep 算法在执行的时候,需要程序暂停,即 STW(Stop The World)。在 STW 的过程中,CPU不执行用户代码,全部用于垃圾回收。
    这个过程影响很大,所以 STW 也是一些回收机制最大的难题和希望优化的点。
  4. 停止暂停,让程序继续运行,然后重复这个过程,直到 Process 程序生命周期结束。

标记清除算法的缺点

标记清除算法简单明了,但是也有非常严重的问题:

  1. STW 让程序暂停,所以程序会出现卡顿。
  2. 标记需要扫描整个 Heap。
  3. 清除数据会产生 Heap 碎片。

Go V1.3 版本执行 GC 的基本流程就是首先启动 STW,使程序暂停,然后执行标记,再执行数据回收,最后停止STW。
全部的 GC 时间都是包裹在 STW 范围之内的,Go V1.3 做了简单的优化,将停止 STW 的步骤提前,缩小 STW 暂停的时间范围。
将 Sweep 清除的步骤放到停止 STW 之后执行,因为这些对象已经是不可达对象了,不会出现回收写冲突等问题。

但是无论怎么优化,这个算法都会暂停整个程序。

Go V1.5 三色标记法

三色标记法 GC 过程和其他用户 Goroutine 可并发运行,但根对象扫描仍然依赖 STW,这是该版本 GC 停顿的主要来源。

对象的初始颜色状态

在一次 GC 周期开始时:
堆中所有存活对象在逻辑上均视为“白色”

白色表示:当前 GC 轮次中尚未被发现为可达对象

需要注意的是:这里的“程序”并不是一个抽象整体,而是由一组 GC Root 组成,包括:

从 GC 的视角看,“程序是否可达”本质上等价于“是否能从 Root 出发访问到”。

GC 开始:STW 根扫描阶段

Stop-The-World(第一次)

在 Go 1.5 中,三色标记开始前必须先进入 STW,原因是:

Root 扫描与初始标记

在 STW 状态下,GC 执行以下操作:

  1. 扫描所有 GC Root

  2. 将从 Root 直接可达的对象:

    • 从 白色标记为灰色
    • 放入 灰色标记队列(mark queue)

这一步是:

例如:Root 直接引用对象 1 和对象 4 ,则对象 1、对象 4 被标记为灰色

启用写屏障并恢复世界

Root 扫描完成后:

这一阶段的 STW 时间与:goroutine 数量、栈大小 强相关

并发三色标记阶段(Concurrent Mark)

灰色对象扫描规则

GC worker 与用户 goroutine 并发运行,不断执行以下过程:

  1. 从灰色标记队列中取出一个灰色对象
  2. 扫描该对象的所有指针字段
  3. 对每一个被引用的对象:
    • 若为白色 → 标记为灰色,并加入灰色队列
  4. 当前灰色对象扫描完成后:
    • 标记为黑色
    • 从灰色集合移动到黑色集合

例如:

重复扫描直到灰色集合为空

上述过程不断重复:

直到:

此时,内存中的对象只剩下两种颜色:

并发正确性的保证:Go 1.5 的写屏障

在并发标记期间,用户程序仍可能修改对象引用关系,例如:

为解决该问题,Go 1.5 引入 写屏障机制:

在指针写操作时:

写屏障的作用是:

防止在并发标记过程中遗漏任何逻辑上可达的对象

代价是:

标记结束确认:Mark Termination(STW)

当并发标记完成后,会进行下面的操作。

Stop-The-World(第二次)

Go 1.5 会再次进入 STW,用于:

  1. 确认灰色队列为空
  2. 确保没有遗漏的标记工作
  3. 关闭写屏障

这一次 STW 相对较短,但仍然存在。

清除阶段(Sweep)

并发清除白色对象

GC 进入清除阶段:

清除阶段是 并发执行的,不再 STW。

Go V1.5 的屏障机制

并发标记下的问题本质:三色不变式

在 并发三色标记阶段,用户程序(mutator)仍在运行,可能发生:

如果不加限制,会直接导致:仍被程序使用的对象,被错误回收

为此,Go 1.5 通过 三色不变式 和 写屏障 来约束并发行为。

并发标记下的问题本质:三色不变式

强三色不变式

特征:

弱三色不变式

特征:

插入屏障(Insertion Barrier)

当执行指针写入操作:

1
A.field = B

若:A 为黑色, B 为白色。则将 B 标记为灰色

插入屏障 仅用于堆对象 不作用于栈对象
原因:栈写频繁,屏障成本不可接受

栈上新增的白色对象引用,无法被插入屏障捕获

因此,在 Go 1.5 中:

并发标记结束后,必须对栈进行一次 STW 重新扫描,以防止栈中仍存在“黑 → 白”的未保护引用

这正是 Go 1.5 GC 停顿的主要来源之一。

删除屏障(Deletion Barrier)

当一个对象引用被删除或覆盖时:

1
2
old = A.field
A.field = nil

若 old 为白色或灰色:将 old 标记为灰色

保证:即使引用被删除或覆盖,原可达对象仍能在本轮 GC 中被扫描

被删除但已标灰的对象:可能在本轮 GC 中存活,只能在下一轮 GC 中回收

删除屏障 牺牲回收精度,换取并发安全性

Go V1.8 的混合写屏障

在 Go 1.5 中:

  1. 插入屏障 保证强三色不变式,结束阶段必须 STW 重新扫描栈
  2. 删除屏障 无需栈 Re-scan ,GC 回收精度低(快照语义)

Go 1.8 引入了混合写屏障机制(Hybrid Write Barrier),避免了对栈 Re-scan(重新扫 描)的过程,这也极大地减少了 STW 的时间,同时结合了插入写屏障和删除写屏障两者的优点

混合写屏障(Hybrid Write Barrier)规则

把“栈”在 GC 语义上直接视为“永远安全的黑色区域”,通过“堆上的写屏障 + 初始栈全黑”,同时覆盖插入与删除两种风险。

  1. GC 开始时,一次性 STW 扫描栈。所有栈可达对象全部标记为黑色,栈对象在整个 GC 期间都被视为安全,不会对栈进行第二次扫描。
  2. GC 期间,栈上新创建的对象直接为黑色。新对象如果分配在栈上,直接视为黑色。栈对象永远不会成为白色
  3. 堆上“删除引用” → 被删除对象标记为灰色。
  4. 堆上“新增引用” → 被新增对象标记为灰色。

混合写屏障实际上满足的是一种变形的弱三色不变式。

写屏障只作用于堆的写操作,栈写入永远不出发屏障。

一些理解上的问题

Go 的 GC 回收哪些内存?栈和堆分别由谁管理?
内存类型管理者回收方式
栈编译器 + runtime函数返回直接回收
堆GC标记-清除

栈帧随着函数调用/返回自动创建和销毁,回收成本极低,不适合也不需要 GC 介入。

为什么栈对象“不会被 GC 回收”,却仍然参与 GC?

GC 需要判断 堆对象 是否还能被 栈或全局变量间接引用,以便确定堆对象是否可以被回收。

混合写屏障带来了什么,代价是什么?

混合写屏障通过 对堆做插入屏障和删除屏障,对栈特殊处理不做屏障。

好处:

缺点:

一些源码

参考 Go 版本为 1.25.5

整体流程

  1. gcStart() 是 GC 的入口
  2. 防止 GC 在“不安全的执行上下文”(gp == mp.g0 || mp.locks > 1 || mp.preemptoff != "")中启动
    • gp == mp.g0 当前在 system stack
    • mp.locks > 1 持有 runtime 锁
    • mp.preemptoff != "" 明确禁止抢占
  3. 补扫 sweep,sweepone(),扫描并释放上一轮 GC 未 sweep 完的 span ,保证 heap 状态在 GC 开始前“干净”
  4. 获取“GC 启动权”,防止多个 goroutine 同时启动 GC
  5. STW
    • stw = stopTheWorldWithSema(stwGCSweepTerm) 停止所有 P ,停止所有 G ,建立 STW 边界
      • casGToWaitingForSuspendG(getg().m.curg, _Grunning, waitReasonStoppingTheWorld) 把“当前发起 STW 的 goroutine”标记为 _Gwaiting。允许 GC mark worker 扫描它的栈,tracer 观察它的状态,GC 和 调度器 的交叉点,防止死锁。
      • sched.stopwait = gomaxprocs;sched.gcwaiting.Store(true);preemptall() stopwait=GOMAXPROCS,设置全局 GC 停顿标志,向所有的 P 发起抢占。
      • for sched.stopwait > 0 { ... 等待所有 P 停止,周期性抢占(preempt),防止遗漏
      • STW 成功后的校验:统计每个 P 的停顿 CPU 时间,为 GC pause time 记账
      • STW 最终状态:worldStopped();casgstatus(getg().m.curg, _Gwaiting, _Grunning)
    • finishsweep_m() 确保所有 span 都处于可分配状态,为 mark 阶段准备 heap。语义上确保上一轮 GC 的 sweep 在 mark 开始前彻底完成
    • clearpools() 清空 sync.Pool,防止池中对象延迟一个 GC 周期回收
  6. GC 全局状态初始化
    • gcController.startCycle(now, int(gomaxprocs), trigger) 控制 GC 频率,计算 assist 比例,决定 mutator 要“干多少 GC 活”
    • gcCPULimiter.startGCTransition(true, now) 控制 GC 占用 CPU 的上限,防止 GC 抢光 mutator CPU
  7. 进入 mark 阶段
    • setGCPhase(_GCmark) 切换 GC phase(全局语义切换),写屏障将开始生效,三色标记语义正式成立
      • _GCoff:本轮 GC 已完成标记,允许 sweep,关闭写屏障
      • _GCmark:三色标记生效,写屏障开启,新分配对象直接当作黑色,灰色队列开始 drain
      • _GCmarktermination:写屏障仍然开启,所有 P 必须协助 GC,即将切换到 GCoff。这是为了安全地过渡
    • gcBgMarkPrepare() 构造一个“永远不会因为 worker 不够而提前结束 mark 的判定条件”,它并不启动任何 goroutine,真正启动 mark worker 的地方是 STW 之前的 gcBgMarkStartWorkers()。
    • gcPrepareMarkRoots() 准备 root,标记:goroutine 栈、全局变量、runtime roots。为后续 gcMarkRoot 做准备,“栈只扫描一次”的入口就在这之后
      把“本轮 GC 需要扫描的所有 root”,拆分成可并发调度的 root jobs
      • Global Roots(data 已初始化的全局变量 / bss 零值全局变量):按 block 切分,避免一个巨大 module 的 root 扫描被一个 worker 独占
      • Span Roots(finalizer specials):带 specials 的 span 主要是:finalizer、weak references(未来)
      • Stack Roots:栈的 root
      • Fixed Roots(runtime 内部):不属于 data/bss、不在任何 goroutine 栈上、但 runtime 必须长期持有、且可能指向堆对象的全局结构(调度器相关结构、所有 goroutine 管理结构、空闲 G / stack 复用池、定时器系统(timer heap)、同步原语等待队列(sudog)等等)。
        • 生命周期 ≈ 程序生命周期
        • 不在用户可见的全局变量中
        • 只能由 runtime 主动扫描
      • gcMarkTinyAllocs() tiny alloc 特殊处理,tinyalloc block 直接置黑,避免分配路径插入额外屏障
      • atomic.Store(&gcBlackenEnabled, 1) 分配会“强迫 mutator 帮 GC 干活”
  8. 恢复世界,进入并发标记 now = startTheWorldWithSema(0, stw) mutator 恢复运行,写屏障开启,并发 mark worker 开始 drain 灰色队列。GC 的“并发标记阶段”正式开始
    • assertWorldStopped();mp := acquirem() 恢复世界前的准备,保证世界确实是停的、当前 P 不会被抢占,防止 P 错乱
    • list, delta := netpoll(0);injectglist(&list);netpollAdjustWaiters(delta) 处理 STW 期间积累的外部事件,是 I/O 与 STW 的边界处理
    • p1 := procresize(procs);sched.gcwaiting.Store(false) 重新建立 P 的规模与归属关系,处理 GOMAXPROCS 变化、清除 gcwaiting 、唤醒 sysmon(如果需要)
    • 把 P 重新交还给 M(或创建新 M),是调度恢复的核心
    • sched.stwTotalTimeGC.record(...);trace.STWDone() 记录 STW 总耗时和 trace
    • wakep() 唤醒调度系统,防止 runnable G 堆积 、P 全部 idle

可以发现,这里的 gcStart 流程只是为 GC 进行环境的准备,保证上一次 GC 完全结束,并且拿到所有的 root。
真正的标记阶段是 gcStart 启动的异步的,在 STW 之后才开始的。
并且这里没有真正的对白色对象进行清理。

Go GC 的“清理阶段(Sweep)”不在 gcStart 里作为一个完整阶段出现,是因为:Sweep 是「跨 GC 周期、并发 + 增量」执行的,而不是一个集中、封闭的阶段。
gcStart 中会有一部分清理(sweepone 和 finishsweep_m),但真正的大部分清理工作是在 GC mark 结束之后,下一轮 GC 开始之前,且与 mutator 并发执行的。

真正清理阶段:

  1. Sweep 的入口:gcMarkTermination()
  2. Sweep 的执行:sweepone() / sweepLocked(),Sweep 不是一个统一的 loop,而是被“顺便”触发的。
    • 分配内存
    • 后台 sweep goroutine
    • 下一轮 GC 启动前
    • heap 不足
  3. 后台 sweep worker,Go 有专门的后台 sweep worker:在 GC 结束后启动,与 mutator 并发,慢慢把 span 扫干净。bgsweep() / sweepone()

源码参考

入口:gcStart():go1.25.5/src/runtime/mgc.go:643

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
// gcStart starts the GC. It transitions from _GCoff to _GCmark (if
// debug.gcstoptheworld == 0) or performs all of GC (if
// debug.gcstoptheworld != 0).
//
// This may return without performing this transition in some cases,
// such as when called on a system stack or with locks held.
func gcStart(trigger gcTrigger) {
// Since this is called from malloc and malloc is called in
// the guts of a number of libraries that might be holding
// locks, don't attempt to start GC in non-preemptible or
// potentially unstable situations.
mp := acquirem()
if gp := getg(); gp == mp.g0 || mp.locks > 1 || mp.preemptoff != "" {
releasem(mp)
return
}
releasem(mp)
mp = nil

if gp := getg(); gp.bubble != nil {
// Disassociate the G from its synctest bubble while allocating.
// This is less elegant than incrementing the group's active count,
// but avoids any contamination between GC and synctest.
bubble := gp.bubble
gp.bubble = nil
defer func() {
gp.bubble = bubble
}()
}

// Pick up the remaining unswept/not being swept spans concurrently
//
// This shouldn't happen if we're being invoked in background
// mode since proportional sweep should have just finished
// sweeping everything, but rounding errors, etc, may leave a
// few spans unswept. In forced mode, this is necessary since
// GC can be forced at any point in the sweeping cycle.
//
// We check the transition condition continuously here in case
// this G gets delayed in to the next GC cycle.
for trigger.test() && sweepone() != ^uintptr(0) {
}

// Perform GC initialization and the sweep termination
// transition.
semacquire(&work.startSema)
// Re-check transition condition under transition lock.
if !trigger.test() {
semrelease(&work.startSema)
return
}

// In gcstoptheworld debug mode, upgrade the mode accordingly.
// We do this after re-checking the transition condition so
// that multiple goroutines that detect the heap trigger don't
// start multiple STW GCs.
mode := gcBackgroundMode
if debug.gcstoptheworld == 1 {
mode = gcForceMode
} else if debug.gcstoptheworld == 2 {
mode = gcForceBlockMode
}

// Ok, we're doing it! Stop everybody else
semacquire(&gcsema)
semacquire(&worldsema)

// For stats, check if this GC was forced by the user.
// Update it under gcsema to avoid gctrace getting wrong values.
work.userForced = trigger.kind == gcTriggerCycle

trace := traceAcquire()
if trace.ok() {
trace.GCStart()
traceRelease(trace)
}

// Check that all Ps have finished deferred mcache flushes.
for _, p := range allp {
if fg := p.mcache.flushGen.Load(); fg != mheap_.sweepgen {
println("runtime: p", p.id, "flushGen", fg, "!= sweepgen", mheap_.sweepgen)
throw("p mcache not flushed")
}
// Initialize ptrBuf if necessary.
if goexperiment.GreenTeaGC && p.gcw.ptrBuf == nil {
p.gcw.ptrBuf = (*[gc.PageSize / goarch.PtrSize]uintptr)(persistentalloc(gc.PageSize, goarch.PtrSize, &memstats.gcMiscSys))
}
}

gcBgMarkStartWorkers()

systemstack(gcResetMarkState)

work.stwprocs, work.maxprocs = gomaxprocs, gomaxprocs
if work.stwprocs > numCPUStartup {
// This is used to compute CPU time of the STW phases, so it
// can't be more than the CPU count, even if GOMAXPROCS is.
work.stwprocs = numCPUStartup
}
work.heap0 = gcController.heapLive.Load()
work.pauseNS = 0
work.mode = mode

now := nanotime()
work.tSweepTerm = now
var stw worldStop
systemstack(func() {
stw = stopTheWorldWithSema(stwGCSweepTerm)
})

// Accumulate fine-grained stopping time.
work.cpuStats.accumulateGCPauseTime(stw.stoppingCPUTime, 1)

// Finish sweep before we start concurrent scan.
systemstack(func() {
finishsweep_m()
})

// clearpools before we start the GC. If we wait the memory will not be
// reclaimed until the next GC cycle.
clearpools()

work.cycles.Add(1)

// Assists and workers can start the moment we start
// the world.
gcController.startCycle(now, int(gomaxprocs), trigger)

// Notify the CPU limiter that assists may begin.
gcCPULimiter.startGCTransition(true, now)

// In STW mode, disable scheduling of user Gs. This may also
// disable scheduling of this goroutine, so it may block as
// soon as we start the world again.
if mode != gcBackgroundMode {
schedEnableUser(false)
}

// Enter concurrent mark phase and enable
// write barriers.
//
// Because the world is stopped, all Ps will
// observe that write barriers are enabled by
// the time we start the world and begin
// scanning.
//
// Write barriers must be enabled before assists are
// enabled because they must be enabled before
// any non-leaf heap objects are marked. Since
// allocations are blocked until assists can
// happen, we want to enable assists as early as
// possible.
setGCPhase(_GCmark)

gcBgMarkPrepare() // Must happen before assists are enabled.
gcPrepareMarkRoots()

// Mark all active tinyalloc blocks. Since we're
// allocating from these, they need to be black like
// other allocations. The alternative is to blacken
// the tiny block on every allocation from it, which
// would slow down the tiny allocator.
gcMarkTinyAllocs()

// At this point all Ps have enabled the write
// barrier, thus maintaining the no white to
// black invariant. Enable mutator assists to
// put back-pressure on fast allocating
// mutators.
atomic.Store(&gcBlackenEnabled, 1)

// In STW mode, we could block the instant systemstack
// returns, so make sure we're not preemptible.
mp = acquirem()

// Update the CPU stats pause time.
//
// Use maxprocs instead of stwprocs here because the total time
// computed in the CPU stats is based on maxprocs, and we want them
// to be comparable.
work.cpuStats.accumulateGCPauseTime(nanotime()-stw.finishedStopping, work.maxprocs)

// Concurrent mark.
systemstack(func() {
now = startTheWorldWithSema(0, stw)
work.pauseNS += now - stw.startedStopping
work.tMark = now

// Release the CPU limiter.
gcCPULimiter.finishGCTransition(now)
})

// Release the world sema before Gosched() in STW mode
// because we will need to reacquire it later but before
// this goroutine becomes runnable again, and we could
// self-deadlock otherwise.
semrelease(&worldsema)
releasem(mp)

// Make sure we block instead of returning to user code
// in STW mode.
if mode != gcBackgroundMode {
Gosched()
}

semrelease(&work.startSema)
}

setGCPhase(_GCmark) 切换 GC phase(全局语义切换):go1.25.5/src/runtime/mgc.go:255

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Garbage collector phase.
// Indicates to write barrier and synchronization task to perform.
var gcphase uint32

// The compiler knows about this variable.
// If you change it, you must change builtin/runtime.go, too.
// If you change the first four bytes, you must also change the write
// barrier insertion code.
//
// writeBarrier should be an internal detail,
// but widely used packages access it using linkname.
// Notable members of the hall of shame include:
//   - github.com/bytedance/sonic
//
// Do not remove or change the type signature.
// See go.dev/issue/67401.
//
//go:linkname writeBarrier
var writeBarrier struct {
enabled bool    // compiler emits a check of this before calling write barrier
pad     [3]byte // compiler uses 32-bit load for "enabled" field
alignme uint64  // guarantee alignment so that compiler can use a 32 or 64-bit load
}

const (
_GCoff             = iota // GC not running; sweeping in background, write barrier disabled
_GCmark                   // GC marking roots and workbufs: allocate black, write barrier ENABLED
_GCmarktermination        // GC mark termination: allocate black, P's help GC, write barrier ENABLED
)

//go:nosplit
func setGCPhase(x uint32) {
atomic.Store(&gcphase, x)
writeBarrier.enabled = gcphase == _GCmark || gcphase == _GCmarktermination
}

gcBgMarkPrepare:go1.25.5/src/runtime/mgc.go:1393

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// gcBgMarkPrepare sets up state for background marking.
// Mutator assists must not yet be enabled.
func gcBgMarkPrepare() {
// Background marking will stop when the work queues are empty
// and there are no more workers (note that, since this is
// concurrent, this may be a transient state, but mark
// termination will clean it up). Between background workers
// and assists, we don't really know how many workers there
// will be, so we pretend to have an arbitrarily large number
// of workers, almost all of which are "waiting". While a
// worker is working it decrements nwait. If nproc == nwait,
// there are no workers.
work.nproc = ^uint32(0)
work.nwait = ^uint32(0)
}

gcPrepareMarkRoots:go1.25.5/src/runtime/mgcmark.go:60

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// gcPrepareMarkRoots queues root scanning jobs (stacks, globals, and
// some miscellany) and initializes scanning-related state.
//
// The world must be stopped.
func gcPrepareMarkRoots() {
assertWorldStopped()

// Compute how many data and BSS root blocks there are.
nBlocks := func(bytes uintptr) int {
return int(divRoundUp(bytes, rootBlockBytes))
}

work.nDataRoots = 0
work.nBSSRoots = 0

// Scan globals.
for _, datap := range activeModules() {
nDataRoots := nBlocks(datap.edata - datap.data)
if nDataRoots > work.nDataRoots {
work.nDataRoots = nDataRoots
}

nBSSRoots := nBlocks(datap.ebss - datap.bss)
if nBSSRoots > work.nBSSRoots {
work.nBSSRoots = nBSSRoots
}
}

// Scan span roots for finalizer specials.
//
// We depend on addfinalizer to mark objects that get
// finalizers after root marking.
//
// We're going to scan the whole heap (that was available at the time the
// mark phase started, i.e. markArenas) for in-use spans which have specials.
//
// Break up the work into arenas, and further into chunks.
//
// Snapshot heapArenas as markArenas. This snapshot is safe because heapArenas
// is append-only.
mheap_.markArenas = mheap_.heapArenas[:len(mheap_.heapArenas):len(mheap_.heapArenas)]
work.nSpanRoots = len(mheap_.markArenas) * (pagesPerArena / pagesPerSpanRoot)

// Scan stacks.
//
// Gs may be created after this point, but it's okay that we
// ignore them because they begin life without any roots, so
// there's nothing to scan, and any roots they create during
// the concurrent phase will be caught by the write barrier.
work.stackRoots = allGsSnapshot()
work.nStackRoots = len(work.stackRoots)

work.markrootNext = 0
work.markrootJobs = uint32(fixedRootCount + work.nDataRoots + work.nBSSRoots + work.nSpanRoots + work.nStackRoots)

// Calculate base indexes of each root type
work.baseData = uint32(fixedRootCount)
work.baseBSS = work.baseData + uint32(work.nDataRoots)
work.baseSpans = work.baseBSS + uint32(work.nBSSRoots)
work.baseStacks = work.baseSpans + uint32(work.nSpanRoots)
work.baseEnd = work.baseStacks + uint32(work.nStackRoots)
}

stopTheWorldWithSema(reason stwReason):go1.25.5/src/runtime/proc.go:1617
startTheWorldWithSema(now int64, w worldStop):go1.25.5/src/runtime/proc.go:1763

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
// stopTheWorldWithSema is the core implementation of stopTheWorld.
// The caller is responsible for acquiring worldsema and disabling
// preemption first and then should stopTheWorldWithSema on the system
// stack:
//
//semacquire(&worldsema, 0)
//m.preemptoff = "reason"
//var stw worldStop
//systemstack(func() {
//stw = stopTheWorldWithSema(reason)
//})
//
// When finished, the caller must either call startTheWorld or undo
// these three operations separately:
//
//m.preemptoff = ""
//systemstack(func() {
//now = startTheWorldWithSema(stw)
//})
//semrelease(&worldsema)
//
// It is allowed to acquire worldsema once and then execute multiple
// startTheWorldWithSema/stopTheWorldWithSema pairs.
// Other P's are able to execute between successive calls to
// startTheWorldWithSema and stopTheWorldWithSema.
// Holding worldsema causes any other goroutines invoking
// stopTheWorld to block.
//
// Returns the STW context. When starting the world, this context must be
// passed to startTheWorldWithSema.
//
//go:systemstack
func stopTheWorldWithSema(reason stwReason) worldStop {
// Mark the goroutine which called stopTheWorld preemptible so its
// stack may be scanned by the GC or observed by the execution tracer.
//
// This lets a mark worker scan us or the execution tracer take our
// stack while we try to stop the world since otherwise we could get
// in a mutual preemption deadlock.
//
// We must not modify anything on the G stack because a stack shrink
// may occur, now that we switched to _Gwaiting, specifically if we're
// doing this during the mark phase (mark termination excepted, since
// we know that stack scanning is done by that point). A stack shrink
// is otherwise OK though because in order to return from this function
// (and to leave the system stack) we must have preempted all
// goroutines, including any attempting to scan our stack, in which
// case, any stack shrinking will have already completed by the time we
// exit.
//
// N.B. The execution tracer is not aware of this status transition and
// andles it specially based on the wait reason.
casGToWaitingForSuspendG(getg().m.curg, _Grunning, waitReasonStoppingTheWorld)

trace := traceAcquire()
if trace.ok() {
trace.STWStart(reason)
traceRelease(trace)
}
gp := getg()

// If we hold a lock, then we won't be able to stop another M
// that is blocked trying to acquire the lock.
if gp.m.locks > 0 {
throw("stopTheWorld: holding locks")
}

lock(&sched.lock)
start := nanotime() // exclude time waiting for sched.lock from start and total time metrics.
sched.stopwait = gomaxprocs
sched.gcwaiting.Store(true)
preemptall()
// stop current P
gp.m.p.ptr().status = _Pgcstop // Pgcstop is only diagnostic.
gp.m.p.ptr().gcStopTime = start
sched.stopwait--
// try to retake all P's in Psyscall status
trace = traceAcquire()
for _, pp := range allp {
s := pp.status
if s == _Psyscall && atomic.Cas(&pp.status, s, _Pgcstop) {
if trace.ok() {
trace.ProcSteal(pp, false)
}
pp.syscalltick++
pp.gcStopTime = nanotime()
sched.stopwait--
}
}
if trace.ok() {
traceRelease(trace)
}

// stop idle P's
now := nanotime()
for {
pp, _ := pidleget(now)
if pp == nil {
break
}
pp.status = _Pgcstop
pp.gcStopTime = nanotime()
sched.stopwait--
}
wait := sched.stopwait > 0
unlock(&sched.lock)

// wait for remaining P's to stop voluntarily
if wait {
for {
// wait for 100us, then try to re-preempt in case of any races
if notetsleep(&sched.stopnote, 100*1000) {
noteclear(&sched.stopnote)
break
}
preemptall()
}
}

finish := nanotime()
startTime := finish - start
if reason.isGC() {
sched.stwStoppingTimeGC.record(startTime)
} else {
sched.stwStoppingTimeOther.record(startTime)
}

// Double-check we actually stopped everything, and all the invariants hold.
// Also accumulate all the time spent by each P in _Pgcstop up to the point
// where everything was stopped. This will be accumulated into the total pause
// CPU time by the caller.
stoppingCPUTime := int64(0)
bad := ""
if sched.stopwait != 0 {
bad = "stopTheWorld: not stopped (stopwait != 0)"
} else {
for _, pp := range allp {
if pp.status != _Pgcstop {
bad = "stopTheWorld: not stopped (status != _Pgcstop)"
}
if pp.gcStopTime == 0 && bad == "" {
bad = "stopTheWorld: broken CPU time accounting"
}
stoppingCPUTime += finish - pp.gcStopTime
pp.gcStopTime = 0
}
}
if freezing.Load() {
// Some other thread is panicking. This can cause the
// sanity checks above to fail if the panic happens in
// the signal handler on a stopped thread. Either way,
// we should halt this thread.
lock(&deadlock)
lock(&deadlock)
}
if bad != "" {
throw(bad)
}

worldStopped()

// Switch back to _Grunning, now that the world is stopped.
casgstatus(getg().m.curg, _Gwaiting, _Grunning)

return worldStop{
reason:           reason,
startedStopping:  start,
finishedStopping: finish,
stoppingCPUTime:  stoppingCPUTime,
}
}

// reason is the same STW reason passed to stopTheWorld. start is the start
// time returned by stopTheWorld.
//
// now is the current time; prefer to pass 0 to capture a fresh timestamp.
//
// stattTheWorldWithSema returns now.
func startTheWorldWithSema(now int64, w worldStop) int64 {
assertWorldStopped()

mp := acquirem() // disable preemption because it can be holding p in a local var
if netpollinited() {
list, delta := netpoll(0) // non-blocking
injectglist(&list)
netpollAdjustWaiters(delta)
}
lock(&sched.lock)

procs := gomaxprocs
if newprocs != 0 {
procs = newprocs
newprocs = 0
}
p1 := procresize(procs)
sched.gcwaiting.Store(false)
if sched.sysmonwait.Load() {
sched.sysmonwait.Store(false)
notewakeup(&sched.sysmonnote)
}
unlock(&sched.lock)

worldStarted()

for p1 != nil {
p := p1
p1 = p1.link.ptr()
if p.m != 0 {
mp := p.m.ptr()
p.m = 0
if mp.nextp != 0 {
throw("startTheWorld: inconsistent mp->nextp")
}
mp.nextp.set(p)
notewakeup(&mp.park)
} else {
// Start M to run P.  Do not start another M below.
newm(nil, p, -1)
}
}

// Capture start-the-world time before doing clean-up tasks.
if now == 0 {
now = nanotime()
}
totalTime := now - w.startedStopping
if w.reason.isGC() {
sched.stwTotalTimeGC.record(totalTime)
} else {
sched.stwTotalTimeOther.record(totalTime)
}
trace := traceAcquire()
if trace.ok() {
trace.STWDone()
traceRelease(trace)
}

// Wakeup an additional proc in case we have excessive runnable goroutines
// in local queues or in the global queue. If we don't, the proc will park itself.
// If we have lots of excessive work, resetspinning will unpark additional procs as necessary.
wakep()

releasem(mp)

return now
}
]]> https://cooooing.github.io/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E3%80%8A%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Go%E8%AF%AD%E8%A8%80%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-Go%E8%AF%AD%E8%A8%80%E6%B7%B7%E5%90%88%E5%86%99%E5%B1%8F%E9%9A%9C%E7%9A%84GC%E5%85%A8%E5%9C%BA%E6%99%AF%E5%88%86%E6%9E%90/ 2025-12-28T09:24:00.000Z 第二章 Go 语言混合写屏障]]> 《深入理解Go语言》读书笔记 - Go 语言混合写屏障的 GC 全场景分析 2025-12-28T09:24:00.000Z 咕咕咕 前言

想深入下 Go 的底层,主要是并发模型、GC和内存管理相关内容。

刘丹冰老师的这本书分为3篇21章
第一篇(1~4章)主要讲 GMP 模型、GC、内存管理和 IO 复用并发模型,是比较核心的内容,会详细阅读。
第二篇(5~12章)主要讲 Go 语言特性和一些进阶知识,会选择性地详细阅读。
第三篇(13~21章)主要是项目实战,通过 Zinx 框架了解 TCP/IP 网络服务器架构,这篇大概率会跳过。

第一章 深入理解 Go 语言协程调度器 GPM 模型

调度器由来

单进程时代不需要调度器

单进程时代过于久远,现在应该不会有这样的系统了,估计只存在于计算机组成原理的课上了。

单一的执行流程,计算机只能一个任务一个任务处理,所有的程序都是阻塞的。
因为在一个进程的完整生命周期中,所需要访问的物理部分包括 CPU、Cache、主内存、磁盘、网络等。
不同的硬件媒介处理计算的能力相差甚大,可能几个数量级。如果将这些处理速度不同的处理媒介通过一个进程串在一起,则会出现高速度媒介等待和浪费的现象。
如当一个程序加载一个磁盘数据的时候,在读写的过程中,CPU处于等待状态,那么对于单进程的操作系统来讲,很明显会造成CPU运算能力的浪费,因为CPU此刻本应该被合理地分配到其他进程上去做高层的计算。

多进程/多线程时代的调度器

当一个进程阻塞 CPU 可以立刻切换到其他进程中去执行,而且调度CPU的算法可以保证在运行的进程都可以被分配到CPU的运行时间片。从宏观来看,似乎多个进程是在同时被运行。

时间片(Timeslice)又称为“量子(Quantum)”或“处理器片(Processor Slice)”
是分时操作系统分配给每个正在运行的进程微观上的一段CPU时间(在抢占内核中是从进程开始运行直到被抢占的时间)。

image

这是会带来新的问题,当进程越来越多,每个进程又拥有太多的资源时,进程的创建、切换、销毁都会占用很多 CPU 性能。
即进程切换和调度带来的性能消耗可能会超过进程本身的性能消耗,这时候就很不划算了。

image

协程提供 CPU 利用率

一个线程可以分为“内核态”和“用户态”两种形态的线程。
所谓用户态线程就是把内核态的线程在用户态实现了一遍而已,目的是更轻量化(更少的内存占用、更少的隔离、更快的调度)和更高的可控性(可以自己控制调度器)。
用户态中的所有东⻄内核态都看得⻅,只是对于内核而言用户态线程只是一堆内存数据而已。

一个用户态线程必须绑定一个内核态线程,但是CPU并不知道有用户态线程的存在,它只知道它运行的是一个内核态线程(Linux的PCB进程控制块)。
如果将线程再进行细化,内核线程依然叫线程(Thread),而用户线程则叫协程(Co-routine)。操作系统层面的线程就是所谓的内核态线程,用户态线程则多种多样,只要能满足在同一个内核线程上执行多个任务,例如Co-routine、Go的Goroutine、C#的Task等。

协程和线程的映射关系有三种,它们分别是 N:1 关系、1:1 关系和 M:N 关系。

  1. N:1 关系
    N个协程绑定1个线程,优点就是协程在用户态线程即完成切换,不会陷入内核态,这种切换非常轻量快速,但缺点也很明显。1个进程的所有协程都绑定在1个线程上。
    这种情况下,单个程序只能利用一个核,即使是多核CPU;某一个协程阻塞,会造成线程阻塞,本进程的其他协程都无法执行了,进而导致没有任何并发能力。
  2. 1:1 关系
    1个协程绑定1个线程,这种方式最容易实现。协程的调度都由CPU完成了,和直接使用线程没有太大区别。
  3. M:N 关系
    M个协程绑定1个线程,实现起来最为复杂。同一个调度器上挂载M个协程,调度器下游则是多个CPU核心资源。
    协程跟线程是有区别的,线程由CPU调度是抢占式的,协程由用户态调度是协作式的,一个协程让出CPU后,才执行下一个协程,所以针对M:N模型的中间层的调度器设计就变得尤为重要,提高线程和协程的绑定关系和执行效率也变为不同语言在设计调度器时的优先目标。

Go 语言的协程 Goroutine

Go语言为了提供更容易使用的并发方法,使用了Goroutine和Channel。
Goroutine来自协程的概念,让一组可复用的函数运行在一组线程之上,即使有协程阻塞,该线程的其他协程也可以被 runtime 调度,从而转移到其他可运行的线程上。
Goroutine的特点,占用内存更小(几KB)和调度更灵活(runtime调度)。

被废弃的 Goroutine 调度器

Go 的调度器在 2012 年重新设计了。

G 表示 Goroutine
M 表示 线程

早期的调度器是基于 M:N 的基础上实现的。
所有的协程(G)都会被放在一个全局的Go协程队列中,在全局队列的外面由于是多个 M 的共享资源,所以会加上一个用于同步及互斥作用的锁。
M 想要执行、放回 G 都必须访问全局 G 队列,并且 M 有多个,即多线程访问同一资源需要加锁进行保证互斥/同步,所以全局 G 队列是由互斥锁进行保护的。

这会带来激烈的锁竞争,因为创建、销毁、调度 G 都需要每个 M 获取锁。
M 转移 G 会造成延迟和额外的系统负载。例如当 G 中包含创建新协程的时候,M 创建了 G′,为了继续执行 G,需要把 G′ 交给 M2 执行,也造成了很差的局部性(共享数据、共享栈索引、可能访问相同内存),因为 G′ 和 G 是相关的,最好放在M上执行,而不是其他 M2。
系统调用(CPU在M之间的切换)导致频繁的线程阻塞和取消阻塞操作增加了系统开销。

Go语言调度器GPM模型的设计思想

面对之前调度器的问题,新的调度器引入了 P (处理器)。
处理器包含了运行 Goroutine 的资源,如果线程想运行 Goroutine,必须先获取 P,P 中还包含了可运行的 G 队列。

GPM 模型

在Go中,线程是运行 Goroutine 的实体,调度器的功能是把可运行的 Goroutine 分配到工作线程上。

image

  1. 全局队列(Global Queue):存放等待运行的 G。
    全局队列可能被任意的 P 去获取里面的 G,所以全局队列相当于整个模型中的全局资源,那么自然对于队列的读写操作是要加入互斥动作的。
  2. P 的本地队列:同全局队列类似,存放的也是等待运行的 G,但存放的数量有限,不超过 256 个。
    新建 G′ 时,G′ 优先加入 P 的本地队列,如果队列满了,则会把本地队列中一半的 G 移动到全局队列。
  3. P 列表:所有的 P 都在程序启动时创建,并保存在数组中,最多有 GOMAXPROCS(可配置)个。
  4. M:线程想运行任务就得获取 P,从 P 的本地队列获取 G,当 P 队列为空时,M 也会尝试从全局队列获得一批 G 放到 P 的本地队列,或从其他P的本地队列“偷”一半放到自己 P 的本地队列(工作窃取)。
    M 运行 G,G 执行之后,M 会从 P 获取下一个 G,不断重复下去。

Goroutine 调度器和 OS 调度器是通过 M 结合起来的,每个 M 都代表了 1 个内核线程,OS调度器负责把内核线程分配到 CPU 的核上执行。

有关 P 和 M 个数的问题

P 的数量由启动时环境变量 $GOMAXPROCS 或者由 runtime 的方法 GOMAXPROCS() 决定。
这意味着在程序执行的任意时刻都只有 $GOMAXPROCS 个 Goroutine 在同时运行。(真正的并行,CPU 核心的数量)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
package runtime

// GOMAXPROCS sets the maximum number of CPUs that can be executing
// simultaneously and returns the previous setting. It defaults to
// the value of [runtime.NumCPU]. If n < 1, it does not change the current setting.
// This call will go away when the scheduler improves.
func GOMAXPROCS(n int) int {
if GOARCH == "wasm" && n > 1 {
n = 1 // WebAssembly has no threads yet, so only one CPU is possible.
}

lock(&sched.lock)
ret := int(gomaxprocs)
unlock(&sched.lock)
if n <= 0 || n == ret {
return ret
}

stw := stopTheWorldGC(stwGOMAXPROCS)

// newprocs will be processed by startTheWorld
newprocs = int32(n)

startTheWorldGC(stw)
return ret
}

M 的数量由 Go 语言本身的限制决定,Go 程序启动时会设置 M 的最大数量,默认为 10000 个,但是内核很难支持这么多的线程数,所以这个限制可以忽略。
runtime/debug 中的 SetMaxThreads() 函数可设置 M 的最大数量,当一个 M 阻塞了时会创建新的 M。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package runtime

// SetMaxThreads sets the maximum number of operating system
// threads that the Go program can use. If it attempts to use more than
// this many, the program crashes.
// SetMaxThreads returns the previous setting.
// The initial setting is 10,000 threads.
//
// The limit controls the number of operating system threads, not the number
// of goroutines. A Go program creates a new thread only when a goroutine
// is ready to run but all the existing threads are blocked in system calls, cgo calls,
// or are locked to other goroutines due to use of runtime.LockOSThread.
//
// SetMaxThreads is useful mainly for limiting the damage done by
// programs that create an unbounded number of threads. The idea is
// to take down the program before it takes down the operating system.
func SetMaxThreads(threads int) int {
return setMaxThreads(threads)
}

M 与 P 的数量没有绝对关系,一个 M 阻塞,P 就会去创建或者切换另一个 M,所以,即使 P 的默认数量是 1,也有可能会创建很多个 M 出来。

有关 P 和 M 何时被创建
  1. P 创建的时机在确定了 P 的最大数量 n 后,运行时系统会根据这个数量创建 n 个 P。
  2. M 创建的时机是在当没有足够的 M 来关联 P 并运行其中可运行的 G 的时候。
    例如所有的 M 此时都阻塞住了,而 P 中还有很多就绪任务,就会去寻找空闲的 M,如果此时没有空闲的 M,就会去创建新的 M。

调度器的设计策略

复用线程

避免频繁地创建、销毁线程,而是对线程的复用。

  1. 偷取(Work Stealing)机制
    当本线程无可运行的 G 时,尝试从其他线程绑定的 P 偷取 G,而不是销毁线程。
    image
    偷取的动作一定是由 P 发起的,而非 M,因为 P 的数量是固定的,如果一个 M 得不到一个 P,那么这个 M 是没有执行的本地队列的,更谈不上向其他的 P 队列偷取了。
  2. 移交(Hand Off)机制
    当本线程因为 G 进行系统调用阻塞时,线程会释放绑定的 P,把 P 转移给其他空闲的线程执行,此时若在 M1 的 GPM 组合中,G1 正在被调度,并且已经发生了阻塞,则这个时候就会触发移交的设计机制。
    GPM 模型为了更大程度地利用 M 和 P 的性能,不会让一个 P 永远被一个阻塞的 G1 耽误之后的工作,所以遇⻅这种情况的时候,移交机制的设计理念是应该立刻将此时的 P 释放出来。
    image
    为了释放 P,所以将 P 和 M1、G1 分离,M1 由于正在执行当前的 G1,全部的程序栈空间均在 M1 中保存,所以 M1 此时应该与 G1 一同进入阻塞的状态,但是已经被释放的 P 需要跟另一个 M 进行绑定,所以就会选择一个 M3(如果此时没有M3,则会创建一个新的或者唤醒一个正在睡眠的M)进行绑定,这样新的 P 就会继续工作,接收新的 G 或者从其他的队列中实施偷取机制。
    image
利用并行

GOMAXPROCS 设置 P 的数量,最多有 GOMAXPROCS 个线程分布在多个 CPU 上同时运行。
GOMAXPROCS 也限制了并发的程度,例如 GOMAXPROCS = 核数 / 2,表示最多利用一半的 CPU 核进行并行。

抢占

在 Co-routine 中要等待一个协程主动让出 CPU 才执行下一个协程。
在 Go 中,一个 Goroutine 最多占用CPU 10ms,防止其他 Goroutine 无资源可用,这是 Goroutine 不同于 Co-routine 的一个地方。

全局G队列

在新的调度器中依然有全局 G 队列,但功能已经被弱化了,当 M 执行偷取,但从其他 P 偷不到 G 时,它可以从全局 G 队列获取 G。

image

go func() 调度流程

  1. 通过 go func() 创建一个 Goroutine
    image
  2. 有两个存储 G 的队列,一个是局部调度器 P 的本地队列,另一个全局 G 队列。
    新创建的 G 会先保存在 P 的本地队列中,如果 P 本地队列满了,则会保存在全局的队列中。
    image
  3. G 只能运行在 M 中,一个 M 必须持有一个 P,M 与 P 是 1:1 的关系。
    M 会从 P 的本地队列弹出一个可执行状态的 G 来执行,如果 P 的本地队列为空,则会从全局队列进行获取,如果从全局队列获取不到,则会向其他的 MP 组合偷取一个可执行的 G 来执行。
    image
  4. 一个 M 调度 G 执行的过程是一个循环机制。
    image
  5. 当 M 执行某一个 G 时如果发生了 syscall 或者其余阻塞操作,则 M 会阻塞,如果当前有一些 G 在执行,runtime 则会把这个线程 M 从 P 中移除(Detach),然后创建一个新的操作系统线程(如果有空闲的线程可用就复用空闲线程)来服务于这个 P。
    image
  6. 当 M 系统调用结束时,这个 G 会尝试获取一个空闲的 P 执行,并放入这个 P 的本地队列。如果获取不到 P,则这个线程 M 会变成休眠状态,加入空闲线程中,然后这个 G 会被放入全局队列中。
    image

调度器的生命周期

Go 语言调度器的 GPM 模型中还有两个比较特殊的⻆色,它们分别是 M0 和 G0。

  1. M0
    1. 启动程序后的编号为0的主线程。
    2. 在全局命令 runtime.m0 中,不需要在 heap 堆上分配。
    3. 负责执行初始化操作和启动第 1 个 G。
    4. 启动第 1 个 G 后,M0 就和其他的 M 一样了。
  2. G0
    1. 每次启动一个 M,创建的第1个 Goroutine 就是 G0。
    2. G0 用于负责调度 G,此外还有信号处理、抢占切换等职责。
    3. G0 不指向任何可执行的用户函数,但仍会运行 runtime 函数。
    4. 每个 M 都会有一个自己的 G0。
    5. 在调度或系统调度时,会使用 M 切换到 G0,再通过 G0 调度。
    6. M0 的 G0 会放在全局空间。

对于一个简单的 main 程序

1
2
3
4
5
6
7
package main

import "fmt"

func main() {
fmt.Println("hello world")
}

流程如下:

  1. runtime 创建最初的线程 M0 和 Goroutine G0,并将它们关联。
  2. 调度器初始化:初始化 M0、栈、垃圾回收,以及创建和初始化由 GOMAXPROCS 个 P 构成的 P 列表。
  3. 示例代码中的 main()函数是 main.main,runtime 中也有 1 个 main() 函数 runtime.main,代码经过编译后,runtime.main 会调用 main.main,程序启动时会为 runtime.main 创建 Goroutine,称为 Main Goroutine,然后把 Main Goroutine 加入 P 的本地队列。
  4. 启动 M0,M0 已经绑定了 P,会从 P 的本地队列获取 G,并获取 Main Goroutine。
  5. G 拥有栈,M 根据 G 中的栈信息和调度信息设置运行环境。
  6. M 运行 G。
  7. G 退出,再次回到 M 获取可运行的 G,这样重复下去,直到 main.main 退出,runtime.main 执行 Defer 和 Panic 处理,或调用 runtime.exit 退出程序。

调度器的生命周期几乎占满了一个 Go 程序的一生。
runtime.main 的 Goroutine 执行之前都是为调度器做准备工作,runtime.main 的 Goroutine 运行才是调度器的真正开始,直到 runtime.main 结束而结束。

可视化 GPM 编程

Go 语言提供了两种方式可以查看一个程序的 GPM 数据。

go tool trace

trace 记录了运行时的信息,能提供可视化的 Web ⻚面。

以下面的程序为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package main

import (
"fmt"
"os"
"runtime/trace"
)

func main() {
f, err := os.Create("trace.out")
if err != nil {
panic(err)
}
defer f.Close()

err = trace.Start(f)
if err != nil {
panic(err)
}
defer trace.Stop()

// main
fmt.Println("hello world")
}

运行后会得到 trace.out 文件,使用 go tool 打开该文件:

1
2
3
4
ubuntu@ubuntu:~$ go tool trace trace.out
2025/12/27 22:00:48 Preparing trace for viewer...
2025/12/27 22:00:48 Splitting trace for viewer...
2025/12/27 22:00:48 Opening browser. Trace viewer is listening on http://127.0.0.1:64230

通过浏览器打开后,点开 view 可以看到:

image

Debug trace

编译下面的程序:

1
2
3
4
5
6
7
8
9
10
11
12
13
package main

import (
"fmt"
"time"
)

func main() {
for i := 0; i < 5; i++ {
time.Sleep(1 * time.Second)
fmt.Println("hello world")
}
}

使用 debug 运行:

1
2
3
4
5
6
7
8
9
10
11
12
ubuntu@ubuntu:~$ go build main.go
ubuntu@ubuntu:~$ GODEBUG=schedtrace=1000 main
SCHED 0ms: gomaxprocs=20 idleprocs=20 threads=6 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] schedticks=[ 1 4 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]
hello world
SCHED 1004ms: gomaxprocs=20 idleprocs=20 threads=6 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] schedticks=[ 1 4 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]
hello world
SCHED 2005ms: gomaxprocs=20 idleprocs=20 threads=6 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] schedticks=[ 1 4 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]
hello world
SCHED 3014ms: gomaxprocs=20 idleprocs=20 threads=6 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] schedticks=[ 1 4 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]
hello world
SCHED 4016ms: gomaxprocs=20 idleprocs=20 threads=6 spinningthreads=0 needspinning=0 idlethreads=3 runqueue=0 [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] schedticks=[ 1 4 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]
hello world
  1. SCHED:调试信息输出标志字符串,代表本行是Goroutine调度器的输出。
  2. 0ms:从程序启动到输出这行日志的时间。
  3. gomaxprocs:P 的数量(并行度的上限),因为默认的 P 的属性是和 CPU 核心数量一致,当然也可以通过 GOMAXPROCS 设置。
  4. idleprocs:处于 idle 状态、没有绑定运行 G 的 P 的数量;通过 gomaxprocs 和 idleprocs 的差值,就可知道执行 Go 代码的 P 的数量。
  5. threads:os threads/M 的数量,包含 scheduler 使用的 m 数量,加上 runtime 自用的类似 sysmon 这样的 thread 的数量。
  6. spinningthreads:处于自旋状态的os thread数量。
  7. needspinning:当前调度器是否需要新的 spinning M。
  8. idlethread:处于 idle 状态的 os thread 的数量。
  9. runqueue=0:全局 runqueue(sched.runq)中等待执行的 G 的数量。
  10. [0 0 …]:每个 P 的本地 runqueue 中等待执行的 G 的数量,数量与 gomaxprocs 一致。
  11. schedticks=[ … ]:每个 P 上发生过多少次调度循环(schedule 调用)。

Go 调度器调度流程

参考 Go 版本 1.25.5 的代码。
场景:当一个 M 已经绑定一个 P,准备执行下一个 G。

首先调度器的总体结构:

  1. newproc 创建 G
  2. ready/runqput G 进入 runnable
  3. schedule 调度入口
  4. findRunnable 寻找可运行 G
  5. execute G 真正运行
  6. park/exit/preempt 阻塞、退出、抢占

创建阶段(newproc)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
go f():编译器会调用 newproc,newproc 流程如下
↓
newproc1:
  - 分配 / 复用 G
  - 初始化栈与 sched 上下文
  - 状态从 _Gdead 原子切换为 _Grunnable(或 _Gwaiting)
↓
runqput:
  - 优先放入 runnext(若 next=true 且条件允许)
  - 否则放入当前 P 的本地 runq
  - 若本地 runq 满:
      调用 runqputslow
      将本地 runq 的前一半(len/2)+ 当前 G
      批量转移到 global runq
↓
当一个 G 被变为 runnable(newproc / ready)时,
在调度器已初始化且条件允许的情况下:
  调用 wakep
↓
wakep:
  - 若已有 spinning M,则直接返回
  - 否则尝试从 idle P 队列中取一个 P
  - 若没有 idle P(所有 P 已在用),则什么都不做
  - 若成功取到 P:
      启动 / 唤醒一个 M
      绑定该 P
      以 spinning 状态开始调度

go f():newproc(): go1.25.5/src/runtime/proc.go:5158

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Create a new g running fn.
// Put it on the queue of g's waiting to run.
// The compiler turns a go statement into a call to this.
func newproc(fn *funcval) {
gp := getg()
pc := sys.GetCallerPC()
systemstack(func() {
newg := newproc1(fn, gp, pc, false, waitReasonZero)

pp := getg().m.p.ptr()
runqput(pp, newg, true)

if mainStarted {
wakep()
}
})
}

创建 G :newproc1(): go1.25.5/src/runtime/proc.go:5176

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
// Create a new g in state _Grunnable (or _Gwaiting if parked is true), starting at fn.
// callerpc is the address of the go statement that created this. The caller is responsible
// for adding the new g to the scheduler. If parked is true, waitreason must be non-zero.
func newproc1(fn *funcval, callergp *g, callerpc uintptr, parked bool, waitreason waitReason) *g {
if fn == nil {
fatal("go of nil func value")
}

mp := acquirem() // disable preemption because we hold M and P in local vars.
pp := mp.p.ptr()
newg := gfget(pp)
if newg == nil {
newg = malg(stackMin)
casgstatus(newg, _Gidle, _Gdead)
allgadd(newg) // publishes with a g->status of Gdead so GC scanner doesn't look at uninitialized stack.
}
if newg.stack.hi == 0 {
throw("newproc1: newg missing stack")
}

if readgstatus(newg) != _Gdead {
throw("newproc1: new g is not Gdead")
}

totalSize := uintptr(4*goarch.PtrSize + sys.MinFrameSize) // extra space in case of reads slightly beyond frame
totalSize = alignUp(totalSize, sys.StackAlign)
sp := newg.stack.hi - totalSize
if usesLR {
// caller's LR
*(*uintptr)(unsafe.Pointer(sp)) = 0
prepGoExitFrame(sp)
}
if GOARCH == "arm64" {
// caller's FP
*(*uintptr)(unsafe.Pointer(sp - goarch.PtrSize)) = 0
}

memclrNoHeapPointers(unsafe.Pointer(&newg.sched), unsafe.Sizeof(newg.sched))
newg.sched.sp = sp
newg.stktopsp = sp
newg.sched.pc = abi.FuncPCABI0(goexit) + sys.PCQuantum // +PCQuantum so that previous instruction is in same function
newg.sched.g = guintptr(unsafe.Pointer(newg))
gostartcallfn(&newg.sched, fn)
newg.parentGoid = callergp.goid
newg.gopc = callerpc
newg.ancestors = saveAncestors(callergp)
newg.startpc = fn.fn
newg.runningCleanups.Store(false)
if isSystemGoroutine(newg, false) {
sched.ngsys.Add(1)
} else {
// Only user goroutines inherit synctest groups and pprof labels.
newg.bubble = callergp.bubble
if mp.curg != nil {
newg.labels = mp.curg.labels
}
if goroutineProfile.active {
// A concurrent goroutine profile is running. It should include
// exactly the set of goroutines that were alive when the goroutine
// profiler first stopped the world. That does not include newg, so
// mark it as not needing a profile before transitioning it from
// _Gdead.
newg.goroutineProfiled.Store(goroutineProfileSatisfied)
}
}
// Track initial transition?
newg.trackingSeq = uint8(cheaprand())
if newg.trackingSeq%gTrackingPeriod == 0 {
newg.tracking = true
}
gcController.addScannableStack(pp, int64(newg.stack.hi-newg.stack.lo))

// Get a goid and switch to runnable. Make all this atomic to the tracer.
trace := traceAcquire()
var status uint32 = _Grunnable
if parked {
status = _Gwaiting
newg.waitreason = waitreason
}
if pp.goidcache == pp.goidcacheend {
// Sched.goidgen is the last allocated id,
// this batch must be [sched.goidgen+1, sched.goidgen+GoidCacheBatch].
// At startup sched.goidgen=0, so main goroutine receives goid=1.
pp.goidcache = sched.goidgen.Add(_GoidCacheBatch)
pp.goidcache -= _GoidCacheBatch - 1
pp.goidcacheend = pp.goidcache + _GoidCacheBatch
}
newg.goid = pp.goidcache
casgstatus(newg, _Gdead, status)
pp.goidcache++
newg.trace.reset()
if trace.ok() {
trace.GoCreate(newg, newg.startpc, parked)
traceRelease(trace)
}

// Set up race context.
if raceenabled {
newg.racectx = racegostart(callerpc)
newg.raceignore = 0
if newg.labels != nil {
// See note in proflabel.go on labelSync's role in synchronizing
// with the reads in the signal handler.
racereleasemergeg(newg, unsafe.Pointer(&labelSync))
}
}
releasem(mp)

return newg
}

将 G 放入队列:runqput(): go1.25.5/src/runtime/proc.go:7058

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
// runqput tries to put g on the local runnable queue.
// If next is false, runqput adds g to the tail of the runnable queue.
// If next is true, runqput puts g in the pp.runnext slot.
// If the run queue is full, runnext puts g on the global queue.
// Executed only by the owner P.
func runqput(pp *p, gp *g, next bool) {
if !haveSysmon && next {
// A runnext goroutine shares the same time slice as the
// current goroutine (inheritTime from runqget). To prevent a
// ping-pong pair of goroutines from starving all others, we
// depend on sysmon to preempt "long-running goroutines". That
// is, any set of goroutines sharing the same time slice.
//
// If there is no sysmon, we must avoid runnext entirely or
// risk starvation.
next = false
}
if randomizeScheduler && next && randn(2) == 0 {
next = false
}

if next {
retryNext:
oldnext := pp.runnext
if !pp.runnext.cas(oldnext, guintptr(unsafe.Pointer(gp))) {
goto retryNext
}
if oldnext == 0 {
return
}
// Kick the old runnext out to the regular run queue.
gp = oldnext.ptr()
}

retry:
h := atomic.LoadAcq(&pp.runqhead) // load-acquire, synchronize with consumers
t := pp.runqtail
if t-h < uint32(len(pp.runq)) {
pp.runq[t%uint32(len(pp.runq))].set(gp)
atomic.StoreRel(&pp.runqtail, t+1) // store-release, makes the item available for consumption
return
}
if runqputslow(pp, gp, h, t) {
return
}
// the queue is not full, now the put above must succeed
goto retry
}

// Put g and a batch of work from local runnable queue on global queue.
// Executed only by the owner P.
func runqputslow(pp *p, gp *g, h, t uint32) bool {
var batch [len(pp.runq)/2 + 1]*g

// First, grab a batch from local queue.
n := t - h
n = n / 2
if n != uint32(len(pp.runq)/2) {
throw("runqputslow: queue is not full")
}
for i := uint32(0); i < n; i++ {
batch[i] = pp.runq[(h+i)%uint32(len(pp.runq))].ptr()
}
if !atomic.CasRel(&pp.runqhead, h, h+n) { // cas-release, commits consume
return false
}
batch[n] = gp

if randomizeScheduler {
for i := uint32(1); i <= n; i++ {
j := cheaprandn(i + 1)
batch[i], batch[j] = batch[j], batch[i]
}
}

// Link the goroutines.
for i := uint32(0); i < n; i++ {
batch[i].schedlink.set(batch[i+1])
}

q := gQueue{batch[0].guintptr(), batch[n].guintptr(), int32(n + 1)}

// Now put the batch on global queue.
lock(&sched.lock)
globrunqputbatch(&q)
unlock(&sched.lock)
return true
}

尝试添加 P 来执行 G:wakep: go1.25.5/src/runtime/proc.go:3217

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Tries to add one more P to execute G's.
// Called when a G is made runnable (newproc, ready).
// Must be called with a P.
//
// wakep should be an internal detail,
// but widely used packages access it using linkname.
// Notable members of the hall of shame include:
//   - gvisor.dev/gvisor
//
// Do not remove or change the type signature.
// See go.dev/issue/67401.
//
//go:linkname wakep
func wakep() {
// Be conservative about spinning threads, only start one if none exist
// already.
if sched.nmspinning.Load() != 0 || !sched.nmspinning.CompareAndSwap(0, 1) {
return
}

// Disable preemption until ownership of pp transfers to the next M in
// startm. Otherwise preemption here would leave pp stuck waiting to
// enter _Pgcstop.
//
// See preemption comment on acquirem in startm for more details.
mp := acquirem()

var pp *p
lock(&sched.lock)
pp, _ = pidlegetSpinning(0)
if pp == nil {
if sched.nmspinning.Add(-1) < 0 {
throw("wakep: negative nmspinning")
}
unlock(&sched.lock)
releasem(mp)
return
}
// Since we always have a P, the race in the "No M is available"
// comment in startm doesn't apply during the small window between the
// unlock here and lock in startm. A checkdead in between will always
// see at least one running M (ours).
unlock(&sched.lock)

startm(pp, true, false)

releasem(mp)
}
]]> https://cooooing.github.io/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0/%E3%80%8A%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Go%E8%AF%AD%E8%A8%80%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-Go%E8%AF%AD%E8%A8%80%E5%8D%8F%E7%A8%8B%E8%B0%83%E5%BA%A6%E5%99%A8GPM%E6%A8%A1%E5%9E%8B/ 2025-12-27T06:33:28.000Z 前言

想深入下 Go 的底层,主要是并发模型、GC和内存管理相关内容。

刘丹冰老师的这本书分为3篇21章
第一篇(1~4章)主]]>

《深入理解Go语言》读书笔记 - Go 语言协程调度器 GPM 模型 2025-12-27T06:33:28.000Z 咕咕咕 前言：减小 Go 应用产物体积

Go 语言通过静态编译生成单一二进制文件，这一特性非常适合用于容器化部署。
但在默认构建和打包方式下，Go 应用的最终交付产物，二进制可执行文件或者镜像会比较大。

这里可以使用下面两种方式减小产物体积：

  • 使用 UPX 压缩 Go 可执行文件，减少二进制体积
  • 使用 Docker scratch 镜像，去掉不必要的运行环境

使用 UPX 压缩 Go 可执行文件

UPX（Ultimate Packer for eXecutables）是一个通用的可执行文件压缩工具。

UPX 的核心特点是：

  • 在磁盘上以压缩形式存在
  • 程序启动时自动解压到内存中执行
  • 对程序逻辑完全透明，无需改代码

UPX 将原始可执行文件压缩，在文件头部插入一个极小的解压 stub，程序启动时，stub 将主体代码解压到内存，跳转到真正的入口点执行。
所以，它的磁盘占用会显著减少，但内存中仍是完整程序，仅在启动阶段会有一次性的解压开销。

对于 Go 应用，在使用 UPX 之前，应该尽量减小二进制产物体积（在每个阶段都考虑减小），推荐使用下面的参数进行编译：

1
2
3
4
5
CGO_ENABLED=0 \
go build \
  -trimpath \
  -ldflags "-s -w" \
  -o app

参数说明：

  • CGO_ENABLED=0：禁用 CGO ，避免链接系统 libc（如 glibc / musl），生成完全静态的 Go 二进制。是使用 scratch 镜像的前提，避免运行时依赖系统动态库。
  • -trimpath：从编译产物中移除本地源码的绝对路径。减小少量二进制体积，避免泄露本地目录结构。
  • -ldflags "-s -w"：去除符号表和调试信息。
    • -s：去除符号表（symbol table），移除函数名、变量名等符号信息，显著减小二进制体积。
    • -w：去除 DWARF 调试信息，移除用于调试和栈回溯的 DWARF 数据，对运行逻辑无影响。

在此基础上，就可以使用 UPX 镜像压缩了。

安装 UPX：apt install upx-ucl

UPX 使用：upx --best --lzma app

参数说明：

  • --best | 使用最高压缩等级
  • --lzma | 使用 LZMA 算法，压缩率最高

使用 UPX 的代价是：增加 CI 环节的步骤、启动阶段一次性解压开销。

使用 Docker Scratch 构建最小运行镜像

scratch 是 Docker 提供的一个空白基础镜像：

  • 没有操作系统
  • 没有 shell
  • 没有任何系统库
  • 大小为 0 字节
1
2
3
FROM scratch
COPY app /app
ENTRYPOINT ["/app"]

使用 scratch 的理念是：

只把“程序本身”放进镜像中

非常适合 Go 这类构建产物为完全静态二进制、无动态链接和外部运行时依赖的语言和应用场景。

使用 scratch 镜像的代价：运行环境没有任何工具，非常不利于调试。

结语

附一张使用 UPX 和 Docker Scratch 镜像的体积对比
原镜像使用没有使用 UPX 压缩，使用 debian:stable-slim 作为运行时镜像
效果还是非常明显的：

image

]]> https://cooooing.github.io/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/Go%20%E5%BA%94%E7%94%A8%E9%83%A8%E7%BD%B2%EF%BC%9AUPX%20%E5%8E%8B%E7%BC%A9%E4%B8%8E%20Docker%20Scratch%20%E9%95%9C%E5%83%8F/ 2025-12-25T11:05:13.000Z 前言：减小 Go 应用产物体积

Go 语言通过静态编译生成单一二进制]]>

Go 应用部署：UPX 压缩与 Docker Scratch 镜像 2025-12-25T11:05:13.000Z 咕咕咕 已经写了四年的流水账了，完全不知道今年怎么写。过得比去年还要平淡了。
脑海中对于今年的记忆好像只有换了工作换了城市…

工作

从印象最深影响最大的换工作开始说吧。
其实简历一直在断断续续得投了有大半年，投到了现在这个杭州的小公司。

整个两次面试都没超过半小时，头一天晚上技术面问了一些 go 基础，就十来分钟，第二天中午和领导视频聊了十来分钟。聊完就发了offer。
快的难以置信，整个过程不管是我还是这个公司，我都觉得非常草率。
草率在就二三十分钟就决定了要完全换个城市工作生活。（不过大概是我投的时候就做好心里准备了

五月中来杭州，五月底入职。还赶得上杭州的应届生补贴政策，没错，那时候我毕业还没有满一年，但实际上班已经快两年了。
等11月份的社保到账之后，就可以去申请了。

换工作后，我的整个技术栈也从 Java 换成了 Go。
这个决定不知道会有什么影响，也许很大，但也许很小。

生活

以前每天都加班，可谓是没有什么生活了。
现在虽然单休，但完全不加班。感觉工作时长反而短了。

朋友六月份也换了工作，来到了杭州。
所以后面一起去了西湖、工联CC、苹果授权店、九溪、法喜寺等等。
原本这个月准备去灵隐寺的，但可惜感冒了，只能暂时搁置了。

附大厨周末来我这给我做的牛排、排骨汤和香肠，嘎嘎好吃。
那天在我的推荐下，还去看了罗小黑战记2的电影。（吃完就库库睡了一下午，啥也没干，乐

image
image

最近几天要和他一起把双人成行打个全成就，打完后准备去玩双影奇境。
哦，对。今年还买了 steamdeck，也展示下吧。（台式电脑的显卡就空着吧，无限期搁置

image
image

摸鱼

以前摸鱼都是找本书看看，不知不觉也看完了好几本（虽然库里还存了几十本没看
找到工作之后，反而不怎么去看书了。大概是没那么焦虑了。学习的节奏也慢了，更多的倒是想实践。

今年也是挖了很多坑，但没一个填上的。

首先就是和鱼油们玩的 奶牛放置。鸽鸽和我都准备复刻一个，可惜，我的暂时弃坑了。（此处，催更鸽鸽
现在回头去看那段时间的代码，反而觉得写的很不好。

其次就是实践！挖了一个巨大坑。
准备用 go 实现一个完整的论坛社区，主要参考鱼排、V2EX等。
这个坑像是无底洞，不知道还要写多久。不过好在有跳佬帮忙写前端，应该是不至于烂尾。

此外就是在我完全不熟悉的领域了。vibe coding 写前端。
给跳佬的 WJU 增加了按难度生成谜题，其实是个没怎么研究明白的数学问题。
前两天给棋牌室加了各全是 bug 的单人俄罗斯方块。

End

现阶段暂时是稳定的，平平淡淡吧。关于技术之类的，我觉得我需要沉淀沉淀，停下脚步，认真地写点什么。
最后，借跳佬的话作为结语：人生难得成为平凡太郎

]]> https://cooooing.github.io/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/2025/ 2025-12-20T01:39:32.000Z 已经写了四年的流水账了，完全不知道今年怎么写。过得比去年还要平淡了。
脑海中对于今年的记忆好像只有换了工作换了城市…

工作

从]]>

2025 2025-12-20T01:39:32.000Z 咕咕咕 系统

之前就在虚拟机和笔记本上装过 ArchLinux，想尝试尝试 Linux 系统作为主力开发系统。
主要原因是 windows 的命令行很难用，即便是有了 powershell，也改变不了使用它的痛苦。
特别是之前做 CI/CD 写 Makefile、Dokcerfile 和 github workflow.yaml 。光是路径问题就花了很久。
替换的契机是前几天用 rdp 远程开发的时候，连接断开（第二次了）。等到回去一看，电脑没有任何反应，应该是死机了。不知道任何原因。
所以花了两三天，给电脑刷了 ArchLinux 系统。

之前有写过一篇安装过程，其实还是很繁琐的。
后来发现其实系统镜像内置了方便的工具 archinstall ，只需要根据选项进行配置就可以了。
比我自己手动装的要好不少（一些配置方面

装完之后难免要去自己自定义美化一下，虽然默认的审美上比以前用过的 ubuntu 桌面之类的有些提升。
下面就是都装完之后，选个好看的壁纸：

image

问题

输入法

使用这个系统目前还是有很多问题的，主要集中在 KDE 的 wayland 这个桌面和图形平台上。
最严重的莫过于输入法的问题了，纯英文情况下还可以，只要配置得当，不会有什么问题。但是中文就不太行了。

Jetbrains Idea 至今还不支持。详见：(Wayland: support input methods (text-input-unstable-v3))[https://youtrack.jetbrains.com/issue/JBR-5672/Wayland-support-input-methods-text-input-unstable-v3]
好消息是将在2025.3版本支持，坏消息是目前最新正式版本是2025.2.5。也是给我赶上了，明年就能用了（好耶！）

VSCode 我以为也不会有问题的，结果和 Idea 的表现一模一样。（用的微软官方提供的 visual-studio-code-bin 版本
不过好消息是可以解决。

修改 ~/.config/code-flags.conf 文件即可（文件默认不存在，需要创建），添加以下内容：

1
2
3
--enable-features=UseOzonePlatform
--ozone-platform-hint=wayland
--enable-wayland-ime

远程控制

另一个问题就是远程控制了，对于远程开发来说还是很重要的功能。
但很可惜，wayland 在这方面做的很不好，可能与他们的安全限制有关系，无法做到无人值守的状态。

目前只能是使用 ssh 了。对于桌面可能就无缘了。

不过对于 Idea 远程开发，使用了它们的 Jetbrains Gateway 的方案。不得不说，各种问题，光是安装就费了我很大的劲，不过好在安装完可以用，虽然体验没那么好。
Jetbrains 在远程开发和 AI 方面真的是没有跟上。

后续可能会尝试 VSCode 的远程开发，不过我用惯了 Jetbrains，是真不习惯 VSCode。

2025-12-07 后记

终于是受不了 Wayland 的各种问题了，决定回归初心。作为开发环境，需要的是稳定，默认的也许就是最好的，于是决定转向 Ubuntu。
选择的系统是 Linux Mint，在经过了一个晚上之后，就得到了：

image

标题也许换成 《Linux 作为主力系统》 更合适。

]]> https://cooooing.github.io/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/ArchLinux%E4%BD%9C%E4%B8%BA%E4%B8%BB%E5%8A%9B%E7%B3%BB%E7%BB%9F/ 2025-11-30T10:14:07.000Z 系统

之前就在虚拟机和笔记本上装过 ArchLinux，想尝试尝试 Linux 系统作为主力开发系统。
主要原因是 windows 的命令行]]>

ArchLinux作为主力系统 2025-11-30T10:14:07.000Z 咕咕咕 这一篇不止是徒步线的记录，还记录了国庆假期左右的其他，其实分两三篇应该会更好。

国庆前

首先国庆和中秋连在一起放了八天假期。
公司在节前发了蟹卡（五公五母十只螃蟹）和两个柚子。螃蟹带回家了没有尝到，柚子倒是很不错。

image

家

国庆假期的前几天在家，久违的过年的感觉。只是比过年的人少了很多，没有那么的热闹，但也足够了。
和朋友去吃了火锅，六个人吃了不到四百，人均才六十多，不到七十。相比我之前和现在工作的地方真的是便宜太多了。
那家火锅店也是很偏僻了，在县城的边边上，旁边就是农田了，对面就是护城河。

image

朋友还跑了两三家药店帮我买药，我跑了几家也没得卖。最后买到了四小瓶。
后来朋友妈妈知道了还打电话来和我说，因为朋友舅舅得过这个病，所以她比较了解，给我推荐了别的药。
真的非常感谢了。

去姨妈家吃饭，在门口盆里的鸡胗和肠子还被猫叼跑了。痛失两道菜。
一共四只猫，还为了这些吃的打架。
对峙吵架中…

image

吃完后就躺在树下的花坛边睡觉，过得真舒服啊。

徒步

假期后半程回到杭州，准备和朋友去徒步。
计划路线是：九溪公交站 - 九溪烟树 - 九溪十八涧 - 龙井村 - 十里锒铛 - 云栖竹径
但是实际上并没有走这条线。

我俩在九溪公交站会合，这里可以看到钱塘江：

image

到了之后，就开始向里进发。应该是沿着小溪一路向上，不多久就可以到九溪烟树。

image
image

再往后，一路上都能碰到各种小溪。喜欢玩水的人会非常开心了，大热天玩水也是很舒服。

image
image

然后就是龙井村，这里的每家每户好像都卖茶叶。
这里商业化不是非常严重，每家都是独栋建筑，有些巷子可以看到别人家的院子，有些在路边会有弄得很好看的花园。

image

在龙井村这里，我们偏离了原定路线。准备接着向北走，去法喜寺尝下素斋。
此时已经下午快一点，除了路上带的几瓶水，两块面包和几块巧克力，我们没吃别的。（饿啊
但后面是上山的路，也是最难走的。

image
image

接着爬到山顶，有个三叉还是四岔路，往法喜寺的方向是下山的方向。一路上都是树荫遮蔽，比上山的茶田一路上晒过来要好了很多。
出了树林，有一段很长很长的下坡，坡度很大。没有阶梯，纯坡。看着护林员骑着电动车走大S线骑上来…

下山后，到法喜寺。进门每人给了三柱香。（朋友说他是党员，所以我有了六柱
寺门口有很多人在摸字。
寺里的锦鲤很多很好看。

image
image
image

在法喜寺休息了很久，有大麦茶和菊花茶。
可惜的是因为在修缮的原因，没有吃到素斋。

不过出了寺庙之后，去吃了一家素食自主，是今天的第一顿饭了。此时已经四点了大概（有点难崩，不过吃了三碗

image

最后迎着夕阳去往公交站，准备坐公交去云栖竹径（他说是不能忘记最开始的目标

image

公交等了很久很久，324H线！
等车的时候，遇到了一家印度人（应该是印度人，非常经典的印度形象）。应该是老父亲，他的英语和中文说的都不错，和他儿子交流是他们自己的语言。
大概聊了一些。

等坐上公交，到达云栖竹径时，已经七点了，天已经黑了。
然后云栖竹径关门了！很遗憾，只能回家了。

遗憾也是常态，不按计划、随心而动的旅途才是放松身心的旅游。相遇是缘，不遇也是。
没有赶进度的计划，没有被时间追着跑。能在公交站等一个小时的公交，和遇到印度人聊聊天也不错，不是吗。

]]> https://cooooing.github.io/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/%E6%9D%AD%E5%B7%9E%E4%B9%9D%E6%BA%AA%E8%87%B3%E4%BA%91%E6%A0%96%E7%AB%B9%E5%BE%84%E5%BE%92%E6%AD%A5%E7%BA%BF/ 2025-10-23T12:41:49.000Z 这一篇不止是徒步线的记录，还记录了国庆假期左右的其他，其实分两三篇应该会更好。

国庆前

首先国庆和中秋连在一起放了八天假期。<]]>

杭州九溪至云栖竹径徒步线 2025-10-23T12:41:49.000Z 咕咕咕 前言

Ubuntu、Deepin之类的玩腻了，尝试下新鲜玩意。
最开始在旧电脑上尝试直接安装，但是失败了，很多报错，现在看来是镜像源的问题。
然后尝试在 Hyper-V 虚拟机中安装，过程很顺利，基本没有问题。
最后再次尝试在旧电脑物理机上安装，有了虚拟机的经验，安装也比较顺利。
唯一失败的就是：分区时没注意磁盘，将分区信息写到了系统u盘，导致u盘数据丢失。惨痛的教训 lsblk 或者 fdisk -l 很重要！

安装 Arch Linux 系统

首先进入 Arch Live 环境（archiso），是官方 ISO 引导后的安装环境。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Arch Linux 6.15.8-arch1-2 (tty1)

archiso login:root (automatic login)

To install Arch Linux follow the installation guide:
https://wiki.archlinux.org/title/Installation_guide

For Wi-Fi,authenticate to the wireless network using the iwctl utility.
For mobile broadband (WWAN) modems,comnect with the mmcli utility.
Ethernet,WLAN and WWAN interfaces using DHCP should work automatically.

After comnecting to the internet,the installation guide can be accessed
via the convenience script Installation_guide.

root@archiso ~ #

配置网络

ping archlinux.org -c 3 确认是否有网络

如果是有线网络，通常自动就有网络。如果是 WIFI ，使用 iwctl 命令：

1
2
3
4
5
6
7
8
iwctl
# 交互模式下（示例）
device list
station wlan0 scan
station wlan0 get-networks
station wlan0 connect YOUR_SSID
station list # 用于查看连接状态
# exit 返回

启动模式

ls /sys/firmware/efi/efivars 用于输出 EFI 变量，区分启动模式是 BIOS 还是 UEFI。

  • BIOS 启动：内核只会得到传统的硬件初始化信息，不会加载 EFI 相关功能。
  • UEFI 启动：内核会通过 UEFI 固件接口（EFI Runtime Services）获得一系列 EFI 变量（比如引导顺序、启动项、安全启动开关等）。Linux 内核会把这些变量暴露在文件系统里，就是 /sys/firmware/efi/efivars。

所以 UEFI 启动必须有一个 EFI 分区 (ESP)，格式化为 FAT32，挂载到 /boot 或 /boot/efi。

BIOS 与 UEFI

BIOS：

  • 历史悠久：BIOS（Basic Input/Output System）是上世纪 80 年代就有的固件。
  • 分区表限制：BIOS 通常和 MBR 分区表搭配使用。MBR 最大只支持 2TB 硬盘容量，最多 4 个主分区。
  • 启动方式：BIOS 启动时，会从磁盘开头的 MBR (Master Boot Record) 读取引导代码，然后加载操作系统。
  • 兼容性好：老机器几乎都是 BIOS，新机器大多支持兼容模式（CSM），可以让 BIOS 模式继续使用。

UEFI：

  • 现代标准：UEFI（Unified Extensible Firmware Interface）是 BIOS 的替代品，大多数 2015 年以后的电脑默认用 UEFI。
  • 分区表支持：UEFI 通常和 GPT 分区表搭配。GPT 支持 >2TB 的硬盘，分区数量几乎无限制。
  • 启动方式：UEFI 会读取硬盘上的 EFI 系统分区 (ESP)，里面存放引导程序（例如 grubx64.efi 或 systemd-boot）。
  • 功能更强：支持图形界面、鼠标操作、安全启动（Secure Boot）、多系统管理更方便。

分区设置

一定注意分区设置的位置！
事先使用 lsblk 或者 fdisk -l 命令查看磁盘信息，确定分区位置。

创建分区

1
fdisk /dev/sda

然后依次输入：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
g                   # 创建 GPT 分区表

n                   # 新建分区 1
<回车>              # 分区号，直接回车（默认 1）
<回车>              # 起始扇区，直接回车（默认）
+512M               # 结束扇区，输入大小 → +512M
t                   # 改类型
1                   # 选择分区 1
1                   # 设置为 EFI System

n                   # 新建分区 2
<回车>              # 分区号，直接回车（默认 2）
<回车>              # 起始扇区，直接回车
+2G                 # 结束扇区，输入大小 → +2G
t                   # 改类型
2                   # 选择分区 2
19                  # 设置为 Linux swap

n                   # 新建分区 3
<回车>              # 分区号，直接回车（默认 3）
<回车>              # 起始扇区，直接回车
<回车>              # 结束扇区，直接回车（用完剩余空间）

w                   # 保存并退出

格式化分区

1
2
3
4
5
6
7
8
9
# EFI 分区
mkfs.fat -F32 /dev/sda1

# swap 分区
mkswap /dev/sda2
swapon /dev/sda2

# 根分区
mkfs.ext4 /dev/sda3

挂载分区

1
2
3
mount /dev/sda3 /mnt
mkdir -p /mnt/boot
mount /dev/sda1 /mnt/boot

配置镜像源（可选）

  1. 临时使用国内镜像
    在 live 环境里，修改 pacman 的镜像源列表： 
    1
    2
    3
    4
    5
    # 先备份原来的
    cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak

    # 编辑镜像列表
    nano /etc/pacman.d/mirrorlist
    把国内源放到前面，例如： 
    1
    2
    3
    Server = https://mirrors.tuna.tsinghua.edu.cn/archlinux/$repo/os/$arch
    Server = https://mirrors.ustc.edu.cn/archlinux/$repo/os/$arch
    Server = https://mirrors.aliyun.com/archlinux/$repo/os/$arch

    注意：把想用的镜像放在 最上面，pacman 会优先使用。
    保存退出后，运行：

    1
    pacman -Syyu

  2. 选择最快的镜像
    Arch 自带 reflector 工具（Live ISO 可能没有，需要先安装）： 
    1
    2
    pacman -Sy reflector --noconfirm
    reflector --country China --latest 5 --sort rate --save /etc/pacman.d/mirrorlist
    会自动选择最近最快的中国镜像。

安装基础系统

1
pacstrap /mnt base linux linux-firmware vim nano networkmanager

安装完成后生成 fstab：

1
genfstab -U /mnt >> /mnt/etc/fstab

然后进入新系统环境：

1
arch-chroot /mnt

安装并配置 bootloader（UEFI 推荐 GRUB 或 systemd-boot）

使用 GRUB（UEFI）

1
2
3
pacman -S --noconfirm grub efibootmgr dosfstools os-prober mtools
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

使用 GRUB（BIOS）

1
2
3
pacman -S --noconfirm grub
grub-install --target=i386-pc /dev/sda   # 注意写在磁盘（如 /dev/sda），不是分区
grub-mkconfig -o /boot/grub/grub.cfg

系统其余配置

  1. 时区： 
    1
    2
    ln -sf /usr/share/zoneinfo/Asia/Taipei /etc/localtime
    hwclock --systohc
  2. 本地化（示例同时启用 zh_CN.UTF-8 与 en_US.UTF-8）： 
    1
    2
    3
    4
    5
    sed -i 's/^#zh_CN.UTF-8/zh_CN.UTF-8/' /etc/locale.gen
    sed -i 's/^#en_US.UTF-8/en_US.UTF-8/' /etc/locale.gen
    locale-gen
    echo LANG=zh_CN.UTF-8 > /etc/locale.conf
    echo KEYMAP=us > /etc/vconsole.conf   # 如需中文控制台可改为 zh_CN
  3. 主机名与 hosts： 
    1
    2
    3
    4
    5
    echo arch > /etc/hostname
    cat >> /etc/hosts <<EOF
    127.0.0.1localhost
    ::1    localhost
    EOF
  4. root 密码： 
    1
    passwd

安装 ssh 服务

sudo pacman -S --noconfirm openssh
sudo systemctl enable sshd
sudo systemctl start sshd

记得编辑/etc/ssh/sshd_config:

1
2
3
PasswordAuthentication yes   # 允许密码登录
PermitRootLogin yes          # 如果你用 root 登录（可选）
UsePAM yes                   # 必须启用 PAM

sudo systemctl restart sshd

安装 KDE 桌面环境

sudo pacman -Syu 更新系统
sudo pacman -S --noconfirm xorg 安装 Xorg（显示服务器）

安装 KDE Plasma 桌面和常用应用：

  • sudo pacman -S --noconfirm plasma kde-system-meta kde-utilities-meta 最小化安装，比较轻量
  • sudo pacman -S --noconfirm plasma kde-applications 完整安装（含所有 KDE 应用，比如浏览器、相册、邮件客户端等）

安装登录管理器（推荐 SDDM）：

1
2
sudo pacman -S --noconfirm sddm
sudo systemctl enable sddm

sudo pacman -S noto-fonts noto-fonts-cjk noto-fonts-emoji adobe-source-han-sans-cn-fonts adobe-source-han-serif-cn-fonts 安装 KDE 常用中文字体

手动指定QT环境变量，在 ~/.xprofile 或 ~/.bashrc 里加上：

1
2
3
export LANG=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8
export QT_QPA_PLATFORMTHEME=kde
]]> https://cooooing.github.io/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/ArchLinux%E5%AE%89%E8%A3%85/ 2025-09-21T14:38:38.000Z 前言

Ubuntu、Deepin之类的玩腻了，尝试下新鲜玩意。
最开始在旧电脑上尝试直接安装，但是失败了，很多报错，现在看来是镜像源的问题。]]>

ArchLinux安装 2025-09-21T14:38:38.000Z 咕咕咕 Go 时间布局格式

Go 使用 参考时间 Mon Jan 2 15:04:05 MST 2006 来定义格式，而不是像 C 语言或 Python 的 %Y %m %d。

类型标记含义示例（参考时间 2025-09-06 11:45:05.123456789）注意事项
年2006四位年份2025常用于完整年份显示
06两位年份25适合老式格式或节省字符
月01两位数字月份090 填充
1数字月份（无前导零）9方便简写
Jan英文缩写月份Sep三个字母英文缩写
January英文全称月份September更易读，长度可变
日02两位数字日060 填充
_2空格填充日 6用于对齐，日<10时左侧空格
小时1524 小时制110-23
0312 小时制110-12，0 会显示为 12
312 小时制，无前导零110-12
分钟/秒04分钟45两位数字
05秒05两位数字
上下午PM大写 AM/PMAM12 小时制，区分大小写
pm小写 am/pmam12 小时制，区分大小写
时区MST时区缩写SGT / CST / UTC受系统时区影响，可能有歧义
-0700数值时区偏移（无冒号）+0800可解析性高，推荐用于存储/传输
Z07:00数值时区偏移（含冒号）+08:00 或 Z（UTC）RFC3339 常用
引号'...'单引号内内容按字面量输出"'06" → '25可在格式中插入固定字符
小数秒.000毫秒.123固定 3 位小数
.000000微秒.123456固定 6 位小数
.000000000纳秒.123456789固定 9 位小数
星期Mon英文缩写星期Sat三个字母
Monday英文全称星期Saturday适合全名显示
其他符号TISO 8601 中的时间分隔符T直接输出字母 T
- / : 直接输出-、/、:可以自由组合布局

注意事项

  1. 空格填充 vs 零填充：
    • _2 → 空格填充的日，02 → 零填充。
  2. 时区选择：
    • MST → 缩写，易读但解析可能歧义。
    • -0700/Z07:00 → 数值偏移，更标准、更安全。
  3. 12 小时制 vs 24 小时制：
    • 3/03 → 12 小时制，配合 PM/pm。
    • 15 → 24 小时制。
  4. 小数秒：
    • StampMilli / StampMicro / StampNano 都基于 .000/.000000/.000000000。

Go time 包时间格式常量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
package time

const (
Layout      = "01/02 03:04:05PM '06 -0700" // The reference time, in numerical order.
ANSIC       = "Mon Jan _2 15:04:05 2006"
UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
RFC822      = "02 Jan 06 15:04 MST"
RFC822Z     = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
RFC3339     = "2006-01-02T15:04:05Z07:00"
RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
Kitchen     = "3:04PM"
// Handy time stamps.
Stamp      = "Jan _2 15:04:05"
StampMilli = "Jan _2 15:04:05.000"
StampMicro = "Jan _2 15:04:05.000000"
StampNano  = "Jan _2 15:04:05.000000000"
DateTime   = "2006-01-02 15:04:05"
DateOnly   = "2006-01-02"
TimeOnly   = "15:04:05"
)

Go time 包时间格式常量对照表

名称布局字符串示例输出（2025-09-06 11:45:05 +08:00）典型用途注意事项
Layout01/02 03:04:05PM '06 -070009/06 11:45:05AM '25 +0800Go 的参考布局示例，展示格式规则实际项目中较少直接使用
ANSICMon Jan _2 15:04:05 2006Sat Sep 6 11:45:05 2025类 Unix 日志/老式系统_2 表示空格填充日期
UnixDateMon Jan _2 15:04:05 MST 2006Sat Sep 6 11:45:05 SGT 2025类 Unix 日期（带时区缩写）MST 会替换为实际时区缩写，可能有歧义
RubyDateMon Jan 02 15:04:05 -0700 2006Sat Sep 06 11:45:05 +0800 2025Ruby 默认日期格式使用数值时区，无歧义
RFC82202 Jan 06 15:04 MST06 Sep 25 11:45 SGT老邮件标准两位年份+时区缩写，解析不安全
RFC822Z02 Jan 06 15:04 -070006 Sep 25 11:45 +0800RFC822 数值时区版优于 RFC822，推荐
RFC850Monday, 02-Jan-06 15:04:05 MSTSaturday, 06-Sep-25 11:45:05 SGT早期 HTTP/邮件日期已过时
RFC1123Mon, 02 Jan 2006 15:04:05 MSTSat, 06 Sep 2025 11:45:05 SGTHTTP-date（旧版）通常用 GMT，时区缩写有歧义
RFC1123ZMon, 02 Jan 2006 15:04:05 -0700Sat, 06 Sep 2025 11:45:05 +0800HTTP-date（推荐版）更精确，兼容性好
RFC33392006-01-02T15:04:05Z07:002025-09-06T11:45:05+08:00JSON / API 常用UTC 时输出 Z，否则 +HH:MM
RFC3339Nano2006-01-02T15:04:05.999999999Z07:002025-09-06T11:45:05.123456789+08:00高精度 API 日志输出到纳秒，0 的处理依版本不同
Kitchen3:04PM11:45AM简洁 UI 时间显示无秒、无日期
StampJan _2 15:04:05Sep 6 11:45:05简洁日志时间戳无年、无时区
StampMilliJan _2 15:04:05.000Sep 6 11:45:05.000日志，带毫秒固定 3 位小数
StampMicroJan _2 15:04:05.000000Sep 6 11:45:05.000000日志，带微秒固定 6 位小数
StampNanoJan _2 15:04:05.000000000Sep 6 11:45:05.000000000日志，带纳秒固定 9 位小数
DateTime2006-01-02 15:04:052025-09-06 11:45:05数据库/日志常用无时区，解析时需额外设定
DateOnly2006-01-022025-09-06仅日期字段常见于表单、数据库
TimeOnly15:04:0511:45:05仅时间字段无日期、无时区

格式化输出测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
package test

import (
"fmt"
"testing"
"time"
)

func TestName(t *testing.T) {
now := time.Now()
layouts := map[string]string{
"Layout":      "01/02 03:04:05PM '06 -0700",
"ANSIC":       time.ANSIC,
"UnixDate":    time.UnixDate,
"RubyDate":    time.RubyDate,
"RFC822":      time.RFC822,
"RFC822Z":     time.RFC822Z,
"RFC850":      time.RFC850,
"RFC1123":     time.RFC1123,
"RFC1123Z":    time.RFC1123Z,
"RFC3339":     time.RFC3339,
"RFC3339Nano": time.RFC3339Nano,
"Kitchen":     time.Kitchen,
"Stamp":       time.Stamp,
"StampMilli":  time.StampMilli,
"StampMicro":  time.StampMicro,
"StampNano":   time.StampNano,
"DateTime":    "2006-01-02 15:04:05",
"DateOnly":    "2006-01-02",
"TimeOnly":    "15:04:05",
}

for name, layout := range layouts {
fmt.Printf("%-12s : %s\n", name, now.Format(layout))
}

fmt.Println("\n-- UTC 格式化 --")
for name, layout := range layouts {
fmt.Printf("%-12s : %s\n", name, now.UTC().Format(layout))
}
}

输出结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
=== RUN   TestName
ANSIC        : Sat Sep  6 14:03:17 2025
UnixDate     : Sat Sep  6 14:03:17 CST 2025
RubyDate     : Sat Sep 06 14:03:17 +0800 2025
RFC822Z      : 06 Sep 25 14:03 +0800
RFC850       : Saturday, 06-Sep-25 14:03:17 CST
RFC1123Z     : Sat, 06 Sep 2025 14:03:17 +0800
RFC3339      : 2025-09-06T14:03:17+08:00
RFC3339Nano  : 2025-09-06T14:03:17.9708592+08:00
Kitchen      : 2:03PM
Stamp        : Sep  6 14:03:17
StampNano    : Sep  6 14:03:17.970859200
DateTime     : 2025-09-06 14:03:17
DateOnly     : 2025-09-06
TimeOnly     : 14:03:17
Layout       : 09/06 02:03:17PM '25 +0800
RFC822       : 06 Sep 25 14:03 CST
RFC1123      : Sat, 06 Sep 2025 14:03:17 CST
StampMilli   : Sep  6 14:03:17.970
StampMicro   : Sep  6 14:03:17.970859

-- UTC 格式化 --
UnixDate     : Sat Sep  6 06:03:17 UTC 2025
RubyDate     : Sat Sep 06 06:03:17 +0000 2025
RFC822Z      : 06 Sep 25 06:03 +0000
RFC850       : Saturday, 06-Sep-25 06:03:17 UTC
RFC1123Z     : Sat, 06 Sep 2025 06:03:17 +0000
RFC3339      : 2025-09-06T06:03:17Z
RFC3339Nano  : 2025-09-06T06:03:17.9708592Z
Kitchen      : 6:03AM
Stamp        : Sep  6 06:03:17
StampNano    : Sep  6 06:03:17.970859200
DateTime     : 2025-09-06 06:03:17
DateOnly     : 2025-09-06
TimeOnly     : 06:03:17
Layout       : 09/06 06:03:17AM '25 +0000
RFC822       : 06 Sep 25 06:03 UTC
RFC1123      : Sat, 06 Sep 2025 06:03:17 UTC
StampMilli   : Sep  6 06:03:17.970
StampMicro   : Sep  6 06:03:17.970859
ANSIC        : Sat Sep  6 06:03:17 2025
--- PASS: TestName (0.01s)
PASS
]]> https://cooooing.github.io/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/Go%E5%86%85%E7%BD%AE%E6%97%B6%E9%97%B4%E5%B8%B8%E9%87%8F%E6%A0%BC%E5%BC%8F%EF%BC%88time%E5%8C%85%EF%BC%89%E5%AF%B9%E7%85%A7%E8%A1%A8/ 2025-09-06T05:43:56.000Z Go 时间布局格式

Go 使用 参考时间 Mon Jan]]>

Go内置时间常量格式（time包）对照表 2025-09-06T05:43:56.000Z 咕咕咕 top 命令

top 命令是 Linux 常用的实时系统监控工具。它默认每隔 3 秒刷新一次。

启动参数（命令行选项）

参数全称作用
-d secondsdelay-time刷新间隔（默认 3 秒），例如 top -d 1 每 1 秒刷新一次
-n countnumber-of-iterations运行多少次后退出，例如 top -n 5 显示 5 次后退出
-p pidprocess-id仅监控指定进程，例如 top -p 1234
-u useruser-name仅显示指定用户的进程，例如 top -u root
-U userUID-based类似 -u，但基于 UID
-bbatch-mode批处理模式（无交互，常用于重定向到文件：top -b -n 1 > out.txt）
-Hthreads-mode显示线程而非进程
-iidle-process toggle启动时忽略空闲任务（= 运行时按 i）
-ccommand-line toggle显示完整命令行（= 运行时按 c）

交互式快捷键（运行时输入）

显示控制

按键全称作用
hhelp显示帮助（所有快捷键说明）
qquit退出 top
zcolor/mono toggle切换彩色/单色模式
Bbold toggle是否加粗高亮
lload-average toggle显示/隐藏顶部的负载信息
ttasks toggle显示/隐藏任务和 CPU 使用情况
mmemory toggle显示/隐藏内存/Swap 行
1cpu-per-core展开/收起所有 CPU 核心的使用率

排序与过滤

按键全称作用
Psort by CPU按 CPU 使用率排序（默认）
Msort by Memory按内存使用率排序
Tsort by Time按运行时间排序
Nsort by PID按 PID 排序
Rreverse sort反向排序
O（大写）change sort field按其他字段排序（进入交互菜单选择）
o（小写）filter by field过滤显示（例如 COMMAND=nginx）
ufilter by user只显示某个用户的进程

进程控制

按键全称作用
kkill杀死进程（输入 PID 和信号，默认 15 SIGTERM）
rrenice调整进程 Nice 值（输入 PID 和新 nice 值）
sset-delay修改刷新间隔（秒）
Wwrite config保存当前配置，下次启动生效（写入 ~/.toprc）

进程显示切换

按键全称作用
ccommand-line toggle显示完整命令行 vs 仅命令名
iidle toggle显示/隐藏空闲进程
Hthreads toggle显示线程而不是进程
xhighlight sort column高亮当前排序列
yhighlight running tasks高亮正在运行的任务
uuser filter只显示指定用户的进程
Vforest view树状显示进程（类似 pstree）

显示信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
top - 13:24:16 up 3 days, 22:41,  0 user,  load average: 0.14, 0.14, 0.11
Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.3 us,  0.8 sy,  0.0 ni, 97.1 id,  0.7 wa,  0.0 hi,  0.1 si,  0.0 st 
MiB Mem :   7940.7 total,    222.3 free,   6399.8 used,   1590.8 buff/cache     
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1540.9 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                    
 1197 root      20   0 1963420 640468  36736 S   4.0   7.9 282:35.87 kube-apiserver                                                                             
 2327 root      20   0 2237824  49708  24064 S   1.3   0.6  80:30.91 calico-node                                                                                
  771 root       0 -20   11.3g  89348  23552 S   1.0   1.1  79:04.21 etcd                                                                                       
 1228 root      20   0 1412044  84508  21376 S   1.0   1.0  78:41.97 kube-controller                                                                            
32616 root      20   0 2227064  92080  50560 S   1.0   1.1  79:00.74 kubelet                                                                                    
 1212 root      20   0 1283348  32972  13056 S   0.3   0.4  15:25.14 kube-scheduler                                                                             
 1648 root      20   0  746604  16832   6400 S   0.3   0.2   9:40.87 node-cache                                                                                 
15415 root      20   0       0      0      0 I   0.3   0.0   0:00.28 kworker/1:1-events                                                                         
31742 root      20   0 2398412  60844  29696 S   0.3   0.7  26:17.82 containerd                                                                                 
43556 ubuntu    20   0   13228   6528   4352 R   0.3   0.1   0:00.18 top                                                                                        
    1 root      20   0   23084  12288   7680 S   0.0   0.2   1:12.93 systemd                                                                                    
    2 root      20   0       0      0      0 S   0.0   0.0   0:00.05 kthreadd                                                                                   
    3 root      20   0       0      0      0 S   0.0   0.0   0:00.00 pool_workqueue_release                                                                     
    4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_g                                                                            
    5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_p                                                                            
    6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-slub_                                                                            
    7 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-netns                                                                            
    9 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/0:0H-events_highpri                                                                
   12 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-mm_pe                                                                            
   13 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_kthread                                                                          
   14 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_rude_kthread                                                                     
   15 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_trace_kthread                                                                    
   16 root      20   0       0      0      0 S   0.0   0.0   0:13.07 ksoftirqd/0                                                                                
   17 root      20   0       0      0      0 I   0.0   0.0   1:02.67 rcu_preempt                                                                                
   18 root      rt   0       0      0      0 S   0.0   0.0   0:02.89 migration/0                                                                                
   19 root     -51   0       0      0      0 S   0.0   0.0   0:00.00 idle_inject/0                                                                              
   20 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/0                                                                                    
   21 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/2                                                                                    
   22 root     -51   0       0      0      0 S   0.0   0.0   0:00.00 idle_inject/2                                                                              
   23 root      rt   0       0      0      0 S   0.0   0.0   0:02.40 migration/2

顶部状态

1
top - 13:24:16 up 3 days, 22:41,  0 user,  load average: 0.14, 0.14, 0.11
  • 13:24:16 → 当前系统时间
  • up 3 days, 22:41 → 系统已运行 3 天 22 小时 41 分钟
  • 0 user → 当前登录用户数（这里没有用户直接登录）
  • load average: 0.14, 0.14, 0.11 系统 1 分钟、5 分钟、15 分钟的平均负载。数字越接近 CPU 核心数，说明负载越合理。比如 4 核 CPU，load average 小于 4 基本健康。
1
Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
  • 163 total → 系统中共有 163 个进程
  • 1 running → 正在运行的进程 1 个
  • 162 sleeping → 休眠状态的进程 162 个（大部分进程常处于此状态，等待事件触发）
  • 0 stopped → 停止的进程（通过信号暂停）
  • 0 zombie → 僵尸进程（子进程结束但父进程未回收资源，数量多时是问题信号）
1
%Cpu(s):  1.3 us,  0.8 sy,  0.0 ni, 97.1 id,  0.7 wa,  0.0 hi,  0.1 si,  0.0 st
  • 1.3 us (user space) → 用户态进程占用 CPU 1.3%
  • 0.8 sy (system) → 内核态占用 CPU 0.8%
  • 0.0 ni (nice) → 调整过 nice 优先级的进程占用 0%
  • 97.1 id (idle) → CPU 空闲 97.1%
  • 0.7 wa (I/O wait) → 等待 I/O 的 CPU 时间（磁盘/网络）
  • 0.0 hi (hardware interrupt) → 硬件中断占用 CPU 时间百分比
  • 0.1 si (software interrupt) → 软件中断占用 CPU 时间百分比
  • 0.0 st (steal time) → 被虚拟机管理程序（Hypervisor）“偷走”的 CPU 时间百分比（虚拟化场景有意义）

一般关注 us+sy（实际负载），如果 wa 很高，说明 I/O 瓶颈。

1
MiB Mem :   7940.7 total,    222.3 free,   6399.8 used,   1590.8 buff/cache
  • 7940.7 total → 总内存 7.9 GB
  • 222.3 free → 空闲内存 222 MB（未使用部分，Linux 下通常较小）
  • 6399.8 used → 被程序使用的内存 6.4 GB（包含应用+缓存）
  • 1590.8 buff/cache → 缓冲和缓存内存（用于磁盘缓存和文件缓存，可回收）
1
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1540.9 avail Mem
  • total 0.0 → 没有配置 swap 分区
  • free 0.0 → 空闲 Swap
  • used 0.0 → 已用 Swap
  • avail Mem 1540.9 → 实际可用内存 1.5 GB（考虑缓存和可回收内存），比 free 更准确

如果 Swap used 很高，说明物理内存不足。

进程列表

1
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  • PID (Process ID) → 进程 ID（唯一标识）
  • USER → 进程所有者（用户名）
  • PR (Priority) → （内核调度的优先级，数值越小优先级越高）
  • NI (Nice) → nice 值（用户可调节，-20 ~ 19，影响优先级）
  • VIRT (Virtual Memory) → 进程使用的虚拟内存 (KB)，进程申请的总地址空间，包括共享库、映射文件等
  • RES (Resident Memory) → 进程常驻物理内存 (KB)，实际占用的物理内存
  • SHR (Shared Memory) → 共享内存 (KB)，与其他进程共享的内存
  • S (State) → 进程状态
    • R → running
    • S → sleeping
    • I → idle
    • D → 不可中断睡眠
    • Z → 僵尸
  • %CPU (CPU usage) → CPU 使用率（按刷新周期计算）
  • %MEM (Memory usage) → 内存使用率（占总内存百分比）
  • TIME+ (CPU Time) → 进程累计使用的 CPU 时间，格式 分钟:秒.百分秒
  • COMMAND → 进程的命令或程序名（默认显示简写，可按 c 显示完整命令行）

一些指标的概念

Nice 值 (Niceness Value)

调节进程的优先级 (Priority, PR)，影响 CPU 调度的先后顺序。

  • 取值范围：-20 ~ 19

    • -20 → 最高优先级（最“自私”，会多抢占 CPU）
    • 0 → 默认值
    • 19 → 最低优先级（最“友好”，让出 CPU 机会）

  • 关系：

    • 最终调度优先级由 PR = base_priority + NI 决定
    • top 里 PR 越小，进程调度优先级越高

  • 修改方式：

    • 启动时指定：nice -n 10 my_program
    • 运行时调整：renice -n -5 -p 1234 （调整 PID=1234 的进程）

  • 大型数据分析进程可以 nice=10 → 不阻塞关键服务

  • 系统关键进程可能会设置低 nice 值（-5 ~ -20），保证调度优先级

交换空间 (Swap Space)

当物理内存不足时，Linux 会把部分不常用的内存页写到磁盘上的 Swap 区域，以释放 RAM。
可以让系统避免“内存不足直接崩溃”。但磁盘速度远低于内存，频繁使用 Swap 会导致性能下降（俗称“抖动 / thrashing”）。

  • 在 top 的 Swap used 升高时，说明内存吃紧
  • 进程会明显变慢

Kubernetes 中默认不允许使用交换内存

Kubernetes 的调度和资源控制主要依赖于 cgroup 的 CPU、内存限制。

  • 内存限制：Pod 被限制多少内存，超过就会触发 OOMKill。
  • 如果允许 swap，那么：
    • Pod 占用的物理内存可能被换出到 swap，而 kubelet 和 cgroup 并不知道。
    • 容器可能“假装”没超内存，实际上性能已经变得非常差。
    • 这会导致 资源隔离失真，调度器也无法准确分配资源。

因此，Kubernetes 默认要求节点运行在 no swap 的状态下，以保证资源控制的可预测性。

但 Kubernetes 在后续版本有支持开启交换内存的功能：

New in Kubernetes v1.22: alpha support for using swap memory
Kubernetes 1.28: Beta support for using swap on Linux

虚拟内存 (Virtual Memory, VIRT)

每个进程拥有独立的地址空间（虚拟内存），由操作系统内核管理并映射到实际物理内存或磁盘。

包含内容：

  1. 程序代码
  2. 已分配但未实际使用的内存
  3. 动态库
  4. 内存映射文件（mmap）
  5. 可能被换出到 Swap 的部分

指标含义：

  • top 里的 VIRT → 进程可寻址的虚拟内存总量（不等于真实占用 RAM）
  • RES → 真实常驻物理内存
  • SHR → 共享内存

举例：一个 Python 程序加载 TensorFlow，VIRT 可能几十 GB，但 RES 可能只有几百 MB，因为很多库只是映射，并没有真正加载到内存。

中断 (Interrupt)

中断是 CPU 在运行用户代码时，被“打断”去处理某个事件的机制。分为硬件中断和软件中断。

硬件中断 (Hardware Interrupt, hi)

来源：外部硬件设备向 CPU 发出信号
例子：

  • 键盘输入（按下一个键）
  • 网络接口卡收到数据包
  • 磁盘 I/O 完成通知

类比：你正在写字（运行程序），突然电话响了（键盘输入），你必须停下去接电话（处理硬件中断）。

软件中断 (Software Interrupt, si)

来源：内核为处理高频硬件事件，把一些工作转交给“软中断”机制（通常由内核线程完成）。
例子：

  • 网络包的协议栈处理（TCP/IP 解析）
  • 大量磁盘 IO 的后续处理

类比：电话太多了，你雇了秘书（内核线程）来代接一部分，这就是软件中断。

]]> https://cooooing.github.io/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/top%E5%91%BD%E4%BB%A4/ 2025-09-03T02:01:14.000Z top 命令

top 命令是 Linux 常用的实时系统监控工具。它默认每隔 3 秒刷新一次。

在并发编程中，锁是用于同步线程、避免数据竞争和确保线程安全的重要机制。

互斥锁（Mutex）

互斥锁是最基本的锁类型，确保同一时间只有一个线程可以访问共享资源。

  • 线程获取锁后，其他尝试获取锁的线程会被阻塞，直到锁被释放。
  • 通常用于保护临界区（Critical Section）。
  • 实现简单，但可能导致线程阻塞和上下文切换开销。

用于需要确保独占访问共享资源的场景。

读写锁（Read-Write Lock）

允许多个线程同时读取共享资源，但写操作需独占访问。

  • 读锁：多个线程可同时持有读锁（共享锁）。
  • 写锁：写锁是独占的，写时不允许其他读或写操作。
  • 提高并发性能，尤其在读多写少的场景。

是互斥锁的一种扩展，区分读写操作以提升性能。

用于读操作频繁、写操作较少的场景，如数据库缓存。

条件锁（Condition Lock）

结合条件变量，用于线程间的协作，线程在特定条件满足时才继续执行。

  • 通常与互斥锁配合使用，线程等待条件满足时进入休眠，条件满足时被唤醒。
  • 提高效率，避免忙等待。

条件锁依赖互斥锁，互斥锁保护共享条件变量。

用于生产者-消费者模型、线程同步等待。

信号量（Semaphore）

一种计数器机制，控制多个线程对有限资源的访问。

  • 允许指定数量的线程同时访问资源（计数>1）。
  • 当计数为1时，行为类似于互斥锁。

信号量是互斥锁的泛化，支持多线程并发访问。互斥锁限制为单一线程访问。

用于限制并发访问数量，如连接池管理。

分布式锁

在分布式系统中，用于协调多个进程或节点对共享资源的访问。

  • 跨机器实现，通常基于外部存储（如Redis、ZooKeeper、Etcd）。
  • 需考虑网络延迟、节点故障等复杂情况。

分布式锁是互斥锁的分布式扩展，适用于跨进程或跨机器场景。本地锁（如Mutex）仅限于单机多线程。

用于分布式系统中协调跨进程或跨节点的资源访问，如分布式任务调度。

悲观锁和乐观锁（加锁策略）

悲观锁（Pessimistic Lock）

悲观锁假设并发操作中冲突（数据竞争）发生的概率较高，因此在访问共享资源之前，总是先获取锁，确保独占访问。其他线程在锁被释放前会被阻塞。

适用于写操作频繁、冲突概率高、数据一致性要求严格的场景。
如互斥锁、读写锁、数据库锁（行锁、表锁）。

乐观锁（Optimistic Lock）

乐观锁假设并发操作中冲突发生的概率较低，允许线程先执行操作，在提交时检查数据是否被修改。
如果未被修改，则提交成功；否则，回滚并重试。乐观锁通常不使用传统锁机制，而是依赖版本控制或原子操作。

乐观锁是非阻塞的，线程直接操作共享资源，而无需等待锁。
通过版本号、时间戳或CAS（Compare-And-Swap）检查数据是否被修改。

适用于读多场景，高并发低冲突。
如缓存更新、计数器

阻塞锁和非阻塞锁（等待机制）

阻塞锁（Blocking Lock）

阻塞锁是指当线程尝试获取锁时，如果锁已被其他线程占用，当前线程会进入阻塞状态（挂起），等待锁释放。
阻塞状态通常由操作系统管理，线程被放入等待队列，暂停执行，直到被唤醒。

锁不可用时，线程被挂起，释放CPU资源。
但通常涉及线程的上下文切换（从用户态到内核态），开销较高。
线程唤醒和重新调度可能引入延迟。

适用于需要强一致性、长时间持有锁或高冲突场景。
互斥锁、读写锁、条件锁都属于阻塞锁。

非阻塞锁（Non-Blocking Lock）

非阻塞锁是指当线程尝试获取锁时，如果锁不可用，线程不会进入阻塞状态，而是立即返回（失败）或通过忙等待（busy-waiting）继续尝试。
非阻塞锁通常基于原子操作实现，尽量避免操作系统介入。

锁不可用时，线程要么立即返回，要么短暂自旋（循环尝试）。
基于原子操作（如CAS、Test-and-Set），通常在用户态完成。
自旋可能浪费CPU资源，但避免上下文切换。

适用于需要高吞吐量、短锁持有时间、冲突概率较低的场景。
自旋锁、乐观锁属于非阻塞锁。TryLock机制用于快速失败（尝试获取锁，失败则立即返回）。

可重入锁和非可重入锁（重入性）

基于锁是否允许同一线程多次获取的特性进行分类。
它们在实现线程安全和避免死锁方面有显著差异。

可重入锁（Reentrant Lock）

可重入锁允许同一线程多次获取同一把锁而不会导致死锁。每次获取锁时，锁内部会记录重入次数，线程必须释放相同次数的锁才能完全解锁。

同一线程可多次调用Lock()，每次增加锁的计数器。
释放时需调用Unlock()与Lock()次数相同，计数器减为0时锁被释放。

适用于复杂逻辑中，同一线程多次进入临界区（递归函数或嵌套调用）的场景。

非可重入锁（Non-Reentrant Lock）

非可重入锁不允许同一线程多次获取同一把锁。如果线程尝试重复加锁，会导致死锁或异常。

适用于简单互斥场景。

公平锁和非公平锁（分配策略）

根据锁的分配策略分类。
区别在于当多个线程（或goroutine）竞争锁时，锁是否按照线程请求的顺序（通常是先到先得）分配。

公平锁（Fair Lock）

公平锁确保线程按照请求锁的顺序获取锁，通常采用先到先得（FIFO，First-In-First-Out）策略。
当锁释放时，等待队列中最先请求的线程优先获得锁。

线程按请求顺序获取锁，避免线程饥饿（某些线程长期无法获取锁）。
维护了一个队列，用于记录线程的请求顺序。在锁被释放时，唤醒队列头部的线程。

适用于需要严格公平性、避免线程饥饿的场景。
需要维护队列，性能相对较低。

非公平锁（Non-Fair Lock）

非公平锁不保证线程按请求顺序获取锁。
当锁释放时，等待线程和新请求线程竞争锁，操作系统或运行时决定哪个线程获得锁，可能导致后请求的线程优先获取。

不保证FIFO，可能导致线程饥饿（某些线程长期无法获取锁）。

适用于追求高性能、允许一定程度不公平的场景。

锁会引发的问题

死锁（deadlock）

多个线程互相持有对方需要的锁，导致所有线程无法继续执行。

死锁产生的四个必要条件（梦回操作系统课）：

  • 互斥条件：一个资源每次只能被一个进程使用。
  • 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
  • 不剥夺条件：进程已获得的资源，在没使用完之前，不能强行剥夺。
  • 循环等待条件：多个进程之间形成一种互相循环等待资源的关系。

发生场景：

  • 多个锁的嵌套获取，且顺序不一致。
  • 非可重入锁（如sync.Mutex）在同一线程重复加锁。

解决方法（破坏四个必要条件）：

  • 统一线程的请求锁的顺序，以保证线程能获取到所需的全部资源而不阻塞，进而保证不发生死锁。
  • 避免线程持有锁并等待锁。在请求锁时，如果锁被其他线程占用，不等待，而是将之前持有的锁释放，保证其他线程顺利执行。

活锁（Livelock）

线程不断尝试获取锁但无法成功，处于活跃但无进展的状态。
活锁其实是避免死锁的一种方式——避免线程持续尝试获取锁，而是通过等待或随机退避来避免。

举个例子：
在一个比较窄但允许两人同行的马路上，两个人相对而行，如果两个人相撞
死锁是：两个人僵持不动，谁都无法往前走
活锁是：两个人都很客气的让路给对方，但是两人同时移动到另一侧，又继续相撞，再移动回来又相撞，一直这样持续下去，那么就会发生活锁

活锁发生的概率是非常非常低的，两人的移动必须一直保持完全同步才可以，不然很快就可以解锁

发生场景：

  • 非阻塞锁（如自旋锁）在高竞争下持续重试。
  • 两个线程互相礼让锁（如CAS失败后退避）。

解决方法：

  • 引入随机退避（如指数退避）。
  • 限制重试次数，切换到阻塞锁。

线程饥饿（Starvation）

死锁或活锁描述的是多个线程的整体状态，线程饥饿描述的是单个线程的状态。
饥饿是某些线程长期无法获取锁，导致无法执行。

发生场景：

  • 非公平锁（如sync.Mutex）优先新请求线程。
  • 高优先级线程抢占锁。

解决方法：

  • 使用公平锁。
  • 调整线程优先级或调度策略。

优先级反转（Priority Inversion）

高优先级线程因等待低优先级线程释放共享资源（如锁）而被阻塞，而低优先级线程可能被其他中优先级线程抢占，导致高优先级线程的执行延迟。
这种现象违背了优先级调度原则，可能导致实时系统无法满足时间要求。

发生场景：

  • 实时系统中，低优先级线程持有锁，高优先级线程被阻塞。

解决方法：

  • 优先级继承（低优先级线程临时提升优先级，确保低优先级的线程优先于中优先级线程运行，尽快释放锁。）
  • 优先级提升（为每个锁设置最高优先级，持有锁的线程提升到该优先级）

伪唤醒（Spurious Wakeup）

伪唤醒是指线程在等待条件变量（如条件锁）时，被操作系统或运行时无故唤醒，而条件并未满足。

伪唤醒是操作系统或并发库实现条件变量时的一种副作用，其原因主要与底层实现和优化相关。
操作系统可能设计为允许伪唤醒，在Signal()或Broadcast()时唤醒多个等待线程，而不是精确唤醒一个。以提高效率或简化同步原语的实现，防止复杂场景下的死锁或错误。
伪唤醒是条件变量实现的“不可避免副作用”，标准（如POSIX、C++）明确允许其存在。
设计上，条件变量不保证“仅当条件满足时唤醒”，因此在使用条件锁时需要额外的处理。

解决方法：

  • 使用循环检查条件

由单次检查条件改为循环检查条件：

1
2
3
4
5
mu.Lock()
if !condition() {
    cond.Wait()
}
mu.Unlock()
1
2
3
4
5
mu.Lock()
for !condition() {
    cond.Wait()
}
mu.Unlock()

ABA问题

ABA问题是指在并发环境中，线程读取共享变量的值为A，准备通过CAS更新时，变量可能被其他线程修改为B后再改回A。由于CAS只检查值是否为A，线程误认为变量未被修改，执行更新操作，导致逻辑错误。

  • 可能导致数据不一致（如无锁栈中重复使用已释放的内存）。
  • 破坏程序逻辑，尤其在涉及指针或资源管理的场景。

任何基于CAS操作的并发控制机制，比如非阻塞锁（自旋锁、乐观锁）、无锁数据结构等，都会引发ABA问题。
涉及内存重用（如指针回收后重新分配相同地址）也会引发。

ABA问题的核心是CAS无法区分“值未变”和“值变回原值”。

解决方法：

  • 版本号/时间戳：CAS检查值和版本，两次CAS，分别比较。
  • 双字CAS（Compare-And-Swap-Double），同时比较两个值（如值和版本号）：单次CAS，需要硬件支持DCAS。
  • 垃圾回收：垃圾回收可以避免指针立即重用，降低ABA问题风险。
  • Tagged Pointers：在指针中嵌入版本信息，CAS操作检查整个指针（值+版本），避免ABA问题，复杂实现。
  • 避免指针重用：使用新分配内存或对象池，避免值恢复原状。
  • 阻塞锁：如sync.Mutex，完全避免ABA。
]]> https://cooooing.github.io/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E5%B8%B8%E7%94%A8%E7%9A%84%E9%94%81/ 2025-07-31T06:22:54.000Z 在并发编程中，锁是用于同步线程、避免数据竞争和确保线程安全的重要机制。

互斥锁（Mutex）

常用的锁 2025-07-31T06:22:54.000Z 咕咕咕 介绍

时间轮（Timing Wheel）是一种高效的时间管理数据结构，广泛应用于网络协议、操作系统、定时任务调度等领域。
时间轮的核心思想是将时间划分为多个“槽”（slot），每个槽对应一个时间单位，并通过指针的旋转来管理定时任务。

时间轮的两种设计

时间轮由多个时间槽组成，每个时间槽对应一个时间单位（如1毫秒、1秒等），是它所支持的最小粒度。
时间轮的核心是一个环形数组，数组的每个元素代表一个时间槽。时间轮有一个指针，指向当前的时间槽，随着时间的推进，指针会顺时针移动，类似于钟表的指针。

  1. 初始化：时间轮初始化时，所有时间槽为空。
  2. 添加任务：当需要添加一个定时任务时，系统会根据任务的延迟时间计算出它应该被放置在哪个时间槽中。例如，如果当前指针指向第 n 个槽，任务的延迟时间为 t，每个槽的时间单位为 Δt，则任务应被放置在 (n + t / Δt) % N 个槽中（其中 N 是时间轮的总槽数）。
  3. 指针移动：每隔一个时间单位（如1毫秒），指针向前移动一个槽。
  4. 任务执行：当指针到达某个槽时，该槽中的所有任务都会被执行。

为了支持更长的定时任务，有两个拓展时间轮的设计。多层时间轮和记录圈数的时间轮。

多层时间轮模仿了现实世界中的时钟结构：秒针、分针、时针分别代表不同层级的时间单位。每一层时间轮负责一个时间单位（如秒、分、小时），低层时间轮每完成一圈，上层时间轮前进一格。

例如：
第一层：每个槽代表1秒，共60槽（代表1分钟）
第二层：每个槽代表1分钟，共60槽（代表1小时）
第三层：每个槽代表1小时，共24槽（代表1天）

每隔一个时间单位（如1秒），最底层时间轮指针移动
如果最底层完成一圈，第二层移动一格
如果第二层完成一圈，第三层移动一格
每当最底层的指针移动到某个槽时，执行该槽中的所有任务。
当其他层的指针移动到某个槽时，将该槽中的任务加入下一层的时间轮。高层轮的任务只是“占位符”，真正的执行在最底层（秒轮）进行。

例如一个任务在 1小时2分钟3秒后执行。当前时间为21:30:02，任务在22:32:05执行。

层级槽号说明
时轮221小时后触发，触发后将任务推进到分轮
分轮3232分钟后触发，触发后将任务推进到秒轮
秒轮55秒后执行最终任务

它支持非常长延时的任务，并且内存占用较低，时间复杂度为O(1)。但实现复杂，需要处理多级时间轮联动。

记录圈数的时间轮在每个槽中不仅记录任务，还记录该任务需要等待的圈数（round）。指针每移动一圈，所有任务的圈数减一，当圈数为零时执行任务。

它是一个固定大小的时间轮（如32或64个槽）。每个槽是一个任务列表，每个任务额外记录圈数。

每次指针移动一个槽
遍历当前槽中所有任务：如果任务的round > 0，round -= 1，如果 round == 0，执行任务

它的结构简单易于实现，支持较长的延迟，时间复杂度也为O(1)。但它每次移动指针时需要遍历当前槽中的所有任务。

实现

这里实现记录圈数方式的时间轮。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
package timewheel

import (
"container/list"
"errors"
"github.com/orcaman/concurrent-map/v2"
"github.com/panjf2000/ants/v2"
"github.com/sirupsen/logrus"
"runtime/debug"
"time"
)

// TimeWheel 核心结构体
type TimeWheel struct {
interval          time.Duration // 时间轮的精度
slots             []*list.List  // 时间轮每个位置存储的Task列表
ticker            *time.Ticker  // 时间轮的计时器
currentPos        int           // 时间轮当前的位置
slotNums          int           // 时间轮的齿轮数 interval*slotNums就是时间轮转一圈走过的时间
addTaskChannel    chan *Task
removeTaskChannel chan *Task
stopChannel       chan bool
taskRecords       cmap.ConcurrentMap[string, *list.Element] // Map结构来存储Task对象，key是Task.key，value是Task在双向链表中的存储对象list.Element
isRunning         bool
pool              *ants.Pool // 协程池
}

// Job 需要执行的Job的函数结构体
type Job func(task *Task)

// Task 时间轮上需要执行的任务
type Task struct {
Key         string        // 用来标识task对象，是唯一的
Interval    time.Duration // 任务周期
Times       int           // 任务需要执行的次数，如果需要一直执行，设置成-1
Job         Job           // 任务需要执行的Job
createdTime time.Time     // 任务的创建时间
pos         int           // 任务在轮的位置
circle      int           // 任务需要在轮走多少圈才能执行
}

// ErrDuplicateTaskKey is an definedError for duplicate task key
var ErrDuplicateTaskKey = errors.New("duplicate task key")

// ErrTaskKeyNotFount is an definedError when task key is not found
var ErrTaskKeyNotFount = errors.New("task key doesn't existed in task list, please check your input")

// NewTimeWheel 初始化一个TimeWheel对象
func NewTimeWheel(interval time.Duration, slotNums int) *TimeWheel {
if interval <= 0 || slotNums <= 0 {
return nil
}
pool, err := ants.NewPool(
16,
ants.WithPreAlloc(true),
ants.WithNonblocking(true),
)
if err != nil {
logrus.Errorf("init [timewhell] ants pool failed: %v", err)
}
tw := &TimeWheel{
interval:          interval,
slots:             make([]*list.List, slotNums),
currentPos:        0,
slotNums:          slotNums,
addTaskChannel:    make(chan *Task, 16),
removeTaskChannel: make(chan *Task, 16),
stopChannel:       make(chan bool),
taskRecords:       cmap.New[*list.Element](),
isRunning:         false,
pool:              pool,
}
tw.initSlots()
return tw
}

// Start 启动时间轮
func (tw *TimeWheel) Start() {
tw.ticker = time.NewTicker(tw.interval)
go func(tw *TimeWheel) {
for {
select {
case <-tw.ticker.C:
tw.checkAndRunTask()
case task := <-tw.addTaskChannel:
tw.addTask(task, false)
case task := <-tw.removeTaskChannel:
tw.removeTask(task)
case <-tw.stopChannel:
tw.ticker.Stop()
return
}
}
}(tw)
tw.isRunning = true
}

// Stop 关闭时间轮
func (tw *TimeWheel) Stop() {
tw.stopChannel <- true
tw.isRunning = false
tw.pool.Release()
}

// IsRunning 检查全局时间轮是否在正常运行
func (tw *TimeWheel) IsRunning() bool {
return tw.isRunning
}

// Exist 检查任务是否存在
func (tw *TimeWheel) Exist(key string) bool {
_, ok := tw.taskRecords.Get(key)
return ok
}

// GetTaskTimes 获取任务剩余执行次数
func (tw *TimeWheel) GetTaskTimes(key string) int {
t, ok := tw.taskRecords.Get(key)
if !ok {
return 0
}
return t.Value.(*Task).Times
}

// AddTask 向时间轮添加固定周期任务
func (tw *TimeWheel) AddTask(task *Task) error {
if task.Interval <= 0 || task.Key == "" {
return errors.New("invalid task params")
}

// 检查Task.Key是否已经存在
_, ok := tw.taskRecords.Get(task.Key)
if ok {
return ErrDuplicateTaskKey
}
task.createdTime = time.Now()
tw.addTaskChannel <- task
return nil
}

// RemoveTask 从时间轮删除任务
func (tw *TimeWheel) RemoveTask(key string) error {
if key == "" {
return nil
}

// 检查该Task是否存在
val, ok := tw.taskRecords.Get(key)
if !ok {
return ErrTaskKeyNotFount
}

task := val.Value.(*Task)
tw.removeTaskChannel <- task
return nil
}

// 初始化时间轮，每个轮上的卡槽用一个双向队列表示，便于插入和删除
func (tw *TimeWheel) initSlots() {
for i := 0; i < tw.slotNums; i++ {
tw.slots[i] = list.New()
}
}

// 检查该轮点位上的Task，看哪个需要执行
func (tw *TimeWheel) checkAndRunTask() {

// 获取该轮位置的双向链表
currentList := tw.slots[tw.currentPos]

if currentList != nil {
for item := currentList.Front(); item != nil; {
task, ok := item.Value.(*Task)
if !ok {
item = item.Next()
continue
}
next := item.Next()
if task.circle > 0 {
task.circle--
} else {
if task.Job != nil {
// 使用协程池执行任务
err := tw.pool.Submit(func() {
defer func() {
if err := recover(); err != nil {
stack := debug.Stack()
logrus.Errorf("task %v panic: %v %s\n", task.Key, err, string(stack))
}
}()
task.Job(task)
})
if err != nil {
logrus.Errorf("task %v submit failed: %v\n", task.Key, err)
}
} else {
logrus.Warnf("The task %s don't have job to run\n", task.Key)
}

tw.taskRecords.Remove(task.Key)
currentList.Remove(item)

if task.Times < 0 {
tw.addTask(task, true) // 无限次，继续添加
} else if task.Times > 1 {
task.Times--
tw.addTask(task, true) // 剩余次数大于1，继续添加
}

}
item = next
}
}

// 轮前进一步
tw.currentPos = (tw.currentPos + 1) % tw.slotNums
}

// 添加任务的内部函数
func (tw *TimeWheel) addTask(task *Task, byInterval bool) {
var pos, circle int
// 使用任务周期或创建时间生成
if byInterval {
pos, circle = tw.getPosAndCircleByInterval(task.Interval)
} else {
pos, circle = tw.getPosAndCircleByCreatedTime(task.createdTime, task.Interval)
}

task.circle = circle
task.pos = pos

element := tw.slots[pos].PushBack(task)
tw.taskRecords.Set(task.Key, element)
}

// 删除任务的内部函数
func (tw *TimeWheel) removeTask(task *Task) {
val, ok := tw.taskRecords.Get(task.Key)
if !ok {
return
}
tw.taskRecords.Remove(task.Key)
if t, ok := val.Value.(*Task); ok && t.pos < tw.slotNums {
tw.slots[t.pos].Remove(val)
}
}

// 该函数通过任务的周期来计算下次执行的位置和圈数
func (tw *TimeWheel) getPosAndCircleByInterval(d time.Duration) (int, int) {
delayMs := int(d.Milliseconds())
intervalMs := int(tw.interval.Milliseconds())
ticks := delayMs / intervalMs
circle := ticks / tw.slotNums
pos := (tw.currentPos + ticks) % tw.slotNums

// 特殊case，当计算的位置和当前位置重叠时，因为当前位置已经走过了，所以circle需要减一
if pos == tw.currentPos && circle != 0 {
circle--
}
return pos, circle
}

// 该函数用任务的创建时间来计算下次执行的位置和圈数
func (tw *TimeWheel) getPosAndCircleByCreatedTime(createdTime time.Time, d time.Duration) (int, int) {
delayMs := int(d.Milliseconds())
intervalMs := int(tw.interval.Milliseconds())
ticksPassed := int(time.Since(createdTime).Milliseconds()) / intervalMs
totalTicks := delayMs / intervalMs
remainingTicks := totalTicks - ticksPassed

if remainingTicks <= 0 {
remainingTicks = 1 // 防止立即过期
}

circle := remainingTicks / tw.slotNums
pos := (tw.currentPos + remainingTicks) % tw.slotNums

// 特殊case，当计算的位置和当前位置重叠时，因为当前位置已经走过了，所以circle需要减一
if pos == tw.currentPos && circle != 0 {
circle--
}

return pos, circle
}

测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
package test

import (
"catventure-idle-server/internal/common/timewheel"
"github.com/sirupsen/logrus"
"testing"
"time"
)

func TestTimeWheel(t *testing.T) {
var err error
tw := timewheel.NewTimeWheel(time.Second, 60)
tw.Start()

err = tw.AddTask(&timewheel.Task{
Key:      "test1",
Interval: time.Second * 5,
Times:    -1,
Job: func(task *timewheel.Task) {
logrus.Infof("task %s run at %s\n", task.Key, time.Now().Format("2006-01-02 15:04:05"))
},
})
if err != nil {
logrus.Errorf("add task failed: %v", err)
}
err = tw.AddTask(&timewheel.Task{
Key:      "test2",
Interval: time.Second * 1,
Times:    10,
Job: func(task *timewheel.Task) {
logrus.Infof("task %s run at %s\n", task.Key, time.Now().Format("2006-01-02 15:04:05"))
},
})
if err != nil {
logrus.Errorf("add task failed: %v", err)
}

time.Sleep(time.Second * 30) // 休眠30s，查看运行结果
}

运行结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
=== RUN   TestTimeWheel
time="2025-07-24T22:24:57+08:00" level=info msg="task test2 run at 2025-07-24 22:24:57\n"
time="2025-07-24T22:24:58+08:00" level=info msg="task test2 run at 2025-07-24 22:24:58\n"
time="2025-07-24T22:24:59+08:00" level=info msg="task test2 run at 2025-07-24 22:24:59\n"
time="2025-07-24T22:25:00+08:00" level=info msg="task test2 run at 2025-07-24 22:25:00\n"
time="2025-07-24T22:25:00+08:00" level=info msg="task test1 run at 2025-07-24 22:25:00\n"
time="2025-07-24T22:25:01+08:00" level=info msg="task test2 run at 2025-07-24 22:25:01\n"
time="2025-07-24T22:25:02+08:00" level=info msg="task test2 run at 2025-07-24 22:25:02\n"
time="2025-07-24T22:25:03+08:00" level=info msg="task test2 run at 2025-07-24 22:25:03\n"
time="2025-07-24T22:25:04+08:00" level=info msg="task test2 run at 2025-07-24 22:25:04\n"
time="2025-07-24T22:25:05+08:00" level=info msg="task test2 run at 2025-07-24 22:25:05\n"
time="2025-07-24T22:25:05+08:00" level=info msg="task test1 run at 2025-07-24 22:25:05\n"
time="2025-07-24T22:25:10+08:00" level=info msg="task test1 run at 2025-07-24 22:25:10\n"
time="2025-07-24T22:25:15+08:00" level=info msg="task test1 run at 2025-07-24 22:25:15\n"
time="2025-07-24T22:25:20+08:00" level=info msg="task test1 run at 2025-07-24 22:25:20\n"
--- PASS: TestTimeWheel (30.00s)
PASS
]]> https://cooooing.github.io/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/%E7%BC%96%E7%A8%8B%E8%AE%B0%E5%BD%95/%E6%97%B6%E9%97%B4%E8%BD%AE/ 2025-07-23T14:29:39.000Z 介绍

时间轮（Timing Wheel）是一种高效的时间管理数据结构，广泛应用于网络协议、操作系统、定时任务调度等领域。
时间轮的核心思想是]]>

时间轮 2025-07-23T14:29:39.000Z 咕咕咕 来杭州一个月了，总算是去了次西湖。
五月中到杭州来，碰到朋友换工作六月中来杭州。算是他乡遇故知了，缘分。
于是在一个周日的雨天，一起去西湖。（为什么是雨天呢，我也不知道。可能雨中的西湖更有意境吧

在江城站会合，先去吃了片川儿垫垫肚子。
然后准备去鼓楼。

这是望仙阁上拍的，可以看到吴山上的寺庙和鼓楼堂（基督教堂）。

image
image

后面是鼓楼，进去是南宋书房，有很多文创和冰箱贴。

image
image
image

再往里就是河坊街，正常景区的商业街。很多小吃，还有中药店（叶种德堂）。

image

朱炳仁铜雕艺术博物馆，全是铜雕的工艺品。

image

杭州博物馆，杭州出土的文物，历史等。杭州现在有大大小小两百多家博物馆。

image
image

博物馆逛了很久，出来后两三点左右，去吃了蟹黄面。第一口很鲜，非常不错。

image
image
image

再然后就是西湖了。断桥残雪、苏堤。雨天人还是挺多，不过雨天的意境肯定也不一样。

image
image
image
image

烟雨朦胧的感觉
最后，全都淋湿了。不过也很久没有这么淋过雨了，还是挺舒服的。

20公里！
image

]]> https://cooooing.github.io/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/%E7%83%9F%E9%9B%A8%E8%A5%BF%E6%B9%96/ 2025-06-29T09:57:54.000Z 来杭州一个月了，总算是去了次西湖。
五月中到杭州来，碰到朋友换工作六月中来杭州。算是他乡遇故知了，缘分。
于是在一个周日的雨天，一起去西湖。（为什么是雨天呢，我也不知道。可能雨中的西湖更有意境吧

在江城站会合，先去吃了片川儿垫垫肚子。
然后准]]>

烟雨西湖 2025-06-29T09:57:54.000Z 咕咕咕 很久没有写博客了，回顾下近况吧。

最大的变动就是工作了，劳动节前提了离职，5月16号上完最后一天半。然后就开始了两周的休息。
第一周主要去医院做了体检，和朋友吃了个饭。也是告别待了快两年的南京（两年了也没怎么把南京的景点玩玩，有点可惜
周一体检，周四拿到体检报告。除了口腔有点问题（智齿有点阻生，浅龋和1度牙结石），其他都非常正常。也许得找个时间去看看牙，之前根管治疗的牙还没有补。

回到工作相关，没记错的话，是在23年9月26号开始实习，24年7月1号签的劳动合同，到今年5月16号离职结束。也是待了快二十个月（对于一份工作来说，感觉是有些短
跟同事相处的感觉也是很不错了，和同事一起租房住了十个月（血亏两个月房租
下面是娟姐送的抱枕
image

关于什么时候决定离开，比实际要早的很多。
最现实的就是我能在南京拿到的薪资比其他的城市低（上海杭州这些互联网发达的地方）。
其次重要的是个人的成长，其实早就一眼看到头了。或许我继续待在那里三年五年，多少会接触到新的东西，但对于我来说有些太慢了。
四月份左右去用户现场碰到我的 leader，他还会问我最近学了什么。说人的技术热情在刚工作的两三年是最高的，成长也是最快的。后面就不会再有了。
这段我还是比较认同的，在刚工作的时候，接触到企业协作，与个人做事是完全不一样的。越大的企业确实如此吧。
为了适应工作，肯定会多去学习。但随着工作的深入，如果不是有兴趣支持，这份热情很快就会消磨。（当兴趣爱好成为工作，很容易消磨掉兴趣。肯定有人说过不要将兴趣爱好当成工作的话

话说回来，当时在看 Kafka（也记了两篇笔记）。他和我说的另一个主题大概就是要关注架构层面的设计，使用层面都差不多，就是如何使用API，看着文档很快就能上手。
这个怎么说呢，我觉得架构层面需要服务具体的业务，同时也跟并发编程一样，需要长时间的运行才能暴露出足够多的问题。
但更加关注架构层面肯定也是没有问题的，和并发编程一样，思考各种可能出现的情况，会有什么问题，怎么解决。
架构层面其实很难离开分布式和微服务，虽然我认为大部分公司单体的架构已经足够使用。
这些都多少会影响我后面的学习方向，go的学习应该是很早之前了，真正想java转go可能只是今年年初。但语言只是微不足道的一部分…（这里省略吧，后续的方向暂时还没有想好

关于新的工作，它其实没有我想象中那样。
新的工作是在杭州的一个小公司，相比上家，在人员配置和开发流程上差的是非常大的。感觉是第一次组建开发团队。
用go写了两周，不得不感慨java生态上的全面。java的繁琐其实也不是java本身，印象中有句话是这么说的：复杂度不会消失，只会被转移到系统的各个地方。
大概是泰斯勒定律（Tesler’s Law），又称复杂度守恒定律（Law of Conservation of Complexity）
spring是个非常厉害的框架，它的抽象程度也是非常之高（当初还去读源码，太不自量力了）。它将系统配置、拓展性等大部分业务无关的复杂度都隐藏在了框架内部，使得对业务的开发变得非常简单，关注的点也非常少。

新同事是三年经验的go开发，最近和他的话题主要在 go、docker 和 kubernetes。
今天下班的路上，也许是看出了我的迷茫，跟我说了一些云原生的方向。kubernetes、服务网格 istio、链路之类的东西，都在云原生方向之中。
看来 kubernetes 是要深度使用的了，虽然我觉得大部分业务都用不上。我现在倒是更倾向单体架构，到单机扛不住的时候可以上分布式（这个需要单体开发时就注意分布式部分，否则改造会比较麻烦），到分布式服务太多运维管理上顶不住的时候才是上kubernetes的时候。
倒也是符合架构的发展历史，不管是架构还是框架、中间件都是为了解决对应具体问题而出现的解决方案。分布式与微服务还是有区别的，微服务大概就是服务划分、拆分之后的各种服务的分布式，服务间的依赖通过rpc解耦。（描述得比较抽象了

最后，写到这里已经不早了，该结束了。
对于以后，大方向已经定下来了。具体什么方向可能还得探索下。
另，希望新工作顺利。也许会留在杭州。

]]> https://cooooing.github.io/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/%E8%AE%B0%E5%BD%95%E7%94%9F%E6%B4%BB/%E8%AE%B0%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%A6%BB%E8%81%8C/ 2025-06-11T15:14:33.000Z 很久没有写博客了，回顾下近况吧。

最大的变动就是工作了，劳动节前提了离职，5月16号上完最后一天半。然后就开始了两周的休息。
第一周主要去医院做了体检，和朋友吃了个饭。也是告别待了快两年的南京（两年了也没怎么把南京的景点玩玩，有点可惜
周一体检，周]]>

记第一次离职 2025-06-11T15:14:33.000Z 咕咕咕 基础环境准备（可选）

虚拟机配置

基础环境这里选择 multipass 虚拟机。（但只是使用它创建虚拟机）
当然，如果有真实物理机，并且他们网络是直通的，那可以省去很多配置的麻烦。这里大部分关于虚拟机的配置应该都可以省略。
但很可惜，我并没有那么多机器或者云服务器。但好在我的电脑（windows11）内存有64G，足够我随意的折腾。

创建三台虚拟机（一主二从）

1
2
3
multipass launch --name=master --cpus=2 --m=4096MiB -d 20G 24.04
multipass launch --name=worker1 --cpus=2 --m=4096MiB -d 20G 24.04
multipass launch --name=worker2 --cpus=2 --m=4096MiB -d 20G 24.04

基础网络配置（固定ip配置）

这里我需要为每台虚拟机都设置一个固定ip，防止机器重启后ip会发生变化，导致需要频繁改一些配置。Multipass 默认通过 NAT 网络 + DHCP 动态分配 IP
将宿主机ip固定为192.168.1.5
master 节点的ip为 192.168.1.10
worker1 节点的ip为 192.168.1.11
worker2 节点的ip为 192.168.1.12

这里以 master 节点为例，展示配置过程。

首先打开Hyper-V 管理器，右侧虚拟交换机管理器，新建虚拟交换机。如下图：
image

保存之后，来到网络适配器，为刚创建的虚拟交换机设置一个固定的ip。
image

修改/etc/netplan/50-cloud-init.yaml：

1
2
3
4
5
6
7
8
9
10
11
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses: [ 192.168.1.10/24 ]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [ 192.168.1.1 ]

应用更改并验证

1
2
3
4
5
6
7
8
# 应用更改
sudo netplan apply
# 应用更改
sudo netplan --debug apply
# 检查 IP 是否生效
ip a show eth0
# 测试网络连通性
ping 192.168.1.1

输出如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ubuntu@master:/etc/netplan$ ip a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 52:54:00:29:3e:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2409:8a20:2a0:6c60:5054:ff:fe29:3ee9/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 198387sec preferred_lft 111987sec
    inet6 fe80::5054:ff:fe29:3ee9/64 scope link
       valid_lft forever preferred_lft forever
ubuntu@master:/etc/netplan$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=7.33 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.45 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=3.77 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=4.16 ms
^C
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 3.449/4.675/7.326/1.550 ms

配置域名

在三台虚拟机的 /etc/hosts 文件末尾添加：

1
2
3
192.168.1.10 master
192.168.1.11 worker1
192.168.1.12 worker2

配置ssh登录

这里配置ssh密码登录，以方便外部宿主机连接使用。（因为修改为固定ip后，multipass将无法连接到虚拟机）

设置密码：

1
sudo passwd ubuntu

修改/etc/ssh/sshd_config配置中的以下内容：

1
2
3
4
5
6
# 是否允许使用密码登录 SSH
PasswordAuthentication yes
# 是否允许使用公钥认证登录 SSH
PubkeyAuthentication yes
# 是否启用 PAM（Pluggable Authentication Modules，可插拔认证模块）
UsePAM no

注意：是否包含Include /etc/ssh/sshd_config.d/*.conf配置
它支持包含其他配置文件，从而实现配置的模块化和可维护性。所有配置会合并，顺序按文件名排序加载，后加载的内容会覆盖前面的设置。

重启 ssh 服务应用更改后，就可以在宿主机使用配好的固定ip进行ssh登录了：

1
sudo systemctl restart ssh

配置全局代理

Linux中，设置全系统代理（包括 GUI 图形界面 + CLI），需要修改/etc/environment文件；仅为 shell 用户（终端）设置代理，需要修改/etc/profile文件；为单用户设置代理，需要修改~/.bashrc文件。

/etc/environment文件添加：

1
2
3
4
http_proxy="http://192.168.1.5:7890"
https_proxy="http://192.168.1.5:7890"
all_proxy="socks5://192.168.1.5:7890"
no_proxy="localhost,127.0.0.1,::1"

重启应用更改。

/etc/profile或者~/.bashrc文件添加：

1
2
3
4
export http_proxy=http://192.168.1.5:7890
export https_proxy=http://192.168.1.5:7890
export all_proxy=socks5://192.168.1.5:7890
export no_proxy="localhost,127.0.0.1,::1"

source /etc/profile或者source ~/.bashrc应用更改。

取消代理：unset http_proxy https_proxy all_proxy

验证代理是否生效，可以使用curl -v https://www.google.com
会返回包含类似Connected to 192.168.1.5 (192.168.1.5) port 7890的内容，如下（上述命令返回过长，这里以本地服务为例）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
ubuntu@master:~$ curl -v http://192.168.1.5:8000/api/user/v1/helloworld/ubuntu
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,::1'
* Uses proxy env variable http_proxy == 'http://192.168.1.5:7890'
*   Trying 192.168.1.5:7890...
* Connected to 192.168.1.5 (192.168.1.5) port 7890
> GET http://192.168.1.5:8000/api/user/v1/helloworld/ubuntu HTTP/1.1
> Host: 192.168.1.5:8000
> User-Agent: curl/8.5.0
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< Content-Length: 26
< Connection: keep-alive
< Content-Type: application/json
< Date: Wed, 23 Apr 2025 15:34:03 GMT
< Keep-Alive: timeout=4
< Proxy-Connection: keep-alive
<
* Connection #0 to host 192.168.1.5 left intact
{"message":"Hello ubuntu"}

kubernetes 环境搭建

部署 Server

这里使用 K3s - 轻量级 Kubernetes 部署。
与 Kubernetes 不同，这里的 Master 节点叫 Server 节点，而 Slave 节点叫 Agent 节点。

部署 Server 节点 curl -sfL https://get.k3s.io | sh -

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ubuntu@master:~$ curl -sfL https://get.k3s.io | sh -
[INFO]  Finding release for channel stable
[INFO]  Using v1.32.3+k3s1 as release
[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.32.3+k3s1/sha256sum-amd64.txt
[INFO]  Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.32.3+k3s1/k3s
[INFO]  Verifying binary download
[INFO]  Installing k3s to /usr/local/bin/k3s
[INFO]  Skipping installation of SELinux RPM
[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
[INFO]  Creating /usr/local/bin/crictl symlink to k3s
[INFO]  Creating /usr/local/bin/ctr symlink to k3s
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
[INFO]  systemd: Enabling k3s unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
[INFO]  systemd: Starting k3s

查看节点运行状态kubectl get node：

1
2
3
ubuntu@master:~$ sudo kubectl get node
NAME     STATUS   ROLES                  AGE   VERSION
master   Ready    control-plane,master   78s   v1.32.3+k3s1

获取 node-token cat /var/lib/rancher/k3s/server/node-token 在部署 Agent 节点的时候需要用到：

1
2
ubuntu@master:~$ sudo cat /var/lib/rancher/k3s/server/node-token
K104869223bb6e5c3c1bb95bc7dcc505cb2d5576cf2253e9bd0df1b3a7852f91397::server:368a64fba85ad0718fe841967df1717f

部署 Agent

部署 Agent 节点 curl -sfL https://get.k3s.io | K3S_URL=https://server:6443 K3S_TOKEN=token sh -

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ubuntu@worker1:~$ curl -sfL https://get.k3s.io | K3S_URL=https://master:6443 K3S_TOKEN=K104869223bb6e5c3c1bb95bc7dcc505cb2d5576cf2253e9bd0df1b3a7852f91397::server:368a64fba85ad0718fe841967df1717f sh -
[INFO]  Finding release for channel stable
[INFO]  Using v1.32.3+k3s1 as release
[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.32.3+k3s1/sha256sum-amd64.txt
[INFO]  Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.32.3+k3s1/k3s
[INFO]  Verifying binary download
[INFO]  Installing k3s to /usr/local/bin/k3s
[INFO]  Skipping installation of SELinux RPM
[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
[INFO]  Creating /usr/local/bin/crictl symlink to k3s
[INFO]  Creating /usr/local/bin/ctr symlink to k3s
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-agent-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s-agent.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s-agent.service
[INFO]  systemd: Enabling k3s-agent unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s-agent.service → /etc/systemd/system/k3s-agent.service.
[INFO]  systemd: Starting k3s-agent

节点都部署完后，节点状态如下：

1
2
3
4
5
ubuntu@master:~$ sudo kubectl get node
NAME      STATUS   ROLES                  AGE   VERSION
master    Ready    control-plane,master   18m   v1.32.3+k3s1
worker1   Ready    <none>                 29s   v1.32.3+k3s1
worker2   Ready    <none>                 5s    v1.32.3+k3s1

设置 K3S_URL 参数会使 K3s 以 worker 模式运行。 K3s agent 会在所提供的 URL 上向监听的 K3s 服务器注册。

到这里，Kubernetes 环境搭建完成。

创建 Deployment

创建nginx-deployment.yaml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 定义 Deployment 基本信息
metadata.name: 给这个 Deployment 起个名字。
apiVersion: apps/v1 # Deployment 所使用的 API 版本，K8s 1.9+ 都是 apps/v1。
kind: Deployment # 资源类型是 Deployment。
metadata:
  name: nginx # Deployment 的名字。
# 定义副本数量和 Pod 选择器
spec:
  replicas: 2 # 创建副本数量
  selector:
    matchLabels:
      app: nginx # Deployment 会管理所有 带有标签 app=nginx 的 Pod。它必须和后面的模板里的 labels 保持一致。
  # 定义 Pod 模板（template）
  template:
    metadata:
      labels:
        app: nginx # 为 Pod 打上 app=nginx 标签，方便 selector 识别。
    # 定义容器信息
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:latest # 镜像名称
          ports:
            - containerPort: 80 # 容器端口

使用 kubectl apply 命令创建 Deployment：

1
2
ubuntu@master:~/apps$ sudo kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx created

使用kubectl get deployment查看运行状态，使用kubectl get pods查看 Pod 状态：

1
2
3
4
5
6
7
ubuntu@master:~/apps$ sudo kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   2/2     2            2           17s
ubuntu@master:~/apps$ sudo kubectl get pods -l app=nginx
NAME                   READY   STATUS    RESTARTS   AGE
nginx-96b9d695-gfjvq   1/1     Running   0          25s
nginx-96b9d695-w5qxx   1/1     Running   0          25s

可以看到 Deployment 创建 Pod 的命名规则：${DeploymentName}-${DeploymentUid}-${Hash}。

使用 kubectl get pod -o wide 查看 Pod 运行状态和 IP 地址，可以看到 nginx 被创建了两个 Pod 副本，分别部署在了 worker1 和 worker2 上面：

1
2
3
4
ubuntu@master:~/apps$ sudo kubectl get pod -o wide
NAME                   READY   STATUS    RESTARTS   AGE     IP          NODE      NOMINATED NODE   READINESS GATES
nginx-96b9d695-gfjvq   1/1     Running   0          8m42s   10.42.2.3   worker2   <none>           <none>
nginx-96b9d695-w5qxx   1/1     Running   0          8m42s   10.42.1.3   worker1   <none>           <none>

此时的 nginx 还不能被外部访问，他们的 IP 是 Cluster 的内部私有 IP，只能在集群内部访问。
并且这些 IP 是浮动的，Pod 重启后，IP 也会变化。
这时就需要创建 Service 来解决这个问题。

创建 Service

Service 是 Kubernetes 中一种网络抽象，用于为一组 Pod 提供统一访问入口。
简单来说，Pod 是会变化的（比如被删除、替换），而 Service 提供一个 固定 IP / 名称 / 端口，始终指向一组后端 Pod。

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1 # 使用 v1 API，Service 资源的标准版本
kind: Service # 声明该资源类型为 Service
metadata:
  name: nginx-service # Service 的名字，供集群中引用、DNS 名称生成等使用
spec:
  type: NodePort  # 设置 Service 类型为 NodePort，支持通过任意节点的 IP + nodePort 端口访问服务
  selector:
    app: nginx    # 选择所有标签为 app=nginx 的 Pod
  ports:
    - port: 80         # Service 自己监听的端口，供集群内其他 Pod 调用这个服务时使用
      targetPort: 80   # 转发到后端 Pod 的哪个端口（nginx 监听的端口）
      nodePort: 30080  # 外部访问时的端口（可不写，系统会自动分配 30000~32767）

使用 kubectl apply 命令创建 Service，使用 kubectl get service 查看运行状态：

1
2
3
4
5
6
ubuntu@master:~/apps/nginx$ sudo kubectl apply -f nginx-service.yaml
service/nginx-service created
ubuntu@master:~/apps/nginx$ sudo kubectl get service
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.43.0.1       <none>        443/TCP        72m
nginx-service   NodePort    10.43.119.114   <none>        80:30080/TCP   2m57s

到这里，已经可以使用节点 node 外部的 IP + nodePort 访问到 nginx 了。
但是，访问 nginx 的时候，IP 是 node 的 IP，没有一个统一的入口。

配置应用打包流程

经过上面 nginx 部署的测试，现在k8s集群已经是可用状态了。下面要将本地编写的应用打包为镜像，并上传到镜像仓库，再通过 yaml 配置部署到 k8s 集群中。

这里使用的本地项目使用 go-kratos 构建的微服务项目。
这是一个大仓项目，目录结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
BBS
├── .github
├── app
│   ├── backend
│   │   ├── common
│   │   │   ├── api
│   │   │   │   ├── common
│   │   │   │   │   ├── v1
│   │   │   │   │   │   ├── error_reason.pb.go
│   │   │   │   │   │   └── error_reason.proto
│   │   │   │   ├── user
│   │   │   │   │   ├── v1
│   │   │   │   │   │   ├── demo.pb.go
│   │   │   │   │   │   ├── demo.proto
│   │   │   │   │   │   ├── demo_grpc.pb.go
│   │   │   │   │   │   └── demo_http.pb.go
│   │   │   ├── third_party
│   │   ├── user
│   │   │   ├── cmd
│   │   │   │   ├── user
│   │   │   │   │   ├── main.go
│   │   │   │   │   ├── wire.go
│   │   │   │   │   └── wire_gen.go
│   │   │   ├── configs
│   │   │   │   ├── config.yaml
│   │   │   ├── internal
│   │   │   ├── Dockerfile
│   │   │   ├── Makefile
│   │   ├── go.mod
│   │   ├── go.sum
│   │   ├── openapi.yaml
│   ├── frontend
└── ...

基于这个目录结构，来修改 应用构建文件Makefile、Docker镜像构建文件Dockerfile、github action 文件user-build.yaml。

首先是 Makefile 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
# 全局变量定义
GOHOSTOS := $(shell go env GOHOSTOS)
GOPATH := $(shell go env GOPATH)
VERSION := latest

# 项目目录结构定义 - 使用更可靠的路径获取方式
ROOT_DIR := $(realpath $(dir $(lastword $(MAKEFILE_LIST)))/..)
COMMON_DIR := $(ROOT_DIR)/common
USER_DIR := $(ROOT_DIR)/user
API_DIR := $(COMMON_DIR)/api
THIRD_PARTY_DIR := $(COMMON_DIR)/third_party
INTERNAL_DIR := $(ROOT_DIR)/user/internal

# 根据操作系统设置查找命令
ifeq ($(GOHOSTOS), windows)
    Git_Bash := $(subst \,/,$(subst cmd\,bin\bash.exe,$(dir $(shell where git))))
    FIND_CMD := $(Git_Bash) -c "find"
else
    FIND_CMD := find
endif

# Proto 文件查找
INTERNAL_PROTO_FILES := $(shell $(FIND_CMD) $(INTERNAL_DIR) -name '*.proto' 2>/dev/null)
API_PROTO_FILES := $(shell $(FIND_CMD) $(API_DIR) -name '*.proto' 2>/dev/null)

## 工具安装
.PHONY: init
init:
@echo "Installing required tools..."
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
go install github.com/go-kratos/kratos/cmd/kratos/v2@latest
go install github.com/go-kratos/kratos/cmd/protoc-gen-go-http/v2@latest
go install github.com/google/gnostic/cmd/protoc-gen-openapi@latest
go install github.com/google/wire/cmd/wire@latest

## 内部 Proto 生成
.PHONY: config
config:
@echo "Generating internal protobuf files..."
@test -n "$(INTERNAL_PROTO_FILES)" || (echo "No proto files found in $(INTERNAL_DIR)" && exit 1)
protoc --proto_path=$(INTERNAL_DIR) \
       --proto_path=$(THIRD_PARTY_DIR) \
       --go_out=paths=source_relative:$(INTERNAL_DIR) \
       $(INTERNAL_PROTO_FILES)

## API Proto 生成
.PHONY: api
api:
@echo "Generating API protobuf files..."
@test -n "$(API_PROTO_FILES)" || (echo "No proto files found in $(API_DIR)" && exit 1)
protoc --proto_path=$(API_DIR) \
       --proto_path=$(THIRD_PARTY_DIR) \
       --go_out=paths=source_relative:$(API_DIR) \
       --go-http_out=paths=source_relative:$(API_DIR) \
       --go-grpc_out=paths=source_relative:$(API_DIR) \
       --openapi_out=fq_schema_naming=true,default_response=false:$(API_DIR) \
       $(API_PROTO_FILES)

## 构建应用
.PHONY: build
build:
@echo "Building application..."
@mkdir -p $(ROOT_DIR)/bin/
@cd $(USER_DIR) && \
go build -ldflags "-X main.Version=$(VERSION)" -o $(ROOT_DIR)/bin/server ./cmd/user/...
@echo "Output binary: $(ROOT_DIR)/bin/server"

## 代码生成
.PHONY: generate
generate:
@echo "Generating code..."
@cd $(USER_DIR) && \
go generate ./... && \
go mod tidy

## 执行全部任务
.PHONY: all
all: init api config build generate

这里的 VERSION 暂时选择写死了，正常会通过 VERSION := $(shell git describe --tags --always) git 命令来获取最新的标签（tag）或提交哈希（commit hash）。

然后是 DockerFile 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 第一阶段：构建Go应用
FROM golang:1.23 as builder

WORKDIR /build

# 复制 go.mod 和 go.sum，提前拉依赖
COPY go.mod go.sum ./
RUN go mod download

# 复制 user 和 common 源码
COPY user/ ./user/
COPY common/ ./common/

# 进入 user 目录进行构建
WORKDIR /build/user

# 编译
RUN make init && make generate && make build

# 第二阶段：制作小体积运行环境
FROM debian:stable-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates netbase && \
    rm -rf /var/lib/apt/lists/*

# 把可执行文件拷贝进来
COPY --from=builder /build/bin/ /app/
COPY --from=builder /build/user/configs/ /app/configs/

WORKDIR /app

EXPOSE 8000 9000

CMD ["/app/server", "-conf", "/app/configs/config.yaml"]

最后是 github action 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
name: Docker Build and Push for Go User App

on:
  workflow_dispatch:

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      # Step 1: Checkout the code
      - name: Checkout Code
        uses: actions/checkout@v4

      # Step 2: Set up Go environment + cache
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.23'

      - name: Cache Go Modules
        uses: actions/cache@v4
        with:
          path: |
            ~/.cache/go-build
            ~/go/pkg/mod
          key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
          restore-keys: |
            ${{ runner.os }}-go-

      # Step 3: Install protoc
      - name: Install Protobuf Compiler
        run: |
          sudo apt-get update
          sudo apt-get install -y protobuf-compiler
          protoc --version

      # Step 4: Docker Login
      - name: Docker Login
        uses: docker/login-action@v3
        with:
          registry: registry.cn-hangzhou.aliyuncs.com
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # Step 5: Build and Push Docker Image
      - name: Build and Push Docker Image
        uses: docker/build-push-action@v5
        with:
          context: app/backend
          file: app/backend/user/Dockerfile
          push: true
          tags: |
            registry.cn-hangzhou.aliyuncs.com/docker-learn-cooooing/user:latest

其中 secrets.DOCKER_USERNAME 和 secrets.DOCKER_PASSWORD 是 GitHub Secrets，需要在项目设置中配置，用于登录阿里的镜像仓库。
目前配置的是手动触发，后续可修改为 push 或者 release 时触发。自动构建最新的镜像推送到阿里的镜像仓库。

最后回到 kubernetes ，通过 yaml 文件创建 deployment：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
  labels:
    app: user-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      imagePullSecrets:
        - name: aliyun-registry-secret
      containers:
        - name: user
          image: registry.cn-hangzhou.aliyuncs.com/docker-learn-cooooing/user:latest
          ports:
            - containerPort: 8000
            - containerPort: 9000
          volumeMounts:
            - name: config-volume
              mountPath: /data/conf
          resources:
            limits:
              cpu: "500m"
              memory: "512Mi"
            requests:
              cpu: "100m"
              memory: "128Mi"
#          readinessProbe: # 就绪探针，确保容器准备好才流量转发
#            httpGet:
#              path: /healthz
#              port: 8000
#            initialDelaySeconds: 5
#            periodSeconds: 10
#          livenessProbe: # 存活探针，崩了自动重启
#            httpGet:
#              path: /healthz
#              port: 8000
#            initialDelaySeconds: 15
#            periodSeconds: 20
      volumes:
        - name: config-volume
          emptyDir: { } # 这里可以替换成挂载 ConfigMap

---
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
    - name: http
      port: 8000
      targetPort: 8000
    - name: grpc
      port: 9000
      targetPort: 9000
  type: ClusterIP

它会从阿里镜像仓库拉取镜像，并创建 pod 和 service。
其中关于探针的部分被注释掉了，探针（Probes）是一种用于检测容器健康状况的机制。探针允许Kubernetes定期检查容器是否仍在运行并且按预期工作。根据探针的检查结果，Kubernetes可以决定是否需要重启容器或者进行其他操作。
探针需要服务实现一个HTTP端点，Kubernetes 将定期对这个端点发送GET请求。如果端点返回一个成功的状态码（通常是200-399范围内），Kubernetes就会认为容器是健康的。

这里 service 并没有配置 NodePort，所以目前服务只暴露在 Kubernetes 集群内部，外部访问需要通过 ingress 配置。

配置 Helm

Helm 是 Kubernetes 的包管理器。安装过程参考Helm 文档，这里省略。

Helm 默认会访问 localhost 的 8080 端口，但是这里使用 k3s，默认的 API Server 地址和端口通常是https://<K3S_SERVER_IP>:6443，所以访问 localhost 的 8080 端口会报错：
Error: INSTALLATION FAILED: Kubernetes cluster unreachable: Get "http://localhost:8080/version": dial tcp [::1]:8080: connect: connection refused
所以需要一些设置：

Helm 默认会读取 ~/.kube/config 文件，但 K3s 的 kubeconfig 默认存储在 /etc/rancher/k3s/k3s.yaml，需要复制到本地并设置权限：

1
2
3
mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER ~/.kube/config

使用 helm ls --all-namespaces 测试 Helm 是否能访问 K3s：

1
2
3
4
ubuntu@master:~$ helm ls --all-namespaces
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
traefik         kube-system     1               2025-04-25 08:22:17.95057216 +0000 UTC  deployed        traefik-34.2.1+up34.2.0         v3.3.2     
traefik-crd     kube-system     1               2025-04-25 08:22:02.482297704 +0000 UTC deployed        traefik-crd-34.2.1+up34.2.0     v3.3.2

创建 Ingress

使用 Kubernetes 的 Ingress 来创建一个统一的负载均衡器，从而实现当用户访问不同的域名时，访问后端不同的服务。
Ingress 的功能其实很容易理解：所谓 Ingress 就是 Service 的“Service”，这就是它们两者的关系。

在 Kubernetes（K8s）中，Ingress Controller 默认是 Traefik，它为云原生和动态环境设计，可以监听k8s的资源变化。
但这里还是使用 Nginx 作为流量入口管理器，虽然它比较偏静态。

首先卸载默认的 Traefik：

1
2
helm uninstall traefik -n kube-system
helm uninstall traefik-crd -n kube-system

然后使用 Helm 安装 Nginx：

1
2
3
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install nginx-ingress ingress-nginx/ingress-nginx -n kube-system

或者使用 kubectl 安装：

1
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.1/deploy/static/provider/baremetal/deploy.yaml

使用以下ingress.yaml创建 Ingress 资源：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2 # 路径重写，去掉 /user
    nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr" # 负载均衡
spec:
  rules:
    - host: ""  # 留空，表示使用 IP 地址
      http:
        paths:
          - path: /user(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: user-service  # 目标服务名
                port:
                  number: 8000  # user-service 服务的 HTTP 端口

使用 kubectl apply -f ingress.yaml 创建 Ingress 资源后，就可以通过 http://master/user 访问到后端服务了。

到这里基本应用的部署就完成了。

]]> https://cooooing.github.io/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/Kubernetes%E6%9C%AC%E5%9C%B0%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA%E5%8F%8A%E5%BA%94%E7%94%A8%E9%83%A8%E7%BD%B2/ 2025-04-23T14:01:51.000Z 基础环境准备（可选）

缓存淘汰算法概述

缓存淘汰算法用于在缓存空间不足时决定哪些数据应该被移除，以腾出空间存储新数据。
两种最常用的算法是：

  • LRU (Least Recently Used) - 最近最少使用，根据数据的历史访问记录来进行淘汰数据
  • LFU (Least Frequently Used) - 最不经常使用，根据数据的历史访问频率来淘汰数据

LRU (最近最少使用) 算法

LRU 基于时间局部性原理，认为最近被访问的数据在将来更有可能被再次访问。当缓存满时，LRU 会淘汰最久未被访问的数据。

Go 实现

  • 使用哈希表实现 O(1) 的查找
  • 使用双向链表维护访问顺序
  • 每次访问数据时，将其移动到链表头部
  • 淘汰时从链表尾部移除数据
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
package utils

import (
"container/list"
"sync"
)

// LRUCache 泛型结构体
type LRUCache[K comparable, V any] struct {
capacity int
cache    map[K]*list.Element
list     *list.List
mu       sync.RWMutex
}

// entry 用于存储键值对
type entry[K comparable, V any] struct {
key   K
value V
}

// NewLRUCache 创建一个新的泛型LRUCache
func NewLRUCache[K comparable, V any](capacity int) *LRUCache[K, V] {
return &LRUCache[K, V]{
capacity: capacity,
cache:    make(map[K]*list.Element),
list:     list.New(),
}
}

// Get 获取键的值，如果不存在返回零值和false
func (l *LRUCache[K, V]) Get(key K) (V, bool) {
l.mu.Lock()
defer l.mu.Unlock()
if elem, ok := l.cache[key]; ok {
l.list.MoveToFront(elem)
return elem.Value.(*entry[K, V]).value, true
}
var zero V
return zero, false
}

// Put 插入或更新键值对
func (l *LRUCache[K, V]) Put(key K, value V) bool {
l.mu.Lock()
defer l.mu.Unlock()
if l.capacity <= 0 {
return false
}

if elem, ok := l.cache[key]; ok {
elem.Value.(*entry[K, V]).value = value
l.list.MoveToFront(elem)
return true
}

if l.list.Len() >= l.capacity {
// 移除最久未使用的元素
back := l.list.Back()
if back != nil {
delete(l.cache, back.Value.(*entry[K, V]).key)
l.list.Remove(back)
}
}

newEntry := &entry[K, V]{key, value}
elem := l.list.PushFront(newEntry)
l.cache[key] = elem
return true
}

// Len 返回缓存中元素的数量
func (l *LRUCache[K, V]) Len() int {
return l.list.Len()
}

测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
package utils

import (
"testing"
)

func TestLRUCache_EmptyCache(t *testing.T) {
cache := NewLRUCache[string, int](2)

// 测试空缓存
if val, ok := cache.Get("nonexistent"); ok || val != 0 {
t.Errorf("Get from empty cache should return zero value, got %v, %v", val, ok)
}

if l := cache.Len(); l != 0 {
t.Errorf("Len of empty cache should be 0, got %d", l)
}
}

func TestLRUCache_SingleItem(t *testing.T) {
cache := NewLRUCache[string, int](1)

// 测试单个元素
cache.Put("one", 1)
if val, ok := cache.Get("one"); !ok || val != 1 {
t.Errorf("Get('one') = %d, %v, want 1, true", val, ok)
}

// 测试替换
cache.Put("two", 2)
if val, ok := cache.Get("one"); ok {
t.Errorf("Get('one') should be evicted, got %d, %v", val, ok)
}
if val, ok := cache.Get("two"); !ok || val != 2 {
t.Errorf("Get('two') = %d, %v, want 2, true", val, ok)
}
}

func TestLRUCache_EvictionPolicy(t *testing.T) {
cache := NewLRUCache[string, int](2)

// 初始填充
cache.Put("one", 1)
cache.Put("two", 2)

// 访问one使其成为最近使用的
if val, ok := cache.Get("one"); !ok || val != 1 {
t.Errorf("Get('one') = %d, %v, want 1, true", val, ok)
}

// 添加新元素，two应该被淘汰
cache.Put("three", 3)
if val, ok := cache.Get("two"); ok {
t.Errorf("Get('two') should be evicted, got %d, %v", val, ok)
}
if val, ok := cache.Get("one"); !ok || val != 1 {
t.Errorf("Get('one') = %d, %v, want 1, true", val, ok)
}
if val, ok := cache.Get("three"); !ok || val != 3 {
t.Errorf("Get('three') = %d, %v, want 3, true", val, ok)
}
}

func TestLRUCache_UpdateExisting(t *testing.T) {
cache := NewLRUCache[string, int](2)

cache.Put("one", 1)
cache.Put("one", 11) // 更新

if val, ok := cache.Get("one"); !ok || val != 11 {
t.Errorf("Get('one') = %d, %v, want 11, true", val, ok)
}
if l := cache.Len(); l != 1 {
t.Errorf("Len should be 1 after update, got %d", l)
}
}

func TestLRUCache_ZeroCapacity(t *testing.T) {
cache := NewLRUCache[string, int](0)

cache.Put("one", 1)
if val, ok := cache.Get("one"); ok {
t.Errorf("Get from zero-capacity cache should return nothing, got %d, %v", val, ok)
}
}

func TestLRUCache_CustomTypes(t *testing.T) {
type customKey struct {
id   int
name string
}

cache := NewLRUCache[customKey, string](2)

key1 := customKey{1, "apple"}
key2 := customKey{2, "banana"}

cache.Put(key1, "red")
cache.Put(key2, "yellow")

if val, ok := cache.Get(key1); !ok || val != "red" {
t.Errorf("Get(key1) = %s, %v, want 'red', true", val, ok)
}

// 测试淘汰
cache.Put(customKey{3, "cherry"}, "pink")
if val, ok := cache.Get(key2); ok {
t.Errorf("Get(key2) should be evicted, got %s, %v", val, ok)
}
}

func TestLRUCache_ConcurrentAccess(t *testing.T) {
cache := NewLRUCache[string, int](100)
done := make(chan bool)

// 并发写入
go func() {
for i := 0; i < 10000; i++ {
cache.Put("key", i)
}
done <- true
}()

// 并发读取
go func() {
for i := 0; i < 10000; i++ {
cache.Get("key")
}
done <- true
}()

<-done
<-done

// 最终检查
if val, ok := cache.Get("key"); !ok {
t.Errorf("Key should exist after concurrent access")
} else if val < 0 || val >= 10000 {
t.Errorf("Unexpected value after concurrent access: %d", val)
}
}

LFU (最不经常使用) 算法

LFU 基于访问频率，认为访问次数最少的数据在未来被访问的可能性也最小。当缓存满时，LFU 会淘汰访问频率最低的数据。如果有多个数据具有相同的最低频率，则淘汰其中最久未被访问的数据。

Go 实现

  • 使用两个哈希表：一个存储键值对，一个存储频率到键列表的映射
  • 使用双向链表维护相同频率下的访问顺序
  • 需要维护一个最小频率变量
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
package utils

import (
"container/list"
"sync"
)

// LFUCache 泛型结构体
type LFUCache[K comparable, V any] struct {
capacity int
minFreq  int
items    map[K]*list.Element     // 存储键到元素的映射
freqs    map[int]*list.List      // 存储频率到双向链表的映射
entries  map[K]*cacheEntry[K, V] // 存储键到entry的映射(辅助快速访问)
mu       sync.RWMutex
}

// cacheEntry 存储缓存值和频率信息
type cacheEntry[K comparable, V any] struct {
key    K
value  V
freq   int
parent *list.Element
}

// NewLFUCache 创建一个新的泛型LFUCache
func NewLFUCache[K comparable, V any](capacity int) *LFUCache[K, V] {
return &LFUCache[K, V]{
capacity: capacity,
items:    make(map[K]*list.Element),
freqs:    make(map[int]*list.List),
entries:  make(map[K]*cacheEntry[K, V]),
}
}

// Get 获取键的值，如果不存在返回零值和false
func (l *LFUCache[K, V]) Get(key K) (V, bool) {
l.mu.Lock()
defer l.mu.Unlock()
if elem, ok := l.items[key]; ok {
entry := elem.Value.(*cacheEntry[K, V])
l.incrementFreq(elem, entry)
return entry.value, true
}
var zero V
return zero, false
}

// Put 插入或更新键值对
func (l *LFUCache[K, V]) Put(key K, value V) bool {
l.mu.Lock()
defer l.mu.Unlock()
if l.capacity <= 0 {
return false
}

// 如果键已存在，更新值并增加频率
if elem, ok := l.items[key]; ok {
entry := elem.Value.(*cacheEntry[K, V])
entry.value = value
l.incrementFreq(elem, entry)
return true
}

// 如果缓存已满，移除最不经常使用且最久未使用的项
if len(l.items) >= l.capacity {
l.removeMinFreqItem()
}

// 创建新条目
entry := &cacheEntry[K, V]{
key:   key,
value: value,
freq:  1,
}

// 添加到频率为1的列表中
if l.freqs[1] == nil {
l.freqs[1] = list.New()
}
elem := l.freqs[1].PushFront(entry)
entry.parent = elem

// 更新映射
l.items[key] = elem
l.entries[key] = entry

// 更新最小频率
l.minFreq = 1
return true
}

// incrementFreq 增加条目的频率
func (l *LFUCache[K, V]) incrementFreq(elem *list.Element, entry *cacheEntry[K, V]) {
// 从当前频率列表中移除
l.freqs[entry.freq].Remove(elem)

// 更新频率
entry.freq++

// 添加到新频率列表中
if l.freqs[entry.freq] == nil {
l.freqs[entry.freq] = list.New()
}
newElem := l.freqs[entry.freq].PushFront(entry)
entry.parent = newElem

// 更新items映射
l.items[entry.key] = newElem

// 如果旧频率是最小频率且该频率列表现在为空，更新最小频率
if entry.freq-1 == l.minFreq && l.freqs[entry.freq-1].Len() == 0 {
l.minFreq = entry.freq
}
}

// removeMinFreqItem 移除最小频率的项
func (l *LFUCache[K, V]) removeMinFreqItem() {
minList := l.freqs[l.minFreq]
if minList == nil {
return
}

// 移除列表中的最后一个元素(最久未使用)
back := minList.Back()
if back == nil {
return
}

entry := back.Value.(*cacheEntry[K, V])
minList.Remove(back)
delete(l.items, entry.key)
delete(l.entries, entry.key)
}

// Len 返回缓存中元素的数量
func (l *LFUCache[K, V]) Len() int {
return len(l.items)
}

测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
package utils

import (
"testing"
)

func TestLFUCache_EmptyCache(t *testing.T) {
cache := NewLFUCache[string, int](2)

// 测试空缓存
if val, ok := cache.Get("nonexistent"); ok || val != 0 {
t.Errorf("Get from empty cache should return zero value, got %v, %v", val, ok)
}

if l := cache.Len(); l != 0 {
t.Errorf("Len of empty cache should be 0, got %d", l)
}
}

func TestLFUCache_SingleItem(t *testing.T) {
cache := NewLFUCache[string, int](1)

// 测试单个元素
cache.Put("one", 1)
if val, ok := cache.Get("one"); !ok || val != 1 {
t.Errorf("Get('one') = %d, %v, want 1, true", val, ok)
}

// 测试替换
cache.Put("two", 2)
if val, ok := cache.Get("one"); ok {
t.Errorf("Get('one') should be evicted, got %d, %v", val, ok)
}
if val, ok := cache.Get("two"); !ok || val != 2 {
t.Errorf("Get('two') = %d, %v, want 2, true", val, ok)
}
}

func TestLFUCache_EvictionPolicy(t *testing.T) {
cache := NewLFUCache[string, int](2)

// 初始填充
cache.Put("one", 1)
cache.Put("two", 2)

// 访问one增加其频率
if val, ok := cache.Get("one"); !ok || val != 1 {
t.Errorf("Get('one') = %d, %v, want 1, true", val, ok)
}

// 添加新元素，two应该被淘汰(频率较低)
cache.Put("three", 3)
if val, ok := cache.Get("two"); ok {
t.Errorf("Get('two') should be evicted, got %d, %v", val, ok)
}
if val, ok := cache.Get("one"); !ok || val != 1 {
t.Errorf("Get('one') = %d, %v, want 1, true", val, ok)
}
if val, ok := cache.Get("three"); !ok || val != 3 {
t.Errorf("Get('three') = %d, %v, want 3, true", val, ok)
}

// 再访问three使其频率与one相同
if val, ok := cache.Get("three"); !ok || val != 3 {
t.Errorf("Get('three') = %d, %v, want 3, true", val, ok)
}

// 添加新元素，one应该被淘汰(相同频率但更久未使用)
cache.Put("four", 4)
if val, ok := cache.Get("one"); ok {
t.Errorf("Get('one') should be evicted, got %d, %v", val, ok)
}
if val, ok := cache.Get("three"); !ok || val != 3 {
t.Errorf("Get('three') = %d, %v, want 3, true", val, ok)
}
if val, ok := cache.Get("four"); !ok || val != 4 {
t.Errorf("Get('four') = %d, %v, want 4, true", val, ok)
}
}

func TestLFUCache_UpdateExisting(t *testing.T) {
cache := NewLFUCache[string, int](2)

cache.Put("one", 1)
cache.Put("one", 11) // 更新

if val, ok := cache.Get("one"); !ok || val != 11 {
t.Errorf("Get('one') = %d, %v, want 11, true", val, ok)
}
if l := cache.Len(); l != 1 {
t.Errorf("Len should be 1 after update, got %d", l)
}
}

func TestLFUCache_ZeroCapacity(t *testing.T) {
cache := NewLFUCache[string, int](0)

cache.Put("one", 1)
if val, ok := cache.Get("one"); ok {
t.Errorf("Get from zero-capacity cache should return nothing, got %d, %v", val, ok)
}
}

func TestLFUCache_MinFrequencyUpdate(t *testing.T) {
cache := NewLFUCache[string, int](2)

// 初始填充
cache.Put("one", 1)
cache.Put("two", 2)

// 访问one增加其频率
if val, ok := cache.Get("one"); !ok || val != 1 {
t.Errorf("Get('one') = %d, %v, want 1, true", val, ok)
}

// 添加新元素，two应该被淘汰(频率较低)
cache.Put("three", 3)

// 现在minFreq应该是1(three的频率)
if val, ok := cache.Get("three"); !ok || val != 3 {
t.Errorf("Get('three') = %d, %v, want 3, true", val, ok)
}

// 再次访问three使其频率增加到2
if val, ok := cache.Get("three"); !ok || val != 3 {
t.Errorf("Get('three') = %d, %v, want 3, true", val, ok)
}

// 添加新元素，应该淘汰one(因为three频率更高)
cache.Put("four", 4)
if val, ok := cache.Get("one"); ok {
t.Errorf("Get('one') should be evicted, got %d, %v", val, ok)
}
}

func TestLFUCache_CustomTypes(t *testing.T) {
type customKey struct {
id   int
name string
}

cache := NewLFUCache[customKey, string](2)

key1 := customKey{1, "apple"}
key2 := customKey{2, "banana"}

cache.Put(key1, "red")
cache.Put(key2, "yellow")

// 访问key1增加其频率
if val, ok := cache.Get(key1); !ok || val != "red" {
t.Errorf("Get(key1) = %s, %v, want 'red', true", val, ok)
}

// 添加新元素，key2应该被淘汰(频率较低)
cache.Put(customKey{3, "cherry"}, "pink")

if val, ok := cache.Get(key2); ok {
t.Errorf("Get(key2) should be evicted, got %s, %v", val, ok)
}
}

func TestLFUCache_ConcurrentAccess(t *testing.T) {
cache := NewLFUCache[string, int](100)
done := make(chan bool)

// 并发写入
go func() {
for i := 0; i < 10000; i++ {
cache.Put("key", i)
}
done <- true
}()

// 并发读取
go func() {
for i := 0; i < 10000; i++ {
cache.Get("key")
}
done <- true
}()

<-done
<-done

// 最终检查
if val, ok := cache.Get("key"); !ok {
t.Errorf("Key should exist after concurrent access")
} else if val < 0 || val >= 10000 {
t.Errorf("Unexpected value after concurrent access: %d", val)
}
}

LRU 和 LFU 的比较

特性LRULFU
淘汰策略淘汰最久未使用的淘汰使用频率最低的
实现复杂度相对简单相对复杂
适用场景访问模式随时间变化不大访问频率差异明显的场景
对突发流量可能淘汰热点数据对新数据不友好
内存消耗较低较高
  • LRU 实现简单，适合大多数通用场景，对突发流量友好。
  • LFU 适合访问模式相对稳定的场景，能更好地保留高频访问数据。

另外，还有 LRU 和 LFU 的变体和混合算法以及FIFO（First in First out），先进先出，最先进入的数据，最先被淘汰等算法，以不同的淘汰策略适应不同的应用场景。

]]> https://cooooing.github.io/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E7%BC%93%E5%AD%98%E6%B7%98%E6%B1%B0%E7%AE%97%E6%B3%95LRU%E3%80%81LFU/ 2025-03-31T03:50:57.000Z 缓存淘汰算法概述

缓存淘汰算法用于在缓存空间不足时决定哪些数据应该被移除，以腾出空间存储新数据。
两种最]]>

缓存淘汰算法LRU、LFU 2025-03-31T03:50:57.000Z