yuhaowin

OpenClaw 源代码全链路解析：一条消息背后的十层旅程

Sun, 15 Mar 2026 00:00:00 +0000

OpenClaw 源代码全链路解析：一条消息背后的十层旅程

当你向 OpenClaw 发出一句"你好"，从按下发送键到看见回复，背后到底经历了什么？本文基于 OpenClaw 源码，逐层拆解其完整执行链路。

引言

OpenClaw 是近期 AI 领域最受关注的开源项目之一。很多人以为它的核心是那个聊天框，但本质上，它首先是一个本地优先（Local-First）的网关平台。只有先把网关跑起来，建立统一的会话管理、渠道管理、工具管理和事件分发能力，来自不同渠道的消息才能汇总进来，进入后续的处理流程。

下面，我们就来一层层拆开这套系统，看看一条用户消息是如何被处理的。

第一层：网关启动 - 以 WhatsApp 渠道为例

源文件：extensions/whatsapp/src/auto-reply/monitor.ts

核心函数：monitorWebChannel

整个流程的起点和大模型没有任何关系，而是从网关的启动开始。

启动过程分为以下几步：

检查网络连接
加载 openclaw.json 总配置文件，其中包含智能体、渠道、环境变量、鉴权信息、模型配置等所有核心字段
解析当前账号（如 WhatsApp 账号）
进入持续循环：创建消息处理器(createWebOnMessageHandler)、启动渠道监听器(listener)、设置心跳机制(heartbeat)和看门狗定时器(watchdogTimer)、处理连接断开与重连、持续更新系统运行状态

只有这整套流程全部完成，网关成功启动，OpenClaw 才算正式进入就绪状态，随时准备接收用户消息。没有网关的支撑，后面所有的能力都无从谈起。

第二层：消息接入与标准化

源文件：extensions/whatsapp/src/inbound/monitor.ts

用户消息进入 OpenClaw 的第一站，并不是直接被转发给大模型，而是先进入消息监听与接入层。

系统通过 sock.ev.on("messages.upsert") 这个事件监听器持续监听新消息，一旦有消息到达，立刻启动以下流程：

2.1 消息去重与高频合并

真实的即时通讯环境中，平台经常重复推送消息，用户也可能短时间内连续发送多条。如果直接处理原始消息，很容易导致机器人重复回复。这一步的去重和合并，就是为了过滤噪声，保证后续流程拿到干净、完整的用户需求。

2.2 权限与合法性检查

判断消息是否来自允许的用户或群组，是否满足预设的触发规则。不符合规则的消息会被直接过滤，根本不会进入智能体处理流程。

2.3 媒体文件预下载

如果用户消息中包含图片、文件等媒体附件，系统会自动下载并保存到本地工作目录，供后续智能体推理时直接访问，完成图片分析、文档读取等操作。

2.4 封装为标准化对象

这是整个接入层最关键的一步：把来自不同即时通讯平台、格式千差万别的原始消息，统一封装成 WebInboundMessage 对象，即系统内部的标准化消息结构。

2.5 放入防抖队列

标准化后的消息被放入防抖队列，防止用户短时间内连续发送大量消息导致系统重复处理，之后触发回调函数，将整理好的消息交给网关进入下一环节。

本层本质：把来自外部世界混乱的、非标准化的用户消息，转化成系统内部可识别、可调度、可处理的标准化事件。

第三层：消息路由与智能体分发

源文件：extensions/whatsapp/src/auto-reply/monitor/on-message.ts

拿到标准化的 WebInboundMessage 对象后，进入路由模块。

并不是所有用户消息都会被送到同一个 AI 模型，由模型自己决定怎么处理。OpenClaw 的设计是：不同类型的任务，会被分配给不同的智能体来处理。

3.1 动态加载配置

系统通过 createWebOnMessageHandler 函数创建消息处理入口，同时重新读取最新的系统配置。这是一个关键的工程细节：OpenClaw 的配置支持动态调整，智能体绑定关系、权限规则等都可以在运行时修改，每次处理消息时重新读取配置，确保用的是最新规则。

3.2 解析消息方向

判断消息来自一对一私聊还是群组聊天，同时确定发送者的唯一 ID。群聊场景下，机器人需要判断是否被 @ 或满足触发规则；私聊场景下，通常默认直接处理。

3.3 智能体路由决策

读取 openclaw.json 配置文件里的 bindings（绑定规则），通过 resolveAgentRoute 函数，判断应该由哪个智能体处理当前消息。这样，不同渠道、不同用户、不同类型的消息，都可以被精准分流到对应的智能体。

3.4 生成会话历史键值

通过 buildGroupHistoryKey 函数，为当前会话生成唯一的历史记录键值——这是实现上下文关联的核心。AI 之所以能"记得"之前的对话，就是因为系统在每次推理前，都会通过这个键值加载对应的历史对话记录。

3.5 安全检查

Same-phone 模式：判断消息是否来自同一台设备，避免机器人对自己发出的消息形成循环回复
echoTracker 回声追踪：过滤掉刚刚自己发送的消息，避免重复处理同步事件

3.6 广播判断

如果满足广播条件，系统让所有需要参与的智能体分别执行一次 processForRoute 路由处理函数；否则只调用一次对应的路由处理逻辑。

最终，消息进入核心处理函数 processMessage，传递给下一环节。

第四层：推理环境准备

源文件：src/auto-reply/reply/get-reply.ts

到了这一步，很多人以为系统已经开始调用大模型了——但事实上，它只是完成了所有幕后准备工作，为接下来的推理搭建好完整、干净、信息完备的运行环境。

4.1 最终确认智能体与模型

通过 resolveSessionAgentId 函数最终确定当前会话对应的智能体，以及本次推理要使用的 AI 模型。

4.2 准备工作目录

执行 ensureAgentWorkspace 函数，为当前智能体准备独立的工作目录。智能体运行时经常需要读写文件、下载附件、生成临时结果、执行工具命令，所以每个智能体都有自己的专属工作区。

4.3 媒体与链接深度解析

applyMediaUnderstanding：对图片内容进行深度解析，转化成文本信息
applyLinkUnderstanding：对链接里的网页内容进行解析，转化成文本信息

让智能体在正式推理之前，就对用户发送的所有内容有全面完整的理解。

4.4 初始化会话状态

通过 initSessionState 函数，把对应的历史对话记录完整加载进来。这就是 AI"记忆"的本质——不是真的有记忆，而是每次推理前把历史对话重新加载到上下文里。

4.5 解析特殊控制指令

通过 resolveReplyDirectives 函数，解析消息里的特殊控制指令：

reset：重置会话
model：指定使用的模型
verbose：开启详细输出模式
/think high：使用更高的推理强度
/new：开启全新会话，不加载历史上下文

4.6 处理内联操作

通过 handleInlineActions 函数处理不需要 AI 推理就能直接完成的操作，比如简单的系统状态查询、内置管理命令。

所有准备工作完成后，进入 runPreparedReply 函数，把会话上下文、模型选择、工具环境、用户消息、运行配置等全部打包传递给后面的流程。

第五层：执行参数转换

源文件：src/auto-reply/reply/get-reply-run.ts

核心函数：runPreparedReply

这一层的作用，是把用户消息和所有配置参数，转换成完整的、大模型可以直接执行的运行配置。

最终判断当前消息是否需要进入 AI 推理流程（某些系统指令或已处理消息会在这里直接结束）
将会话信息整理成大模型可理解的提示词结构
根据用户指令调整模型运行配置（推理强度、会话模式等）
校验推理的思考等级和运行策略（简单问答 vs. 复杂多步骤任务规划）
处理会话里的消息队列，确保消息按正确顺序进入推理流程

完成后，将整理好的参数包传递给 agent-runner.ts，排队执行下一步流程。

第六层：智能体生命周期调度

源文件：src/auto-reply/reply/agent-runner.ts

这个文件负责管理智能体运行的完整生命周期，是 OpenClaw 保证系统稳定运行的核心调度中枢。

调用 runReplyAgent 把消息放进对应的处理队列，标记为"正在处理"，避免重复处理
执行 runMemoryFlushIfNeeded：在必要时自动保存当前会话的记忆状态

长会话记忆的核心机制：在长时间对话中，系统需要不断叠加历史会话信息。如果不控制上下文长度，很快会撑爆大模型的上下文窗口导致推理失败。OpenClaw 会在会话信息达到上下文窗口上限时，自动对历史内容进行压缩，然后持久化到记忆文件里——这就是长会话记忆机制的核心实现。

准备完成后，才进入真正的 AI 调用流程：runAgentTurnWithFallback 函数。

第七层：执行容错与失败降级

源文件：src/auto-reply/reply/agent-runner-execution.ts

核心函数：runAgentTurnWithFallback

这一层不仅负责调用模型，还内置了完整的失败重试和降级机制：

用 crypto.randomUUID 给本次 AI 调用生成全局唯一标识
用 registerAgentRunContext 注册本次调用的完整上下文，方便后续精准追溯
进入循环执行框架：模型调用失败时（网络问题、服务异常、接口限流），按预设策略重试或切换备用模型后端
执行 normalizeStreamingText：清理无意义的心跳标识、静默回复、空文本等噪声
进入 runWithModelFallback，判断执行路径：
- CLI 模式：进入 runCliAgent，交给外部 CLI 后端执行（如 Claude Code、Codex CLI、Gemini CLI）
- 嵌入式模式（默认）：进入 runEmbeddedPiAgent

这一层还会持续检查返回结果里的异常信号：会话损坏、上下文溢出、消息顺序错误等，确保不会在基础条件不符合的情况下强行执行模型调用。

