设计模式 on 小盒子的技术分享

一文讲透 GoF 的 23 种设计模式之工厂方法

Fri, 27 Feb 2026 23:00:00 +0000

一文讲透 GoF 的 23 种设计模式之工厂方法

工厂方法（Factory Method）是创建型模式

定义

用一句话概括工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。它让类的实例化推迟到了子类。

简单工厂

了解工厂方法模式前，我们先了解下简单工厂，既然叫简单工厂，那自然很 “简单”。

它的核心思想非常直接：专门定义一个类（包揽大权），通过接收不同的参数，用 switch 或 if-else 来决定创建并返回哪一种具体的产品实例。

假设我们在开发一个 AI 应用，需要根据不同场景创建不同类型的 AI Agent（比如负责对话的 Agent，和负责处理数据的 Agent）。

第一步：定义产品的共同接口和具体实现

 1⚡ java片段// 1. 抽象产品
 2public interface AIAgent {
 3 voidexecuteTask();
 4}
 5
 6// 2. 具体产品 A：聊天助理
 7publicclass ChatAgent implements AIAgent {
 8 @Override
 9 publicvoidexecuteTask() {
10 System.out.println("ChatAgent: 正在与用户进行自然语言对话...");
11 }
12}
13
14// 2. 具体产品 B：数据分析助理
15publicclass DataAnalysisAgent implements AIAgent {
16 @Override
17 publicvoidexecuteTask() {
18 System.out.println("DataAnalysisAgent: 正在提取并分析核心数据...");
19 }
20}

第二步：创建“简单工厂”类

 1⚡ java片段// 3. 简单工厂类 (通常使用静态方法)
 2publicclass AIAgentFactory {
 3 
 4 // 根据传入的类型参数，决定实例化哪个具体的 Agent
 5 publicstatic AIAgent createAgent(String agentType) {
 6 if ("chat".equalsIgnoreCase(agentType)) {
 7 return new ChatAgent();
 8 } elseif ("data".equalsIgnoreCase(agentType)) {
 9 return new DataAnalysisAgent();
10 } else {
11 throw new IllegalArgumentException("未知的 Agent 类型: " + agentType);
12 }
13 }
14}

第三步：客户端调用

 1⚡ java片段public class Client {
 2 public static void main(String[] args) {
 3 // 客户端不需要知道 ChatAgent 和 DataAnalysisAgent 是怎么被 new 出来的
 4 // 只需要告诉工厂：“给我一个 chat 类型的 Agent”
 5 AIAgent agent1 = AIAgentFactory.createAgent("chat");
 6 agent1.executeTask();
 7
 8 AIAgent agent2 = AIAgentFactory.createAgent("data");
 9 agent2.executeTask();
10 }
11}

结合代码，我们可以很直观地看到它的特点：

●优点（省事、解耦）：客户端彻底和具体的实现类解耦了。你不需要在业务代码里到处写 new ChatAgent()，把“创建对象”的脏活累活全交给了工厂。

●缺点（牵一发而动全身）：它严重违反了“开闭原则”（对扩展开放，对修改关闭）。假设我们现在要引入一个新的 CodingAgent（写代码助手），除了要新建产品类，你必须去修改 AIAgentFactory 里面的 if-else 代码。一旦产品种类极其庞大，这个工厂类就会变得非常臃肿且难以维护。

正是为了解决简单工厂“违反开闭原则”的这个致命缺点，才演进出了工厂方法模式（把这一个大工厂，拆成了一个个不用改代码、只需新增的具体小工厂）。

工厂方法模式的结构与角色

工厂方法模式主要包含四个角色：

●抽象产品 (Product)：定义产品的统一接口。

●具体产品 (Concrete Product)：实现抽象产品接口的具体类。

●抽象工厂 (Creator)：声明返回产品对象的工厂方法。

●具体工厂 (Concrete Creator)：重写工厂方法，返回具体的实例化产品

Java 代码实现

1. 定义产品（大模型客户端）

 1⚡ java片段// 抽象产品：统一的大模型调用接口
 2public interface LLMClient {
 3 String generate(String prompt);
 4}
 5
 6// 具体产品 A：Claude 客户端
 7publicclass ClaudeClient implements LLMClient {
 8 private String modelVersion;
 9 
10 publicClaudeClient(String modelVersion) { this.modelVersion = modelVersion; }
11
12 @Override
13 public String generate(String prompt) {
14 return"[Claude " + modelVersion + "] 思考并返回结果...";
15 }
16}
17
18// 具体产品 B：OpenAI 客户端
19publicclass OpenAIClient implements LLMClient {
20 private String endpoint;
21 
22 publicOpenAIClient(String endpoint) { this.endpoint = endpoint; }
23
24 @Override
25 public String generate(String prompt) {
26 return"[OpenAI API] 处理输入并返回结果...";
27 }
28}

2. 定义创建者（核心：业务骨架 + 工厂方法）

这里是关键：AgentWorkflow 不是一个纯粹的“工厂类”，它是业务类，工厂方法只是它的一部分。

 1⚡ java片段// 抽象创建者：Agent 工作流骨架
 2public abstract class AgentWorkflow {
 3
 4 // 核心业务逻辑：定义了标准的处理流程（这其实也是个模板方法）
 5 publicvoidprocessTask(String taskContext) {
 6 System.out.println("=== 1. 解析任务上下文，提取关键信息 ===");
 7 
 8 // 【灵魂所在】：这里调用工厂方法，拿到一个产品对象。
 9 // 父类在此刻完全不知道自己拿到的是 Claude 还是 OpenAI。
10 LLMClient client = createLLMClient();
11 
12 System.out.println("=== 2. 请求大模型进行推理 ===");
13 String result = client.generate(taskContext);
14 
15 System.out.println("=== 3. 结果后处理并落库 ===\n" + result + "\n");
16 }
17
18 // 【工厂方法】：将实例化具体产品的职责，推迟到子类去实现
19 protected abstract LLMClient createLLMClient();
20}

3. 定义具体创建者（子类重写工厂方法）

 1⚡ java片段// 具体创建者 A：基于 Claude 的工作流
 2publicclass ClaudeAgentWorkflow extends AgentWorkflow {
 3 @Override
 4 protected LLMClient createLLMClient() {
 5 // 这里封装 Claude 特有的复杂初始化逻辑（比如加载凭证、设置代理等）
 6 System.out.println(" -> [工厂方法] 正在初始化 Claude 客户端环境...");
 7 return new ClaudeClient("3.5-Sonnet");
 8 }
 9}
10
11// 具体创建者 B：基于 OpenAI 的工作流
12publicclass OpenAIAgentWorkflow extends AgentWorkflow {
13 @Override
14 protected LLMClient createLLMClient() {
15 System.out.println(" -> [工厂方法] 正在构建 OpenAI 客户端环境...");
16 return new OpenAIClient("https://api.openai.com/v1");
17 }
18}

4. 客户端调用

 1⚡ java片段public class Client {
 2 publicstaticvoidmain(String[] args) {
 3 String task = "编写一段 Python Web 框架对比报告";
 4
 5 // 场景 1：启动基于 Claude 的 Agent 工作流
 6 AgentWorkflow claudeWorkflow = new ClaudeAgentWorkflow();
 7 claudeWorkflow.processTask(task);
 8
 9 // 场景 2：切换为基于 OpenAI 的 Agent 工作流
10 AgentWorkflow openaiWorkflow = new OpenAIAgentWorkflow();
11 openaiWorkflow.processTask(task);
12 }
13}

如果你回看之前的例子，你会发现这个 Demo 解决了一个架构设计上的核心痛点：控制反转 (IoC) 的雏形。