第八层：嵌入式智能体准备

源文件：src/agents/pi-embedded-runner/run.ts

核心函数：runEmbeddedPiAgent

到了这一步，前面所有的准备工作全部完成：执行路径确认、模型选定、容错机制部署、上下文和参数打包完毕。

8.1 确认排队规则

resolveSessionLane：确认本次 AI 调用应该遵守哪条排队规则——会话级顺序执行，还是全局级统一调度。

8.2 确定输出格式

resolvedToolResultFormat：根据消息来自的渠道（WhatsApp、Telegram 等），确定最终输出内容的格式。不同平台的消息能力完全不一样，所以在调用模型之前就确定好适配格式。

8.3 补全模型细节

resolveModel：把当前要使用的模型的所有细节全部补齐，包括完整名称、上下文窗口大小、API 地址、调用方式、默认运行参数等。

8.4 多密钥轮询认证

系统不只使用一个固定的 API 密钥，而是遍历一组认证配置候选项，优先尝试第一个可用的 API 密钥。如果当前密钥认证失败，自动切换到下一个，直到找到可用密钥或遍历完所有候选项。这种多密钥轮询机制在生产环境里可以最大限度避免单密钥限流或失效导致的服务不可用。

8.5 发起单次 AI 调用尝试

通过 runEmbeddedAttempt 函数进行单次 AI 调用尝试，把提示词、会话历史、工具环境、模型参数、认证信息、工作目录全部交给底层的智能体运行时，正式向大模型发起请求。

第九层：Agent Loop 执行循环

源文件：src/agents/pi-embedded-runner/run/attempt.ts

核心函数：runEmbeddedAttempt

这是整个流程里真正向大模型发起请求、完成核心推理的一步。

9.1 准备运行环境

通过 resolveUserPath 和 resolveSandboxContext 函数确定工作目录和沙箱边界，确保所有文件操作都在受控工作区内进行，不对用户系统造成非预期修改。

9.2 加载技能与上下文文件

加载当前智能体可用的所有技能和上下文文件。

9.3 创建工具集

执行 createOpenClawCodingTools 函数，创建智能体可以使用的所有工具：

OpenClaw 自研工具：exec（执行命令）、process（管理后台进程）、apply_patch（应用代码补丁）等
Pi SDK 提供的工具：read（读取文件）、write（写入文件）、edit（编辑文件）、grep（内容搜索）等

9.4 构建系统提示词

通过 buildEmbeddedSystemPrompt 和 buildAgentSystemPrompt 函数，读取大量运行时环境信息，拼接成一个非常长的结构化系统提示词——包括所有技能文档、项目说明文档、架构文档、灵魂设定文档，甚至每日生成的记忆文件。

大模型获得了更完整的环境信息，但也会消耗巨量 token；上下文过长时，反而会稀释模型注意力，导致抓不住核心需求，甚至触发上下文窗口溢出。这是 OpenClaw token 消耗过快、偶尔出现幻觉的核心原因之一。

9.5 创建智能体会话并发起请求

通过 Pi SDK 的 createAgentSession 函数创建智能体会话，把所有工具、上下文、规则绑定到会话里，再通过 applySystemPromptOverrideToSession 把系统提示词固定到本次会话。

最核心的一步：通过 activeSession.agent.streamFn 建立流式请求函数，调用 activeSession.prompt(effectivePrompt) 真正向大模型发送请求。

Pi SDK 负责管理整个 Agent Loop（智能体执行循环）：

模型生成文本内容
触发工具调用
接收工具返回结果
把工具结果写回会话历史
继续下一轮推理生成
循环直到任务完成

9.6 流式分发

因为是流式生成，模型会逐段输出内容，系统通过 subscribeEmbeddedPiSession 订阅会话里的所有事件，在流式输出过程中触发 onPartialReply、onBlockReply 等回调函数，把每一段刚生成的内容立刻推送给前端消息渠道。

这就是我们在聊天窗口看到的"打字机效果"的底层实现：事件订阅 + 块级流式分发机制。

第十层：回复分发与发送

源文件：extensions/whatsapp/src/auto-reply/monitor/process-message.ts

核心函数：dispatchReplyWithBufferedBlockDispatcher

最后一步：接收 AI 已经生成好的回复内容，按照合适的方式发送回对应的聊天平台。

replyresolver：接收来自智能体运行层的所有结果（文本内容、工具调用信息、内容块 ID 等），转换成最终可以发送的回复结构
deliverWebReply：根据当前使用的渠道（WhatsApp、Telegram 等），调用对应的平台接口，把整理好的回复内容推送给用户

在流式回复场景下，系统接收到每一段完整内容后就立刻发送出去，所以我们看到的回复是一段一段逐渐出现的，而不是等待很久后一次性显示完整答案。

当所有内容发送完成，这一轮的消息处理流程正式结束，整个系统回到初始监听状态，等待下一条用户消息。

总结：OpenClaw 的四个核心特质

经过以上十层的完整拆解，我们可以提炼出 OpenClaw 的四个核心特质：

1. 运行时装配体系

OpenClaw 最核心的价值，在于构建了一套完整的运行时装配体系，能把用户的一条消息精准嵌入到一个全维度的运行环境里。

2. 不生产智能，只搭建舞台

OpenClaw 本身并不生产智能——它把核心的智能生成任务完整交给了外部的 Pi SDK，自己却完成了鉴权校验、文件读写、工具管理、上下文装配、会话调度、渠道适配、异常处理等所有的"脏活累活"，最后把整理好的数据喂给大模型的 SDK。

3. 提示词工程的极致实践

OpenClaw 把所有的运行时信息，全部显式地、结构化地翻译进了系统提示词里，是提示词工程做到极致的典型案例。

4. 本地优先的消息系统网关

从架构上看，OpenClaw 的前端对接了大量消息渠道，中间是统一的控制平面，底层挂载了智能体运行时、工具集、CLI 交互界面、记忆系统等。网关才是整个系统的控制平面，本质上它是一个网关系统。

完整流程一览

用户发送消息
    ↓
[第一层] 网关启动与初始化 (monitor.ts)
    ↓
[第二层] 消息接入与标准化 (inbound/monitor.ts)
         去重 → 权限校验 → 媒体下载 → 封装为 WebInboundMessage → 防抖队列
    ↓
[第三层] 消息路由与智能体分发 (on-message.ts)
         动态配置 → 方向解析 → resolveAgentRoute → 会话键值 → 安全检查
    ↓
[第四层] 推理环境准备 (get-reply.ts)
         确认智能体 → 工作目录 → 媒体解析 → 加载历史 → 解析指令
    ↓
[第五层] 执行参数转换 (get-reply-run.ts)
         提示词结构化 → 运行配置调整 → 消息队列排序
    ↓
[第六层] 生命周期调度 (agent-runner.ts)
         入队 → 记忆压缩持久化 → 触发 runAgentTurnWithFallback
    ↓
[第七层] 执行容错与降级 (agent-runner-execution.ts)
         UUID 注册 → 失败重试 → 降级切换 → CLI/嵌入式路径选择
    ↓
[第八层] 嵌入式智能体准备 (pi-embedded-runner/run.ts)
         排队规则 → 输出格式 → 模型补全 → 多密钥轮询
    ↓
[第九层] Agent Loop 执行循环 (run/attempt.ts)
         沙箱环境 → 工具集 → 系统提示词构建 → 创建会话 → 发起请求
         ↕ (工具调用 ↔ 推理生成，循环直到任务完成)
    ↓
[第十层] 回复分发与发送 (process-message.ts)
         结果整理 → 格式适配 → 推送到即时通讯平台
    ↓
用户看到回复

理解了这套完整的执行链路，你会发现 OpenClaw 真正厉害的地方，不在于它调用了多么先进的 AI 模型，而在于它用工程化的方式，把"让 AI 真正可用于生产环境"这件事，做得非常扎实。

Java Static Inner Class

Thu, 12 Feb 2026 00:00:00 +0000

Java Static Inner Class

import java.lang.reflect.Field;

public class Outer {

    class Inner {
    }

    static class StaticInner {
    }

    public static void main(String[] args) {
        System.out.println("Inner fields:");
        for (Field f : Inner.class.getDeclaredFields()) {
            System.out.println("  " + f.getName() + " : " + f.getType());
        }

        System.out.println("StaticInner fields:");
        for (Field f : StaticInner.class.getDeclaredFields()) {
            System.out.println("  " + f.getName() + " : " + f.getType());
        }
    }
}

运行结果：

Inner fields:
  this$0 : class Outer
StaticInner fields:

结论：

Java 的静态内部类（Static Inner Class）不会隐式地持有对外部类实例的引用，因此它没有 this$0 字段。
非静态内部类（Inner Class）会隐式地持有对外部类实例的引用，因此它有一个 this$0 字段，指向外部类的实例。

当我们谈论 Agent Infra 时，我们到底在谈什么？

Sat, 31 Jan 2026 00:00:00 +0000

当我们谈论 Agent Infra 时，我们到底在谈什么？

引言

Agent 基础设施毫无疑问是当下 VC 投资中最火热的方向之一。我个人也在这个领域下注——但与大多数 VC 不同的是，我是以基础设施使用者和构建者的身份进入这个领域的。正因如此，我想从一个经常被忽视、却非常基础的问题出发：

当我们谈论 Agent Infra 时，我们到底在谈什么？

这篇文章不讨论什么

首先，先划清边界。这篇文章不是在讨论通用 AI 基础设施——无论是预训练、后训练 RL，还是推理基础设施。这些都不在本文的讨论范围内，说实话，我对它们兴趣也不大。