在 AgentWorkflow 这个父类中，业务主流程已经被彻底固化并复用（processTask 方法）。如果在未来，业务需求要求你接入一个全新的本地开源模型（比如 DeepSeek），你不需要修改任何现有的主流程代码，只需要：

●新建一个 DeepSeekClient（实现 LLMClient）。

●新建一个 DeepSeekAgentWorkflow，重写 createLLMClient() 方法返回这个新 Client。

这才是工厂方法模式真正强大的地方：它是为了让高层模块（业务骨架）能够独立于底层模块（具体产品）的创建而存在，从而支撑起大型框架的扩展性。 JDK 里的 Iterable 接口和它的 iterator() 方法，本质上就是这种工厂方法模式的经典体现。

什么时候用?

●你写的“父类流程”需要创建某种对象，但父类不该/不想知道具体类是谁（框架留扩展点的典型方式）。

●你希望通过继承覆写来扩展“产物类型”，让调用方不动、流程不动。

一些具体的场景：

●框架扩展点：工厂方法很常见于“框架规定流程、业务方覆写创建”的场景（你写子类接入框架）。

●Spring 的 FactoryBean：它的语义就是“这个 bean 不是普通 bean，而是用来生产另一个对象的”，并且暴露的是 getObject() 创建出来的对象。

●Java ServiceLoader：通过 SPI 在运行时发现/加载实现类，属于“把具体实现延迟到运行时配置/部署”的一类机制，和“解耦创建与使用”的目标一致。

注意模式的命名

我们回头看一下这个模式为什么叫 Factory Method，而不是干脆叫 Factory ? 这个命名是有讲究的。

核心原因在于：这个模式的灵魂是一个“方法”，而不是一个“类”。

1.“工厂 (Factory)”是一个通俗的广义概念：

在日常沟通中，只要一个类的主要职责是造对象，我们都叫它工厂（比如前面提过的“简单工厂”，它就是一个充斥着 if-else 的具体类）。

2.“工厂方法 (Factory Method)”强调的是面向对象中的“多态”与“继承”：

在 GoF 的定义中，创建对象的逻辑并不是封装在一个独立的、包揽大权的“工厂类”里，而是定义在了一个普通业务类（Creator）的内部，作为一个抽象方法存在。

●这个模式的精髓是：父类定义业务骨架，把其中“需要实例化具体对象”的那一步，挖空成一个方法（也就是 Factory Method）。

●具体的实例化工作，推迟（Defer）到了子类去重写这个方法来实现

一文讲透 GoF 的 23 种设计模式之单例

Wed, 25 Feb 2026 10:13:49 +0000

一文讲透 GoF 的 23 种设计模式之单例

单例模式–Singleton 是创建型模式

定义

确保一个类在一个 JVM 内只有一个实例，并提供全局访问点

什么时候用?

●配置中心、缓存管理器、日志器（有时）

●需要全局共享状态/资源

对于那些初始化很贵，重复创建又特别浪费资源的场景非常合适。

不要滥用

单例本质是“全局变量 + 访问入口”，会增加耦合、影响测试

实现方式

以下为常见的 5 种实现方式对比。

实现方式	核心机制简述	并发安全性 (线程安全)	性能表现	核心易错点 / 致命缺陷	综合推荐度
1. 饿汉式(Eager)	类加载时立即创建静态 final 实例。	安全(JVM类加载机制保证)	高 (运行时)获取实例无锁。但可能会拖慢系统启动速度，且如果不用会浪费内存。	低实现简单，不易出错。缺点是无法进行懒加载，且难以传递动态参数进行初始化。	⭐⭐⭐
2. 懒汉式(同步方法)	在 getInstance 方法上加 synchronized 锁。	安全(粗粒度锁保证)	非常低每次调用 getInstance 都要发生线程竞争和锁获取，高并发下是严重的性能瓶颈。	低实现简单。主要的"错"是选择了这种低效的方案。	⭐
3. 双重检查锁(DCL)	两次判空 + 同步代码块 + volatile 关键字。	安全 (有前提)必须在实例变量上加 volatile 禁止指令重排序。	高只在第一次初始化时加锁，后续调用无锁。实现了高性能的懒加载。	极高 (致命)最常见的错误是忘记加 volatile 关键字。这会导致多线程环境下，某个线程可能会拿到一个"半初始化"的对象，引发难以排查的 Bug。	⭐⭐⭐
4. 静态内部类(Holder模式)	利用 JVM 加载外部类时不加载静态内部类的特性实现懒加载。	安全(JVM类加载机制保证)	高既实现了懒加载，又在获取实例时没有任何锁机制，性能优异。	低非常规整的写法。唯一需要注意的是要确保构造函数私有，防止外部意外实例化。	⭐⭐⭐⭐⭐ (手动实现首选)
5. 枚举(Enum)	利用 Java 枚举类型的特殊语法和底层实现。	安全 (天然)(JVM 层面保障，防御反射和序列化攻击)	高类似于饿汉式，类加载时完成初始化，运行时无锁。	极低代码最简洁，几乎不可能写错。缺点是无法继承其他类，且在语义上用来做复杂业务对象时显得突兀。	⭐⭐⭐⭐⭐ (最安全简洁)

重点说明两种实现方式：枚举和静态内部类。

枚举

这是 Java 最简洁实现。Java 的 Enum 在语言层面有一些特殊保证（例如不会被克隆），这也是它常被用来实现单例的原因之一。

 1⚡ java片段public enum AppConfig {
 2 INSTANCE;
 3
 4 private String env = "prod";
 5
 6 public String getEnv() {
 7 return env;
 8 }
 9
10 public void setEnv(String env) {
11 this.env = env;
12 }
13
14 public static void main(String[] args) {
15 AppConfig c1 = AppConfig.INSTANCE;
16 AppConfig c2 = AppConfig.INSTANCE;
17
18 c1.setEnv("test");
19
20 System.out.println(c1 == c2); // true
21 System.out.println(c2.getEnv()); // test
22 }
23}

使用枚举（enum）来实现单例模式，被《Effective Java》的作者 Joshua Bloch 称为 “实现单例模式的最佳方法”。

它之所以备受推崇，是因为它用极其简洁的代码，完美解决了传统单例模式面临的线程安全、序列化破坏和反射破坏三大难题

原理一：利用 JVM 类加载机制保证“线程安全”

在传统的懒汉式单例中，为了保证多线程下只创建一个实例，我们需要写复杂的“双重检查锁（Double-Checked Locking）”并加上 volatile 关键字。

而枚举怎么做的？

当你定义 INSTANCE 时，编译器底层实际会把它转化为类似这样的代码：

⚡ java片段public static final AppConfig INSTANCE = new AppConfig();

Java 虚拟机（JVM）在加载类的时候，会利用底层的类加载机制保证静态成员的初始化是绝对线程安全的。在这个类被加载到内存时，JVM 会自动实例化 INSTANCE 且只实例化一次，整个过程由 JVM 内部加锁保证同步，不需要你手动写任何并发控制代码。

原理二：天生防御“反射攻击”

传统的单例模式有一个致命弱点：恶意代码可以通过 Java 的反射机制（Reflection）把私有构造函数设置为可见（setAccessible(true)），从而强行 new 出新的实例，打破单例。

而枚举怎么做的？

Java 的反射 API 从源码级别就直接“封杀”了通过反射创建枚举实例的可能性。如果你去看 Constructor.newInstance() 的 Java 底层源码，会发现有一段明确的校验逻辑：

1⚡ java片段if ((clazz.getModifiers() & Modifier.ENUM) != 0)
2 throw new IllegalArgumentException("Cannot reflectively create enum objects");

也就是说，一旦 JVM 发现你要用反射去创建枚举类的对象，就会直接抛出异常，从根本上杜绝了反射攻击。