这些系统大多服务于训练流程，不管是预训练还是 RL。模型训练本质上是一次性或按代进行的活动，这意味着围绕它构建的许多支撑系统天生就是"可丢弃"的。

而推理基础设施则已经高度商品化，在产品层面几乎没有太多创新空间。

真正的机遇

真正让我感兴趣的是：推理基础设施之上的东西。

随着 Agent 开始接管越来越多的工作，我相信在"推理之上、Agent 之下"，会出现一个全新的基础设施层——一个专门为 Agent 的执行与协作而设计的运行时层。

当前默认的 Agent 架构

我们先对齐一下大多数人心中"默认"的 Agent 架构。一个典型的 Agent 系统通常包含以下组件：

五个核心组件

LLM / 推理核心
- 负责理解上下文、生成计划、决定下一步行动
Planner / Executor（规划器 / 执行器）
- 将复杂目标拆解为步骤，并逐步执行
Tools / Skills（工具 / 技能）
- 封装的外部能力，例如调用 API、执行代码、访问数据库、浏览网页等
Memory / Context Store（记忆 / 上下文存储）
- 存储中间状态、历史行为、长期偏好等
Environment（环境，通常是隐式的）
- 动作被执行的真实或虚拟世界

Agentic Loop

这些组件运行在一个持续循环中——也就是 Agentic Loop，这几乎是当今所有 Agent 所采用的架构。

当前架构的问题

虽然这个架构在概念上清晰，但在实践中存在多个关键瓶颈，限制了 Agent 系统的能力和效率。

顺序执行是天然瓶颈

我之前已经写过相关内容。即使规划是完美的，大多数 Agent 仍然按如下方式执行任务：

一步 → 等结果 → 下一步

这是一个高度顺序化的执行模型。即便使用了子 Agent，任务分发的粒度也通常非常小。

问题表现

动作之间的强依赖使并行几乎不可能
任意一步失败都会阻塞整个执行路径
对探索型任务极其低效

关键洞察

我强烈直觉认为：大规模探索是解决真正复杂任务的关键。

举个例子，在我优化 Coding Agent 工作流时，目标是让 Agent 在尽可能长的时间内自主运行、无需人工干预。但"没有方向的自主"是毫无意义的，真正的关键在于：让 Agent 能持续探索多种可能性、总结结果、并迭代改进。

如果探索本身是低效的，整体吞吐和质量都会迅速崩溃。

Agent 协作的极限

我们已经见过许多 Agent 协作的尝试：通信协议、协调框架、多 Agent 系统。MCP、A2A 是其中比较有代表性的例子——但它们都谈不上真正成功。

今天的 Agent 协作，更像是"勉强能对话的 Agent"，离真正的协作还差得很远。

协议的局限

当然，人们在积极推动 A2A 类方案，想法本身也没错：Agent 应该能委派任务、汇报进度、动态协作。

问题在于：协议本身并不够。

A2A 只是定义了"应该发生什么"，却没有回答"如何构建一个真正可用的系统，让这些事情真的发生"。中间仍然缺失一个关键层，而到目前为止，还没有一个真正可用的平台。

长时间任务中的环境退化

还有一个我认为极其重要、却被严重低估的问题。

如果你的系统无法提供原子化、无副作用的动作，那么在复杂任务执行过程中，环境几乎必然会逐步退化。

问题的根源

这在 Demo 中并不明显。但在任何长链路、多步骤、探索型工作流中，几乎是必然发生的。

现实世界中的大多数动作都具有强副作用。一旦第一个动作执行，环境就已经被"污染"了。随着动作不断叠加，状态累积、错误放大、失败路径与成功路径交织在一起，最终 Agent 根本无法判断当前环境真实处于什么状态。

到那时，无论规划器多聪明、推理能力多强，Agent 都是在一个不断腐化的环境中做决策。

现实案例：Coding Agent

Coding Agent 是最典型的例子。把它们放进一个真实的大型代码库，很快就会出现同样的模式：

工作区变得混乱
随机的 Markdown 文件到处都是
日志风格不统一
临时代码没人清理
多个子 Agent 在同一目录互相覆盖修改

这就是环境退化的教科书案例。

现有的变通方案：Git Worktree

工程师们已经找到了一种粗糙但有效的变通方案：Git worktree。

每个子 Agent 拥有一个隔离的 worktree，在最小化的环境中完成任务，只通过 diff 或 PR 的形式返回结果。

本质上，这是一种低成本的方式，用来提供隔离、可丢弃的执行环境。它很接近正确答案，但它无法规模化，也无法泛化。

通往物理世界的"最后一公里"

表面上看，今天的 Agent 已经很强大了。但一旦你让它们做一些没有干净 API 的事情，一些真正影响现实世界的操作，体验立刻变得脆弱不堪。

试着让 Agent 去下单、付款、订酒店。

Skills 的局限

Skills 是一个很好的抽象——我也非常喜欢它。在纯软件场景下，它们表现不错。但一旦任务进入物理世界，这个抽象就开始失效。

现实世界充满了隐式状态：登录会话、权限、风控、UI 变化、临时校验、重试机制。人类可以直觉性地处理这些，但它们几乎从未被封装成干净的执行模型。

结果是：Agent 的每一步操作都会在环境中留下"残留"，而这些残留又会反过来影响后续规划。

未来展望

我怀疑，Skills 很快会从"软件操作"扩展到诸如"买菜 Skill""买咖啡 Skill"这类能力。只有这样，Claude Cowork 这样的产品才能真正发挥潜力。

一个可能的方向：Box 抽象

问题的既视感

这些问题让我产生了一种强烈的既视感。

在过去十多年里，DevOps 和云计算在从单机系统迈向大规模分布式架构时，曾遇到过几乎一模一样的挑战。

早期系统不稳定、难以调试、不可复现。在单机上还能勉强应付，一旦到 1000 台机器，状态爆炸就成了致命问题。

最初我们责怪人：流程不规范、运维粗心、文档不完整。后来才意识到，真正的问题并不在于人，而在于缺乏稳定的执行基础。

云计算的解决方案

容器、不可变基础设施、基础设施即代码、声明式配置，并没有让软件更聪明，但它们让环境变得可控：

失败可复现
部署可重复
操作可幂等

历史的重复

当我今天看 Agent Infra 时，感觉我们正站在同一个拐点上。

Agent 并不缺智能，它们被迫在不稳定、不可预测的环境中工作。

引入 Box

我的第一个建议其实很简单：将 Skill 与其执行环境绑定在一起。

引入一个新的抽象，我们称之为 Box。

Box 的定义

一个 Box：

不暴露任何执行细节
没有外部依赖
没有副作用
封装了 Skill 引导的动作 + 可复现、可丢弃的环境

Box 解决的是单一环境内的执行质量问题。由于它是由 Skill 定义的，因此可以组合、继承。

实际例子

例如，"给我买一杯咖啡"可以拆解为原子级 Skills：

打开浏览器 → Box1
登录我的账号 → Box2
下单买咖啡 → Box3

这些可以组合成一个 "Buy Coffee" Box，前两个 Box 甚至可以被缓存。

Claude 只需要写：

box3 = box1 + box2
box3.spawn().buy_coffee('latte')

咖啡买完后，Box 被销毁——本地环境不会被污染。

Box vs Docker

与 Docker 不同，Box 的环境是纯粹的、轻量的、完全语义化的，没有任何技术细节向上泄漏。

从编码到物理世界

这种方式不仅解决了 Coding Agent 的"最后一公里"问题，还能走得更远——它弥合了代码与现实世界之间的鸿沟。

对于"买咖啡""找并预订最便宜的酒店"这类任务，等待 API 出现并不现实。

Box 是一次尝试：把物理世界编码化。

一旦我们拥有足够多的 Box 函数，编程现实世界将变成 Agent 最擅长的事情。

已有的探索

已经有一些前沿创业公司在探索类似方向，例如：

Agent 的 Kubernetes

如果每个动作都运行在可复现、可丢弃的 Box 中，下一个问题几乎是必然的：

谁来创建 Box？
谁来调度它们？
谁来监控它们？
谁来决定重试、放弃，还是分叉执行路径？

答案再次来自云基础设施。

Kubernetes 成为了容器编排的事实标准。那么，Agent 的 Kubernetes 会是什么样？

理想的基础设施层

我认为它应该是一个与模型无关的基础设施层，包含以下组件：

1. Context Manager（上下文管理器）

基于分布式数据库和分布式文件系统。数据库管理结构化的共享上下文（如对话历史，用于 prompt 构造），文件系统则提供 Agent 工作区之外的协作空间。

2. 一等公民的"分支"能力

这不是 Git 分支或 worktree，而是系统级的执行分支机制。多个 Agent（或同一个 Agent）可以在共享目标的前提下，同时探索不同路径，且互不产生副作用。

元数据由数据库管理，分支文件系统提供底层支撑。

3. 网络内消息 / 通信枢纽

嵌入到每个 Box 运行时中：

box1.send_message(box2, 'hello')
box1.publish_event('buy_coffee_success')
box2.on_event('buy_coffee_success', on_success)

4. 调度器 + 生命周期管理器

负责资源放置、并发控制、重试、超时、取消以及失败策略。

在容器世界里，Kubernetes 每天都在做这些事；而在 Agent 系统中，大多数团队仍然把这些逻辑硬编码进框架里，反复造轮子，可靠性却参差不齐。

5. Box Runtime

也就是前面描述的执行环境。

结语

到这个阶段，我认为已经没必要再反复强调模型会变得多么聪明。

决定 Agent 能否胜任复杂任务的，并不仅仅是智能水平，而是：

执行是否可控
失败是否廉价
环境是否可替换
协作是否由基础设施保障

借鉴历史

Agent Infra 面临的挑战并不新。我们在其他领域已经遇到过，也部分解决过。

现在剩下的，是将这些经验重新组织，并应用到这个新的运行时层之上——Agent Runtime。

深分页（deep pagination）在 MySQL 的应对策略

Tue, 11 Nov 2025 00:00:00 +0000

深分页（deep pagination）在 MySQL 的应对策略

Keyset Pagination（也叫 Seek / 游标分页）原理：不使用 OFFSET，而用已知的“最后一条记录的排序键”做 WHERE 过滤（比如自增主键、时间戳或组合索引），做索引查找，效率非常高。

示例（倒序按 created_at + id 唯一确定顺序）

-- 首次请求（第一页）
SELECT id, title, created_at
FROM posts
WHERE status = 'published'
ORDER BY created_at DESC, id DESC
LIMIT 20;

-- 之后请求（把上次最后一条的 (created_at_last, id_last) 作为游标）
SELECT id, title, created_at
FROM posts
WHERE status = 'published'
  AND (created_at < '2025-11-11 12:34:56'
       OR (created_at = '2025-11-11 12:34:56' AND id < 12345))
ORDER BY created_at DESC, id DESC
LIMIT 20;

也可用行比较（MySQL 支持）：

... AND (created_at, id) < ('2025-11-11 12:34:56', 12345)

优点：速度快、稳定，适合实时滚动（如“下一页/上一页”或无限滚动）。缺点：无法直接跳到任意第 N 页（比如用户输入页码 10000），需要“游标 / token”支持或预计算索引。

实践建议： • 对排序字段建立覆盖索引（如 INDEX(status, created_at, id)），避免回表。 • 用 opaque cursor（例如 base64 编码的 created_at|id）在前后端传递，而不是明文 id。

https://www.cnblogs.com/pDJJq/p/18876878/how-to-do-pagination-z1bs5pm

keyset(seek) pagination vs offset pagination Keyset 就是指前一页最后一条的 (created_at, id), 用这一组 key 来决定下一页从哪里继续。 Seek 表示“从某个位置开始查找”

acme.sh and nginx

Sun, 01 Dec 2024 00:00:00 +0000

acme.sh and nginx

配置 DNSPod API Key

export DP_Id="539918"
export DP_Key="d979904a961294da0e797669b7c18f9d"

颁发证书

acme.sh --issue --dns dns_dp -d yuhaowin.com -d *.yuhaowin.com

部署证书到七牛云

export QINIU_AK="_woYoRMBoiC_qRYOmaB4ukjAOS7tPYhrzJS-wf82"
export QINIU_SK="WOtu_RHHWgUpSyDj-GSz98tl1Qo_5Kg89fsr6azm"
export QINIU_CDN_DOMAIN=".yuhaowin.com"
acme.sh --deploy -d yuhaowin.com --deploy-hook qiniu

部署证书到本地 nginx

acme.sh --install-cert -d yuhaowin.com \
--key-file       /home/ubuntu/app/nginx/cert/yuhaowin.com/yuhaowin.com.key  \
--fullchain-file /home/ubuntu/app/nginx/cert/yuhaowin.com/fullchain.cer \
--reloadcmd     "docker restart nginx"

java record class feature

Mon, 21 Oct 2024 00:00:00 +0000

java record class feature

使用 jackson 反序列化 record 类型遇到的问题

定义一个 record 类

包含两个组件(字段), 一个是基本类型 age, 一个是集合类型 nickNames。

public record Person(int age, List<String> nickNames) {
}

上述代码没有声明构造器，java 编译器会自动生成一个标准构造器，参数是 age 和 nickNames。

public record Person(int age, List<String> nickNames) {
    // java 编译器会自动生成一个标准构造器
    public Person(int age, List<String> nickNames) {
        this.age = age;
        this.nickNames = nickNames;
    }
}

通过 jackson 反序列化 json 字符串到 Person 类型对象。

{
  "age": 18,
  "nick_names": [
    "Tom",
    "Jerry"
  ]
}

问题 1

通过 jackson 反序列化 json 字符串到 Person 类型对象时，遇到如下异常。

public record Person(int age, List<String> nickNames) {

    public static void main(String[] args) throws Exception {
        ObjectMapper mapper = new ObjectMapper();
        Person person = mapper.readValue("""
                {
                  "age": 18,
                  "nick_names": ["Tom", "Jerry"]
                }
                """, Person.class);
        System.out.println(mapper.writeValueAsString(person));
    }
}

Exception in thread "main" com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "nick_names"

这是因为 jackson 默认使用驼峰命名法，而 json 字符串中的字段是下划线命名法，所以需要在 record 类中使用 @JsonProperty 注解。

public record Person(int age, @JsonProperty("nick_names") List<String> nickNames) {

    public static void main(String[] args) throws Exception {
        ObjectMapper mapper = new ObjectMapper();
        Person person = mapper.readValue("""
                {
                  "age": 18,
                  "nick_names": ["Tom", "Jerry"]
                }
                """, Person.class);
        System.out.println(mapper.writeValueAsString(person));
    }
}

同样会生成一个标准构造器。

public record Person(int age, @JsonProperty("nick_names") List<String> nickNames) {
    // java 编译器会自动生成一个标准构造器
    public Person(int age, @JsonProperty("nick_names") List<String> nickNames) {
        this.age = age;
        this.nickNames = nickNames;
    }
}

对 nickNames 字段进行校验

使用简化构造器（Compact Constructor）对 nickNames 字段进行校验，如果为 null，则初始化为一个空的集合。这种构造器可以省略构造器参数列表，直接在构造器主体中编写逻辑。编译器会自动推断出所有定义的字段，并进行赋值。

public record Person(int age, @JsonProperty("nick_names") List<String> nickNames) {

    // 使用简化构造器对 nickNames 字段进行校验
    public Person {
        if (Objects.isNull(nickNames)) {
            nickNames = List.of();
        }
    }

    public static void main(String[] args) throws Exception {
        ObjectMapper mapper = new ObjectMapper();
        Person person = mapper.readValue("""
                {
                  "age": 18,
                  "nick_names": ["Tom", "Jerry"]
                }
                """, Person.class);
        System.out.println(mapper.writeValueAsString(person));
    }
}

上述简化构造编译后等价于下面代码实现

public record Person(int age, @JsonProperty("nick_names") List<String> nickNames) {
    // 上述简化构造编译后等价于下面的标准构造器
    public Person(int age, @JsonProperty("nick_names") List<String> nickNames) {
        if (Objects.isNull(nickNames)) {
            nickNames = List.of();
        }
        this.age = age;
        this.nickNames = nickNames;
    }
}

同样我们也开始手动实现一个标准构造器，标准构造器。

public record Person(int age, @JsonProperty("nick_names") List<String> nickNames) {

    // 手动实现标准构造器，对 nickNames 字段进行校验
    public Person(int age, @JsonProperty("nick_names") List<String> nickNames) {
        this.age = age;
        this.nickNames = Objects.isNull(nickNames) ? List.of() : nickNames;
    }

    public static void main(String[] args) throws Exception {
        ObjectMapper mapper = new ObjectMapper();
        Person person = mapper.readValue("""
                {
                  "age": 18,
                  "nick_names": ["Tom", "Jerry"]
                }
                """, Person.class);
        System.out.println(mapper.writeValueAsString(person));
    }
}

需要注意的是，手动实现的标准构造器的 nickNames 字段必须用 @JsonProperty("nick_names") 修饰。不然会出现一下错误。

public record Person(int age, @JsonProperty("nick_names") List<String> nickNames) {

    // nickNames 字段没有使用 @JsonProperty("nick_names") 修饰，导致反序列化失败
    public Person(int age, List<String> nickNames) {
        this.age = age;
        this.nickNames = Objects.isNull(nickNames) ? List.of() : nickNames;
    }

    public static void main(String[] args) throws Exception {
        ObjectMapper mapper = new ObjectMapper();
        Person person = mapper.readValue("""
                {
                  "age": 18,
                  "nick_names": ["Tom", "Jerry"]
                }
                """, Person.class);
        System.out.println(mapper.writeValueAsString(person));
    }
}

Exception in thread "main" com.fasterxml.jackson.databind.JsonMappingException: Can not set final java.util.List field com.wosai.crm.qa.Person.nickNames to java.util.ArrayList

这是因为 jackson 无法通过构造器完成 Person 对象的反序列化，构造器参数 nickNames 无法和 nick_names 对应，然后使用反射机制直接修改了 nickNames 字段，而 nickNames 字段是 final 的，所以会抛出异常。

问题 2

如果使用普通类代替 record 类，需要使用 @JsonCreator 修改构造器和使用 @JsonProperty 修饰构造器参数。

public class Person {

    @JsonProperty("age")
    private final Long age;

    @JsonProperty("nick_names")
    private final List<String> nickNames;

    // 使用 @JsonCreator 修改构造器和使用 @JsonProperty 修饰构造器参数。
    @JsonCreator
    public Person(@JsonProperty("age") Long age, @JsonProperty("nick_names") List<String> nickNames) {
        this.age = age;
        this.nickNames = nickNames;
    }

    public static void main(String[] args) throws JsonProcessingException {
        ObjectMapper mapper = new ObjectMapper();
        Person metaData = mapper.readValue("""
                {
                   "age": 18,
                   "nick_names": ["Tom", "Jerry"]
                 }
                """, Person.class);
        System.out.println(mapper.writeValueAsString(metaData));
    }
}