原理三：天生防御“序列化破坏”

传统的单例对象如果实现了 Serializable 接口，在进行网络传输或持久化到磁盘再反序列化读取回来时，默认会重新分配内存，生成一个全新的对象。传统做法是必须手动写一个 readResolve() 方法来返回原实例。

而枚举怎么做的？

Java 规范对枚举的序列化有特殊的规定。枚举在序列化的时候，仅仅是将枚举常量的名称（name）输出到了结果中；在反序列化的时候，Java 会调用 java.lang.Enum.valueOf() 方法，通过名字去查找并返回内存中已经存在的那个常量对象。

因此，无论你反序列化多少次，拿到的永远是内存里的同一个 INSTANCE 对象。

总结来说：枚举单例的核心原理就是 直接利用 Java 语言底层的机制：

●用 JVM 类加载机制搞定了线程安全。

●用反射 API 的硬编码拦截搞定了反射破坏。

●用特殊的名称匹配机制搞定了序列化破坏。

在理论上，枚举单例确实是“最完美”的单例实现；但在实际的工程代码中，它的出场率确实不高。这并不是因为枚举本身有 bug，而是因为它在现代工程架构、面向对象设计理念以及测试友好度上，存在一些不可避免的局限性

具体来说，有以下几个核心原因：

1.现代框架（如 Spring）接管了单例的管理这是最根本的原因。在现代 Java 工程中（尤其是企业级开发），我们几乎不再手动编写任何单例模式了。我们广泛使用 Spring/Spring Boot 这样的依赖注入（DI）框架。在 Spring 中，你只需要在一个普通的类上加上 @Service、@Component 或 @Configuration 注解，Spring 容器（IoC Container）就会默认将其作为一个单例来管理。框架不仅帮你保证了单例，还能帮你自动注入其他依赖（如数据库连接、其他服务），这比用枚举手写单例要强大、灵活得多。

2.违反了“语义”和开发者的直觉代码不仅是给机器运行的，更是给人读的。枚举的本来语义：代表一组固定的常量集合（如星期、颜色、订单状态）。单例的语义：通常是一个拥有复杂业务逻辑的管理类（如 UserManager、DatabaseConnectionPool）。

如果把一个复杂的业务服务写成 enum，会让接手代码的其他开发者感到困惑，这违反了“最小惊讶原则（Principle of Least Astonishment）”。感觉就像是“为了用单例模式而强行用枚举”。

3.面向对象特性的缺失（无法继承） Java 规定，所有的枚举类都隐式继承了 java.lang.Enum。因为 Java 不支持多重继承，这意味着你的枚举单例不能再继承任何其他的父类。如果你的架构需要 AppConfig 继承一个 BaseConfig 类来复用代码，枚举单例直接就做不到。虽然枚举可以实现接口（implements Interface），但在需要共享基类代码的场景下，它的表现非常无力。

4.传参初始化非常困难在工程实践中，单例对象在初始化时往往需要外部参数。比如，一个数据库连接池单例，在启动时需要读取配置文件里的 url 和 password。普通的单例模式或 Spring 管理的 Bean，可以在运行时读取配置后，再进行初始化。枚举常量的实例化是在类加载的最早期进行的，这个时候你很难把运行时的参数优雅地传递给枚举的构造函数。

5.极难进行单元测试（Mock）在做单元测试时，我们经常需要把某些依赖的单例对象“Mock（模拟）”掉（比如使用 Mockito），以隔离测试环境。普通类别的单例很容易被 Mock 框架替换。但是，枚举是静态的全局常量，它的生命周期和类加载器绑定。在测试中强行替换枚举实例极其困难，容易导致测试用例之间互相污染。

在实际工程中：

●如果你要写一个完全无状态、不需要继承、不依赖外部配置的纯工具类/简单配置类，用枚举单例确实不错。

●但对于包含业务逻辑、需要依赖注入、需要被测试的类，交给 Spring 等框架去管理才是工业界的最佳实践。

静态内部类

如果你不想用枚举，又想要一个既能延迟加载（懒汉式），又绝对线程安全，还能完美避开繁琐的加锁（synchronized） 的单例，静态内部类是最佳选择。

 1⚡ java片段public class DatabaseConnectionPool {
 2
 3 // 1. 私有化构造函数，防止外部 new
 4 private DatabaseConnectionPool() {
 5 // 可选：在这里加上防御反射攻击的代码
 6 if (SingletonHolder.INSTANCE != null) {
 7 throw new RuntimeException("不允许通过反射创建单例！");
 8 }
 9 }
10
11 // 2. 核心：定义一个私有的静态内部类
12 // 这个类直到被调用时才会被 JVM 加载
13 private static class SingletonHolder {
14 // 由 JVM 保证这里的实例化是绝对线程安全的
15 private static final DatabaseConnectionPool INSTANCE = new DatabaseConnectionPool();
16 }
17
18 // 3. 提供全局访问点
19 public static DatabaseConnectionPool getInstance() {
20 // 只有在调用这里时，SingletonHolder 才会被加载，从而实例化 INSTANCE
21 return SingletonHolder.INSTANCE;
22 }
23}

为什么它很巧妙？

●懒加载（Lazy Loading）：当你加载 DatabaseConnectionPool 这个类时，内部类 SingletonHolder 并不会被立刻加载。只有当你真正调用 getInstance() 方法时，内部类才会被加载，对象才会被创建。这就节省了内存。

●零并发负担：它没有使用任何 synchronized 或者 volatile 关键字。它完全将线程安全的控制权交给了 JVM 底层的类加载机制（JVM 在加载一个类时，会自动加锁保证全局唯一）。

Spring 是如何实现单例的？

Spring 里的单例（Singleton）和我们在《设计模式》书里学到的单例，在概念和实现思路上有很大的不同。

●传统单例（GoF单例）：保证在一个 JVM（准确地说是类加载器）级别，某个类只有一个实例。类自己控制自己的实例化。

●Spring 单例：保证在一个 Spring IoC 容器（ApplicationContext）内部，某个指定的 Bean 名称只有一个实例。它是由 Spring 框架来统一管理的。

Spring 实现单例的核心原理可以概括为：单例注册表（Singleton Registry）

1. 核心数据结构：ConcurrentHashMap

如果你翻开 Spring 的底层源码（DefaultSingletonBeanRegistry 类），你会发现 Spring 管理单例的本质，就是一个大大的缓存 Map：

1⚡ java片段// Spring 源码中的 "一级缓存"，存放所有完全初始化好的单例 Bean
2private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

Spring 的单例其实就是把创建好的对象塞进了一个线程安全的 ConcurrentHashMap 里。Key 是 Bean 的名字（通常是类名首字母小写），Value 就是这个类的实例对象。

2. Spring 创建单例的流程

当你在代码里注入一个单例（比如通过 @Autowired），或者调用 context.getBean(“myService”) 时，Spring 大致会经历以下步骤：

1.查缓存：Spring 首先会去 singletonObjects 这个 Map 里查，看看有没有叫 “myService” 的对象。

2.有则返回：如果 Map 里有，说明已经创建过了，直接把这个对象返回给你。这就是单例的体现。

3.无则创建并加锁：如果 Map 里没有，Spring 就会准备创建它。为了保证在多线程环境下只有一个线程能去创建这个 Bean，Spring 会对这个 Bean 的名字进行加锁（通常是通过对全局单例集合的锁或者特定的互斥锁来实现同步）。

4.实例化与初始化：Spring 通过反射调用构造函数把对象 new 出来，然后进行属性填充（依赖注入），再调用 @PostConstruct 等初始化方法。