http 接口偶然响应慢问题排查

Mon, 05 Aug 2024 00:00:00 +0000

http 接口偶然响应慢问题排查

apt-get update && apt-get install -y tcpdump hping3 mtr traceroute iputils-ping --no-install-recommends tcpdump hping3 mtr

tcpdump -i eth0 host api.dify.ai -w capture.pcap

kubectl cp crm-qa-12579-7ff6459456-rzzz6:/app/bin/capture.pcap ~/Desktop/crm-qa.pcap

curl --location 'https://api.dify.ai/v1/chat-messages'
--header 'Content-Type: application/json'
--header 'Authorization: Bearer fake-token'
--data '{ "query": "拉卡拉校园食堂开通分账业务审批填写规范", "response_mode": "streaming", "user": "yuhao", "inputs": {} }'

https://weiborao.link/docker-traceroute-tcpdump.html

curl -o /dev/null -s -w time_namelookup:"\t"%{time_namelookup}"\n"time_connect:"\t\t"%{time_connect}"\n"time_appconnect:"\t"%{time_appconnect}"\n"time_pretransfer:"\t"%{time_pretransfer}"\n"time_starttransfer:"\t"%{time_starttransfer}"\n"time_total:"\t\t"%{time_total}"\n"time_redirect:"\t\t"%{time_redirect}"\n" --location 'https://api.dify.ai/v1/chat-messages'
--header 'Content-Type: application/json'
--header 'Authorization: Bearer fake-token'
--data '{ "query": "拉卡拉校园食堂开通分账业务审批填写规范", "response_mode": "streaming", "user": "yuhao", "inputs": {} }'

tcpdump -i lo port 6310 -w http.pcap

tcpdump -i eth0 host sg-dify.wosai-inc.com -w capture.pcap

tcpdump -i eth0 host api.dify.ai -w capture.pcap

apt-get update && apt-get install -y traceroute iputils-ping --no-install-recommends tcpdump

apt-get install hping3

hping3 -S -p 443 -c 100 api.dify.ai

kubectl cp crm-qa-base-5799dbd479-kjxcv:/app/bin/capture.pcap ~/Desktop/crm-qa-1.pcap

kubectl cp crm-qa-12579-7ff6459456-rzzz6:/opt/jacoco/report/profit-sharing/report.exec ~/Downloads/report.exec

curl -w "总时间: %{time_total}s\n名称解析时间: %{time_namelookup}s\n连接时间: %{time_connect}s\nTLS握手时间: %{time_appconnect}s\n等待时间: %{time_starttransfer}s\n数据传输时间: %{time_total}s\nHTTP状态码: %{http_code}\n" -o /dev/null --location 'https://api.dify.ai/v1/chat-messages'
--header 'Content-Type: application/json'
--header 'Authorization: Bearer fake-token'
--data '{ "query": "拉卡拉校园食堂开通分账业务审批填写规范", "response_mode": "streaming", "user": "yuhao", "inputs": {} }'

curl -o /dev/null -s -w time_namelookup:"\t"%{time_namelookup}"\n"time_connect:"\t\t"%{time_connect}"\n"time_appconnect:"\t"%{time_appconnect}"\n"time_pretransfer:"\t"%{time_pretransfer}"\n"time_starttransfer:"\t"%{time_starttransfer}"\n"time_total:"\t\t"%{time_total}"\n"time_redirect:"\t\t"%{time_redirect}"\n" --location 'http://sg-dify.wosai-inc.com/v1/chat-messages'
--header 'Content-Type: application/json'
--header 'Authorization: Bearer fake-token'
--data '{ "query": "拉卡拉校园食堂开通分账业务审批填写规范", "response_mode": "streaming", "user": "yuhao", "inputs": {} }'

curl -o /dev/null -s -w time_namelookup:"\t"%{time_namelookup}"\n"time_connect:"\t\t"%{time_connect}"\n"time_appconnect:"\t"%{time_appconnect}"\n"time_pretransfer:"\t"%{time_pretransfer}"\n"time_starttransfer:"\t"%{time_starttransfer}"\n"time_total:"\t\t"%{time_total}"\n"time_redirect:"\t\t"%{time_redirect}"\n" --location --request GET 'https://api.dify.ai/v1/datasets?page=1&limit=20'
--header 'Authorization: Bearer fake-token'

state-machine 状态机

Sun, 12 May 2024 00:00:00 +0000

state-machine 状态机

https://www.cnblogs.com/StarbucksBoy/p/16888787.html

https://blog.csdn.net/significantfrank/article/details/104996419

https://cloud.benym.cn/pages/2ae430/#%E8%83%8C%E6%99%AF

回车和换行的历史

Thu, 17 Aug 2023 00:00:00 +0000

回车和换行的历史

"回车" 和 "换行" 均是来源机械英文打字机，是两个独立的过程。

回车

回车的英文是：Carriage Return，回车的意思是回到一行的开头，但并不会换到下一行，只是回到了一行的开头。

回车中的"车"指的是纸车,带着纸一起左右移动的模块，当开始打第一个字之前，要把纸车拉到最右边，弹簧处于拉伸状态，随着打字弹簧会把纸车往左边拉，每当打完一行后，纸车就完全收回去了，当打下一行之前需要重新把纸车拉到最右边，使得指针指向行的开头，所以叫回车。

换行

换行的英文是：Line Feed，换行的意思是换到下一行，但并不会回到行的开头，只是换到了下一行的同一位置。

机械英文打字机左边有个"把手"，往下扳动一下，纸会上移一行，所以叫换行。

回车换行在现代计算机中的表示

回车：CR，ASCII 代码是 13，或 0x0D，CR=Carriage Return=/r
换行：LF，ASCII 代码是 10，或 0x0A，LF=Line Feed=/n

不同操作系统对行分隔符的不同实现

行分隔符，Line Separator，不同操作系统对行分隔符的实现是不同的。

Windows 系统里，行分隔符为 /r/n，每行结尾是 "回车+换行"，即 "CR+LF"，ASCII 码为 0x0D 0x0A
Mac 9 以及以前系统里，行分隔符为 /r，即 "CR"，ASCII 码为 0x0D
Unix/Linux、Mac X 以及以后系统里，行分隔符为 /n，即 "LF"，ASCII 码为 0x0A

显示文本文件中的行分隔符

在 macOS 终端中，要正确显示文件中的回车换行字符，可以使用如下命令：

cat -e filename

这个命令会将文件的内容显示在终端上，并以可见的方式显示回车换行字符。回车字符会显示为^M，换行字符会显示为$。

也可以使用 od 命令，将文件的内容以十六进制形式显示，并显示特殊字符的表示。以下是一个示例命令:

od -c filename

这将会以十六进制和字符形式显示文件内容，可以在输出中找到回车换行字符（\r 和 \n）。

常用文本编辑器和 IDE 中行分隔符的设置

一般文本编辑器都可以选择使用不同的行分隔符。

Sublime Text

View -> Line Endings

JetBrains IDE

Settings -> Editor -> Code Style -> Line separator

reference

closure table

Thu, 03 Aug 2023 00:00:00 +0000

closure table

https://blog.csdn.net/qq_38011415/article/details/95462698

https://juejin.cn/post/7129023794701828104

MySQL InnoDB Buffer Pool Size 调优

Tue, 06 Jun 2023 00:00:00 +0000

MySQL InnoDB Buffer Pool Size 调优

背景：项目提测，发现数据库性能不佳，内存占用并不高，经过排查，发现是数据库的缓存池配置不合理，导致数据库频繁 IO，影响性能。

MySQL 内存分配

MySQL 的内存可以分为 global 级的共享内存和 session 级的私有内存两部分，共享内存是实例启动时分配的是所有连接共享的。私有内存用于每个连接到 MySQL 服务器时才分配各自的缓存，一些特殊的 SQL 或字段类型会导致单个线程可能分配多次缓存，因此当出现 OOM 异常，都是由各个连接私有内存造成的。

InnoDB Buffer Pool

该部分缓存是 InnoDB 引擎最重要的缓存区域，是通过内存来弥补物理数据文件的重要手段，MySQL 参考手册推荐该部分配置为机器内存规格配置的50% - 75% 。其中主要包含数据页、索引页、undo 页、insert buffer、自适应哈希索引、锁信息以及数据字典等信息。在进行 SQL 读和写的操作时，首先并不是对物理数据文件操作，而是先对 buffer_pool 进行操作，再通过 checkpoint 等机制写回数据文件。该空间的优点是可以提升数据库的性能、加快 SQL 运行速度，缺点是故障恢复速度较慢。

InnoDB Buffer Pool Size 调优

1. 查看当前 Buffer Pool Size

默认大小为 128M，支持配置的单位时 K、M、G，不支持小数点，如果配置的值不是这些单位，会被转换为字节。

mysql> show variables like '%innodb_buffer_pool_size%';

2. 查看当前 Buffer Pool 使用情况

mysql> show engine innodb status

3. 查看当前 Buffer Pool 命中率

mysql> show global status like 'innodb_buffer_pool_read%';

MySQL 基准测试

修改配置前后需要进行基准测试，以便对比优化效果。

使用 sysbench 做基准测试

1. 安装 sysbench

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
sudo yum -y install sysbench

2. 查看版本

sysbench --version

3. 准备数据

sysbench oltp_common.lua --time=300 --mysql-host=10.120.68.91 --mysql-port=3306 --mysql-user=root --mysql-password=xkjc_123 --mysql-db=sbtest --table-size=1000000 --tables=10 --threads=32 --events=999999999 prepare

4. 运行测试