5.放入 Map 并返回：最后，把完全准备好的对象放进 singletonObjects 这个 ConcurrentHashMap 里，然后返回给你。以后所有对这个 Bean 的请求，都直接从 Map 里拿。

3. 补充：循环依赖的杀手锏“三级缓存”

Spring 在管理单例时，还要解决一个传统单例很难解决的问题——循环依赖（比如 A 依赖 B，B 又依赖 A）。

为了解决这个问题，Spring 其实并没有只用一个 Map，而是用了三个 Map（传说中的三级缓存）：

●一级缓存（singletonObjects）：存完整的、可用的单例对象。

●二级缓存（earlySingletonObjects）：存半成品对象（刚 new 出来，但还没注入属性的对象），用于提前暴露自己，打破循环。

●三级缓存（singletonFactories）：存对象工厂，用于在需要时生成代理对象（比如处理 AOP 切面）。

结合上面的图，核心过程如下：

第一阶段：A 的创建与曝光

1.调用 getBean(A)：Spring 容器开始创建 Bean A。

2.实例化 A：调用构造函数，A 对象在内存中诞生，但属性（如 B）还是 null。

3.暴露三级缓存：Spring 将 A 的工厂对象放入三级缓存 (singletonFactories)。这是解决循环依赖的关键一步，意味着此时如果有其他对象引用 A，可以通过这个工厂拿到 A 的引用。

第二阶段：A 填充属性，触发 B 的创建

4.填充属性 B：A 发现自己依赖 B，于是暂停自己，转而去创建 B。

第三阶段：B 的创建与获取 A

5.实例化 B：B 对象诞生，属性（如 A）还是 null。

6.暴露三级缓存：将 B 的工厂放入三级缓存。

7.填充属性 A：B 发现自己依赖 A，于是尝试去缓存找 A。

第四阶段：B 从缓存中找到 A (核心转折)

8.查找缓存：

●找一级缓存？没有（A 还没彻底完工）。

●找二级缓存？没有（还没人提取过 A 的早期引用）。

●找三级缓存？有了！

9.升级缓存：

●B 调用三级缓存中的工厂方法，拿到 A 的早期引用。

●重点：如果 A 配置了 AOP（比如事务管理），这个工厂会提前生成 A 的代理对象。

●将 A 的早期引用放入二级缓存 (earlySingletonObjects)，并从三级缓存移除。

10.B 完成：B 拿到了 A 的引用，完成属性填充和初始化，放入一级缓存。

第五阶段：A 完成

11.A 获取 B：B 已经创建好了，A 顺利拿到 B 的引用。

12.A 完成：A 完成属性填充和初始化，放入一级缓存。

RAG 的五大范式

Tue, 11 Mar 2025 10:27:02 +0000

Naive RAG (朴素 RAG)

定义

核心思想

将文档分块、向量化并存入向量数据库
用户查询也向量化，并在数据库中检索最相似的文档块
最后，将查询和检索到的文档块一起输入 LLM 生成答案

优缺点分析

Advanced RAG (高级 RAG)

定义

核心思想

化索引（如滑动窗口、细粒度分割、元数据利用）
优化查询（如查询重写、扩展、转换）
优化检索结果（如重排序、过滤、压缩）

优缺点分析

Modular RAG (模块化 RAG)

定义

核心思想

模块化设计，每个模块可独立实现和替换
支持迭代、自适应、递归等多种检索模式
通过组合不同模块来适应不同任务需求

优缺点分析

GraphRAG (图 RAG)

定义

核心思想

建基于图的文档索引
利用图数据库和查询语言进行检索
将检索到的图信息与文本信息结合，输入 LLM 生成答案

优缺点分析

Agentic RAG (智能体 RAG)

定义

核心思想

使用 AI 代理管理 RAG 流程
利用代理设计模式（反射、规划、工具使用、多代理协作）
代理可动态协调 RAG 组件，进行推理，并根据上下文采取行动

优缺点分析

总结

参考

https://arxiv.org/html/2407.21059v1

再聊聊Netty

Mon, 21 Mar 2022 07:13:56 +0000

为什么还要用 Netty

既然 JAVA NIO / JAVA AIO 已经实现了各主流操作系统的底层支持，那么为什么现在主流的 JAVA NIO 技术会是 Netty 和 MINA 呢？答案很简单：因为更好用，这里举几个方面的例子：

虽然 JAVA NIO 和 JAVA AIO 框架提供了多路复用 IO/异步 IO 的支持，但是并没有提供上层“信息格式”的良好封装。例如前两者并没有提供针对 Protocol Buffer、JSON 这些信息格式的封装，但是 Netty 框架提供了这些数据格式封装（基于责任链模式的编码和解码功能）
要编写一个可靠的、易维护的、高性能的（注意它们的排序） NIO/AIO 服务器应用。除了框架本身要兼容实现各类操作系统的实现外。更重要的是它应该还要处理

架构

整体架构

逻辑架构

线程模型

在高性能的 I/O 设计中，有两个著名的模型：Reactor 模型和 Proactor 模型，其中 Reactor 模型用于同步 I/O，而 Proactor 模型运用于异步 I/O 操作。实际上 Netty 线程模型就是 Reactor 模型的一个实现。

什么是 Reactor

“

The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.

”

Reactor 设计模式是一种事件处理模式，用于处理由一个或多个输入同时传递到服务处理程序的服务请求。然后，服务处理程序对传入的请求进行解复用，并将它们同步分派给关联的请求处理程序。

以上来自 wiki, 我们可以看到以下重点。

事件驱动（event handling）
可以处理一个或多个输入源（one or more inputs）
通过 Service Handler 同步的将输入事件（Event）采用多路复用分发给相应的 Request Handler（多个）处理

根据 Doug Lea 在《Scalable IO in Java 》中的介绍，Reacotr 模型主要分为三个角色：

Reactor：把 IO 事件分配给对应的 handler 处理
Acceptor：处理客户端连接事件
Handler：处理非阻塞的任务

Reactor 处理请求的流程：

同步的等待多个事件源到达（采用 select() 实现）
将事件多路分解以及分配相应的事件服务进行处理，这个分派采用 server 集中处理（dispatch）
分解的事件以及对应的事件服务应用从分派服务中分离出去（handler）

为什么使用 Reactor？

传统阻塞 IO 模型的不足

每个连接都需要独立线程处理，当并发数大时，创建线程数多，占用资源
采用阻塞 IO 模型，连接建立后，若当前线程没有数据可读，线程会阻塞在读操作上，造成资源浪费

针对传统阻塞 IO 模型的两个问题，可以采用如下的方案

基于池化思想，避免为每个连接创建线程，连接完成后将业务处理交给线程池处理
基于 IO 复用模型，多个连接共用同一个阻塞对象，不用等待所有的连接。遍历到有新数据可以处理时，操作系统会通知程序，线程跳出阻塞状态，进行业务逻辑处理

Reactor 线程模型分类

根据 Reactor 的数量和处理资源的线程数量的不同，分为三类：

单 Reactor 单线程模型
单 Reactor 多线程模型
多 Reactor 多线程模型

单 Reactor 单线程模型

消息处理流程：

Reactor 对象通过 select 监控连接事件，收到事件后通过 dispatch 进行转发。
如果是连接建立的事件，则由 acceptor 接受连接，并创建 handler 处理后续事件。
如果不是建立连接事件，则 Reactor 会分发调用 Handler 来响应。
handler 会完成 read->业务处理->send 的完整业务流程。

该线程模型的不足

仅用一个线程处理请求，对于多核资源机器来说是有点浪费的
当处理读写任务的线程负载过高后，处理速度下降，事件会堆积，严重的会超时，可能导致客户端重新发送请求，性能越来越差
单线程也会有可靠性的问题

Redis 是由 C 语言实现的，它采用的正是「单 Reactor 单进程」的方案，因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上，所以 Redis 对于命令的处理是单进程的方案。

对于单线程的 Redis 来说，基于内存，且命令操作时间复杂度低，因此读写速率是非常快的。

针对上面的种种不足，就有了下面的线程模型

单 Reactor 多线程模型

消息处理流程：

Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 dispatch 进行分发。
如果是建立连接请求事件，则由 acceptor 通过 accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后续的各种事件。
如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应。
Handler 只负责响应事件，不做具体业务处理，通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理。
Worker 线程池会分配独立的线程完成真正的业务处理，然后将响应结果发给 Handler 进行处理。
Handler 收到响应结果后通过 send 将响应结果返回给 Client。

相对于第一种模型来说，在处理业务逻辑，也就是获取到 IO 的读写事件之后，交由线程池来处理，handler 收到响应后通过 send 将响应结果返回给客户端。这样可以降低 Reactor 的性能开销，从而更专注的做事件分发工作了，提升整个应用的吞吐。

但是这个模型存在的问题：

多线程数据共享和访问比较复杂。如果子线程完成业务处理后，把结果传递给主线程 Reactor 进行发送，就会涉及共享数据的互斥和保护机制。
Reactor 承担所有事件的监听和响应，只在主线程中运行，可能会存在性能问题。例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。

为了解决性能问题，产生了第三种主从 Reactor 多线程模型。

主从 Reactor 多线程模型

比起第二种模型，它是将 Reactor 分成两部分：

mainReactor 负责监听 server socket，用来处理网络 IO 连接建立操作，将建立的 socketChannel 指定注册给 subReactor。
subReactor 主要做和建立起来的 socket 做数据交互和事件业务处理操作。通常，subReactor 个数上可与 CPU 个数等同。

Nginx、Memcached 和 Netty 都是采用这种实现。

消息处理流程：

从主线程池中随机选择一个 Reactor 线程作为 acceptor 线程，用于绑定监听端口，接收客户端连接
acceptor 线程接收客户端连接请求之后创建新的 SocketChannel，将其注册到主线程池的其它 Reactor 线程上，由其负责接入认证、IP 黑白名单过滤、握手等操作
步骤 2 完成之后，业务层的链路正式建立，将 SocketChannel 从主线程池的 Reactor 线程的多路复用器上摘除，重新注册到 Sub 线程池的线程上，并创建一个 Handler 用于处理各种连接事件
当有新的事件发生时，SubReactor 会调用连接对应的 Handler 进行响应
Handler 通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理
Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理
Handler 收到响应结果后通过 Send 将响应结果返回给 Client

Reactor 三种模式形象比喻

餐厅一般有接待员和服务员，接待员负责在门口接待顾客，服务员负责全程服务顾客

Reactor 的三种线程模型可以用接待员和服务员类比

单 Reactor 单线程模型：接待员和服务员是同一个人，一直为顾客服务。客流量较少适合
单 Reactor 多线程模型：一个接待员，多个服务员。客流量大，一个人忙不过来，由专门的接待员在门口接待顾客，然后安排好桌子后，由一个服务员一直服务，一般每个服务员负责一片中的几张桌子
多 Reactor 多线程模型：多个接待员，多个服务员。这种就是客流量太大了，一个接待员忙不过来了

什么是 Proactor

Proactor 正是采用了异步 I/O 技术，所以被称为异步网络模型。

无论是 Reactor，还是 Proactor，都是一种基于「事件分发」的网络编程模式，区别在于 Reactor 模式是基于「待完成」的 I/O 事件，而 Proactor 模式则是基于「已完成」的 I/O 事件。

在 Linux 下的异步 I/O 是不完善的， aio 系列函数是由 POSIX 定义的异步操作接口，不是真正的操作系统级别支持的，而是在用户空间模拟出来的异步，并且仅仅支持基于本地文件的 aio 异步操作，网络编程中的 socket 是不支持的，这也使得基于 Linux 的高性能网络程序都是使用 Reactor 方案。

而 Windows 里实现了一套完整的支持 socket 的异步编程接口，这套接口就是 IOCP，是由操作系统级别实现的异步 I/O，真正意义上异步 I/O，因此在 Windows 里实现高性能网络程序可以使用效率更高的 Proactor 方案。

线程模型的应用

Redis