sysbench oltp_read_write.lua --time=300 --mysql-host=10.120.68.91 --mysql-port=3306 --mysql-user=root --mysql-password=xkjc_123 --mysql-db=sbtest --table-size=1000000 --tables=10 --threads=16 --events=999999999  --report-interval=10  run

5. 清理数据

sysbench oltp_read_write.lua --time=300 --mysql-host=10.120.68.91 --mysql-port=3306 --mysql-user=root --mysql-password=xkjc_123 --mysql-db=sbtest --table-size=1000000 --tables=10 --threads=16 --events=999999999 --report-interval=10 cleanup

6. 效果对比

机器物理内存 16G。

buffer_pool_size 默认为 128M 时，性能如下：

buffer_pool_size 调整为 6G 时，性能如下：

innodb_buffer_pool_size 无法动态调整到 1G 以下问题

如果需要调整 innodb_buffer_pool_size 至 1G 以下，innodb_buffer_pool_instances 参数值必须是 1，否则会报错。

如果配置的 innodb_buffer_pool_size 大于 1G，innodb_buffer_pool_instances 没有手动配置则会自动配置为 8 。此时无法把 innodb_buffer_pool_size 动态调整到 1G 以下。

参考

Java generic & wildcard

Sun, 12 Mar 2023 00:00:00 +0000

Java generic & wildcard

泛型类

泛型类的定义

    class name<T1, T2, Tn> { /* ... */ }

Java 把上述 T1, T2, and Tn 称为泛型类型(Generic Types)，或者类型参数(type parameters), 类型参数可以在类中任何地方使用。

    public class Box<T> {
        // T stands for "Type"
        private T t;

        public void set(T t) { this.t = t; }
        public T get() { return t; }
    }

泛型类的使用

    Box<Integer> integerBox = new Box<Integer>();
    Box<String> stringBox = new Box<String>();

泛型在使用时可以是任何的类、接口、数组、甚至是另一个泛型类。如上述的 T, T1, T2, and Tn 可以是 Integer, String, List, List 等等。

泛型接口

和泛型类一样，泛型接口也可以定义一个或多个类型参数，将类型参数置于接口名的后面。

    public interface Pair<K, V> {
        public K getKey();
        public V getValue();
    }

    public class OrderedPair<K, V> implements Pair<K, V> {
        private K key;
        private V value;
    
        public OrderedPair(K key, V value) {
	    this.key = key;
	    this.value = value;
        }
    
        public K getKey()	{ return key; }
        public V getValue() { return value; }
    }

其中 OrderedPair<K, V> 是泛型的定义，implements Pair<K, V> 中的 K 和 V 是泛型的使用，而不是定义，因为OrderedPair<K, V> 已经定义了 K 和 V。

    OrderedPair<String, Box<Integer>> p = new OrderedPair<>("primes", new Box<Integer>(...));

泛型方法

泛型方法有自己声明的类型参数，这些类型参数的声明放在返回值之前。但泛型方法的类型参数的作用域只限于方法本身。适用于静态方法和实例方法以及泛型类的构造器。可以被用到方法的参数声明、方法返回值、方法体中变量的声明和类型转换。泛型方法使得该泛型方法的类型参数独立于类而产生变化。泛型方法和泛型类没有必然关系。

    public class Util {
        public static <K, V> boolean compare(Pair<K, V> p1, Pair<K, V> p2) {
            return p1.getKey().equals(p2.getKey()) &&
                   p1.getValue().equals(p2.getValue());
        }
    }

    Pair<Integer, String> p1 = new Pair<>(1, "apple");
    Pair<Integer, String> p2 = new Pair<>(2, "pear");
    boolean same = Util.<Integer, String>compare(p1, p2);
    // 借助类型推断，可以省略类型参数
    boolean same = Util.compare(p1, p2);

有界的类型参数

可以限制类型参数的范围，限制上界使用 extends 关键字。这里可以 extends 类和接口。

    public class NaturalNumber<T extends Integer> {

        private T n;
    
        public NaturalNumber(T n)  { this.n = n; }
    
        public boolean isEven() {
            return n.intValue() % 2 == 0;
        }
    }

可以在类中使用泛型上界类的方法，如这里 Integer#intValue() 方法。

多个边界的类型参数

类型参数可以有多个上界，用 & 分隔。

    <T extends A & B & C>

这里类型参数 T 拥有 A B C 三个上界，这三个上界可以是类，也可以是接口，如果是类的话，只有有一个类，其他的都是接口，且类必须放在第一个。

    Class A { /* ... */ }
    interface B { /* ... */ }
    interface C { /* ... */ }
    
    class D <T extends A & B & C> { /* ... */ }

泛型方法中的多个边界

    public static <T extends Comparable & Serializable> T max(T[] a) { ... }

通配符类型

无边界通配符 Unbounded Wildcards 通常用于不依赖类型参数的方法中，如下面的 printList 方法。

    public static void printList(List<?> list) {
        for (Object elem: list)
            System.out.print(elem + " ");
        System.out.println();
    }

上界通配符 Upper Bounded Wildcards，

    List<? extends Number> list = new ArrayList<Integer>();

    public static double sumOfList(List<? extends Number> list) {
        double s = 0.0;
        for (Number n : list)
            s += n.doubleValue();
        return s;
    }

下界通配符 Lower Bounded Wildcards

    public static void addNumbers(List<? super Integer> list) {
        for (int i = 1; i <= 10; i++) {
            list.add(i);
        }
    }

类型参数和通配符的区别

通配符有且仅有一个边界，而类型参数可以有多个边界。
通配符可以有一个上界或有一个下界，而类型参数不支持下界。
通配符不能在泛型类、泛型接口定义中使用，只能在泛型方法定义中使用。

类型参数和通配符的选择

在方法中可以同时使用类型参数和通配符

    public <T> void func(List<? extends T> list, T t) {
        list.add(t); // compile error 不可以修改 list
    }

    public <T> void func(List<? super T> list, T t) {
        list.add(t); // 可以修改 list
    }

    public <T, E extends T> void func(List<E> list, T t){
        list.add((E) t); // 可以修改，但是需要强制类型转换
    }

通配符中上下界(extents、super) 的选择

遵循 PECS 原则，Producer Extends Consumer Super。

频繁往外读取内容的，适合用上界Extends，无法往里插入任何元素。
经常往里插入的，适合用下界Super，取出来的元素都是 Object 类型。

    public static <T> void copy(List<? extends T> src, List<? super T> dest) {
        for (int i = 0; i < src.size(); i++)
            dest.set(i, src.get(i));
    }

参考

Spring Bean 被提前创建，导致 BeanPostProcessor 对其失效

Sat, 04 Mar 2023 00:00:00 +0000

Spring Bean 被提前创建，导致 BeanPostProcessor 对其失效

问题

在一个 Spring Boot 项目中，我们集成了 Shiro 权限框架，在我们实现 AuthorizingRealm 的 UserRealm 类中，通过 @Autowired 注解注入了一个 LoginService 类，用于获取用户信息。