Redis 是典型的单 Reactor 单线程类型。Redis 主要通过 aeMain、aeProcessEvents，以及 aeCreateFileEvent 三个关键函数来实现 Reactor 模型，对源码 (Linux 系统）的整理如下：

源码文件	函数	被调用点	主要功能
ae.c/ae.h	aeMain()	server.c 的 main()	事件捕获，分发和循环处理
ae.c/ae.h	aeProcessEvents()	ae.c 的 aeMain()	根据事件类型进行响应的处理
ae.c/ae.h	aeApiPoll()	ae.c 的 aeProcessEvents()	调用操作系统的 IO 多路方法
Linux 内核文件	epoll_wait()	ae.c 的 aeApiPoll()	检测并返回内核中网络 IO 事件

nginx

nginx 是多进程模型，master 进程不处理网络 IO，每个 Wroker 进程是一个独立的单 Reacotr 单线程模型。详情参考官方文档：Inside NGINX: Designed for Performance & Scalability

Netty

Netty 的线程模型主要是基于 Reactor 模型，但是可以灵活配置，单 reactor 单线程，单 reactor 多线程，和多 reactor 多线程模型。

kafka

kafka 采用的是主从 Reactor 多线程模型，因为 Kafka 主要与磁盘 IO 交互，因此真正的读写数据不是从 Reactor 处理的，而是有一个 worker 线程池，专门处理磁盘 IO，从 Reactor 负责网络 IO，然后把任务交给 worker 线程池处理。

Netty 线程模型

上文说 Netty 就是采用 Reactor 模型实现的。下面是 Netty 使用中很常见的一段代码

 1public class Server {
 2 public static void main(String[] args) throws Exception {
 3 EventLoopGroup bossGroup = new NioEventLoopGroup(1);
 4 EventLoopGroup workerGroup = new NioEventLoopGroup();
 5 try {
 6 ServerBootstrap b = new ServerBootstrap();
 7 b.group(bossGroup, workerGroup)
 8 .channel(NioServerSocketChannel.class)
 9 .childOption(ChannelOption.TCP_NODELAY, true)
10 .childAttr(AttributeKey.newInstance("childAttr"), "childAttrValue")
11 .handler(new ServerHandler())
12 .childHandler(new ChannelInitializer<SocketChannel>() {
13 @Override
14 public void initChannel(SocketChannel ch) {
15 }
16 });
17 ChannelFuture f = b.bind(8888).sync();
18 f.channel().closeFuture().sync();
19 } finally {
20 bossGroup.shutdownGracefully();
21 workerGroup.shutdownGracefully();
22 }
23 }
24}

boss 线程池作用：

接收客户端的连接，初始化 Channel 参数。
将链路状态变更时间通知给 ChannelPipeline。

worker 线程池作用：

异步读取通信对端的数据报，发送读事件到 ChannelPipeline。
异步发送消息到通信对端，调用 ChannelPipeline 的消息发送接口。
执行系统调用 Task。
执行定时任务 Task。

通过配置 boss 和 worker 线程池的线程个数以及是否共享线程池等方式，Netty 的线程模型可以在以上三种 Reactor 模型之间进行切换。

netty 通过 Reactor 模型基于多路复用器接收并处理用户请求，内部实现了两个线程池，boss 线程池和 work 线程池：

其中 boss 线程池的线程负责处理请求的 accept 事件，当接收到 accept 事件的请求时，把对应的 socket 封装到一个 NioSocketChannel 中，并交给 worker 线程池
其中 worker 线程池负责请求的 read 和 write 事件

零拷贝

Netty 的接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外内存直接读写。

Netty 中的零拷贝和传统 Linux 的零拷贝不太一样。Netty 中的零拷贝技术除了操作系统级别的功能封装，更多的是面向用户态的数据操作优化，主要体现在以下 5 个方面：

堆外内存，避免 JVM 堆内存到堆外内存的数据拷贝。
CompositeByteBuf 类，可以组合多个 Buffer 对象合并成一个逻辑上的对象，避免通过传统内存拷贝的方式将几个 Buffer 合并成一个大的 Buffer。
通过 Unpooled.wrappedBuffer 可以将 byte 数组包装成 ByteBuf 对象，包装过程中不会产生内存拷贝。
ByteBuf.slice 操作与 Unpooled.wrappedBuffer 相反，slice 操作可以将一个 ByteBuf 对象切分成多个 ByteBuf 对象，切分过程中不会产生内存拷贝，底层共享一个 byte 数组的存储空间。
Netty 使用 FileRegion 实现文件传输，FileRegion 底层封装了 FileChannel#transferTo() 方法，可以将文件缓冲区的数据直接传输到目标 Channel，避免内核缓冲区和用户态缓冲区之间的数据拷贝，这属于操作系统级别的零拷贝。

堆外内存

如果在 JVM 内部执行 I/O 操作时，必须将数据拷贝到堆外内存，才能执行系统调用。这是所有 VM 语言都会存在的问题。那么为什么操作系统不能直接使用 JVM 堆内存进行 I/O 的读写呢？主要有两点原因：第一，操作系统并不感知 JVM 的堆内存，而且 JVM 的内存布局与操作系统所分配的是不一样的，操作系统并不会按照 JVM 的行为来读写数据。第二，同一个对象的内存地址随着 JVM GC 的执行可能会随时发生变化，例如 JVM GC 的过程中会通过压缩来减少内存碎片，这就涉及对象移动的问题了。

Netty 在进行 I/O 操作时都是使用的堆外内存，可以避免数据从 JVM 堆内存到堆外内存的拷贝。

NIO epoll bug

JDK 的 NIO 类库有一个 epoll 死循环 bug，它会导致 Selector 空轮询，IO 线程 CPU 达到 100%，严重影响系统运行。

netty 从 api 使用层面对该 bug 进行了规避解决，重建 Selector。当发生 epoll bug，则创建一个新的 Selector，将出现 bug 的 Selector 上的 channel 重新注册到新的 Selector 上，关闭 bug 的 Selector，使用新的 Selector 进行替换。

具体策略：

对 Selector 的 select 操作周期进行统计。
每完成一次空的 select 操作进行一次计数。
在某个周期内如果连续 N 次空轮询，则说明触发了 JDK NIO 的 epoll 死循环 bug。
创建新的 Selector，将出现 bug 的 Selector 上的 channel 重新注册到新的 Selector 上。
关闭 bug 的 Selector，使用新的 Selector 进行替换。

如果发生 epoll 死循环 bug，那么当前 I/O 线程将停下来进行 bug 的修复，然后再继续进行逻辑处理，bug 的修复是非阻塞操作，处理速度非常快；而且 netty 线程池中一般设置有多个 I/O 线程，其中某个 I/O 线程中的 Selector 触发 bug 并不会影响其他 I/O 线程运行，所以 netty 通过这种策略，在几乎不影响性能的情况下从 api 使用层面规避解决了该 bug。

粘包拆包

TCP 层可能会出现当次接收到的数据是不完整数据的情况。出现粘包可能的原因有：

发送方每次写入数据 < 套接字缓冲区大小；
接收方读取套接字缓冲区数据不够及时。

出现半包的可能原因有：

发送方每次写入数据 > 套接字缓冲区大小；
发送的数据大于协议 MTU，所以必须要拆包。

解决问题肯定不是在 4 层来做而是在应用层，通过定义通信协议来解决粘包和拆包的问题。发送方和接收方约定某个规则：

当发生粘包的时候通过某种约定来拆包；
如果在拆包，通过某种约定来将数据组成一个完整的包处理。

业界常用解决方案

定长协议

指定一个报文具有固定长度。比如约定一个报文的长度是 5 字节，那么：报文：1234，只有 4 字节，但是还差一个怎么办呢，不足部分用空格补齐。就变为：1234 。如果不补齐空格，那么就会读到下一个报文的字节来填充上一个报文直到补齐为止，这样粘包了。定长协议的优点是使用简单，缺点很明显：浪费带宽。

Netty 中提供了 FixedLengthFrameDecoder ，支持把固定的长度的字节数当做一个完整的消息进行解码。

特殊字符分割协议

很好理解，在每一个你认为是一个完整的包的尾部添加指定的特殊字符，比如：\n，\r 等等。需要注意的是：约定的特殊字符要保证唯一性，不能出现在报文的正文中，否则就将正文一分为二了。

Netty 中提供了 DelimiterBasedFrameDecoder 根据特殊字符进行解码，LineBasedFrameDecoder默认以换行符作为分隔符。

变长协议

变长协议的核心就是：将消息分为消息头和消息体，消息头中标识当前完整的消息体长度。

发送方在发送数据之前先获取数据的二进制字节大小，然后在消息体前面添加消息大小；
接收方在解析消息时先获取消息大小，之后必须读到该大小的字节数才认为是完整的消息。

Netty 中提供了 LengthFieldBasedFrameDecoder ，通过LengthFieldPrepender 来给实际的消息体添加 length 字段。

Netty 提供的能力

为了解决网络数据流的拆包粘包问题，Netty 为我们内置了如下的解码器：

ByteToMessageDecoder：如果想实现自己的半包解码器，实现该类；
MessageToMessageDecoder：一般作为二次解码器，当我们在 ByteToMessageDecoder 将一个 bytes 数组转换成一个 java 对象的时候，我们可能还需要将这个对象进行二次解码成其他对象，我们就可以继承这个类；
LineBasedFrameDecoder：通过在包尾添加回车换行符 \r\n 来区分整包消息；
StringDecoder：字符串解码器；
DelimiterBasedFrameDecoder：特殊字符作为分隔符来区分整包消息；
FixedLengthFrameDecoder：报文大小固定长度，不够空格补全；
ProtoBufVarint32FrameDecoder：通过 Protobuf 解码器来区分整包消息；
ProtobufDecoder：Protobuf 解码器；
LengthFieldBasedFrameDecoder：指定长度来标识整包消息，通过在包头指定整包长度来约定包长。

Netty 还内置了如下的编码器：

ProtobufEncoder：Protobuf 编码器；
MessageToByteEncoder：将 Java 对象编码成 ByteBuf；
MessageToMessageEncoder：如果不想将 Java 对象编码成 ByteBuf，而是自定义类就继承这个；
LengthFieldPrepender：LengthFieldPrepender 是一个非常实用的工具类，如果我们在发送消息的时候采用的是：消息长度字段+原始消息的形式，那么我们就可以使用 LengthFieldPrepender。这是因为 LengthFieldPrepender 可以将待发送消息的长度（二进制字节长度）写到 ByteBuf 的前两个字节。

UDP 是否会发生粘包或拆包的现象呢？

答案是不会。

UDP 是基于报文发送的，从 UDP 的帧结构可以看出，在 UDP 首部采用了 16bit 来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

而TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段，基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。

API

ByteBuf

ByteBuf 是一个字节容器，内部是一个字节数组。从逻辑上来分，字节容器内部，可以分为四个部分：

第一个部分是已经丢弃的字节，这部分数据是无效的；
第二部分是可读字节，这部分数据是 ByteBuf 的主体数据，从 ByteBuf 里面读取的数据都来自这一部分；
第三部分的数据是可写字节，所有写到 ByteBuf 的数据都会写到这一段。
第四部分的字节，表示的是该 ByteBuf 最多还能扩容的大小。

四个部分的逻辑功能，如下图所示：

ByteBuf 通过三个整型的指针（index），有效地区分可读数据和可写数据，使得读写之间相互没有冲突。

这三个指针，分别是：

readerIndex（读指针）
writerIndex（写指针）
maxCapacity（最大容量）

这三个指针，是三个 int 型的成员属性，定义在 AbstractByteBuf 抽象基类中。三个指针的代码截图，如下：

readerIndex 读指针

指示读取的起始位置。

每读取一个字节，readerIndex 自增 1 。一旦 readerIndex 与 writerIndex 相等，ByteBuf 不可读。

writerIndex 写指针

指示写入的起始位置。

每写一个字节，writerIndex 自增 1。一旦增加到 writerIndex 与 capacity（）容量相等，表示 ByteBuf 已经不可写了。

“

capacity（）容量不是一个成员属性，是一个成员方法。表示 ByteBuf 内部的总容量。注意，这个不是最大容量。

”

maxCapacity 最大容量

指示可以 ByteBuf 扩容的最大容量。

当向 ByteBuf 写数据的时候，如果容量不足，可以进行扩容。

扩容的最大限度，直到 capacity（）扩容到 maxCapacity 为止，超过 maxCapacity 就会报错。

“

capacity() 扩容的操作，是底层自动进行的。

”

从三个维度三大系列，介绍 ByteBuf 的常用 API 方法。

第一组：容量系列

方法一：capacity()

表示 ByteBuf 的容量，包括丢弃的字节数、可读字节数、可写字节数。
方法二：maxCapacity()

表示 ByteBuf 底层最大能够占用的最大字节数。当向 ByteBuf 中写数据的时候，如果发现容量不足，则进行扩容，直到扩容到 maxCapacity。

第二组：写入系列

方法一：isWritable()

表示 ByteBuf 是否可写。如果 capacity（）容量大于 writerIndex 指针的位置，则表示可写。否则为不可写。

isWritable() 的源码，也是很简单的。具体如下：
```
1public boolean isWritable() {
2
3 return this.capacity() > this.writerIndex;
4
5} 
```

“

注意：如果 isWritable() 返回 false，并不代表不能往 ByteBuf 中写数据了。如果 Netty 发现往 ByteBuf 中写数据写不进去的话，会自动扩容 ByteBuf。

”

方法二：writableBytes()

返回表示 ByteBuf 当前可写入的字节数，它的值等于 capacity（）- writerIndex。

如下图所示：
方法三：maxWritableBytes()

返回可写的最大字节数，它的值等于 maxCapacity-writerIndex 。
方法四：writeBytes(byte[] src)

把字节数组 src 里面的数据全部写到 ByteBuf。

这个是最为常用的一个方法。
方法五：writeTYPE(TYPE value）基础类型写入方法

基础数据类型的写入，包含了 8 大基础类型的写入。

具体如下：writeByte()、 writeBoolean()、writeChar()、writeShort()、writeInt()、writeLong()、writeFloat()、writeDouble() ，向 ByteBuf 写入基础类型的数据。
方法六：setType(TYPE value）基础类型写入，不改变指针值

基础数据类型的写入，包含了 8 大基础类型的写入。

具体如下：setByte()、 setBoolean()、setChar()、setShort()、setInt()、setLong()、setFloat()、setDouble() ，向 ByteBuf 写入基础类型的数据。

“

setType 系列与 writeType 系列的不同：

”

setType 系列不会改变写指针 writerIndex ；

writeTYPE 系列会改变写指针 writerIndex 的值。
方法七：markWriterIndex() 与 resetWriterIndex()

这里两个方法一起介绍。

前一个方法，表示把当前的写指针 writerIndex 保存在 markedWriterIndex 属性中后一个方法，表示把当前的写指针 writerIndex 恢复到之前保存的 markedWriterIndex 值。

标记 markedWriterIndex 属性，定义在 AbstractByteBuf 抽象基类中。

截图如下：

第三组：读取系列

方法一：isReadable()

表示 ByteBuf 是否可读。如果 writerIndex 指针的值大于 readerIndex 指针的值，则表示可读。否则为不可写。

isReadable() 的源码，也是很简单的。具体如下：
```
1public boolean isReadable() {
2
3 return this.writerIndex > this.readerIndex;
4
5} 
```
方法二：readableBytes()

返回表示 ByteBuf 当前可读取的字节数，它的值等于 writerIndex - readerIndex 。

如下图所示：
方法三：readBytes(byte[] dst)

把 ByteBuf 里面的数据全部读取到 dst 字节数组中，这里 dst 字节数组的大小通常等于 readableBytes() 。这个方法，也是最为常用的一个方法。
方法四：readType(）基础类型读取

基础数据类型的读取，可以读取 8 大基础类型。

具体如下：readByte()、readBoolean()、readChar()、readShort()、readInt()、readLong()、readFloat()、readDouble() ，从 ByteBuf 读取对应的基础类型的数据。
方法五：getTYPE(TYPE value）基础类型读取，不改变指针值

基础数据类型的读取，可以读取 8 大基础类型。

具体如下：getByte()、 getBoolean()、getChar()、getShort()、getInt()、getLong()、getFloat()、getDouble() ，从 ByteBuf 读取对应的基础类型的数据。

“

getType 系列与 readTYPE 系列的不同：

”

getType 系列不会改变读指针 readerIndex ；

readTYPE 系列会改变读指针 readerIndex 的值。
方法六：markReaderIndex() 与 resetReaderIndex()

前一个方法，表示把当前的读指针 ReaderIndex 保存在 markedReaderIndex 属性中。

后一个方法，表示把当前的读指针 ReaderIndex 恢复到之前保存的 markedReaderIndex 值。

标记 markedReaderIndex 属性，定义在 AbstractByteBuf 抽象基类中。

截图如下：

pipeline

ChannelPipeline 和 ChannelHandler 机制类似于 servlet 和 Filter 过滤器，这类拦截器实际上是职责链模式的一种变形，主要为了方便事件的拦截和用户业务逻辑的定制。
ChannelPipeline 实际上是一个 ChannelHandler 的容器，内部维护了一个 ChnnelHandler 的链表和迭代器，可以方便地实现 ChannelHandler 查找、添加、替换和删除。

参考

一个学习设计模式的好资源

Mon, 06 Apr 2020 04:15:27 +0000

https://refactoringguru.cn/design-patterns

上面是网站地址，不说别的，光是图画的就深得我心。

贴几个大家感受下：

工厂方法模式是一种创建型设计模式，其在父类中提供一个创建对象的接口，允许子类决定实例化对象的类型。

抽象工厂模式是一种创建型设计模式，它能创建一系列相关的对象，而无需指定其具体类。

生成器模式是一种创建型设计模式，使你能够分步骤创建复杂对象。该模式允许你使用相同的创建代码生成不同类型和形式的对象。

原型模式是一种创建型设计模式，使你能够复制已有对象，而又无需使代码依赖它们所属的类。

单例模式是一种创建型设计模式，让你能够保证一个类只有一个实例，并提供一个访问该实例的全局节点。

适配器模式是一种结构型设计模式，它能使接口不兼容的对象能够相互合作。

怎么样？还不错吧，有些模式光看图你就大概明白是怎么回事儿了。网站上也有它的电子书卖（注意，这不是广告，我也没拿钱啊）。想买书的也可以买本来看看，不过我觉得看网站上的大部分内容应该就够了。

关注公众号获取更多精彩内容

一个实例搞懂抽象工厂模式

Sun, 15 Mar 2020 16:00:00 +0000

关于工厂模式三兄弟（简单工厂、工厂方法、抽象工厂），前两个兄弟比较容易懂，基本一看就明白，第三位兄弟初看起来确实有些抽象，网上看到一个例子讲的很好，分享给大家，保证一看就明白。

文末给出系列文章出处。

Sunny软件公司欲开发一套界面皮肤库，可以对Java桌面软件进行界面美化。为了保护版权，该皮肤库源代码不打算公开，而只向用户提供已打包为jar文件的class字节码文件。用户在使用时可以通过菜单来选择皮肤，不同的皮肤将提供视觉效果不同的按钮、文本框、组合框等界面元素，其结构示意图如图所示：

图1 界面皮肤库结构示意图

该皮肤库需要具备良好的灵活性和可扩展性，用户可以自由选择不同的皮肤，开发人员可以在不修改既有代码的基础上增加新的皮肤。

Sunny软件公司的开发人员针对上述要求，决定使用工厂方法模式进行系统的设计，为了保证系统的灵活性和可扩展性，提供一系列具体工厂来创建按钮、文本框、组合框等界面元素，客户端针对抽象工厂编程，初始结构如图所示：

图2 基于工厂方法模式的界面皮肤库初始结构图

在图2中，提供了大量工厂来创建具体的界面组件，可以通过配置文件更换具体界面组件从而改变界面风格。但是，此设计方案存在如下问题：

(1) 当需要增加新的皮肤时，虽然不要修改现有代码，但是需要增加大量类，针对每一个新增具体组件都需要增加一个具体工厂，类的个数成对增加，这无疑会导致系统越来越庞大，增加系统的维护成本和运行开销；

(2) 由于同一种风格的具体界面组件通常要一起显示，因此需要为每个组件都选择一个具体工厂，用户在使用时必须逐个进行设置，如果某个具体工厂选择失误将会导致界面显示混乱，虽然我们可以适当增加一些约束语句，但客户端代码和配置文件都较为复杂。

如何减少系统中类的个数并保证客户端每次始终只使用某一种风格的具体界面组件？这是Sunny公司开发人员所面临的两个问题，显然，工厂方法模式无法解决这两个问题，别着急，本文所介绍的抽象工厂模式可以让这些问题迎刃而解。

Sunny公司开发人员使用抽象工厂模式来重构界面皮肤库的设计，其基本结构如图所示：

如果需要更换皮肤，只需修改配置文件即可，在实际环境中，我们可以提供可视化界面，例如菜单或者窗口来修改配置文件，用户无须直接修改配置文件。如果需要增加新的皮肤，只需增加一族新的具体组件并对应提供一个新的具体工厂，修改配置文件即可使用新的皮肤，原有代码无须修改，符合“开闭原则”。

扩展

在真实项目开发中，我们通常会为配置文件提供一个可视化的编辑界面，类似Struts框架中的struts.xml编辑器，大家可以自行开发一个简单的图形化工具来修改配置文件，实现真正的纯界面操作。

本文并没有展开讲抽象工厂模式的方方面面，只是用一个例子，让大家对这个设计模式有个直观的感受，让它“落地”到实例中，建议大家看看下面的系列文章（认真看用不了多久），我也是从这里摘取的例子。

以下为文章参考出处: 《工厂三兄弟之抽象工厂模式》

关注公众号获取更多精彩内容

设计模式没时间学？(一图带你搞定23种设计模式)

Sat, 14 Mar 2020 16:00:00 +0000

**设计模式学完容易忘? **

**设计新东西时，不知道用哪个？ **

知道用哪个模式又开始手忙脚乱的一通查？

面试让画个设计模式的UML图拉了胯？

你碰到的问题很多人都有

早在2007年国外的Jason McDonald小哥就为我们整理出了一个超精简版设计模式文件（文末有下载链接，大家可以去下载原PDF文件）

所谓精简版，既没有详细地论证和介绍每一个模式，而是让在你有一定理论基础的情况下，通过这个文件快速回顾或回忆起来。如果你对每一种设计模式还不清楚，建议还是先认认真真学习一遍（比如看四人帮写的相关书籍），不然看了也不深刻。

设计模式分类

这23种设计模式，可以分为三类，如下图所示

蓝色的C就是创建型模式
绿色的B就是行为型模式
橙色的S就是结构型模式

责任链模式

命令模式

解释器模式

迭代器模式

中介者模式

备忘录模式

观察者模式

状态模式

策略模式

模版模式

访问者模式

适配器模式

桥接模式

组合模式

装饰器模式

门面模式

享元模式

代理模式

抽象工厂模式

构造器模式

工厂方法模式

原型模式

单例模式

完整PDF文件可以通过这个链接下载：

http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf

关注公众号获取更多精彩内容

如何学习算法？

Sat, 15 Feb 2020 17:13:17 +0000

最近读了些文章，以下的文章并没有对具体算法的解答，有的是一些关于学习、信念等问题的更为抽象的思考和方法论，我个人读完认为挺有用的，分享给大家。

我知道很多人对于学习，尤其是算法学习是有一些心理障碍，或者缺乏信念，关于如何保持坚定的信念可以看看这篇：别高估自己1年的成就，却低估自己10年的发展

总结来说：“认知信念原则执行”

进入正题

首先是讲学习方法的：如果高效学习有什么秘诀的话，那就都在这里了：）

文中主要强调几点

不要完美主义！
不要过度“学习路径依赖”，学习要冲着自己的目标去
不要看不起“薄薄”的“傻”教材，这些你看不起的学习材料，可能是你入门某个领域的关键
不要迷信单一教材
实践！
debug非常非常重要
量变到质变
最后，一定要相信时间的力量

接着是探讨学习算法有没有用的问题：学算法有什么用？唉，对你来说，可能真没用

文中重点是：

“算法不是技术领域的唯一的核心竞争力，但无论是一个人，一个企业，还是做一份事业，都需要有核心竞争力。什么都没有，肯定是不行的。很多同学问我，去大厂工作，一定要有算法比赛的成绩吗？答案当然不是。我认识太多大佬，没有参加过任何算法比赛，轻轻松松进大厂。有的大佬在面试时直接说：算法我不太懂，但是设计模式软件架构随便问；有的大佬则本科三年就做出一个简易的操作系统内核，面试时聊os把面试官聊晕；有的大佬在iPhone 3的年代就自学iOS开发，一年时间直接进大厂iOS部门当负责人；有的大佬只有高中学历，考不上大学，自学外挂技术竟然成才，如今成为知名游戏厂商的安全部门技术大拿。

所以，“没有什么”从来不是问题。关键问题，从来都是：“你有什么”。”

怎么才叫学会了？：什么叫学会了？自己到底有没有学会？知识掌握的七个境界

也许你会说，我不会算法照样能在大厂混，算法非得学吗？关于这个可以看看这篇：大厂面试为什么总考算法？以及如何避开算法面试。

关于以上的问题，文中已经有答案了：就是成为领域专家

最后，祝你成为技术大牛。关于如何成为，可以看看这篇：资深技术 Leader 曹乐：如何成为技术大牛

文中强调：

“但其实在成为技术大牛的路上，方法反而是没那么重要的。真正困难的，在于数年，数十年如一日的坚持。太多人遇到挫折，遇到瓶颈，就觉得手头的事情太乏味枯燥，就想要换一个方向，换一个领域，去学新的技术，新的东西。而真正能够成为大牛的，必须是能够青灯古佛，熬得住突破瓶颈前长时间的寂寞的，必须是肯下笨功夫的聪明人**。因此**，和坚持相比，方法其实并没有那么重要。”

关注公众号获取更多精彩内容