LoginService 中有使用自定义注解用于在 Bean 实例化阶段获取配置信息。通过 BeanPostProcessor 实现的。但 LoginService 在实例化的使用，没有被 BeanPostProcessor 增强。

    @Configuration
    public class ShiroConfiguration {
        @Bean
        public UserRealm userRealm() {
            UserRealm userRealm = new UserRealm();
            return userRealm;
        }    
    }

    @Slf4j
    public class UserRealm extends AuthorizingRealm {
        @Autowired
        private LoginService loginService;
    ｝

    @Service
    public class LoginServiceImpl implements LoginService {
        @Config("prefix")
        private String prefix;
    }

原因

UserRealm 是通过 @Configuration + @Bean 的方式注入到 Spring 容器中的。通过这种方式创建的 UserRealm 实例时，会导致 UserRealm 依赖的 LoginService 实例被提前创建，从而导致 BeanPostProcessor 对其失效。

解决

通过 @Lazy 注解，延迟 LoginService 实例的创建。

    @Slf4j
    public class UserRealm extends AuthorizingRealm {
        @Lazy
        @Autowired
        private LoginService loginService;
    ｝

参考

在 mac 下构建自己的输入法

Sun, 25 Dec 2022 00:00:00 +0000

在 mac 下构建自己的输入法

mac 是支持构建自己的输入法的，核心是编写一个 .inputplugin 的文件。

要求这个文件是 UTF-16 的编码格式。文件的具体格式见官网示例

我这里编写的是一个输入英语音标的输入法：

# https://support.apple.com/zh-cn/guide/mac-help/mchlp2866/mac
# D.J. 音标 - (IPA88)
METHOD: TABLE
ENCODE: SC
PROMPT: D.J. 音标
DELIMITER: ,
VERSION: 1.2
MAXINPUTCODE: 8
VALIDINPUTKEY: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
TERMINPUTKEY: 123456789
BEGINCHARACTER
####### 测试内容
mac     💻
apple 	🍎

####### 短元音
a 	æ
e 	e,ə
i 	i,ɪ
o 	ɒ
u 	u,ʌ,ʊ

####### 长元音
a;	ɑː
e; 	ɜː
i; 	iː
o; 	ɔː
u; 	uː

####### 双元音
au 	aʊ
ai 	aɪ
ei 	eɪ
eu 	əʊ
ee 	eə
ie 	ɪə
oi 	ɔɪ
ue 	ʊə

####### 辅音，英音和美音没有区别，D.J.63、D.J.88 和 K.K. 音标一致
p 	p
b 	b
t 	t
d 	d
k 	k
g 	g
m 	m
n 	n,ŋ
f 	f
v 	v
s 	s
z 	z
th 	θ,ð
x 	ʃ,ʒ
tx 	tʃ
dx 	dʒ
h 	h
w 	w
r 	r
j 	j
l 	l

####### 辅音连缀，可以不认为是新的音标
ts 	ts
dz 	dz
tr 	tr
dr 	dr

####### 常见两音标组合 - 待完善
an 	ʌn,æn
am 	ʌm
ek 	ək
di 	dɪ
en 	ən
em 	əm
er 	ər
eu 	əu
fe 	fə
ga 	gæ
hi 	hɪ
ke 	kə
ik 	ɪk
in 	ɪn,ɪŋ
ir 	ɪr
kj 	kjʊ
la 	lʌ,læ
le 	lə,lɛ
li 	lɪ
me 	mə
mo 	mɒ
ne 	nə
ni 	nɪ
ou 	oʊ
pa 	pæ
ra 	ræ,rʌ
re 	rə
ri 	rɪ
sa 	sʌ
se 	sə
si 	sɪ
so 	sɒ
ta 	tæ,tʌ
te 	tə
ti 	tɪ
to 	tɒ
ue 	uə
ve 	və
xn 	ʃn
xl 	ʃl

####### 符号
/ 	/
, 	ʼ,ʻ,ː,ʽ
. 	.
ENDCHARACTER

编写完成后保存，双击改文件就会安装到内建的输入法中，该文件会保存在 ~/Library/Input Methods 目录下。如果不需要可以直接删除。

安装或删除自定义的输入法后，可能需要重新登录系统，或重启系统。

效果如下：

到底如何设置线程池的核心线程数、最大线程数

Wed, 27 Apr 2022 00:00:00 +0000

到底如何设置线程池的核心线程数、最大线程数

线程池在业务中的实践

场景一：快速响应用户请求

这种场景可以将用户请求封装成任务并发执行，缩短总体响应时间，该场景需要获取最大的响应速度满足客户，应该不应该设置缓冲队列，缓冲并发任务。可以适当调高 corePoolSize 和 maxPoolSize 去尽可能创造多的线程快速执行任务。

场景2：快速处理批量任务

这种场景一般是需要大量执行离线任务，是吞吐量优先，但是不是要求瞬时完成，也就是要求尽可能在单位时间内处理更多的任务，可以使用缓冲队列，缓冲任务，corePoolSize 不适合特别大，太大频繁上下文切换，反而影响吞吐量。

业界的线程数配置方案一般都是比较理想化

并发任务的执行情况和任务类型相关，IO密集型和CPU密集型的任务运行起来的情况差异非常大，较难合理预估，这导致很难有一个简单有效的通用公式帮我们直接计算出结果。

CPU 密集型任务

比如像加解密，压缩、计算等一系列需要大量耗费 CPU 资源的任务，大部分场景下都是纯 CPU 计算。

核心线程数，可以设置为CPU核数 + 1 , +1是为了实现最优的利用率。即使当密集型的线程由于偶尔的内存页失效或其他原因导致阻塞时，这个额外的线程也能确保 CPU 的时钟周期不会被浪费，从而保证 CPU 的利用率。

IO 密集型任务

比如像 MySQL 数据库、文件的读写、网络通信等任务，这类任务不会特别消耗 CPU 资源，但是 IO 操作比较耗时，会占用比较多时间。

核心数设置的一般比较多一些，因为 IO 读写速度相比于 CPU 的速度而言是比较慢的，核心线程数=CPU 核心数 * (1 + IO 耗时/ CPU 耗时)

尽管通过严谨的评估，依然很难一次计算出合适的参数，因此，可以换一个思路，把修改参数的成本降低，这样可以在告警发生时，快速调整，尽快恢复。

动态调整线程池参数

简化参数配置，关注核心参数，corePoolSize maxPoolSize workQueue，

延时优先的场景，同步队列。
吞吐量优先的场景，使用有界队列。

修改 corePoolSize ThreadPoolExecutor#setCorePoolSize：在运行期间可以通过该方法修改 corePoolSize，会直接覆盖之前的 corePoolSize 值。

当前值小于之前值，表示有多余的 work 线程，此时会向当前 idle 的 worker 线程发起中断请求以实现回收，其余多余的 worker 在下次 idel 的时候也会被回收。
当前值大于之前值，并且队列里有任务的时候，会创建新的线程执行任务。

修改 maxPoolSize ThreadPoolExecutor#setMaximumPoolSize

当前值小于之前值，超过的，并且已经在运行的线程会在 idle 的时候停止。

修改 workQueueSize

LinkedBlockingQueue 没有开放修改 capacity 的方法，可以参考 LinkedBlockingQueue 自定义支持修改 capacity 的 Queue。

public class DynamicThreadPool {

    ThreadPoolExecutor threadPoolExecutor;

    public static void main(String[] args) throws InterruptedException {
        DynamicThreadPool threadPool = new DynamicThreadPool();
        threadPool.buildThreadPool();
        threadPool.print(threadPool.threadPoolExecutor, "init");
        for (int i = 0; i < 15; i++) {
            int finalI = i;
            threadPool.threadPoolExecutor.submit(() -> {
                threadPool.print(threadPool.threadPoolExecutor, "创建任务: " + finalI);
                try {
                    TimeUnit.SECONDS.sleep(10);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            });
        }
        threadPool.modifyMaxSize(10);
        threadPool.modifyCoreSize(10);
        TimeUnit.SECONDS.sleep(2);
        threadPool.modifyWorkQueueSize(100);
    }

    public ThreadPoolExecutor buildThreadPool() {
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
                2,
                5,
                30,
                TimeUnit.MILLISECONDS,
                new ResizeLinkedBlockingQueue<>(10));
        this.threadPoolExecutor = executor;
        return executor;
    }

    public void modifyCoreSize(int num) {
        threadPoolExecutor.setCorePoolSize(num);
    }

    public void modifyMaxSize(int num) {
        threadPoolExecutor.setMaximumPoolSize(num);
    }

    public void modifyWorkQueueSize(int size) {
        ResizeLinkedBlockingQueue<Runnable> queue = (ResizeLinkedBlockingQueue<Runnable>) threadPoolExecutor.getQueue();
        queue.setCapacity(size);
    }

    public void print(ThreadPoolExecutor executor, String name) {
        ResizeLinkedBlockingQueue queue = (ResizeLinkedBlockingQueue) executor.getQueue();
        String message = String.format("%s 核心线程数: %s,最大线程数: %s,活动线程数: %s,完成任务数: %s,队列大小: %s,队列剩余: %s",
                name,
                executor.getCorePoolSize(),
                executor.getMaximumPoolSize(),
                executor.getActiveCount(),
                executor.getCompletedTaskCount(),
                queue.size(),
                queue.remainingCapacity());
        System.out.println(message);

    }
}

问题一：线程池被创建后里面有线程吗？如果没有的话，你知道有什么方法对线程池进行预热吗？

默认情况线程池被创建后如果没有任务过来，里面是不会有线程的。如果需要预热的话可以调用下面的两个方法：

prestartCoreThread 启动一个核心线程
prestartAllCoreThreads 启动所有的核心线程

问题二：核心线程数会被回收吗？需要什么设置？

核心线程数默认是不会被回收的，如果需要回收核心线程数，需要调用下面的方法：

allowCoreThreadTimeOut(boolean value)

reference：

美团

公众号

VIDEO-03｜boku-ga

Fri, 15 Apr 2022 00:00:00 +0000

VIDEO-03｜boku-ga

为什么要有 StringTable

Thu, 24 Mar 2022 00:00:00 +0000

为什么要有 StringTable

In computer science, string interning is a method of storing only one copy of each distinct string value, which must be immutable. Interning strings makes some string processing tasks more time- or space-efficient at the cost of requiring more time when the string is created or interned. The distinct values are stored in a string intern pool.

为什么字符串要被设计为 Immutable？

1、便于实现 StringTable。

2、在多线程环境下，并发读取同一个字符串是安全的，不会产生竞争。

3、加快字符串处理速度，字符串不可变，hashcode 唯一，可以在对象中缓存 hashcode。

计算机相关常见概念

Wed, 23 Mar 2022 00:00:00 +0000

计算机相关常见概念

TP:分位值(top percentile)

The TP9999 is a minimum time under which 99.99% of requests have been served.

可以认为 TP9999 的意思是保证 99.99% 请求都能被响应需要的最小耗时。

计算方法

calculating TP is very simple: 1.sort all respond times in ascending order，eg: [2s, 10s, 100s, 1000s] 2.find latest item in portion you need to calculate. 2.1 for TP50 it will be ceil 4*0.5=2 requests. You need 2nd request. 2.2 for TP90 it will be ceil 4*0.9=4 You need 4th request. 3.we get time for the item found above. TP50=10s. TP90=1000s

+++++++++

SLA:服务等级协议(service level agreement)

服务提供商与用户间定义的一种双方认可的协定，用来保障服务的性能和可用性。

计算方法

1年 = 365天 = 8760小时,可以计算全年可停机的时间。

SLA99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时

SLA99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟

SLA99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

Amdahl‘s law 阿姆达尔定律

是并行计算领略一个非常著名的定律,描述对于一个固定计算任务，在并行处理下的加速比。

S=1/((1-f)+f/p)

假设一个大的任务串行处理耗时 1 个单位时间，其中有 f 部分可以进行并行化处理，现在的耗时为，(1-f)+f/p

reference: Youtube-Amdahl's Law

英语发音技巧

Wed, 26 Jan 2022 00:00:00 +0000

英语发音技巧

英语的连读现象

英语和中文的一个很大区别是英语在句中有大量的连读现象，连读是造成听力不好和口语不地道的原因之一，连读有连音、加音、同化、异化等多种现象。

一、连音 - Catenation / Liaison

单词(辅音结尾) + 单词(元音开头) ，连音并不是无中生有凭空捏造一个音插入句子中。

上一个单词以辅音结尾下一个单词以元音开头时，上一个词词尾的音和下一个词开头的音会连在一起，连音造成的困扰是，很难区分单词的界限，尤其是我们中国人喜欢把句子断句为一个个以 辅音开头 + 元音结尾 的词，因为大多数的中文都是如此。

因此发音时需要注意一下几点：

在说英文的时候不要按中文习惯划分单词的界限
以辅音结尾的单词，其结尾的辅音要发到位，并且不要加上不存在的元音

例子：

not at all --- not 词尾连上 at 开头，at 词尾连上 all 开头
take it easy -- take 和 it 后不加不存在的元音
in an instant -- in 和 an 结尾的鼻音发到位
all of it -- all 和 of 连音
couple of weeks off -- couple 和 of 连音
all over -- all over 连音

二、加音 - Intrusion

在英语中，元音 + 元音，因为界限不明确，很容易糊在一起，很难发音，因此需要人工干预。

把 a -> an，例如 a apple 都是元音开头，把 a -> an 后，an 和 apple 可以连音

单词(元音结尾) + 单词(元音开头)，会加上一个之前不存在的音，使得发音连贯，这个不存在的音，是一个很微弱的过度音。

加音的情况有：

前一个单词以元音 /uː/、/ʊ/、/əʊ/、/aʊ/ 结尾的单词 + 单词(元音开头)时，会加一个 /w/ 过渡。
- just do it -- do 和 it 会加一个 /w/
- who is
- too often
前一个单词以元音 /iː/、/ɪ/、/eɪ/、/aɪ/、/ɔɪ/ 结尾的单词 + 单词(元音开头)时，会加一个 /j/ 过渡。
- I am
- she asked
前一个单词以元音 /ə/、/ɑː/、/ɔː/ 结尾的单词 + 单词(元音开头)时，会加一个 /r/ 过渡 - （英式）。
- the idea of -- idea 和 of 会加一个 /r/
- law and order -- law 和 and
- china and india -- china 和 and
前一个单词以 r 结尾 + 单词(元音开头)时，会加一个 /r/ 过渡 - （英式）。
- bear it
- gear up
- far away

三、同化 - Assimilation

一前一后的两个音碰到一起时，互相影响改变了原来的音。

逆行同化 - regressive assimilation

前一个音受后一个音影响，前一个音改变，后一个音不变。

1、无声除阻 - unreleased stop (塞音(爆破音) - /k/、/t/、/d/ + 辅音),在发塞音的时候气流释放不完全，也被称为不完全爆破，失去爆破、失爆

如 look back、that job、good night 遇到辅音后，前面的 k t d 变弱了很多，而不是完全发出来。

2、浊音变清音 - devoicing

声带震动的浊音变成声带不振振动的清音

have to -> have 中的 /v/ 变为 /f/，因为前一个浊音 + 后一个清音，声带要突然停止，不好发音，因此前一个浊音也改为清音

of course -> of 中的 /v/ 变为 /f/

3、鼻化 - nasalization

前面一个音是鼻音时，也有可能受到后一个音的影响

in person -> /n/ 本来发音的时候不需要闭住上下嘴唇，但是受到后面的 /p/ 这个需要闭住嘴唇的音的影响，所以 /n/ -> /m/

impolite 、impatient，这里表示反义的词把 n -> m

顺行同化 - progressive assimilation

后一个音受前面的音影响。

主要是单词复数结尾的 s，例如：

books /bʊks/ 复数结尾读 /s/，/k/ 是声带不振动的清音，后面就发清音 /s/ 更容易，更轻松

dogs /dɒɡz/ 复数结尾读 /z/，/g/ 是声带振动的浊音，后面就发浊音 /z/

前后相互影响

1、融合 - coalescence

后一个音是半元音 /j/ 的时候

/s/ + /j/ = /ʃ/

God bless you

/z/ + /j/ = /ʒ/

as you wish

/t/ + /j/ = /tʃ/

Nice to meet you

/d/ + /j/ = /dʒ/

Did you do it？

2、辅音延长 - gemination

前一个音和后一音是同一个音，两个音会自然合并起来，只需要发一次

life force

fish shop

black coffee

四、异化 -Dissimilation

主要发生在字母 s 和 r 上。

1、/s/ 后面的 /t/、/k/、/p/ 会变成不送气的版本，声带是不振动的，严格说不同于 /d/、/g/、/b/，它们是声带振动的。

2、字母 r，在美式英语中会让之前的元音 r化(r-coloring)

五、省音(吞音) - Elision

主要指有些本来该发的音没有发。

1、英语单词中的省音

different 中 f 后面的 e 没有发音

interesting 中 t 后面的 e 没有发音

family 中的 i 的音可以选择读，也可以选择不读

有些词中的音是一定要省略的，这是历史省音，下列加粗字母不发音

debt、subtle、know、knee、write、wrong、wrapper、christmas、sandwich、handbag、histo ry、factory、mathematics

2、单词和单词之间的省音

/t/、/d/ 这两个音经常在句中被省音，

last year 可以把 t 省略，t 可以无声除阻

you and me

还有 h /h/ 和 g /ŋ/ 也经常被省音

H-dropping

get him、tell her

G-dropping 经常出现在 ing 结尾中

Are you listening 省略了结尾的 /ŋ/

更多例子：

next door、most common、must be、give me that、what‘s his name？

六、弱读 - Reduction / Weak forms

指的是一些词在词组、语句中元音发生了变化，变为另外的元音。

默认发音

to /tuː/ --> go to school /tə/

at /æt/ --> look at me /ət/

but /bʌt/ --> sad but true /bət/

can /kæn/ --> I can do it /kən/

这些词弱读是为了发音方便，说话更自然。

一般常用的、少音节的虚词如：介词、代词、连词都会有弱读，它们不影响意思的主要意思，弱读时中间的元音一般都会变成中央元音，如下列这里：

介词：at、for、from、of、to

连词：and、but

冠词：an、some

代词：you、us、them、her

助动词：am、are、have、has、do、does、would、can、could、should

还有一些弱读的元音 /iː/ -> /ɪ/, 如：he、she、me

七、缩读 - Contraction

主要是指两个词合并为一个词，也就是缩写导致的音节变少。

want to = wanna

go to = gonna

have got to = gotta

out of = outta

kind of = kinda

a lot of = a lotta

don't know = dunno

give me = gimme

would have = would've / would'a

you and I = you 'n' I

come on = c'mon

what are you = wachya / watcha

what do you = whaddya / wadya

what did you = whatdja / wadja

can not = can't

good bye = g'bye

爆破音 / 塞音 - Plosive / stop

发音器官先阻挡气流再释放气流而发出的音，英语中的爆破音有：/p/、/b/、/t/、/d/、/k/、/g/，喉塞音也可以归为塞音

发塞音有三个阶段：

1、第一阶段：成阻 - 发音部位紧闭

2、第二阶段：持阻 - 让气流聚集，形成压力

3、第三阶段：除阻 - 除去气流的阻碍

当一个塞音后面紧跟另一个塞音时，第一个塞音的除阻阶段后，马上紧跟第二个塞音的成阻阶段，在快速的语流中有点不方便，因此，第一个音的除阻阶段不真正的释放气流，而只做一个动作，这种现象就是无声除阻、不完全爆破、失去爆破、失爆。

塞音后面跟辅音时需要无声除阻

单词内：doctor、friendly、department、bedtime、midnight、lately

短语：hot dog、not good、bad day、big girl、good job、fried chicken、bad name

java -jar some.jar

Sat, 25 Dec 2021 00:00:00 +0000

java -jar some.jar

执行 java -jar some.jar 后发生了什么？

一般而已，一个 jar 包，其实的本质就一个 zip 包，是一堆 class 文件的集合，class 文件按照它们的包名分布在各个文件夹中的。

JVM 被设计成只有一个使命：按照类的全限定名字，加载、执行类。

全限定名 - Fully Qualified Name 就是包含了包名的类的名字，例如：com.company.Application

这样 JVM 就可以根据全限定名顺藤摸瓜找到类的 class 文件，然后加载执行。

JVM 是如何找到 class 文件的呢？

是通过 -classpath 的参数指定了 class 文件所在的目录

通过 -classpath 设置的不是一个目录，而是一串目录，jar 包也可以看成是一个目录，目录和目录之间使用冒号 : 分隔

JVM 和 JVM 的包管理机制非常简单：

JVM 一辈子只干一件事，读字节码，执行字节码；
每当JVM看到一个全限定名称，就尝试从 classpath 中加载。

我们需要做的，就是把 JVM 所需要的字节码完整、正确的给到 classpath。

完整 - 意思是任何时候 JVM 都不会抱怨找不到某个类（NoClassDefFoundError）

正确 - 意思是给到 classpath 的字节码的版本是正确的（NoSuchMethodError）

当执行完 java -jar some.jar 后，会发生什么呢？

Java.c中的LoadMainClass方法负责加载 jar 包中 main 方法所在的类，该方法首先加载 sun.launcher.LauncherHelper 类。
调用 LauncherHelper 类中的checkAndLoadMain方法

jdk 自带的 AppClassLoader 只能加载只包含 class 文件的 jar，那 jar in jar 如果加载呢，就需要自定义 classloader 了

执行Java -jar somefile.jar时发生了什么一

执行Java -jar somefile.jar时发生了什么二