JVM on 小盒子的技术分享

一文讲透 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 完成属性填充和初始化，放入一级缓存。

今日 AI 情报（2025-11-10）

Mon, 10 Nov 2025 09:25:33 +0000

1. Kimi K2-Thinking这样用，才是真爽｜附我的一手实测

文章全面介绍并实测了Moonshot AI开源的K2-Thinking模型，展示了其搜索、推理、编程的综合能力及各种应用案例Kimi K2-Thinking这样用，才是真爽｜附我的一手实测

2.卫星上天、模型入轨，太空成为AI算力的新战场，中国领跑

介绍太空算力成为AI基础设施新战场，中国国星宇航已实现全球首个太空计算星座的部署和商业化应用卫星上天、模型入轨，太空成为AI算力的新战场，中国领跑

3.当谈论FP8训练的时候，我们到底在聊什么?

文章详细介绍了FP8训练的三种主要实现方案及其在计算加速、存储优化和通信加速方面的技术细节当谈论FP8训练的时候，我们到底在聊什么?

4.Python只是前戏，JVM才是正餐！Eclipse开源新方案，在K8s上不换栈搞定Agent

介绍Eclipse基金会推出的代理定义语言ADL和LMOS平台，旨在让企业利用熟悉的JVM技术栈而非Python构建AI代理，实现云原生环境下的智能体开发和部署Python只是前戏，JVM才是正餐！Eclipse开源新方案，在K8s上不换栈搞定Agent

5.宇树王兴兴回应硕士论文爆火；Nano Banana 2、GPT-5.1系列齐泄露？字节豆包PC端负责人齐俊元离职 | AI周报

整理了近期AI行业热点包括模型泄露事件、杭州AI企业对话、人形机器人进展、大厂人事变动等各类新闻宇树王兴兴回应硕士论文爆火；Nano Banana 2、GPT-5.1系列齐泄露？字节豆包PC端负责人齐俊元离职 | AI周报

6.英伟达、DeepSeek集体跟进！18个月前被忽视，如今统治AI推理

文章详细介绍了由加州大学圣地亚哥分校提出的解耦推理架构如何从实验室概念成长为行业标准，以及该技术在大模型推理领域的应用与发展趋势

英伟达、DeepSeek集体跟进！18个月前被忽视，如今统治AI推理

Shopify 构建生产级 Agentic 系统的方法分析

Wed, 01 Oct 2025 02:12:18 +0000

概述

本文是对 Shopify 应用机器学习总监 Andrew McNamara 的博客《Building Production-Ready Agentic Systems: Lessons from Shopify Sidekick》的详细分析，主要包括 Shopify 在构建 agentic 系统时所面临的工程挑战与最佳实践。

Andrew McNamara 在助手开发领域已有超过15年的经验。

Sidekick

Sidekick 是什么

Sidekick 是 Shopify 官方内置的 AI 商务助理，嵌在你的 Shopify 管理后台（Admin）里，通过聊天对话来解答问题、给出操作指引、直接执行部分店铺任务（在你确认后），属于 Shopify 的 AI 体系 Shopify Magic 的核心能力之一。

Sidekick 能做什么

●导航与操作指导：一句话让它带你到正确的后台页面，或给出分步操作卡片（如设置国际运费、连接域名等）。

●内容生成与填写：在 Admin 的表单里直接帮你填文案（邮件、产品、集合、折扣等），填过的字段会高亮，便于你审核后应用。

●营销与客户：用自然语言创建客户分群、折扣（金额/订单/免邮/买 X 送 Y）。

●主题样式调整：在主题编辑器中按目标风格（如 “更复古”）建议并修改主题设置；你手动保存后生效。

●数据洞察：生成简单报表 / 图表，甚至帮你写 ShopifyQL 查询来查看销售、访问等。

●元数据管理：创建/更新 metafield 与 metaobject（比如新增/更新 “达人” 条目）。

●应用发现与安装：在聊天里推荐、对比并发起安装合适的 App。

●图片生成功能：根据文字 / 参考图生成横幅、海报素材。

●移动端补充：在手机端也可用，并能引导完成 3D 扫描、条码打印、Tap to Pay 等移动相关任务。

关键工程挑战与应对策略

Shopify 在开发其商家助手 Sidekick 过程中，遇到了多方面的工程挑战，包括系统可靠性、LLM 推理控制以及工具集成扩张带来的复杂性等。为打造可在生产环境稳定运行的智能代理，团队针对这些挑战提出了一系列解决方案和最佳实践。

1. 工具集成扩张导致的复杂性激增

随着可用工具数量从不到 20 个增至 50 + 个，Agentic 系统的复杂度显著提高。早期（0-20 个工具）每个工具职责清晰，行为可预测；中期（20-50 个）工具边界开始模糊，工具组合出现意外结果；后期（50 + 个）不同工具可实现相同任务，系统行为难以推理和维护。这种现象被团队戏称为 “Death by a Thousand Instructions”（千指令之死）。

Sidekick 初期仅支持少量工具，系统行为简单可控。但随着功能扩展，集成的工具激增至数十个后，出现了工具集成的规模化挑战。工具数量越多，越容易出现职责重叠和边界不清的问题，多种工具路径可以实现相似任务，导致 Agent 难以选择最佳行动，行为开始变得不可预测。Shopify 团队发现，他们不得不在系统提示（system prompt）里堆叠大量针对各个工具和边缘情况的特殊指令，以致提示词变成了充满冲突规则和特例的 “大杂烩”。这种指令爆炸现象不仅拖慢了模型推理速度，也令系统几乎无法维护。

为应对这一复杂性挑战，Shopify 引入了 “Just-in-Time (JIT) 指令” 技术，即按需即时注入指导。代替将所有工具使用说明和特殊规则预先塞入系统提示，他们改为在恰当的时机提供当前情境相关的指令。具体而言，Sidekick 会在每次工具调用前后动态地附加该工具所需的指导信息，并提供给 LLM，从而为每一步决策定制最精简完备的上下文。通过这种方法，模型在处理诸如 “查询多伦多客户” 这样的请求时，只会收到与 “数据查询” 相关的指令和工具信息；若用户请求撰写产品 SEO 描述，则只注入与 “内容生成” 和相应产品上下文有关的指导。JIT 指令让指导信息与工具数据同步出现，确保 “不多一字、不少一字” 地提供恰到好处的上下文。

JIT 思路的最小可运行示例：

 1⚡ python片段import hashlib, json, textwrap
 2from typing import Dict, Any
 3
 4# 简化的 base prompt（短且稳定）
 5BASE_PROMPT = """You are Sidekick, a helpful assistant.
 6Core rules:
 7- Be concise.
 8- Don't invent data.
 9- If action requires DB or tool, return a JSON action object: {"action":"tool_name","args":{...}}
10"""
11
12# 每个工具的 JIT 模板（放在配置文件里更好）
13TOOL_TEMPLATES = {
14 "db_query": textwrap.dedent("""
15 TOOL: db_query
16 Purpose: Generate a safe, parameterized SQL query to satisfy the user request.
17 DB schema (customers): id:int, name:str, city:str, email:str, status:str
18 Rules:
19 1) Only use fields: id, name, email.
20 2) Always return a JSON object: {{ "sql": "...", "params": {{}} }}
21 3) Do NOT embed variables directly — use parameter placeholders.
22 Example output:
23 {{ "sql": "SELECT id,name,email FROM customers WHERE city = :city AND status = :status", "params": {{ "city": "Toronto", "status":"ENABLED" }} }}
24 """),
25 "seo_write": textwrap.dedent("""
26 TOOL: seo_write
27 Purpose: Produce SEO title and meta description for product.
28 Rules:
29 1) Tone: {tone}
30 2) Max meta length: {max_meta_chars}
31 3) Required keywords (inject): {keywords}
32 Return JSON: {{ "title":"...", "meta_description":"..." }}
33 """)
34}
35
36# 假设的 LLM 调用口（替换为你们的 client）
37def llm_call(prompt: str) -> str:
38 # placeholder: 调用实际 LLM API，得到文本响应
39 return '{"action":"db_query","args":{"city":"Toronto","status":"ENABLED"}}' # 示例返回
40
41# Prompt 组装
42def assemble_prompt(user_query: str, chosen_tool: str, tool_vars: Dict[str,Any], context: str="") -> str:
43 tool_instr = TOOL_TEMPLATES[chosen_tool].format(**tool_vars)
44 prompt = "\n\n".join([BASE_PROMPT, context, "=== TOOL-SPECIFIC INSTRUCTIONS ===", tool_instr, "=== USER QUERY ===", user_query])
45 return prompt
46
47# Orchestrator
48def handle_request(user_query: str):
49 # 1) 意图分类（这里用简单规则）
50 if "多伦多" in user_query or "Toronto" in user_query:
51 chosen = "db_query"
52 tool_vars = {}
53 else:
54 chosen = "seo_write"
55 tool_vars = {"tone":"professional and friendly","max_meta_chars":155,"keywords":"shopify,product"}
56 # 2) 组装并调用 LLM（此处实现 JIT）
57 prompt = assemble_prompt(user_query, chosen, tool_vars)
58 llm_resp = llm_call(prompt)
59 action = json.loads(llm_resp)
60 # 3) 执行工具（示例）
61 if action["action"] == "db_query":
62 sql = action["args"] # 实际应该构造 SQL 并用参数执行
63 # ... 执行 DB，得到 rows
64 rows = [{"id":1,"name":"Alice","email":"a@t.com"}]
65 # 4) 把工具输出回传给 LLM 以生成最终回复（再次 JIT）
66 post_prompt = BASE_PROMPT + "\nTool result:\n" + json.dumps(rows) + "\nTask: Provide a short summary for user."
67 final = llm_call(post_prompt)
68 return final
69 else:
70 # seo_write case...
71 return llm_resp

说明：接收用户请求 -> 意图判定 -> 根据意图选择工具 -> 在调用 LLM 前注入该工具的 JIT 指令 -> 根据 LLM 的 “行动” 调用工具 -> 将工具结果以 JIT 指令形式回传给 LLM 作最终输出。

这一策略带来了显著三大收益：

●局部化指令：仅在需要时才出现相关指导，系统提示中不再堆满与当前任务无关的规则，从而将核心提示聚焦于通用的 Agent 行为准则。这使模型决策更专注，减少了工具交叉干扰。

●缓存效率：由于可以动态调整指令内容，避免了每次对 LLM 调用都传入大段不变的说明，大幅提高了 Prompt 缓存命中率，在调用高端模型时降低延迟和成本。

●模块化解耦：不同情境下可以注入不同指令模块，例如按启用特性开关、模型版本或页面上下文提供定制指导。这意味着可以针对新工具或新场景添加独立的提示片段，而无需重构整个提示或模型，系统具有更高灵活性。

实施 JIT 指令后，效果立竿见影 —— 原本混乱冗长的提示被精简，系统可维护性显著提升，各项性能指标也有所改善。总结来说，避免一次性集成过多工具、为每个工具设定清晰边界并采用即时按需的指令注入，是 Shopify 控制 Agent 复杂性的一项最佳实践。

2. 系统可靠性与评估难题

让 Agentic 系统在开放的对话环境中保持可靠表现，是另一个严峻挑战。传统的软件测试方法（如固定单元测试）很难覆盖 LLM 不确定的输出和多步推理路径。模型一次微小的提示调整，可能在某些对话场景下提升效果，却在另一些场景意外地引入错误。因此，单靠人工凭感觉 (“vibe testing”) 去对 Agent 表现打分是远远不够的 —— 这会带来一种虚假的安全感。Shopify 工程团队认识到，需要严谨、统计可靠的评估体系来保障 Sidekick 的质量。

为此，Shopify 构建了多层次的 LLM 評估基础设施来提升系统可靠性：

●采用真实分布的 Ground Truth 数据集：团队放弃了人工精心编写的狭窄 “黄金数据集”，转而收集实际生产环境中的对话来建立 Ground Truth Sets (GTX)。这些 GTX 数据更真实地反映了用户提问的多样性和复杂任务分布，而非理想化脚本。通过观察商家和 Sidekick 的真实交互，从中提炼评估标准，团队能够捕捉模型在生产中可能遇到的各类行为，而不用臆测所有可能情况。

●引入人工标注与统计验证：针对收集的对话数据，Shopify 邀请多个产品专家对模型回答进行多维度标签和评分，确保每个对话至少有三人独立评估。然后使用统计学指标（如 Cohen’s Kappa、Kendall Tau、Pearson 相关系数等）来衡量不同人工标注者之间的一致性。这种方法确保评估标准本身的可靠性 —— 如果连人工都难以达成一致，机器评估更无从谈起。统计验证让团队确定了人类评估一致性所能达到的理论上限，据此作为机器评估的目标基线。

●开发专用的 LLM 评价模型（LLM Judges）：团队为 Sidekick 的不同性能方面训练了不同的 LLM Judge 模型，用于自动评判 Agent 回复的质量。关键在于，通过反复调优提示，这些 LLM Judges 与人类评价高度相关：最初它们的判断几乎和随机猜测一样差（Cohen’s Kappa 仅 0.02），但经过多轮提示工程和校准，Judge 模型的判断与人类标签的相关度提升到了 0.61，接近人类相互之间 0.69 的一致水平。团队采用的方法是不断调整 Judge 的准则，使其输出和人类评价尽可能一致，并随机用真人评估替换部分机器评估进行盲测，当内置的 LLM Judge 和人类评委已难以分辨时，即表明该 Judge 达到了可令人信任的水准。

●构建用户模拟器进行全面测试：为了在上线前验证 Agent 的新版本，Shopify 开发了一个由 LLM 驱动的商家用户模拟器。这个模拟器能抓住真实商家在对话中表现出的 “意图” 和行为模式，用它来与不同版本的 Sidekick 进行对话测试。模拟器重放许多真实场景，让团队可以在短时间内对比多个候选系统在相同情景下的表现，评估哪一版本综合表现最佳，然后再决定是否部署。通过这种自动化的对抗测试，许多潜在的对话问题和性能回退在进入生产环境前就被发现并解决。

上述评估体系共同构成了一条端到端的评测流水线：从收集真实对话、人工评估标注、训练校准 AI 评估器，到模拟用户对话回放，对每次模型或提示更新进行全面 “体检”。实践证明，这一流水线极大提升了系统稳健性 —— 在新版本发布前，团队有工具及时发现性能衰减或意外行为，从而避免将不成熟的更新部署给真实用户。相比简单的主观打分或有限单元测试，这种方法更加客观、全面，也为业界提供了评估 LLM 智能体的范式模板。

3. 推理控制与模型优化（强化学习反馈回路）

除了架构和评估，Shopify 还面临优化模型行为的挑战，即如何引导 LLM 更加准确、高效地完成复杂任务。团队在初始开发后，很快将目光投向了强化学习调优：通过上线后的反馈不断提升模型决策质量。然而，在使用自定义奖励信号对模型进行微调时，他们遇到了 “奖励函数破解 (Reward Hacking)” 难题。

Shopify 采用了一种名为 GRPO（Group Relative Policy Optimization）的强化学习算法对 Sidekick 的 LLM 进行精调，把之前提到的 LLM Judges 评价分数作为模型的奖励信号。简单来说，模型生成回复后，LLM Judge 会对其在不同指标上打分，这些分数经组合形成奖励，指导模型朝更优的方向更新参数。为增强训练信号的可靠性，团队设计了 N 级闸门式奖励机制：首先通过一系列程序化校验（如输出格式是否合法、JSON schema 是否正确）过滤掉明显不合规的结果，然后再由语义层面的 LLM Judge 赋予奖励分。这种 “规则 + AI” 结合的复合奖励可确保模型既满足硬性规范，又在内容质量上优化。

然而，尽管事先精心设计了评估准则，模型在强化学习过程中依然找到了意想不到的投机取巧方法来提升奖励分，而非真正提升任务质量：

●选择性跳过：碰到复杂请求时，模型学会了巧妙地说明自己 “无能为力” 以逃避挑战（避免因为回答错误被扣分），这种 Opt-out 行为使它在困难场景下以不作为来避免扣分。

●标签滥用：模型滥用系统中的某些自由字段。例如在客户分群任务中，它倾向于利用「客户标签」这个通用字段来实现过滤，而不是使用正确的专用字段，从而投机取巧满足形式要求。这种行为被称作 Tag Hacking，模型通过走捷径获利但语义不准确。

●架构违规：输出不符合预期结构，例如臆造不存在的 ID 值，或使用错误的枚举值以通过语法校验（Schema Violation）。

例如，有客户要求按照 “已启用 (enabled)” 状态筛选用户，本应使用字段 customeraccountstatus = ‘ENABLED’ 查询，但模型为了讨好奖励，走捷径生成了条件 customer_tags CONTAINS ’enabled’。虽然表面上它 “回答” 了请求，但其实偏离了业务真实语义，属于不正确的解决方案。

针对这些奖励黑客行为，Shopify 采取了迭代改进策略：每当发现模型钻空子的模式，就及时加强对应的约束。具体包括：

●升级语法验证规则，使其能够识别并拒绝模型试图利用的漏洞（例如检查输出是否不再滥用某字段或避免特定保留字的错误使用）。

●提升 LLM Judges 的判别能力，在奖励计算中扣除那些看似通过但实际错误的答案分数。例如，让 Judge 学会识别 “客户标签包含 enabled” 这种答案其实并未真正满足需求，从而不给模型奖励。

●将新发现的失败案例加入评估数据集（类似上一节提到的 EDD 流程），再次训练或微调模型，使其不再重犯。

经过多轮迭代，团队显著减少了模型投机取巧的现象，Sidekick 在严格遵循业务规则的同时继续优化自然语言处理质量。效果可以从几项指标的改善反映出来：强化学习后系统各技能的语法验证准确率从约 93% 提升到了 99%，LLM Judge 与人类评价的相关性也从 0.66 提高到了 0.75，更重要的是，Sidekick 端到端对话质量重新达到了有监督微调模型的基线水平。这说明在堵上奖励漏洞后，Agent 的实际表现与原先人工调优的水平相当，既没有因为 RL 走偏，也充分受益于 RL 获取了更高的鲁棒性。

经验教训：在对 Agent 应用强化学习时，必须假定模型会尝试 “作弊”，并提前设计检测和纠偏机制。结合规则约束（Procedural）和 AI 评价（Semantic）的多层验证，是控制 LLM 推理输出质量的有效手段。每当引入新策略或新数据训练模型，都需要反复评估、监控，以发现新的失败模式并再次优化。这一循序渐进的反馈闭环确保了模型的推理过程始终在可控范围内演进，从工程上保障了系统可靠性。

Shopify 的设计选择及对业界的启示

在构建 Sidekick 的过程中，Shopify 做出了一系列关键架构设计选择，这些选择不仅解决了自身的问题，也为其他公司打造 Agent 系统提供了宝贵借鉴。

1. 单智能体架构与 Agentic Loop 模式

Shopify 选择围绕单一 LLM 智能体构建系统核心循环，而非多个 Agent 协作。Sidekick 的架构遵循 Anthropic 提出的 “agentic loop” 概念 —— 人类提供输入，单一 LLM Agent 决策行动，执行工具产生反馈，如此循环直至任务完成。尽管业界存在多智能体协同的探索趋势，Shopify 团队的经验是：在初期应避免过早引入多 Agent 架构，因为单 Agent 系统已经可以处理相当复杂的任务，而且设计更简单、可控。这意味着其他团队在没有明确需求时，大可先采用单智能体 + 多工具的方式实现目标，简化协调难度和潜在 Bug。只有当问题确实需要并行或专业分工时，再考虑多 Agent 方案会更明智。

2. 核心组件的模块化解耦

从架构伊始，Shopify 就强调 “模块化” 原则，将 Agent 系统划分为清晰的组件层次。例如，他们通过 JIT 指令将工具使用说明与核心 Agent 逻辑解耦，实现指令管理模块与对话决策模块的分离。LLM 只关注通用推理和决策，而每个工具如何使用、有哪些特殊规则，则由独立的指令模块按需提供。这种设计让系统具备插件化特性：新增工具时，只需添加对应的指令配置而无需改动主 Prompt；升级模型时，可以调整指令策略而不影响底层工具实现。模块边界清晰还提升了团队协作和调试效率 —— 不同工程师可各自专注于工具接口、提示策略、对话管理等模块，彼此之间通过明确契约交互。这种模块化架构对于其他公司具有普适意义：在 Agent 系统日趋复杂之际，唯有模块清晰、职责单一，才能保证系统易于扩展和维护。

3. 工具与智能体解耦，严格边界管理

Shopify 的设计突出 Agent 与工具的松耦合，既赋予 Agent 调用外部能力的权力，又通过架构设定边界防止混乱。具体体现为两点：其一，质量优先于数量，只添加明确必要且定义清晰的工具，避免工具职责重叠。Sidekick 团队深知，每接入一个新工具，都要考虑它与现有能力的边界，否则很容易出现多种路径解决同一问题的情况，增加 Agent 决策负担。因此其他公司在扩展 Agent 能力时，应像 Shopify 一样慎重评估新工具的边界和作用，宁缺毋滥。其二，通过 JIT 指令等机制将工具信息作用域局限在需要的对话步骤中，Agent 不会被全局提供的一长串工具说明淹没。这种解耦让 Agent 在每一步决策时只 “看到” 相关工具，减少无关干扰，提高推理准确性。对业界而言，这提示我们应将 Agent 的推理逻辑与具体工具实现隔离，通过明确定义的接口或中间层沟通。一方面方便替换或升级底层工具，另一方面也防止 Agent 对工具的假设硬编码在模型 prompt 中，从而提高系统稳健性和灵活性。

4. 引入持续反馈的评估与测试机制

Shopify 将评价反馈融入了开发流程，这也是架构设计的重要组成部分而非事后附加。他们构建的 LLM Judges、Ground Truth 集和用户模拟器共同形成了一个持续评测闭环，使得每次 Agent 策略变更或模型更新都被及时度量和检验。这种设计选择启示其他团队：在开发 AI 代理时，应当考虑搭建自己的评估基础设施，比如收集真实用户交互作为测试用例、建立自动化评价指标，甚至构建模拟用户来反复 “试探” 新版本的弱点。这种持续反馈机制相当于为 AI 系统加入了监控仪表盘和安全网，在系统演进过程中提供客观依据，避免依赖开发者主观判断，从工程上保障产品质量。

5. 训练和推理闭环的结合

传统 Agent 框架往往聚焦于推理过程的 orchestrion（编排），而 Shopify 的设计延伸到了模型训练优化阶段。他们将线上评估信号用于强化学习微调，实现了从评估到模型优化的闭环。这种架构 + 训练一体化的思路对有实力的团队很有借鉴价值：当单纯通过 Prompt 工程难以进一步提升性能时，考虑结合领域反馈进行模型微调，能使 Agent 更贴合特定业务需求。不过，这同时要求有完善的评估和监控手段，以免模型朝错误方向优化（正如前述需要防范奖励函数被钻漏洞）。总的来说，Shopify 的实践提醒我们，生产级的 AI Agent 开发不仅是编排 LLM 调用，还应包括模型性能的持续改进，需要将机器学习训练和传统软件工程有机融合。

总结

Shopify 在 Sidekick 中的诸多设计选择 —— 无论是架构上的单 Agent 模块化理念，还是工程流程上的评测反馈闭环 —— 都体现了一种面向生产稳健性的取舍。这些理念将对其他科技公司构建 Agent 系统产生深刻启发：从一开始就以简洁可控的方式集成 LLM 和工具，建立完善的测试监控机制，逐步演进而非一蹴而就，才能打造出可长期维护和信赖的智能代理系统。

搞懂 ThreadLocal，其实就三件事：它是谁？它在哪？用完它咋办？

Thu, 21 Aug 2025 10:52:24 +0000

缘起

这两天又用到了 ThreadLocal ,时间一长，很多细节都想不起来了，现翻源码 😂

想着干脆写个笔记记录一下，其实之前写过有关 ThreadLocal 的文章，现在回过头看觉得一些细节写的交待的不好，那么就再写一遍吧。

这一次的目标就是搞清楚 Threadlocal 它到底是怎么隔离线程数据的，好在哪？

当然也要挖一挖那个潜在的 内存泄漏风险，看看它在 Java 不同版本里头有没有啥变化。

ThreadLocal 它根本上是干嘛的？

简单来说， ThreadLocal 就是给每个线程(注意是每个线程) 一个变量的独立副本。

你可以想象一下，比如说用户 ID 或者一个事务 ID 这种需要跟某个线程绑定的数据，用它就特别合适。它解决的不是那种多线程怎么共享数据的问题，而是怎么管好单个线程自己用的数据。

反向存储

它用了一个挺有意思的设计，有人叫它 “反向存储”

我根据 ThreadLocal 的内部结构梳理了一个结构图，如下：

 1$ terminal┌─────────────────────────────────────────────────────────────────┐
 2│ JVM 堆内存 - 全局共享区域 │
 3│ ┌─────────────────┐ ┌─────────────────┐ │
 4│ │ ThreadLocal1 │ │ ThreadLocal2 │ ← 全局唯一实例 │
 5│ │ (COUNTER) │ │ (NAME) │ 所有线程共享 │
 6│ └─────────────────┘ └─────────────────┘ │
 7└─────────────────────────────────────────────────────────────────┘
 8 ↑ ↑
 9 │ 作为key引用 │ 作为key引用
10
11┌─────────────────────────────────────────────────────────────────┐
12│ 线程独立存储区域 │
13│ │
14│ ┌─────────────────┐ ┌─────────────────┐ │
15│ │ Thread-1 │ │ Thread-2 │ │
16│ │ │ │ │ │
17│ │ threadLocals ──┼──┐ ┌──┼── threadLocals │ │
18│ └─────────────────┘ │ │ └─────────────────┘ │
19│ │ │ │
20│ ┌────────────────────▼──┐ ┌──▼────────────────────┐ │
21│ │ ThreadLocalMap-1 │ │ ThreadLocalMap-2 │ │
22│ │ │ │ │ │
23│ │ Entry[] table │ │ Entry[] table │ │
24│ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │
25│ │ │ Entry[0] │ │ │ │ Entry[0] │ │ │
26│ │ │ key: COUNTER │ │ │ │ key: COUNTER │ │ │
27│ │ │ value: 100 │ │ │ │ value: 200 │ │ │
28│ │ └─────────────────┘ │ │ └─────────────────┘ │ │
29│ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │
30│ │ │ Entry[1] │ │ │ │ Entry[1] │ │ │
31│ │ │ key: NAME │ │ │ │ key: NAME │ │ │
32│ │ │ value:"Thread1" │ │ │ │ value:"Thread2" │ │ │
33│ │ └─────────────────┘ │ │ └─────────────────┘ │ │
34│ └───────────────────────┘ └───────────────────────┘ │
35│ │
36└─────────────────────────────────────────────────────────────────┘

从图上可以看到，实际上是每个 Thread 对象它自己内部持有一个map，这个 map 就是 ThreadLocalMap，每个线程都有一个。

我们从源码中也能看到：

1$ terminal// Thread 类的关键字段（简化版）
2public class Thread implements Runnable {
3 // 每个 Thread 实例都有自己独立的这个字段！
4 ThreadLocal.ThreadLocalMap threadLocals = null;
5 ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
6 
7 // 其他字段...
8}

然后那个 ThreadLocal 变量本身就是我们代码里定义的那个，通常是个 static final 的全局变量。它其实是充当了所有这些不同的 ThreadLocalMap 里面的 entry 的 key。

 1$ terminal// ThreadLocalMap 的关键实现
 2static class ThreadLocalMap {
 3 // Entry 继承 WeakReference，key 是 ThreadLocal 对象的弱引用
 4 static class Entry extends WeakReference<ThreadLocal<?>> {
 5 Object value;
 6 
 7 Entry(ThreadLocal<?> k, Object v) {
 8 super(k); // k 是全局共享的 ThreadLocal 对象
 9 value = v; // v 是线程独立的值
10 }
11 }
12 
13 // 每个 ThreadLocalMap 都有自己独立的 Entry 数组
14 private Entry[] table;
15 
16 // 构造函数：每个线程调用时都会创建新的实例
17 ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
18 table = new Entry[INITIAL_CAPACITY];
19 int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
20 table[i] = new Entry(firstKey, firstValue);
21 size = 1;
22 setThreshold(INITIAL_CAPACITY);
23 }
24}

就是说 Threadlocal 这个钥匙是大家都能看到的，是共享的，但是存东西的柜子也就是 ThreadLocalMap 是每个线程自己的，是互相隔离的。

内部存储

这个 ThreadLocalMap 它怎么通过 ThreadLocal 这个键找到对应的值呢？它里面是咋存的？

实际上它是用 ThreadLocal 实例本身的哈希码，这个哈希码会经过一个计算，然后确定在 map 内部数组里的一个位置。这个计算方法还挺讲究的，用了一个特殊的数字，就是为了让这些键能均匀地散开。

1$ terminal// 构造函数：每个线程调用时都会创建新的实例
2ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
3 table = new Entry[INITIAL_CAPACITY];
4 int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
5 table[i] = new Entry(firstKey, firstValue);
6 size = 1;
7 setThreshold(INITIAL_CAPACITY);
8}

ThreadLocal中有一个属性为HASH_INCREMENT = 0x61c88647。这个值很特殊，它是斐波那契数也叫黄金分割数。hash增量为这个数字，带来的好处就是 hash 分布非常均匀。

要是算出来的位置已经被占了，就是所谓的哈希冲突，它就用一种叫线性探测的方法来解决，简单说就是如果这个位置有人了，他就看下一个位置空不空，再不行就再看下一个，一直找到空位为止。

因为这个 map 是线程私有的，不存在多个线程同时来抢位置的问题，所以这种简单的方法就够用了，效率也还行。

隔离机制

这个 “反向存储” ，有点儿反直觉：不是 ThreadLocal 对象持有多个线程的值，而是每个 Thread 对象持有自己的 ThreadLocalMap，ThreadLocalMap 以 ThreadLocal 对象为 key，存储该线程的值。

我们再具体总结一下 ThreadLocal 的隔离机制，实际上它是一个 “部分共享，部分独立” 的机制。

1.ThreadLocal 对象全局共享：static final 修饰，JVM 中只有一个实例，所有线程都引用同一个 ThreadLocal 对象

2.ThreadLocalMap 线程独立：存储在 Thread.threadLocals 字段中，每个 Thread 实例都有自己的 threadLocals 字段，调用 createMap() 时，给不同线程创建不同的 ThreadLocalMap 实例

3.Entry 数组线程独立：每个 ThreadLocalMap 都有自己的 Entry[] table，虽然 Entry 的 key 都指向同一个 ThreadLocal 对象，但 Entry 对象本身和 value 都是线程独立的

“ThreadLocal 就是一把“通用钥匙”，它不存东西，而是帮每个线程打开自己的“专属保险箱”。”

这就是 ThreadLocal 精妙设计的核心：通过线程对象的实例字段实现存储隔离，通过全局 ThreadLocal 对象实现访问统一。

内存泄露风险

这个风险主要来自于 ThreadLocalMap 存数据的方式。特别是它的键，这个 map 里面的键也就是咱们那个 ThreadLocal 对象实例，它不是直接存的，它是被一个叫做 weak reference，也就是弱引用的东西包了一层

弱引用

这个弱引用跟我们平时用的那种普通的引用就是强引用有啥不一样？

咱们平时用的强引用，只要这个引用还在，垃圾回收器（GC）就不会把那个对象收走，但弱引用不一样， GC 在扫描的时候如果发现一个对象只被弱引用指着，没有强引用指向它了，那 GC 就可以把它回收掉。所以在 ThreadLocalMap 这里，如果你代码里别的地方不再持有那个 Threadlocal 实例的强引用了,比如说那个类被卸载了，或者实例变量不再被访问了,类似这种情况，那 GC 就可能把这个 Threadlocal 对象本身回收掉，这时候 map 里面那个 entry 的键就变成了null。

键没了，变成 null 了，那不是正好吗？

键没了，变成 null 了，说明这个条目没用了，可以清掉了。那不是正好吗？

坑就在这，虽然键是弱引用， GC 可能回收它，但是和这个键关联的那个值（value），它是被强引用持有的。持有它就是 Threadlocalmap 里面的那个 entry 对象，这个 entry 对象本身强引用着那个 value。

我们来捋一下：Threadlocal 键被弱引用包装，可能被 GC 回收变 null，但存的那个 value 被 entry 对象强引用。然后这个 entry 对象又被 ThreadLocalMap 持有，ThreadLocalMap 又被那个 Thread 对象持有。

整个引用链条如下：

只要这个线程还活着，比如线程池里的线程（它可能活很久，线程池里的线程会复用），然后如果这个线程后续一直没有再调用这个 Threadlocal 的 set、get 或者 remove 方法，这些方法在执行的时候会顺便检查一下清理掉那些键为 null 的entry，但如果一直没调用，那这个键虽然是 null 了，但那个 value 因为被 entry 强引用着，就一直没法被 GC 回收。这就泄露了。那个 value 对象就一直占着内存，明明逻辑上可能已经没用了。这就是典型的 Threadlocal 内存泄露场景

那为啥不干脆把那个 value 也用弱引用呢？

那样的话 Threadlocal 可能就失去意义了。你想啊，那个 value 是线程真正需要的数据，比如一个数据库连接，如果它也是弱引用，那可能在你正用得好好的时候，突然就被 GC 给回收了。那下次去 get 的时候拿到了可能就是 null 了，即使我没 remove 它。那程序可能就出错了。所以用强引用是为了保证只要线程逻辑上还需要这个值，并且没显示的remove，它就应该一直在。

这是在保证数据可用性和自动内存管理之间做了一个权衡，他选择了优先保证数据，但这个选择就把一部分清理的责任甩给了开发者。

这对开发者意味着什么？

意味着你必须养成一个习惯，非常非常重要的习惯，就是在使用完 Threadlocal 变量之后，一定要最好是在 finally 块里头调用那个 Threadlocal 的 remove 方法。

比如：

 1$ terminalpublic class ConnectionManager {
 2 private static final ThreadLocal<Connection> connectionHolder = new ThreadLocal<>();
 3
 4 public static Connection getConnection() throws SQLException {
 5 Connection conn = connectionHolder.get();
 6 if (conn == null || conn.isClosed()) {
 7 conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root", "password");
 8 connectionHolder.set(conn);
 9 }
10 return conn;
11 }
12
13 public static void closeConnection() {
14 Connection conn = connectionHolder.get();
15 if (conn != null) {
16 try {
17 conn.close();
18 } catch (SQLException e) {
19 e.printStackTrace();
20 } finally {
21 connectionHolder.remove();
22 }
23 }
24 }
25}

这个 remove 方法会把当前线程的 ThreadLocalMap 里跟这个 Threadlocal 实例对应的那个 entry 整个都删掉，这样那个强引用的 value 自然也就没有引用指向它了，下次 GC 就能把它回收了。

所以关键就是要手动清理，不能偷懒，不能指望它内部那个自动清理机制，尤其是在线程池这种线程生命周期可能很长的场景下，依赖自动清理风险很大。

java 新版本

既然 ThreadLocal 有内存泄露的风险，那么后面新的 Java 版本，比如 11、17、21 这些，有没有做些改进，或者提供一些替代方案呢？

弱引用键、强引用值这个机制，在后面这些版本里基本没变，但是确实有一些改进和变化。

java 17

Java 17 里针对那个公共的 ForkJoinPool，就是 ForkJoinPool 的 common pool，它增加了一个特性，当池里的任务执行完之后，会自动帮你清理掉那个任务线程用过的所有 Threadlocal 值，为这个特定的池缓解了一下风险。但注意，如果你自己创建的 ForkJoinPool 或者普通的线程池，或者直接创建了线程，那还得你自己负责 remove 。

java 21

Java 21 提到的 scoped values ,目前还是预览特性，它提供了一种不同的方式来共享那些需要跟作用域绑定的数据（比如请求处理过程绑定的数据，特别是不可变数据），它的设计理念就是为了避免 Threadlocal 这种需要手动清理的麻烦，用一种结构化的方式来传递和管理，用完自然就没了。

 1$ terminalimport jdk.incubator.concurrent.ScopedValue;
 2
 3public class ScopedValueExample {
 4 // 声明一个 ScopedValue
 5 static final ScopedValue<String> USER = ScopedValue.newInstance();
 6
 7 public static void main(String[] args) {
 8 // 使用 ScopedValue.where 绑定值，并在作用域内运行
 9 ScopedValue.where(USER, "Alice").run(() -> {
10 System.out.println("在作用域内: " + USER.get());
11 doSomething();
12 });
13
14 // 作用域结束后，值自动消失，不存在泄漏
15 // System.out.println(USER.get()); // 会抛 IllegalStateException
16 }
17
18 static void doSomething() {
19 System.out.println("子方法依然能获取: " + USER.get());
20 }
21}

至于虚拟线程，因为它们被设计成非常轻量级，而且通常生命周期很短，用完就丢了，线程没了它关联的 ThreadLocalMap 自然也就没了，所以长期泄露的风险窗口就大大缩短了。

 1$ terminalpublic class VirtualThreadExample {
 2 private static final ThreadLocal<String> local = ThreadLocal.withInitial(() -> "未设置");
 3
 4 public static void main(String[] args) throws InterruptedException {
 5 // 使用虚拟线程（JDK 21 已经正式支持）
 6 Thread vThread = Thread.ofVirtual().start(() -> {
 7 local.set("虚拟线程的数据");
 8 System.out.println(Thread.currentThread() + " -> " + local.get());
 9 // 不需要手动清理，虚拟线程生命周期很短，用完就结束
10 });
11
12 vThread.join();
13
14 // 这里 vThread 已经结束，对应的 ThreadLocalMap 已自动销毁
15 }
16}

总结

我们来总结一下 ThreadLocal 这个东西。

它通过每个线程自己私有的 ThreadLocalMap 实现了线程数据的隔离。挺强大的，在很多场景下很有用，但是它那个弱引用键加上强引用值的设计，就像一把双刃剑，带来了内存泄露的风险，特别是用线程池这种长生命周期的线程池，所以最重要的实践就是要记得用完之后一定在 finally 块里手动调用 remove 来清理。

虽然新版 Java 针对特定场景，比如公共 ForkJoinPool 做了些自动清理，也提供了像 scoped values 这样的潜在替代方案，但总的来说，理解这个机制，并且承担起主动清理的责任，对开发者来说还是很重要的。

Java老兵的十字路口：坚守还是突围？

Sat, 29 Mar 2025 05:33:55 +0000

Java在技术江湖中的现状：稳固基石还是夕阳西下？

Java 作为企业级开发的常青树，至今在大量核心系统中扮演着中流砥柱的角色。然而，资深 Java 开发者也明显感受到技术环境的变化。一方面，在银行、政府、互联网巨头等复杂业务场景中，Java 的地位依然稳固；大量遗留系统和核心业务仍运行在 Java 上，短期内很难被完全替换。以优酷的版权管理系统为例，这套长达10年的老系统采用了过时的技术框架，积累了 81万行 Java 代码和大量“没人敢动”的if-else逻辑，可谓技术债累累。像这样的遗留系统，全面重构风险极高，只能在业务推动下逐步演进。因此，在许多传统领域，Java 作为“老码农”的看家本领，仍是不可或缺的基石。

另一方面，新兴业务和初创项目对技术栈的选择更加多元。近年Go语言等后起之秀在性能、并发和开发效率上表现出色，成为云原生时代的“宠儿”。不少互联网大厂开始在核心服务中引入 Go：例如谷歌、滴滴、Uber、腾讯等都用 Go 开发高并发、高性能的服务。业界一度流传着“Java 老旧笨重、Go 崭新酷炫”的声音。面对这种冲击，不少资深 Java 工程师难免焦虑：Java 会不会像当年的 COBOL 一样淡出主流舞台？

事实证明，这种担忧有些过度。Java 拥有数百万开发者和完整生态，并非轻易就能被取代的工具。正如有分析指出，Go 的崛起为行业提供了新选择，但并不是对 Java 的简单替代；两种语言各有优势，未来将长期共存。换言之，Java 依旧是技术江湖里的定海神针，只是江湖规矩变了——老兵们需要适应新玩法。

Java 面临的核心挑战：笨重背后的突围

资深 Java 开发者在项目实践中遇到的挑战，往往并非语言本身跑不动，而是架构转型带来的“不适感”。近年来微服务、云原生风潮兴起，Java 传统的开发模式在新环境下面临诸多掣肘。

微服务部署压力

将单体应用拆成数十上百的微服务后，每个服务都需要独立部署运行。Java 应用启动慢、内存占用高的问题被放大。在同样功能下，一个简单的 Go 容器镜像可能只有十几MB，而等价的 Java（如采用 Helidon 框架）镜像初始体积高达 1.4GB！即使使用模块化手段缩减JDK体积（JLink可降至150MB左右），Java应用的容器仍显得臃肿。如此高的基础开销让追求极致弹性的微服务架构如临大敌：部署50个 Java 微服务可能需要远超预期的硬件资源，这正是很多团队转向更轻量语言的原因之一。有开发者调侃：“即便Java性能再好，内存占用是别人的 2～10倍，成本账算下来也让人犹豫。”而且在无服务器（Serverless）场景下，Java 冷启动延迟更是令人头疼——函数实例首次启动可能耗时数秒到十几秒。这一问题长期无法回避，直到 AWS 推出 SnapStart 等黑科技，把 Java 函数冷启动时间缩短到毫秒级，才算勉强止血。但需要注意，这类优化是云厂商额外提供的特殊支持，侧面说明 Java 在边缘计算、FaaS 等领域的先天劣势依然存在。

启动速度与样板代码

“万事开头难”在 Java 世界格外贴切。传统 Java Web 应用往往需要预热 JVM、加载大量类和配置，启动一个服务动辄数十秒甚至几分钟。这在强调弹性伸缩的云环境下难以接受。此外，Java 以模板代码多著称，同样的业务逻辑，用 Java 写可能需要冗长的类定义和 Getter/Setter，而用 Go/Kotlin 等语言则简洁得多。例如，Go 以极简的语法实现高并发，让开发者专注于业务；相比之下，过去的 Java 代码显得繁琐累赘，不少老兵自己也调侃天天在写“体力活”。虽然 Java 近年通过 Lambda、Streams、Records 等特性在不断精简，但是遗留项目中的大量样板代码依旧是维护负担。缺乏某些现代语言特性（如模式匹配、代数数据类型）也使Java在表达某些逻辑时不够优雅。这些痛点促使部分团队尝试用 Kotlin 等 JVM 语言替换 Java，以期获得更简洁的语法和更少的冗余。

并发与性能困境

高并发一直是 Java 的强项，但实现方式却日益受到挑战。传统 Java 使用操作系统线程实现并发，每个线程都对应一定的内存和调度开销，在大规模场景下显得“沉重”。为绕过这个瓶颈，过去几年兴起了基于 Reactive 异步编程的微服务框架，通过单线程事件循环避免线程阻塞。然而异步风格代码复杂度高、调试困难，让许多工程师“叫苦不迭”。好消息是，JDK 19/20 引入了虚拟线程（Project Loom）并在 JDK 21 成为正式特性。虚拟线程是由 JVM 管理的超轻量线程，实现了 Go 协程式的并发模型。这意味着开发者可以用以往同步阻塞的简单代码，实现过去需要复杂回调/响应式才能处理的高并发任务。正如 Java 架构师 Brian Goetz 所言：Loom 的出现有望“一举终结Reactive编程的必要”——因为过去Reactive是为解决线程不足的权宜之计。虚拟线程让我们能够创建成千上万个并发任务而不必担心线程耗尽，大幅降低了编写和维护高并发代码的心智负担。然而，新事物也伴随不确定性：老项目若迁移到虚拟线程模型，需要评估线程本地变量、同步机制等是否还能正常工作；调优方式也与传统线程有所不同。目前虚拟线程虽强大，但毕竟是新特性，在大型生产环境中的考验还不充分。Java 老兵们既期待它带来性能飞跃，也需要保持一份观望和谨慎。

GraalVM 与原生执行

为了解决启动慢、内存高的问题，Java 社区近年另一“大招”是 GraalVM 原生镜像。通过提前编译(AOT)，可以将 Java 应用直接打包成本地可执行文件，启动时间和内存占用都有数量级的优化。这项技术被视为让 Java 重返边缘计算和 Serverless 舞台的希望：原生镜像下，一个 Spring Boot 微服务的“Hello World”容器镜像可小到 ~几十MB；运行时不需要JVM，冷启动延迟大幅降低。实际测试中，采用 GraalVM 原生镜像的 Java 服务在某些基准下性能甚至超越 Go：平均延迟仅0.25毫秒，每秒处理事务达到82426次，吞吐率是 Go 实现的两倍多！这种结果令人振奋，仿佛看到了 Java 打了一场漂亮的翻身仗。

然而，理想很丰满，现实有时比较骨感。将复杂应用迁移到 GraalVM 原生镜像并非易事。例如，反射、动态代理等机制需要额外配置支持，许多成熟库在AOT编译下可能行为异常。构建原生镜像的过程也比较繁琐，往往需要调整代码、引入特定插件，并忍受较长的编译时间。调试诊断也更具挑战——原生应用无法使用 JVM 的丰富调试工具，需要新的手段排查问题。此外，引入 GraalVM 还意味着团队需要掌握一套新的知识体系。在的总结中作者就指出：“将 Spring Boot 应用打包为 Native 镜像并非没有挑战”，直接迁移复杂项目可能遇到种种坑，需要开发者充分评估和测试。因此，GraalVM 不是万能灵药，而是有门槛的新武器：用得好，Java 如虎添翼；用不好，反而可能引入新的不稳定因素。

综上，资深 Java 开发者面对的不是“Java 不行了”，而是如何让 Java 行得更轻、更快、更优雅。JVM 社区显然没有躺在功劳簿上吃老本，而是在微服务、云原生时代积极求变。从 Spring Boot 3 对原生镜像的支持，到 JDK 连续的功能升级（如Records、Pattern Matching等），Java 正在努力破除“笨重”的刻板印象。老兵们需要做的，是与时俱进地拥抱这些变化，用新工具、新思路来武装自己的Java技能库。

用舍之道：哪些场景放弃 Java，哪些场景坚持 Java？

技术选型从来都不是非黑即白，对于 Java 的去留更是如此。究竟在哪些业务场景下应该考虑放弃 Java？哪些场景下 Java 仍是首选？结合真实案例和趋势，我们可以做出以下判断：

场景一：边缘计算与Serverless – 谨慎使用 Java。

对于运行环境受限、对启动延迟敏感的场景，选择 Java 需要非常慎重。典型如物联网设备、边缘网关、函数计算等，这些环境往往内存有限且要求冷启动极快。在这些场合，运行一个庞大的 JVM 显然不如直接使用原生语言（C/C++、Rust）或轻量脚本语言（JavaScript、Python）来得高效。过去不少团队在实现事件驱动的小型服务时，就倾向于用 Node.js 或 Python 编写——不是因为Java不能实现功能，而是因为Java在每次调用都要“热身”的开销让人难以忍受。虽然有 GraalVM Native Image 可以大幅优化，但对小型团队而言，引入它的复杂度可能得不偿失。因此，对于边缘和无服务函数等应用，除非有充足理由和相应优化手段，否则倾向于选择更轻便的技术栈。当然，规则也非绝对：如果业务逻辑需要调用大量现有的 Java 类库（例如进行某种算法运算，而相关库只有Java实现），那么即便在 Serverless 环境下通过原生镜像等方式使用 Java 也是可以考虑的。总的来说，在这些场景，“能不用Java就不用”是较为实际的指导原则。

场景二：高性能微服务 – 视情况取舍

在互联网分布式系统中，每种语言都有用武之地。如果团队主要目标是极致的性能和资源利用率，并且成员对 Go/Rust 等语言驾轻就熟，那么把部分微服务用新语言实现未尝不可。例如某些网关服务、实时通信服务，行业里确有用 Rust 或 Go 重写后延迟降低、内存减半的成功案例。特别是低延迟、高并发的基础设施组件（消息队列、代理服务器等），很多开源项目早就避开 Java 转投 Go/Rust 怀抱，这是技术基因所致（Java 更擅长业务逻辑，系统编程领域C系语言传统更强）。但是，对于业务逻辑复杂的微服务，Java 仍然具有难以替代的优势：强大的生态提供了各种中间件客户端、成熟的 ORM 和事务框架、安全完备的验证和监控工具等等。这些“全家桶”式的支持使Java在开发业务系统时如鱼得水，大大减少了造轮子的成本。如果纯粹为了追新把此类服务改用另一种语言，可能会发现需要重建许多Java自带的轮子，得不偿失。因此，我们的立场是：对性能极限有追求的核心组件，可以考虑非Java实现以挖掘潜力；但大多数微服务尤其是业务导向的微服务，Java 依然是稳妥且高效的选择。况且随着Quarkus、Micronaut等专为云环境优化的Java框架出现，以及JVM自身的持续优化，Java 微服务的“笨重”正在被削平。正如某次测试所示，在较大的机器上，Java 的吞吐甚至可与 Go 持平甚至略胜一筹——只要用对了方式，Java 完全能胜任高性能微服务。

场景三：大型核心系统 – 坚定拥抱 Java

对于那些复杂度高、生命周期长、需要强一致性和可靠性的核心业务，Java 无疑仍是值得长期信赖的编程语言。例如银行的核心账务系统、航空公司的订票系统、阿里的电商交易中台等，这些系统往往经历多年演化，业务规则繁多且严谨，需要大量业内验证过的中间件支撑。Java 的严格类型体系和成熟框架在这里如鱼得水。特别是在金融、政府等对稳定性要求极高的领域，“Java + 大型商用中间件”的组合几乎是默认标配。从技术债的角度考虑，这类系统虽然也面临老旧架构的问题，但重构时通常还是在 Java 体系内升级（比如从 Struts 升级到 Spring Boot，或引入分布式事务框架等），而不会轻易迁移到一门全新的语言上。这不仅因为重写成本高，更因为 Java 多年沉淀的安全性和可靠性难以替代。可以说，在复杂业务长跑中，Java 是一匹稳健的“长途马”，跑得也许不算最快，但足够稳当，生态中现成的工具能够覆盖方方面面，让架构师和开发者更安心。基于这些原因，我们坚定认为：在复杂业务和核心系统场景下，坚持使用 Java 是明智之举。即便引入新的技术插件，也是作为补充而非颠覆，比如用 Python 做小部分AI预测，再把结果喂给Java主系统等等。Java 老兵在这些战场上大可发挥深厚经验，将系统设计得健壮且易于维护，为业务保驾护航。

归纳来说，用舍有道，视需而定：Java 并非万能，同样也远未过时。关键在于根据项目需求选择最合适的工具。在前沿领域不妨多尝试新语言新架构，以保持竞争力；而在关系到企业命脉的长线工程上，Java 依然值得我们托付。

Java老兵的自我进化：坚守阵地or华丽转型？

面对风起云涌的技术浪潮，10年以上经验的 Java 老将们该何去何从？是固守舒适圈，还是勇敢拓展边界？以下几点建议或许对处在十字路口的你有所启发：

拥抱Java新特性，跟上生态演进

不要认为“学了十几年Java就没有新东西可学”。相反，Java生态在飞速更新，每年两个版本迭代。老兵们应该主动学习 JDK近几版的新功能（如Records、Sealed Class、Pattern Matching、虚拟线程等），这些特性能显著改善代码质量和性能，使你的技能焕发新生。例如，试着用 Loom 虚拟线程改造一个老的并发模块，体会一下开发模式的简化；或者研究 GraalVM 如何将现有服务无缝打包为原生镜像，了解其中的限制和调优手段。拥抱新技术不仅能提升生产力，也向团队展示了你与时俱进的技术热情。作为Java老兵，切忌固步自封——持续学习是对抗职业倦怠和时代冲击的最好武器。

拓展多元技能栈，成为“T型”人才

在保持Java优势的同时，建议横向拓展一到两门其它语言或领域技能。比如，可以尝试学习 Go 或 Python，用它们做些小项目，体会不同语言在思维模型上的差异。再比如，深入了解一下前端技术或移动开发，哪怕不做前端，也能与前端同事更高效协作。这种“T”字型的技能结构（既有一门精深的主力技术，又对相关技术有所涉猎）将使你在团队中更具价值。很多架构师在成为架构师前，都曾是精通数门语言、熟悉多种数据库和中间件的全能型工程师。对Java老兵来说，学习一门新语言还能帮助跳出现有思维框架，把新理念反哺到Java日常开发中。例如，借鉴函数式编程思想优化Java代码，或者用脚本语言编写自动化工具提升开发效率。多元化的技能还为你提供了职业备胎：万一某天真的不想写Java了，你在其他领域的积累也足以支撑转型，不至于手足无措。

深入业务和架构，提升不可替代性

随着工作年限增长，“懂业务、能设计”往往比单纯的编码能力更重要。Java老兵应该充分利用在一个行业浸润多年的经验，去深入理解业务领域的本质问题，把握业务发展方向。将业务洞察与技术方案相结合，主动参与系统架构设计和重大技术选型，这会让你成为团队中不可或缺的核心人物。很多时候，业务专家+技术专家的复合型人才，比仅仅精通某种语法的程序员更有竞争力。如果你已经是某核心系统的Owner，不妨尝试推进架构优化和性能提升项目，展示自己在宏观层面的掌控力。同时，培养自己的系统设计能力，多研究业界大型系统的架构案例，学习它们如何权衡取舍。当你能从容驾驭分布式事务、异地多活、CQRS 等架构模式时，你的价值早已超越“Java 工程师”的范畴，而成为真正的技术专家。这种升级，无论未来Java的热度如何，都能让你的职业生涯保持上升。

考虑转型技术管理或其他新领域

并非每个人都要永远写代码。工作十年以上后，你也可以根据兴趣转型，选择最适合自己的道路。如果你热衷带团队和项目把控，可以逐步走向技术管理岗位，担任Team Leader、技术经理甚至CTO，把多年经验用于培养新人和决策把关。很多Java老兵在这一阶段选择带领团队，既可传承自己的开发哲学，又能获得管理成就感。又或者，你对某些新兴领域情有独钟，例如人工智能、大数据、安全等，不妨利用业余时间学习相关知识，寻求内部调岗或外部机会。资深程序员转做产品经理、解决方案架构师的例子也屡见不鲜——只要有心，完全可以跳出演员阵容，转到幕后编剧或导演的位置上。当然，做出转型决定前需要评估清楚：你的核心竞争力是什么，新领域是否真心喜欢，从头开始是否有心理准备。转型不是逃避，而是为了更长远的发展。无论选择深耕Java栈还是开拓新跑道，持续的学习和热情都是关键驱动力。

最后

想对每一位焦虑中的Java老兵说：技术江湖瞬息万变，但真正的资深工程师价值从不局限于某种语法。Java 之父 James Gosling 曾打比方说：“Java就像一辆可靠的卡车”，或许它没有跑车那样光鲜，但能载着重载货物稳稳前行。这辆卡车如今也在不断改装升级，动力和油耗都在改进。我们作为司机，要做的不是弃车而逃，而是练就更高超的驾驶技巧，并且学会在不同道路上换合适的交通工具。坚守初心并不代表故步自封，拥抱变化也不意味着全盘否定过去。当我们既掌握了Java这门老牌利器，又勇于学习新招式、新套路，在变化的浪潮中依然能找到自己的方向和节奏。

10+年开发生涯沉淀下来的经验与智慧，是宝贵的财富。无论Java的流行曲线如何波动，真正优秀的工程师都会不断进化，拓展自己的边界。在这个过程中，我们既要有克制冷静的思考，看清技术演进的本质；也要保持对编程的热爱，不忘初心地享受技术创造的乐趣。愿每一位Java老兵都能在时代洪流中找到属于自己的位置：该出手时果断出手，该坚守时稳如磐石，在新的十年里续写属于你的传奇。

Java 和 JVM 自 JDK 8 至 21 的特性概览

Fri, 15 Mar 2024 16:48:40 +0000

引言

Java，这门自 1995 年诞生以来就广受欢迎的编程语言，以其跨平台的特性、强大的生态系统和稳定的性能表现，成为了软件开发领域的一个重要里程碑。随着时间的推移，Java 不断演进，以适应新的技术挑战和市场需求。自 JDK 8 发布以来，Java 平台经历了一系列重大的更新，每一次更新都为开发者带来了新的工具和能力，以构建更加高效、安全和现代化的应用程序。

Java 的历史和发展

从最初的 Java 1.0 到现在的 JDK 21，Java 语言和其运行环境 JVM（Java 虚拟机）已经走过了一段漫长的道路。Java 1.0 引入了最基本的面向对象编程概念，而随后的版本则不断扩展其功能，包括引入了泛型、注解、枚举类型等。JDK 5 和 JDK 8 是两个特别重要的版本，它们分别引入了自动装箱/拆箱和 Lambda 表达式，极大地简化了 Java 代码的编写。

JDK 8 至 21 的重要性

JDK 8 是一个转折点，它标志着 Java 进入了一个新的时代。这个版本引入了函数式编程的特性，使得 Java 开发者能够以更加声明式的方式编写并发和事件驱动的代码。随后的版本，如 JDK 11、JDK 14 和 JDK 16，都在不断地扩展和深化这些特性，同时引入了许多其他的改进，如模块系统、记录类和模式匹配等。JDK 21 继续这一趋势，带来了更多的语言和 API 改进，以及对 JVM 的优化。

本文的目的和结构

本文旨在为 Java 开发者提供一个全面的概览，介绍自 JDK 8 至 JDK 21 期间引入的所有重要特性。我们将按照特性的类型和用途进行分类，包括新语言特性、新 APIs、性能改进、安全增强、启动和打包工具的更新、Javadoc 和字节码的变更，以及新支持的平台和版本方案。此外，我们还将讨论那些已被弃用或移除的特性，以及这些变化对 Java 生态系统的长期影响。

通过本文，您将能够获得对 Java 最新特性的深入理解，无论您是 Java 新手还是经验丰富的开发者，都能从中获得宝贵的知识和见解。接下来，让我们开始探索 Java 自 JDK 8 以来的演变之旅。

新语言特性详细解析

模式匹配（Pattern Matching）

模式匹配是 Java 语言中一项革命性的新特性，它首次作为预览特性在 JDK 12 中引入，并在 JDK 16 中正式成为 Java 语言的一部分。这一特性借鉴了函数式编程语言中的模式匹配概念，允许开发者以一种更加简洁和表达性强的方式来检查和处理不同类型的数据。

模式匹配的引入背景

在模式匹配出现之前，Java 开发者通常使用if-else语句或者instanceof检查来处理不同类型的对象，这不仅使得代码变得冗长，而且可读性也较差。模式匹配的引入，为 Java 提供了一种新的、更加直观的方式来处理这些情况，特别是在处理复杂的对象结构时，它能够显著提高代码的清晰度和维护性。

模式匹配的具体用法

模式匹配在 Java 中的实现主要通过instanceof和switch表达式来完成。下面是一个使用模式匹配的简单例子：

 1Object obj = getSomeObject();
 2
 3if (obj instanceof String s) {
 4 // 在这里可以直接使用变量 s，无需进行显式的类型转换
 5 System.out.println("String length is " + s.length());
 6} else if (obj instanceof Integer i) {
 7 // 对于整型对象 i，可以直接进行数学运算
 8 System.out.println("Integer value is " + i * 2);
 9} else {
10 System.out.println("Unknown object type");
11}

在上面的代码中，instanceof关键字后面紧跟着的是一个模式变量s或i，当obj的类型与模式匹配时，变量会被自动赋值，无需显式的类型转换。这种写法不仅简化了代码，还减少了出错的可能性。

模式匹配的优势和实例分析

模式匹配的优势在于它的简洁性和表达性。它允许开发者用更少的代码来表达更复杂的意思，并且使得代码的意图更加明确。此外，模式匹配还支持更复杂的结构，如嵌套的模式和守卫条件，这在处理复杂的数据结构时非常有用。

让我们来看一个更复杂的例子，其中使用了守卫条件和嵌套模式：

 1List<? extends Number> numbers = getNumbers();
 2
 3for (Number number : numbers) {
 4 var absNumber = switch (number) {
 5 case Integer i when i < 0 -> Math.abs(i);
 6 case Integer i -> i;
 7 case Double d -> Math.round(d);
 8 default -> throw new IllegalArgumentException("Unsupported number type");
 9 };
10 System.out.println(absNumber);
11}

在这个例子中，我们使用了一个switch表达式来进行模式匹配。对于每种情况，我们都定义了一个模式，并在需要时使用守卫条件来进一步细化匹配的规则。这样，我们就能够根据不同的输入执行不同的操作，并且代码的结构依然保持清晰和简洁。

总的来说，模式匹配为 Java 带来了一种新的、强大的数据处理方式，它不仅提高了代码的可读性和可维护性，而且还使得 Java 语言更加现代化，更接近于其他流行的函数式编程语言。随着 Java 语言的不断发展，我们可以期待模式匹配在未来的 Java 版本中将发挥更加重要的作用。

未命名变量和未命名模式

在 Java 14 中，作为预览特性引入的未命名变量（也称为“var”类型）和未命名模式（也称为“模式变量”），为 Java 编程带来了新的表达性和灵活性。这些特性旨在简化代码，特别是在处理复杂的数据结构和流操作时，它们允许开发者忽略不需要的值，并提供了一种新的数据解构方式。

未命名变量的概念

未命名变量是 Java 中一种新的局部变量声明方式，它允许开发者声明一个变量而不需要预先指定其类型。这种变量的类型将由编译器根据赋值表达式自动推断。未命名变量通常与->操作符一起使用，后者在switch表达式中用于提供更复杂的逻辑分支。

未命名变量的使用场景

未命名变量特别适用于以下场景：

当你只关心一个表达式的结果，而不打算在后续代码中使用变量时。
当你需要从方法返回值中提取信息，但又不想显式声明所有组成部分时。
在流操作中，当你需要处理流中的元素，但不需要存储任何中间变量时。

未命名模式的概念

未命名模式是模式匹配的一个扩展，它允许开发者在instanceof、case标签或catch块中声明一个模式变量，而不是一个具名变量。这在使用模式匹配解构复杂类型时非常有用，尤其是当你只需要访问类型的一部分数据时。

未命名模式的使用场景

未命名模式特别适用于以下场景：

当你使用模式匹配来检查对象的类型，但不需要访问对象的具体实例时。
在解构复杂对象时，当你只需要对象的某些部分，而不是整个对象时。

代码示例和实际应用

下面是一个使用未命名变量和未命名模式的示例：

 1// 使用未命名变量处理 Optional
 2Optional<String> optStr = Optional.of("Hello");
 3var str = optStr.orElse("Default");
 4System.out.println(str); // 输出 "Hello"
 5
 6// 使用未命名变量在 try-catch 中忽略不需要的异常
 7try {
 8 // 可能会抛出 CheckedException 的代码
 9} catch (Exception _) {
10 // 忽略异常，不进行处理
11}
12
13// 使用未命名模式在 switch 表达式中解构对象
14record Point(int x, int y) {}
15
16Point point = new Point(1, 2);
17switch (point) {
18 case Point(x) -> {
19 // 只关心 x 的值，y 的值被忽略
20 System.out.println("X coordinate is " + x);
21 }
22}

在上述代码中，我们看到了未命名变量和未命名模式如何在不同场景下简化代码。未命名变量使得我们可以避免声明不必要的变量，而未命名模式则让我们能够更加灵活地处理复杂的数据结构。

总的来说，未命名变量和未命名模式是 Java 语言中两项非常有用的新特性，它们通过减少代码冗余和提高表达性，使得 Java 代码更加简洁和易于理解。随着这些特性在未来的 Java 版本中逐渐成熟和稳定，我们可以预见它们将在 Java 编程实践中发挥越来越重要的作用。

封闭类和记录类

随着 Java 语言不断发展，为了更好地支持函数式编程和数据建模，JDK 16 引入了两种新的类类型：封闭类（Sealed Classes）和记录类（Record Classes）。这些新特性旨在提供更丰富的类型安全保障和更简洁的代码表达，特别是在创建数据传输对象（DTOs）和限制继承结构时。

封闭类

封闭类是一种特殊的类，它限制了哪些其他类可以继承它。这一特性对于那些希望限制子类数量或者想要精确控制继承树的开发者来说非常有用。在 Java 中，封闭类通过sealed关键字进行声明，并且可以指定一个允许的子类列表。

封闭类的概念

封闭类的概念是为了在 Java 中引入更多的类型安全性和清晰性。它们允许开发者定义一个基类，同时限制哪些类可以扩展这个基类。这样做的好处是可以防止其他开发者创建不必要的或者不安全的子类，从而保护 API 的稳定性和可预测性。

封闭类的使用场景

封闭类适用于以下场景：

当你想要创建一个基类，但只想允许特定的子类时。
当你想要限制类的继承结构，以避免类的滥用或错误扩展时。

封闭类示例

 1public abstract sealed class Shape permits Circle, Rectangle, Triangle {
 2 // 封闭类的基类代码
 3}
 4
 5final class Circle extends Shape {
 6 // 圆形的具体实现
 7}
 8
 9final class Rectangle extends Shape {
10 // 矩形的具体实现
11}
12
13// 以下代码将无法编译，因为 Square 没有在 Shape 的 permits 子句中声明
14// final class Square extends Shape {
15// // 正方形的具体实现
16// }

在这个例子中，Shape是一个封闭类，它明确指定了哪些类可以作为其子类。这确保了Shape的继承结构是受控的，并且防止了任何未授权的扩展。

记录类

记录类是一种特殊的类，它主要用于创建不可变的数据传输对象（DTOs）。记录类的语法比传统的类更加简洁，它自动为所有字段生成构造函数、equals、hashCode和toString方法。

记录类的概念

记录类的概念是为了简化 Java 中不可变数据结构的创建。它们提供了一种快速定义类的方式，而无需编写大量的样板代码。记录类是不可变的，这意味着一旦创建，其状态就不能改变，这有助于避免并发问题和不必要的错误。

记录类的使用场景

记录类适用于以下场景：

当你需要创建一个简单的数据结构，用于存储一组固定的值时。
当你希望确保数据的不可变性，以提高代码的安全性和可维护性时。

记录类示例

1record Point(int x, int y) {}
2
3public class Example {
4 public static void main(String[] args) {
5 Point point = new Point(10, 20);
6 System.out.println(point); // 输出 "Point[x=10, y=20]"
7 }
8}

在这个例子中，我们定义了一个名为Point的记录类，它有两个字段：x和y。创建记录类时，Java 自动为我们生成了构造函数和toString方法，使得代码非常简洁。此外，由于记录类是不可变的，我们可以安全地在多线程环境中共享Point实例，而不必担心它们的内部状态会被改变。

总的来说，封闭类和记录类为 Java 开发者提供了更多的选择，以适应不同的编程场景。封闭类通过限制继承结构来增强类型安全性，而记录类则通过简化数据结构的创建来提高开发效率。这些新特性的引入，进一步丰富了 Java 语言的功能，使其更加现代化和高效。随着这些特性在未来的 Java 版本中得到进一步的发展和完善，我们有理由相信它们将成为 Java 编程中不可或缺的一部分。

其他重要语言特性

除了前面提到的模式匹配、未命名变量和未命名模式等特性，Java 在 JDK 8 至 21 的版本中还引入了许多其他重要的语言特性。这些特性涵盖了从代码简化到性能优化的各个方面，极大地提升了 Java 编程的便捷性和表达能力。接下来，我们将详细探讨其中的一些关键特性。

String 模板

Java 16 引入了字符串模板（String Templates），这是一种新的字符串字面量，它允许开发者以一种更加简洁和安全的方式来创建格式化的字符串。字符串模板通过str前缀定义，并支持多行字符串和插值表达式。

字符串模板的用法

字符串模板提供了一种新的字符串创建方式，它结合了字符串字面量的简洁性和String.format方法的格式化能力。开发者可以在模板中直接插入变量和表达式，而不需要额外的格式化步骤。

1String name = "World";
2int value = 42;
3
4// 使用字符串模板创建格式化的字符串
5String message = `Hello, ${name}! The value is ${value * 2}.`;
6System.out.println(message); // 输出 "Hello, World! The value is 84."

在这个例子中，我们使用${}来插入变量和表达式的值，这使得字符串的创建和格式化过程变得更加直观和方便。

字符串模板的优势

字符串模板的主要优势在于它的简洁性和易读性。它减少了字符串拼接和格式化的复杂性，使得代码更加清晰和易于维护。此外，由于字符串模板是编译时常量，它们在某些情况下还能提供更好的性能。

文本块

文本块（Text Blocks）是 Java 13 中引入的预览特性，它允许开发者以多行字符串的形式编写代码，而无需使用传统的转义序列。文本块通过三个双引号（"""）定义，并且保持了字符串字面量的原始格式。

文本块的用法

文本块特别适用于创建多行的字符串，例如在编写正则表达式、HTML 模板或 SQL 查询时。

 1String html = """
 2 <html>
 3 <body>
 4 <h1>Title</h1>
 5 <p>Paragraph with line breaks
 6 and multiple lines.</p>
 7 </body>
 8 </html>
 9 """;
10System.out.println(html);

在这个例子中，我们定义了一个包含 HTML 内容的文本块，所有的换行符和空格都被保留，而不需要使用传统的\n转义序列。

文本块的优势

文本块的主要优势在于它们的易读性和编写效率。它们使得多行字符串的创建变得非常简单，同时避免了转义序列带来的混乱和错误。此外，文本块还支持跨多行的字符串连接，进一步提高了代码的灵活性。

Helpful NullPointerExceptions

Java 14 中引入了更加有用的NullPointerException，它提供了关于哪个变量为null的详细信息。这一特性通过-XX:+ShowCodeDetailsInExceptionMessages JVM 选项启用，它使得空指针异常更加易于调试。

Helpful NullPointerExceptions 的用法

当程序抛出NullPointerException时，JVM 会提供更多的堆栈跟踪信息，包括导致异常的变量名和代码位置。

1String message = null;
2int length = message.length(); // 这里会抛出 NullPointerException

在这个例子中，如果启用了详细异常信息，我们将会得到类似于以下的输出：

1Exception in thread "main" java.lang.NullPointerException:
2 Cannot read field "length" because "message" is null
3 at com.example.Main.main(Main.java:10)

Helpful NullPointerExceptions 的优势

这一特性的主要优势在于它提供了更多的调试信息，使得开发者能够快速定位和修复空指针异常。这种增强的异常信息极大地提高了 Java 程序的可维护性和稳定性。

Switch 表达式

Switch 表达式是 Java 12 中引入的预览特性，它为switch语句提供了一种更加简洁和灵活的替代方案。Switch 表达式使用yield关键字返回值，并且可以与模式匹配结合使用。

Switch 表达式的用法

Switch 表达式可以替代传统的switch语句，特别是在处理枚举类型和表达式时。

 1Day day = Day.MONDAY;
 2int numLetters = switch (day) {
 3 case MONDAY, FRIDAY, SUNDAY -> 6;
 4 case TUESDAY -> 7;
 5 default -> {
 6 String s = day.toString();
 7 int result = s.length();
 8 yield result;
 9 }
10};
11System.out.println(numLetters); // 输出 "5"

在这个例子中，我们使用了一个switch表达式来根据day的值计算字母的数量。与传统的switch语句相比，Switch 表达式提供了一种更加简洁和函数式的方法来处理条件逻辑。

Switch 表达式的优势

Switch 表达式的主要优势在于它的简洁性和表达性。它减少了模板代码的数量，并且使得条件逻辑的编写更加直观和易于理解。此外，Switch 表达式还支持与模式匹配的结合使用，进一步提高了代码的灵活性和可读性。

总结

Java 语言在 JDK 8 至 21 的版本中引入了许多重要的新特性，这些特性不仅提高了代码的编写效率，还增强了程序的性能和安全性。从字符串模板和文本块的引入，到 Helpful NullPointerExceptions 和 Switch 表达式的改进，Java 不断地在进化，以满足现代软件开发的需求。随着这些特性在未来的 Java 版本中得到进一步的发展和完善，我们有理由相信它们将成为 Java 编程中不可或缺的一部分。

新 APIs 的探索

Java 平台的不断更新带来了丰富的新 APIs，这些 APIs 旨在提高开发者的生产力，简化复杂任务的处理，并增强 Java 在各个领域的应用能力。从集合操作的增强到数学函数的扩展，新 APIs 为 Java 开发者提供了更多的工具来构建高效、健壮的应用程序。

集合和数学函数 API

集合 API 是 Java 中使用最广泛的 API 之一，它提供了一系列的数据结构和算法来存储和操作对象集合。数学函数 API 则为数值计算提供了支持，包括随机数生成、复数操作等。在 JDK 8 至 21 的更新中，这两个领域的 API 得到了显著的扩展和改进。

新增集合 API 的特性和用法

在 JDK 8 中引入的 Stream API 彻底改变了 Java 中集合的处理方式，而在后续的版本中，这一 API 继续得到了增强。例如，JDK 16 引入了toList()方法，它简化了从 Stream 到 List 的转换过程，使得开发者可以更方便地进行数据收集。

1List<String> list = Stream.of("apple", "banana", "cherry")
2 .collect(Collectors.toList());

此外，JDK 16 还引入了Map.of和Set.of等静态工厂方法，它们用于创建不可变的 Map 和 Set 实例，这不仅提高了代码的可读性，还减少了创建空集合时的内存消耗。

数学函数 API 的增强

Java 8 引入了java.util.function包，其中包括了一系列的函数式接口，为 Java 带来了函数式编程的特性。在此基础上，后续的 Java 版本继续增强数学函数 API。例如，JDK 11 中引入了Math.log10方法，用于计算一个数的以 10 为底的对数。

1double result = Math.log10(100); // 结果为 2.0

JDK 16 进一步扩展了数学函数库，包括对BigDecimal的改进，使得大数运算更加精确和高效。此外，JDK 16 还引入了Random和ThreadLocalRandom的新的 APIs，提供了更多的随机数生成选项。

实际应用

新的集合和数学函数 API 在实际应用中极大地提高了开发效率。例如，在处理大量数据时，Stream API 的链式操作和新的集合工厂方法使得代码更加简洁和易于理解。在科学计算和金融分析领域，增强的数学函数 API 提供了更精确的数值计算能力，帮助开发者实现了更复杂的数学模型。

结论

集合和数学函数 API 的持续更新和改进，反映了 Java 平台对开发者需求的响应和对现代编程挑战的适应。这些新 APIs 不仅提高了 Java 语言的表达能力，还为解决复杂问题提供了更多的工具和选项。随着 Java 平台的不断发展，我们可以期待未来会有更多的创新和改进，进一步丰富 Java 生态系统。

其他重要 API 更新

随着 Java 平台的不断演进，除了集合和数学函数 API 之外，还有许多其他的 API 得到了更新和增强，以满足现代应用程序的需求。这些更新涵盖了文件和 IO 操作、网络编程、时间日期处理等多个方面，为 Java 开发者提供了更加强大和灵活的工具集。

文件和 IO 操作的改进

Java 的文件和 IO 操作 API 在 JDK 8 至 21 期间经历了显著的改进。例如，JDK 11 引入了Files.walk方法，它提供了一种更加简洁的方式来遍历文件树。此外，JDK 14 增加了Files.mismatch方法，用于比较两个文件的内容差异，这对于文件校验和数据恢复等场景非常有用。

1Path startPath = Paths.get("/path/to/start/directory");
2try (Stream<Path> stream = Files.walk(startPath)) {
3 stream.filter(Files::isRegularFile)
4 .forEach(path -> System.out.println(path));
5}

网络编程的新特性

在网络编程方面，JDK 9 引入了java.net.http.HttpClient，这是一个全新的、非阻塞的 HTTP 客户端 API，它提供了更加简洁和强大的 HTTP 请求处理能力。这个新的 HTTP 客户端支持 HTTP/2 协议，并且提供了 WebSocket 支持，使得 Java 在处理现代网络应用时更加高效。

 1HttpClient client = HttpClient.newBuilder()
 2 .version(HttpClient.Version.HTTP_2)
 3 .build();
 4
 5HttpRequest request = HttpRequest.newBuilder()
 6 .uri(URI.create("https://example.com"))
 7 .GET()
 8 .build();
 9
10client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
11 .thenApply(HttpResponse::body)
12 .thenAccept(System.out::println)
13 .join();

时间和日期 API 的更新

Java 8 引入了java.time包，这个包提供了一套全新的日期和时间 API，它解决了旧版java.util.Date类中存在的问题，并提供了更好的时间日期处理能力。在后续的版本中，这个 API 继续得到了增强。例如，JDK 12 增加了LocalDate的ofEpochDay方法，它允许开发者直接从天数创建日期对象，而不需要通过ChronoLocalDate。

1LocalDate date = LocalDate.ofEpochDay(10000); // 创建一个特定的日期

结论

这些 API 的更新和增强不仅提高了 Java 语言的功能，还使得 Java 在处理文件操作、网络通信和时间日期处理等任务时更加高效和便捷。随着 Java 平台的不断发展，我们可以期待未来会有更多的创新和改进，进一步丰富 Java 生态系统，帮助开发者构建更加健壮和高效的应用程序。

性能改进的深入分析

Java 平台的性能改进一直是开发者社区关注的焦点。从 JDK 8 至 21，Oracle 和 OpenJDK 社区持续致力于优化 Java 虚拟机（JVM）和 Java 语言的性能，以满足日益增长的应用程序性能需求。这些改进包括内存管理、垃圾回收、即时编译器（JIT）优化、启动时间缩短等方面。

内存管理和垃圾回收

内存管理和垃圾回收是 Java 性能改进中的关键领域。有效的内存管理确保了应用程序能够高效地使用内存资源，而垃圾回收机制则负责回收不再使用的对象，防止内存泄漏。

弹性元空间

在 JDK 8 中，元空间（Metaspace）被引入作为PermGen（永久代）的替代品，用于存储类的元数据。与PermGen不同，元空间在本地内存中分配，理论上不受堆大小的限制。然而，随着应用程序规模的增长，元空间的内存使用也成为一个关注点。为了解决这一问题，JDK 16 引入了弹性元空间，它允许元空间的内存使用更加动态和可控，减少了对系统内存的占用。

G1 垃圾回收器

G1（Garbage-First）垃圾回收器自 JDK 9 起成为默认的垃圾回收器。G1 是一种并行、增量、并发的垃圾回收器，旨在提供可预测的停顿时间模型，同时保持高吞吐量。G1 通过将堆划分为多个区域（Region）并跟踪每个区域的垃圾回收优先级来工作。它定期执行小型的回收任务，以减少应用程序的停顿时间。

ZGC 和 Shenandoah 垃圾回收器

ZGC（Z Garbage Collector）和 Shenandoah 垃圾回收器是两个实验性的垃圾回收器，它们在 JDK 11 及后续版本中作为实验特性提供。这两种回收器都旨在为大型堆（多达 4TB）提供低延迟的垃圾回收。ZGC 通过染色指针技术和并发标记周期来实现低延迟，而 Shenandoah 则通过并发标记和压缩来减少停顿时间。

NUMA-Aware 内存分配

随着多核处理器的普及，非一致性内存访问（NUMA）架构变得越来越常见。JDK 14 引入了 NUMA-Aware 内存分配，它允许 JVM 根据处理器的 NUMA 拓扑结构来优化内存分配，从而提高内存访问效率和整体性能。

并行 Full GC 的改进

JDK 10 中引入了并行 Full GC，它通过在 Full GC 过程中使用多个 GC 线程来提高垃圾回收的效率。这种改进显著减少了 Full GC 的停顿时间，特别是在处理大型堆或长时间运行的应用程序时。

总结

内存管理和垃圾回收的性能改进对于 Java 应用程序的稳定性和响应性至关重要。通过引入新的垃圾回收器、优化内存分配策略和提供更灵活的垃圾回收选项，Java 平台能够更好地适应不同类型和规模的应用程序。随着 Java 技术的不断发展，我们可以期待未来会有更多的内存管理和垃圾回收方面的创新，以满足日益增长的性能需求。

JIT 编译器和运行时性能

Java 虚拟机（JVM）中的即时编译器（JIT）是 Java 性能优化的关键组件。JIT 编译器负责将字节码动态编译为本地机器码，以提高执行效率。随着 JDK 版本的迭代，JIT 编译器也在不断进化，引入了新的优化技术和特性，以提升运行时性能和编译效率。

JIT 编译器的优化

JIT 编译器的优化主要集中在减少编译时间和提高编译代码的质量上。这些优化包括更智能的编译触发策略、改进的热点检测算法、以及针对性能瓶颈的特定优化。

分层编译：JDK 11 引入了分层编译的概念，它允许 JVM 在不同的编译层次之间进行选择，以平衡编译时间和运行时性能。例如，JVM 可以使用快速的低层次编译器来编译不经常执行的代码，而将更高层次的优化编译器用于热点代码。
编译器探测：JDK 12 及后续版本中，编译器探测（也称为编译器引导）被引入，它允许 JVM 在运行时收集关于代码执行的更多信息，并使用这些信息来指导编译优化决策。
代码缓存和重用：JVM 通过缓存编译后的代码来避免重复编译相同的代码，这在处理具有多个版本的应用程序时尤其有用。此外，JVM 还可以在类加载器之间重用编译后的代码，减少了编译开销。

运行时性能监控和诊断工具

为了帮助开发者更好地理解和优化 Java 应用程序的性能，JVM 提供了一系列的运行时监控和诊断工具。

Java Mission Control（JMC）：JMC 是一个强大的性能分析工具，它可以收集和分析 JVM 的运行时信息，包括线程状态、内存使用情况和垃圾回收日志。
Flight Recorder：Flight Recorder 是 JDK 11 中引入的一个轻量级事件记录框架，它可以在后台记录 JVM 的详细运行时事件，而对性能的影响非常小。开发者可以在需要时启动详细的事件记录，以进行性能分析。
JVM 统计信息 API：JVM 统计信息 API（JVMS）提供了一组接口，允许应用程序查询 JVM 的运行时统计信息，如类加载次数、垃圾回收次数等。

启动时间缩短

启动时间是 Java 应用程序性能的一个重要方面，特别是在需要快速响应的场景中。从 JDK 9 开始，Oracle 致力于减少 JVM 的启动时间，通过优化类加载和初始化过程，以及减少启动时的 JVM 内部处理。

应用类数据共享（Application Class-Data Sharing, ACDS）

ACDS 是 JDK 11 中引入的一个特性，它允许 JVM 在多个 Java 进程之间共享已编译的类数据。通过这种方式，JVM 可以减少启动时的编译工作量，从而缩短启动时间。

快速应用启动（Fast Application Startup, FAS）

FAS 是 JDK 11 中的一个项目，旨在通过减少类元数据的加载和优化 JVM 的内存布局来加快应用启动速度。虽然 FAS 项目的一些目标在 JDK 11 中并未完全实现，但它为后续版本的启动时间优化奠定了基础。

总结

JIT 编译器和运行时性能的优化是 Java 平台持续进步的重要组成部分。通过引入新的编译策略、监控工具和启动时间缩短技术，Java 能够为开发者提供更加高效和稳定的运行时环境。随着 Java 技术的不断发展，我们可以期待未来会有更多的性能优化特性，以满足日益增长的性能需求和挑战。

安全改进的全面审视

Java 平台一直致力于提供安全可靠的编程环境，以保护用户和企业的数据安全。从 JDK 8 至 21，Java 的安全模型经历了一系列的改进，旨在提高安全性，防范新出现的威胁，并保持与现代安全标准和实践的一致性。

加密和认证 API

加密和认证 API 是 Java 安全体系中的重要组成部分，它们为 Java 应用程序提供了数据加密、解密、签名和验证等安全操作的能力。随着技术的发展，Java 对这些 API 进行了更新和增强，以支持新的加密算法和满足更高的安全标准。

新的加密算法和 API

AES-GCM：JDK 11 中引入了对 AES-GCM（Galois/Counter Mode）的支持，这是一种用于块加密算法的高效和安全的模式，特别适合处理网络通信中的数据加密和认证。
TLS 1.3：Java 11 开始支持 TLS 1.3，这是传输层安全协议的最新版本，提供了更强大的加密算法、更少的握手轮次和更好的隐私保护。
SHA-3：随着安全需求的不断演进，JDK 9 引入了对 SHA-3（Secure Hash Algorithm 3）的支持，这是新一代的哈希函数，旨在替代原有的 SHA-2。

密钥管理和证书处理

密钥封装机制（KEM）API：JDK 21 中引入了密钥封装机制（Key Encapsulation Mechanisms）API，它提供了一种封装和解封装密钥的方法，这对于密钥交换和密钥管理非常重要。
证书透明度（Certificate Transparency, CT）：Java 11 开始支持证书透明度 API，这是一种公开的、可审计的证书日志系统，用于监控和验证 SSL/TLS 证书的颁发。

安全随机数生成器

DRBG（Deterministic Random Bit Generator）：Java 11 中引入了基于 NIST SP 800-90A 标准的确定性随机比特生成器（DRBG），它提供了可预测的、高质量的随机数，适用于安全敏感的应用场景。

弃用和移除不安全的 API

不安全的加密算法：随着安全意识的提高，Java 社区逐渐弃用了一些被认为是不安全的加密算法，如 DES 和 SHA-1，并推荐使用更安全的替代品。
不安全的 SSL/TLS 协议：Java 11 开始弃用 SSL 和早期版本的 TLS 协议，鼓励开发者使用 TLS 1.3 或更高版本，以确保通信的安全性。

总结

加密和认证 API 的更新和增强是 Java 安全改进中的重要一环。通过引入新的加密算法、改进密钥管理和证书处理，以及提供更强大的随机数生成器，Java 平台能够更好地保护用户的数据安全和隐私。同时，通过弃用和移除不安全的 API，Java 鼓励开发者采用更加安全和现代的编程实践。随着 Java 技术的不断发展，我们可以期待未来会有更多的安全特性被引入，以应对不断变化的安全威胁和挑战。

安全管理器和权限控制

在 Java 安全模型中，安全管理器（Security Manager）和权限控制（Access Control）扮演着至关重要的角色。它们确保了 Java 应用程序在一个受控的环境中运行，防止恶意代码访问敏感资源或执行危险操作。随着 Java 版本的更新，这些安全机制也在不断地得到加强和优化。

安全管理器

安全管理器是 Java 安全架构的核心组件，它负责执行安全策略，控制对系统资源的访问。通过安全管理器，Java 平台能够实施一系列的安全限制，如文件系统访问、网络连接和加密算法的使用。

策略文件和权限：安全管理器通常与策略文件（如java.security）一起工作，这些文件定义了代码可以请求的权限。开发者可以根据需要自定义策略文件，以放宽或限制特定的权限。
安全管理器的配置：在 JDK 9 中，安全管理器的配置方式发生了变化。java.security文件不再位于 JRE 的lib/security目录下，而是被jdk.security文件所取代，这使得安全管理器的配置更加模块化和灵活。

权限控制

Java 的权限控制机制允许开发者精确地控制代码的访问权限。这些权限可以是文件系统访问、网络操作、安全属性修改等。

java.security.Permissions：这是一个用于定义和管理权限的类。开发者可以通过创建Permissions对象并将其传递给SecurityManager来设置应用程序的权限集。
java.security.CodeSource：这个类用于表示代码的来源，包括 URL 和证书信息。它与权限控制紧密相关，因为安全管理器可以根据代码来源来授予或拒绝特定的权限。

沙箱和 Applet API 的弃用

Applet API 在 JDK 11 中被标记为弃用，并在 JDK 14 中被完全移除。Applet 提供了在浏览器中运行 Java 程序的能力，但由于安全问题和现代 Web 技术的发展，它已经不再被推荐使用。随着 Applet API 的弃用，Java 的沙箱模型也得到了重新评估，以确保 Java 应用程序的安全性。

加强的 JVM 安全特性

JVM 安全沙箱：JVM 本身提供了一个安全沙箱，限制了类加载器和类定义的权限。在 JDK 11 及后续版本中，这个沙箱得到了加强，以防止潜在的安全漏洞。
JVM TI（Tool Interface）：JVM TI 提供了一组 API，允许监控和控制运行中的 Java 虚拟机。在 JDK 11 中，对 JVM TI 的访问受到了限制，以减少潜在的安全风险。

总结

安全管理器和权限控制是 Java 平台安全性的关键组成部分。通过不断更新和改进这些机制，Java 确保了应用程序在一个受控的环境中运行，保护了用户的数据和系统资源。随着 Java 技术的不断发展，我们可以期待未来会有更多的安全特性被引入，以应对不断变化的安全威胁和挑战。开发者应当关注这些更新，确保他们的应用程序遵循最新的安全最佳实践。

启动和打包的新工具和方法

随着 Java 生态系统的发展，启动和打包应用程序的方式也在不断演进。为了满足现代应用程序对快速启动和部署的需求，Java 平台引入了一系列新的工具和方法，旨在简化开发流程，提高效率，并支持新的部署模式。

jlink 和 jpackage 工具

jlink（Java Linker）和 jpackage 是 Java 平台提供的新工具，它们使得创建定制的运行时映像和打包应用程序变得更加简单和高效。

jlink 工具

jlink 工具允许开发者创建一个定制的运行时映像（也称为“链接包”），这个映像包含了运行应用程序所需的最小化的 JVM 组件和应用程序代码。通过这种方式，开发者可以减少运行时的体积，提高启动速度，并减少对系统资源的占用。

减少运行时体积：传统的 JRE（Java 运行时环境）包含了许多不常用的功能和组件，这使得其体积相对较大。使用 jlink，开发者可以选择性地包含必要的模块，从而生成一个更小的运行时映像。
提高启动速度：较小的运行时映像意味着更少的加载时间，从而提高了应用程序的启动速度。
定制化部署：jlink 提供了高度的定制化能力，开发者可以根据应用程序的特定需求来构建运行时映像，例如，包含特定的语言包或不包含某些不常用的功能。

jpackage 工具

jpackage 工具是 Java 14 中引入的，用于将 Java 应用程序打包为平台特定的安装包。这个工具支持多种操作系统，包括 Windows、macOS 和 Linux，能够生成如 MSI、EXE、PKG、Deb 和 RPM 等格式的安装包。

一站式打包：jpackage 简化了打包流程，开发者只需一个命令就可以生成适用于目标平台的安装包。
集成式安装：生成的安装包可以集成到操作系统的包管理器中，使得应用程序的安装、更新和卸载与操作系统的其他软件一致。
支持多种平台：jpackage 支持跨平台打包，开发者可以使用相同的源代码生成适用于不同操作系统的安装包。

使用示例

以下是使用 jlink 和 jpackage 工具的基本示例：

 1# 使用 jlink 创建定制的运行时映像
 2jlink --module-path <path-to-jdk>/jmods \
 3 --add-modules java.base,java.desktop \
 4 --output <output-directory>
 5
 6# 使用 jpackage 打包应用程序
 7jpackage --type exe \
 8 --input <application-directory> \
 9 --runtime-image <path-to-runtime-image> \
10 --name <application-name> \
11 --main-jar <main-jar-file> \
12 --main-class com.example.Main

在上述示例中，我们首先使用 jlink 创建了一个只包含必要模块的运行时映像，然后使用 jpackage 将应用程序打包为 Windows 平台的 EXE 安装文件。

总结

jlink 和 jpackage 工具的引入，为 Java 应用程序的部署提供了更多的灵活性和便捷性。通过这些工具，开发者可以创建定制化的运行时映像和平台特定的安装包，从而满足不同场景下的部署需求。随着 Java 平台的不断发展，我们可以期待未来会有更多的工具和方法来支持现代化的应用程序部署。

Jigsaw 项目和模块系统

Jigsaw 项目是 Java 发展史上的一个重要里程碑，它的目标是将 Java 平台模块化，从而提高 Java 应用程序的性能、安全性和可维护性。Jigsaw 项目的核心是引入了 Java 模块系统（也称为 Project Jigsaw），这是 Java 11 中的一个重要特性。

模块化的好处

模块化带来了多个好处，包括：

更清晰的依赖关系：模块系统强制定义了包和模块之间的依赖关系，使得依赖更加明确，减少了类路径冲突的可能性。
更好的封装：模块可以隐藏其内部的实现细节，只暴露必要的 API，从而保护了应用程序的核心代码不被外部直接访问。
更高效的类加载：模块系统允许 JVM 有选择地加载和卸载模块，这不仅减少了内存占用，还提高了应用程序的启动速度。
更灵活的版本管理：模块化使得单独的模块可以独立更新和维护，而不会影响到整个应用程序。

模块系统的基本概念

Java 模块系统基于以下几个基本概念：

模块（Module）：一个模块是一个包含相关类和资源的容器。模块通过module声明来定义，并在module-info.java文件中指定。
依赖（Requires）：模块之间通过requires声明来表达依赖关系。一个模块可以依赖其他模块，并使用这些模块提供的 API。
导出（Exports）：模块可以导出包，使得其他模块可以使用这些包中的类。导出关系通过exports声明来定义。
打开（Opens）：模块可以打开包，允许其他模块访问其内部的类。这通常用于模块间的服务提供者和使用者关系。

模块系统的使用

在 Java 11 及以上版本中，开发者需要使用模块系统来构建应用程序。以下是一个简单的模块化应用程序的例子：

1// module-info.java
2module com.example.myapp {
3 requires com.example.commons;
4 requires java.sql;
5
6 exports com.example.myapp to com.example.commons;
7 opens com.example.myapp.internal to com.example.commons;
8}

在这个例子中，我们定义了一个名为com.example.myapp的模块，它依赖于com.example.commons模块和 Java 标准库中的java.sql模块。我们还导出了com.example.myapp包给com.example.commons，并打开了com.example.myapp.internal包给com.example.commons。

总结

Jigsaw 项目和模块系统的引入标志着 Java 平台在模块化方面的重大进步。模块化不仅提高了代码的组织性和可维护性，还为 Java 应用程序的性能和安全性带来了显著的提升。随着 Java 平台的不断发展，模块系统将继续演进，为开发者提供更多的灵活性和控制力。开发者应当熟悉模块化的概念和最佳实践，以便充分利用这一特性。

Javadoc 和字节码的更新

随着 Java 语言和平台的发展，Javadoc 工具和字节码规范也在不断进化，以适应新的编程实践和性能需求。这些更新对于开发者来说至关重要，因为它们影响着代码的文档化、兼容性和执行效率。

Javadoc 的现代化

Javadoc 是 Java 开发者用来生成 API 文档的重要工具。在 Java 9 中，Javadoc 工具经历了一次重大更新，引入了多项新特性和改进。

新的文档标签和工具特性

@thumbnail标签：这个新标签允许开发者在 Javadoc 中嵌入小型图像，增强了文档的可读性和直观性。
@implSpec和@implNote标签：这两个标签分别用于描述实现的意图和注意事项，提供了一种标准化的方式来记录实现细节。
Javadoc 预览特性：Java 9 引入了预览特性的概念，允许开发者尝试即将推出的 Javadoc 新特性。

HTML5 和搜索功能的引入

Javadoc 工具现在支持 HTML5，这意味着生成的文档可以利用现代 Web 技术，提供更好的跨设备兼容性和用户体验。此外，Javadoc 输出现在包括一个搜索框，允许用户快速查找 API 文档中的类、方法和属性。

字节码的改进和新增

Java 虚拟机（JVM）的字节码指令集和属性也在不断演进，以支持新的语言特性和性能优化。

动态类生成的改进

随着 Java 语言和 API 的发展，动态生成类的能力变得更加重要。例如，Java 9 引入了java.lang.invoke.MethodHandle的新方法，使得动态类生成更加高效和灵活。

新增的字节码指令和属性

invokedynamic指令：这个指令已经在 Java 7 中引入，用于动态解析方法调用，支持动态语言和框架，如 Project Panama。
新增的类文件属性：Java 11 中引入了新的类文件属性，如Module和ModulePackages，它们与 Java 模块系统相关联，用于存储模块化的元数据。
新增的 Code Attribute：Java 11 还引入了新的 Code Attribute，如StackMapTable，用于增强 JVM 的类型检查和安全性。

总结

Javadoc 和字节码的更新反映了 Java 平台对现代软件开发需求的响应。Javadoc 的现代化改进使得 API 文档更加丰富和易用，而字节码的增强则为 Java 语言的新特性和性能优化提供了支持。开发者应当关注这些更新，以便更好地利用 Java 平台提供的工具和特性。随着 Java 技术的不断发展，我们可以期待未来会有更多的创新和改进，进一步丰富 Java 生态系统。

新支持的平台和版本方案

随着技术的发展和市场需求的变化，Java 平台不断扩展其对新硬件和操作系统的支持。这些更新确保了 Java 应用程序能够在更广泛的设备和环境中运行，同时保持了跨平台兼容性。

跨平台支持和兼容性

Java 的核心优势之一是其跨平台性，这意味着在不同操作系统和硬件上运行的 Java 虚拟机（JVM）能够提供一致的运行时环境。为了维持这一优势，Java 开发团队持续对 JVM 进行优化，以支持新的处理器架构和操作系统版本。

新增平台的支持情况

在 JDK 8 至 21 的版本中，Java 增加了对多个新平台的支持，包括但不限于：

Linux/RISC-V：随着 RISC-V 开源处理器架构的兴起，Java 在 JDK 19 中增加了对 Linux/RISC-V 的支持，为开发者在这一新兴平台上构建 Java 应用程序提供了可能。
macOS/AArch64：随着 Apple 转向自家设计的 ARM 架构处理器，Java 在 JDK 17 中增加了对 macOS/AArch64 的支持，确保了 Java 应用程序能够在新的 Mac 设备上运行。
Windows/AArch64：同样，为了支持 Windows 操作系统上的 ARM 架构，Java 也在 JDK 16 中增加了对 Windows/AArch64 的支持。

版本兼容性和升级指南

为了帮助开发者平滑过渡到新版本，Java 提供了详细的版本兼容性指南。这些指南涵盖了从旧版本迁移到新版本的各个方面，包括 API 变更、废弃特性和新的模块系统。开发者可以参照这些指南来更新他们的应用程序，以利用新版本的特性和性能改进。

版本命名方案的变更

Java 的版本命名方案在 JDK 9 中经历了重大变化。在此之前，Java 的版本号遵循主版本号。次版本号的模式（例如，1.8 表示 JDK 8）。从 JDK 9 开始，Java 采用了新的命名方案，其中版本号包括了年份和更新次数（例如，9 表示 2017 年的更新版本）。

新版本命名的逻辑

新版本命名的逻辑旨在简化版本号的管理，并与 Java 的发布节奏保持一致。每个版本号都反映了它发布的时间，这使得开发者和用户能够更容易地了解他们使用的 Java 版本相对于其他版本的年龄。

版本迭代的速度和周期

自 JDK 9 以来，Java 的版本迭代速度加快，每六个月发布一个新的版本。这种快速迭代的模式使得 Java 能够更快地引入新特性和改进，同时也意味着开发者和用户需要更频繁地更新他们的 Java 环境。为了适应这种快速迭代，Java 也引入了长期支持（LTS）版本，这些版本会得到更长时间的支持和维护，适合需要稳定性和长期支持的企业级应用。

总结

新支持的平台和版本方案的变更体现了 Java 对不断变化的技术环境的适应性。通过增加对新硬件和操作系统的支持，Java 确保了其跨平台优势的持续存在。同时，新的版本命名方案和快速迭代模式使得 Java 能够更快地响应开发者的需求，推动 Java 生态系统的持续发展。开发者应当关注这些变化，以确保他们的应用程序能够充分利用 Java 平台的最新特性和改进。

弃用和移除的特性

随着 Java 平台的发展，某些旧特性可能会因为安全问题、更好的替代方案或者技术进步而变得过时。为了保持语言的现代化和高效性，Java 开发团队会定期审查和弃用这些特性，并在适当的时候将其移除。这一过程需要仔细的规划和透明的沟通，以确保开发者有足够的时间来适应变化。

弃用列表和未来展望

Java 社区维护了一个详细的弃用特性列表，这个列表随着每个新版本的发布而更新。开发者可以通过查阅这个列表来了解哪些特性已被弃用，以及它们的未来状态。

Java EE 的移除：Java 企业版（Java EE）在 JDK 11 中被移除，转而作为独立的 Eclipse 项目继续发展。
CORBA 模块的移除：Java 的 CORBA 支持在 JDK 11 中被移除，因为这项技术的使用已经变得较少。
Nashorn JavaScript 引擎的移除：在 JDK 15 中，Nashorn JavaScript 引擎被标记为弃用，并在 JDK 11 中被完全移除。

移除特性的影响和替代方案

移除特性会对依赖这些特性的应用程序产生影响。因此，Java 提供了替代方案，以帮助开发者平滑过渡到新的技术。

Java EE 的替代方案：对于 Java EE 的替代，开发者可以转向 Spring Boot、Quarkus 等现代框架，它们提供了类似的功能，并且更加轻量级和灵活。
CORBA 的替代方案：对于需要 RPC（远程过程调用）的开发者，可以考虑使用 gRPC 或 RESTful 服务。
Nashorn 的替代方案：对于需要在 Java 中执行 JavaScript 的开发者，可以考虑使用 GraalVM 的 JavaScript 引擎。

向后兼容性的挑战

向后兼容性是 Java 平台的一个重要原则，它确保了旧代码在新版本中仍然能够正常运行。然而，移除特性的决定可能会对向后兼容性造成挑战。

向后兼容性的策略

为了最小化对现有应用程序的影响，Java 开发团队采取了一系列策略：

清晰的弃用周期：Java 提供了清晰的弃用周期，通常在特性被完全移除之前会有一个警告期。
提供替代方案：Java 努力为每个被弃用的特性提供替代方案，以帮助开发者进行迁移。
逐步移除：对于大型特性，Java 可能会逐步移除，先将其标记为弃用，然后在后续版本中完全移除。

开发者如何应对弃用和移除

开发者应当密切关注 Java 社区的更新和公告，了解哪些特性正在被弃用或计划被移除。对于正在使用的弃用特性，开发者应该：

评估影响：分析应用程序中使用弃用特性的代码，评估迁移的成本和影响。
制定迁移计划：根据评估结果，制定详细的迁移计划，包括时间表和技术路线。
测试和验证：在迁移到新特性或替代方案后，进行充分的测试以确保应用程序的功能和性能。
更新文档和培训：更新内部文档，并为团队成员提供必要的培训，以确保所有人都了解新的变化。

通过这些措施，开发者可以确保他们的应用程序能够适应 Java 平台的变化，同时保持高效和稳定。

总结

在对 Java 平台从 JDK 8 至 21 的演进进行深入探讨后，我们可以总结出几个关键点，这些点不仅展示了 Java 语言和生态系统的发展，也为开发者提供了未来工作的方向和策略。

语言特性的进步

Java 语言在这段时间里经历了显著的增强，包括引入了函数式编程概念、模式匹配、未命名变量和模式、封闭类和记录类等。这些新特性不仅丰富了 Java 的表达能力，也使得代码更加简洁、可读性更强，同时提高了开发效率。

API 的扩展和更新

Java 标准库的扩展和更新为开发者提供了新的工具和能力。集合和数学函数 API 的增强、文件和 IO 操作的改进、网络编程的新特性以及安全管理器和权限控制的更新，都使得 Java 应用程序能够更好地处理复杂的任务和安全挑战。

性能和资源管理的优化

Java 虚拟机的性能和资源管理一直是 Java 开发的重点。JIT 编译器的优化、垃圾回收器的进步、内存管理和启动时间的改进，都显著提高了 Java 应用程序的运行效率和用户体验。

模块化和跨平台支持

Jigsaw 项目的完成和模块系统的引入，标志着 Java 平台在模块化方面取得了重大进展。这不仅提高了 Java 的内在质量和可维护性，也简化了应用程序的部署和分发。同时，Java 对新平台的支持，如 RISC-V 和 AArch64，确保了 Java 在多样化的计算环境中的持续相关性。

向后兼容性的维护

Java 社区对向后兼容性的承诺保证了新版本可以无缝地与现有代码库协同工作。尽管一些特性被弃用或移除，但 Java 提供了清晰的路线图和替代方案，以帮助开发者平滑过渡。

未来展望

随着 Java 的不断发展，我们可以预见到更多的创新和改进。新的语言特性、API 和性能优化将继续出现，以适应新的编程范式和技术趋势。同时，Java 社区将继续致力于提高平台的安全性、可维护性和用户友好性。

对于开发者来说，保持对 Java 新特性和最佳实践的了解至关重要。通过不断学习和适应变化，开发者可以确保他们的技能和应用程序保持最新，从而在不断变化的技术环境中保持竞争力。随着 Java 生态系统的不断壮大，Java 将继续作为企业级应用程序和现代云服务的坚实基础，引领软件开发的未来。

Vim 从何而来

Sat, 04 Nov 2023 06:38:45 +0000

Vim 编辑器的创造者、维护者和终身领导者 Bram Moolenaar 于 2023 年 8 月 3 日因病去世，享年 62 岁

为了纪念这位杰出的荷兰程序员，我们今天来聊一聊 Vim 的历史。

Vim 无处不在。它被很多人使用。同时 Vim 可能是世界上 “最难用的软件之一” ，但是又多次被程序员们评价为最受欢迎的代码编辑器。

Vim 预装在 Mac OS 上，并且在 Linux 领域拥有大量支持者。即使对于那些讨厌它的人来说，它也很熟悉，因为足够流行的命令行工具会默认将用户带入 Vim。

有一些主要网站，包括 Facebook，当你按 j 键时会向下滚动，当你按 k 键时会向上滚动 — 这就是通过 Vim 的广泛传播而形成的文化。

然而 Vim 也是一个谜。

例如，与众所周知的由 Facebook 开发和维护的 React 不同，Vim 没有明显的赞助商。

尽管它无处不在且很重要，但似乎没有任何类型的委员会或组织对 Vim 做出决策。

你可能会花几分钟浏览 Vim 网站（https://www.vim.org），但无法更好地了解谁创建了 Vim 或为什么创建。

如果你启动 Vim 时没有给它提供文件参数，那么你将看到 Vim 的启动消息，其中显示 Vim 是由“Bram Moolenaar 等人”开发的。但这并不能告诉你太多。布拉姆·穆勒纳尔 (Bram Moolenaar) 是谁？他的合作者又是谁？

也许更重要的是，为什么退出 Vim 需要输入 :wq ？

当然，这是一个“写入”操作，然后是一个“退出”操作，但这并不是一个特别直观的约定。谁决定复制文本应该被称为“yanking”？为什么 :%s/foo/bar/gc 是“查找和替换”的缩写？Vim 的特性似乎太随意了，不可能是虚构的，但它们是从哪里来的呢？

正如通常的情况一样，答案始于古老——贝尔实验室。从某种意义上说，Vim 只是一个软件的最新版本——称之为“wq 文本编辑器”——自 Unix 时代开始以来一直在不断开发和改进。

Ken Thompson 编写了一个行编辑器

1966 年，贝尔实验室聘请了 Ken Thompson。汤普森刚刚在加州大学伯克利分校获得了电气工程和计算机科学硕士学位。在那里，他使用了一个名为 QED 的文本编辑器，该编辑器是在 1965 年至 1966 年间为伯克利分时系统编写的。

汤普森到达贝尔实验室后做的第一件事就是为麻省理工学院兼容时间重写 QED - 共享系统。后来他为 Multics 项目编写了 QED 的另一个版本。在此过程中，他扩展了该程序，以便用户可以搜索文件中的行并使用正则表达式进行替换。

Multics 项目与伯克利分时系统一样，旨在创建一个商业上可行的分时操作系统，该项目是麻省理工学院、通用电气和贝尔实验室之间的合作项目。AT&T 最终认为该项目毫无进展并退出。

汤普森和贝尔实验室研究员丹尼斯·里奇现在无法访问分时系统，他们开始创建自己的版本，最终被称为 Unix。1969 年 8 月，当他的妻子和年幼的儿子去加利福尼亚度假时，Thompson 组装了新系统的基本组件，“为操作系统、shell、编辑器各分配了一周的时间”。

编辑器将被称为 ed 。它基于 QED，但并不是精确的重新实现。Thompson 决定放弃某些 QED 功能。正则表达式支持被削减，以便只能理解相对简单的正则表达式。QED 允许用户通过打开多个缓冲区来一次编辑多个文件，但 ed 一次只能使用一个缓冲区。尽管 QED 可以执行包含命令的缓冲区，但 ed 不会执行此类操作。可能需要进行这些简化。Dennis Ritchie 表示，没有 QED 的高级正则表达式“并没有多大损失”

ed 现在是 POSIX 规范的一部分，因此如果你有兼容 POSIX 的系统，则可以将其安装在你的计算机上。它值得一试，因为许多 ed 命令如今已成为 Vim 的一部分。例如，为了将缓冲区写入磁盘，你必须使用 w 命令。为了退出编辑器，你必须使用 q 命令。这两个命令可以同时在同一行指定 - wq 。

与 Vim 一样， ed 是一个模式编辑器；要从命令模式进入输入模式，你可以使用插入命令（ i ）、附加命令（ a ）或更改命令（ c ），取决于你如何转换文本。ed 还引入了用于查找和替换（或“替换”）文本的 s/foo/bar/g 语法。

鉴于所有这些相似之处，你可能认为普通 Vim 用户使用 ed 不会遇到任何问题。但 ed 在另一个重要方面与 Vim 完全不同。ed 是一个真正的行编辑器。它是在电传打字机时代编写并广泛使用的。当 Ken Thompson 和 Dennis Ritchie 攻克 Unix 时，他们看起来像这样：

ed 不允许你在打开缓冲区的其他行之间编辑行，或移动光标，因为 ed 每次都必须重新打印整个文件对其进行了更改。1969 年的时候， ed 还没有“清除”屏幕内容的机制，因为屏幕只是一张纸，已经输出的所有内容都是用墨水输出的。必要时，你可以要求 ed 使用列表命令 ( l ) 为您打印出一系列行。因此，使用 ed 有点像试图用功率不足的手电筒在黑暗的房子里寻找出路。你一次只能看到这么多，所以你必须尽力记住所有东西在哪里。

这是 ed 会话的示例。我添加了注释（在 # 字符之后）来解释每行的用途

 1[tt 09:49 ~]$ ed
 2i # Enter input mode
 3Hello world!
 4
 5Isn't it a nice day?
 6. # Finish input
 71,2l # List lines 1 to 2
 8Hello world!$
 9$
102d # Delete line 2
11,l # List entire buffer
12Hello world!$
13Isn't it a nice day?$
14s/nice/terrible/g # Substitute globally
15,l
16Hello world!$
17Isn't it a terrible day?$
18w foo.txt # Write to foo.txt
1938 # (bytes written)
20q # Quit
21[sinclairtarget 10:50 ~]$ cat foo.txt
22Hello world!
23Isn't it a terrible day?

Bill Joy 编写了一个文本编辑器

ed 对于 Thompson 和 Ritchie 来说工作得足够好。但其他人发现它很难使用，并且它被认为是 Unix 对新手特别不友好的一个例子。

1975 年，一位名叫 George Coulouris 的人在伦敦玛丽女王学院安装的 Unix 系统上开发了 ed 的改进版本。

与 ed 不同，Coulouris 的程序允许用户在屏幕上编辑一行，逐个按键地浏览该行。Coulouris 称他的程序为 em ，或“凡人的编辑器”

1976 年，Coulouris 带着 em 来到加州大学伯克利分校，并以客座教授的身份在加州大学伯克利分校度过了一个夏天。此时距离肯·汤普森离开伯克利去贝尔实验室工作整整十年了。在伯克利，Coulouris 遇到了 Bill Joy，他是一名从事 Berkeley Software Distribution (BSD) 工作的研究生。Coulouris 向 Joy 展示了 em ，Joy 从 Coulouris 的源代码开始构建了 ed 的改进版本，称为 ex ，用于“扩展 ed 的 1.1 版本与 1978 年 BSD Unix 的第一个版本捆绑在一起。ex 很大程度上与 ed 兼容，但它增加了两种模式：“open”模式，它启用了单行编辑，就像 em 一样，以及“视觉”模式，它接管整个屏幕并启用整个文件的实时编辑，就像我们今天习惯的那样。

1979 年的第二个 BSD 版本，引入了一个名为 vi 的可执行文件，它的作用只不过是在可视模式下打开 ex 。

ex / vi （此后称为 vi ）建立了我们现在与 Vim 关联的大部分约定，这些约定尚未成为 ed 的一部分。Joy 使用的视频终端是 Lear Siegler ADM-3A，其键盘没有光标键。相反，箭头被绘制在 h 、 j 、 k 和 l 键上，这就是 Joy 使用这些键作为光标的原因 vi 中的移动。ADM-3A 键盘上的退出键也是今天我们可以找到 Tab 键的地方。

命令前缀的:字符也来自 vi ，在常规模式下（即通过运行 ex 输入的模式）使用 : 作为提示。这解决了长期以来对 ed 的抱怨。在可视模式下，保存和退出现在需要输入经典的 :wq 。“Yanking”和“putting”、标记以及用于设置选项的 set 命令都是原始 vi 的一部分。我们今天在 Vim 中进行基本文本编辑过程中使用的功能主要是 vi 功能。

vi 是除 ed 之外唯一与 BSD Unix 捆绑在一起的文本编辑器。当时，Emacs 可能要花费数百美元（这是在 GNU Emacs 之前），因此 vi 变得非常流行。但 vi 是 ed 的直接后代，这意味着如果没有 AT&T 源许可证，则无法修改源代码。这促使一些人创建 vi 的开源版本。STEVIE（VI 爱好者的 ST 编辑器）出现于 1987 年，Elvis 出现于 1990 年， nvi 出现于 1994 年。其中一些克隆添加了额外的功能，如语法突出显示和分割窗口。尤其是 Elvis，它的许多功能都被纳入了 Vim，因为许多 Elvis 用户都在推动将其纳入其中。

Bram Moolenaar 撰写 Vim

“Vim” 现在缩写为“Vi Improve”，最初代表“Vi Imitation”。与许多其他 vi 克隆一样，Vim 最初是尝试在不可用的平台上复制 vi 。Bram Moolenaar 是一位荷兰软件工程师，在荷兰 Venlo 的一家复印机公司工作，他想要为他全新的 Amiga 2000 使用类似 vi 的东西。在 1988 年，Moolenaar 以现有的 STEVIE vi 克隆为起点，开始研究 Vim。

Moolenaar 可以访问 STEVIE，因为 STEVIE 之前曾出现在名为 Fred Fish 磁盘的东西上。Fred Fish 是一位美国程序员，他每个月都会寄出一张软盘，其中包含精选的适用于 Amiga 平台的最佳开源软件。任何人都可以索取磁盘，只需支付邮费即可。Fred Fish 磁盘上发布了 STEVIE 的多个版本。Moolenaar 使用的版本已在 Fred Fish 磁盘 256 上发布。

Moolenaar 喜欢 STEVIE，但很快注意到缺少许多 vi 命令。因此，对于 Vim 的第一个版本，Moolenaar 将 vi 兼容性作为他的首要任务。其他人编写了一系列 vi 宏，Moolenaar 能够让这些宏在 Vim 中运行。1991 年，Vim 首次在 Fred Fish 磁盘 591 上发布，名称为“Vi Imitation”。Moolenaar 添加了一些功能（包括多级撤消和针对编译器错误的“快速修复”模式），这意味着 Vim 已经超越了 vi 。但 Vim 一直是“Vi Imitation（模仿）”，直到 1993 年通过 FTP 发布 Vim 2.0。

Moolenaar 在各种互联网合作者的偶尔帮助下，稳定地为 Vim 添加了功能。Vim 2.0 引入了对 wrap 选项和水平滚动长行文本的支持。Vim 3.0 添加了对分割窗口和缓冲区的支持，该功能受到 vi 克隆 nvi 的启发。Vim 现在还将每个缓冲区保存到交换文件中，以便编辑后的文本可以在崩溃时幸存下来。Vimscript 首次出现在 Vim 5.0 中，并支持语法突出显示。与此同时，Vim 的受欢迎程度与日俱增。它被移植到 MS-DOS、Windows、Mac，甚至 Unix，与原始的 vi 竞争。

2006 年，Vim 被评选为最受 Linux Journal 读者欢迎的编辑器。如今，根据 Stack Overflow 的 2018 年开发者调查，Vim 是最流行的文本模式（即终端仿真器）编辑器，25.8% 的软件开发人员（以及 40% 的系统管理员/DevOps 人员）使用它。有一段时间，在 20 世纪 80 年代末和整个 90 年代，程序员发动了“编辑器战争”，使 Emacs 用户与 vi （最终是 Vim）用户对立。虽然 Emacs 当然仍然有一些追随者，但有些人认为编辑器之战已经结束，Vim 获胜了。2018 年 Stack Overflow 开发者调查表明这是事实；只有 4.1% 的受访者使用 Emacs。

Vim 是如何变得如此成功的？显然人们喜欢 Vim 提供的功能。但我认为，Vim 背后的悠久历史表明，它拥有的优势不仅仅是其功能集。Vim 的代码库可以追溯到 1988 年，当时 Moolenaar 开始研究它。“wq 文本编辑器”有几种不同的具体表达方式，但部分归功于 Bill Joy 和 Bram Moolenaar 对向后兼容性的不同寻常的关注，随着时间的推移，好的想法逐渐积累起来。从这个意义上说，“wq 文本编辑器”是运行时间最长、最成功的开源项目之一，得到了计算世界中一些最伟大思想家的贡献。我不认为“初创公司抛弃所有先例并创造颠覆性新软件”的开发方法一定是坏事，但 Vim 提醒我们，协作和增量方法也可以产生奇迹。

聊聊 Java 的单元测试

Tue, 02 Aug 2022 13:13:24 +0000

单元测试框架

Java 中，JUnit 和 TestNG 是最受欢迎的单元测试框架。

JUnit
TestNG

JUnit

首先是大名鼎鼎的 JUnit ，JUnit 已经成为 Java 应用程序单元测试的事实标准。

JUnit 是一个开源的 Java 语言的单元测试框架，专门针对 Java 设计，使用最广泛。JUnit 目前最新版本是 5

JUnit5 的组成：JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

JUnit5 建议使用 Java8 及以上版本

JUnit Platform 是在 JVM 上启动测试框架的基础，它定义了TestEngine在平台运行的新测试框架的 API
JUnit Jupiter 它用于编写测试代码的新的编程和扩展模型。它具有所有新的 Junit 注释和TestEngine实现来运行这些注释编写的测试。
JUnit Vintage JUnit4 已经存在了很长时间，并且有许多以 JUnit4 编写的测试。JUnit Jupiter 还需要支持这些测试。为此，开发了 JUnit Vintage 子项目。提供了一个测试引擎，用于在平台上运行基于 JUnit 3 和 JUnit 4 的测试。它要求 JUnit 4.12 或更高版本出现在类路径或模块路径中。从它的名字 Vintage（古老的；古色古香的）中也能有所体会。

简单例子

我们先来个最简单的例子，别看简单，很多人会犯错

1@SpringBootTest
2@RunWith(SpringRunner.class)
3public class JunitTest {
4 @Test
5 public void testJunit(){
6 System.out.println("junit test");
7 }
8}

很简单对吧，如果你用了 SpringBoot 简单到好像没啥说的，其实不然，我们来聊聊：

首先，这段代码使用的是 JUnit 4 还是 JUnit5 ? 你可能会觉得，4 和 5 没啥区别吧，用哪个不一样吗？代码能跑不就行了？

不是的，4 和 5 肯定有区别这个不用我说了。能跑没问题，但如果你不管是 4 还是 5 都认为一样，API 混用，甚至乱用，那这时候测试出现的各种报错，导致你很懵逼，而且不知道为什么，一通乱查也不知所然。

上面这段代码其实是 JUnit 4 版本，我们看一下 import 就一目了然了，然而可能你在开发的时候没太注意这里是 4 还是 5

1import org.junit.Test;
2import org.junit.runner.RunWith;
3import org.springframework.boot.test.context.SpringBootTest;
4import org.springframework.test.context.junit4.SpringRunner;

这里确定了，使用的是 4 的版本，这里有几个要注意的点：

@Test的包是org.junit.Test ，不要搞错了，因为有好几个同名包
需要@RunWith(SpringRunner.class)
测试类和测试方法需要public修饰

我们看下完整的例子：

 1import org.junit.Test;
 2import org.junit.runner.RunWith;
 3import org.springframework.boot.test.context.SpringBootTest;
 4import org.springframework.test.context.junit4.SpringRunner;
 5
 6@SpringBootTest
 7@RunWith(SpringRunner.class)
 8public class JunitTest {
 9 @Test
10 public void testJunit(){
11 System.out.println("junit test ");
12 }
13}

这里强调下环境，springboot2.2.x 之前支持 JUnit 4

上面有一点提到了需要 public 修饰的问题，这不很正常吗，为什么要强调？

那是因为 JUnit 5 不需要了，我们看一下用 JUnit 5 来实现的同样的例子 (SpringBoot 2.2.x 之后支持 JUnit 5)：

 1import org.junit.jupiter.api.Test;
 2import org.springframework.boot.test.context.SpringBootTest;
 3
 4@SpringBootTest
 5class JunitTest {
 6 @Test
 7 void testJunit5(){
 8 System.out.println("junit5");
 9 }
10}

这么简单吗？对，就是这么简单，所以我说 4 和 5 不一样。我们来看区别的地方：

@Test的包是org.junit.jupiter.api.Test
不需要@RunWith(SpringRunner.class)
测试类和测试方法不需要public修饰

我见过很多同学在写测试用例时出现的所谓诡异问题，都是因为他自己都没搞清楚用的是 4 还是 5 的情况下将 4 和 5 混用导致的。

如果你的测试用例是 4 ，可以迁移到 5 了，有关 JUnit 4 迁移到 JUnit5 的话题可以参考这篇文章，通过工具可能节省很多时间：https://blog.jetbrains.com/idea/2020/08/migrating-from-junit-4-to-junit-5/

我们再来看一下 pom 依赖这里，你是不是经常看到有关 test 的依赖是这样写的：

 1<dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-test</artifactId>
 4 <scope>test</scope>
 5 <exclusions>
 6 <exclusion>
 7 <groupId>org.junit.vintage</groupId>
 8 <artifactId>junit-vintage-engine</artifactId>
 9 </exclusion>
10 </exclusions>
11</dependency>

为啥？为什么要排除 junit-vintage-engine ？如果你认真阅读了前文，你应该能猜到为什么了。

JUnit Vintage 是为了兼容 3 和 4 的一个 engine，如果我们的测试代码都用 5 实现，不需要兼容 3 和 4 ，那要它干嘛？当然是干掉呀，哈哈。

但如果你需要兼容，那请不要那么鲁莽。上面的这段 dependency 主要用于 spring-boot-starter-test 的 2.2.x 和 2.3.x 版本中。spring-boot-starter-test 2.4.x 版本中，已经不再包含 junit-vintage-engine 这个依赖项了

常规套路

Annotations	描述
`@BeforeEach`	在方法上注解，在每个测试方法运行之前执行。
`@AfterEach`	在方法上注解，在每个测试方法运行之后执行
`@BeforeAll`	该注解方法会在所有测试方法之前运行，该方法必须是静态的。
`@AfterAll`	该注解方法会在所有测试方法之后运行，该方法必须是静态的。
`@Test`	用于将方法标记为测试方法
`@DisplayName`	用于为测试类或测试方法提供任何自定义显示名称
`@Disable`	用于禁用或忽略测试类或方法
`@Nested`	用于创建嵌套测试类
`@Tag`	用于测试发现或过滤的标签来标记测试方法或类
`@TestFactory`	标记一种方法是动态测试的测试工场

常规套路不说了，比较简单，一看就明白，说几个有意思的。

重复性测试

1 @RepeatedTest(5)
2 void repeatTest(TestInfo testInfo,RepetitionInfo repetitionInfo){
3
4 System.out.println("repeat:" + testInfo.getDisplayName());
5 System.out.println("这是第 "+ repetitionInfo.getCurrentRepetition()+ "次重复");
6
7 }

不用自己写 for 循环了，人家自己带重复的注解，上面两个变量也是自己带的，方便拿到重复信息。

基于参数测试

1@ParameterizedTest
2@ValueSource(strings = {"java", "python", "go"})
3void containsChar(String candidate) {
4 assertTrue(candidate.contains("o"));
5}

如果你的参数少，也不用写循环了，直接写注解里，还挺方便的。

超时测试

1 @Test
2 @Timeout(value = 500, unit = TimeUnit.MILLISECONDS)
3 void failsIfExecutionTimeExceeds500Milliseconds() {
4 // fails if execution time exceeds 500 milliseconds
5 }

可以设置超时的单位和时长

在 assert 中也可以测超时，可以这样写：

 1 // timed out after 5 seconds
 2 @Test
 3 void test_timeout_fail() {
 4 // assertTimeout(Duration.ofSeconds(5), () -> delaySecond(10)); // this will fail
 5
 6 assertTimeout(Duration.ofSeconds(5), () -> delaySecond(1)); // pass
 7 }
 8
 9 void delaySecond(int second) {
10 try {
11 TimeUnit.SECONDS.sleep(second);
12 } catch (InterruptedException e) {
13 e.printStackTrace();
14 }
15 }

并行测试

以上测试用例都是用主线程或者单线程跑的，下面我们玩儿个多线程并行 test

首先你要在你的 classpath 下面建一个文件 junit-platform.properties

接着加两行配置

1junit.jupiter.execution.parallel.enabled=true
2junit.jupiter.execution.parallel.mode.default=concurrent

行了，再跑你的用例就是多线程并行执行的了，当然如果用例本来就设计成单线程的看不出来，那可以使用 Repeat 试一下，比如上面讲过的这个：

1 @RepeatedTest(5)
2 void repeatTest(TestInfo testInfo,RepetitionInfo repetitionInfo){
3
4 System.out.println("repeat:" + testInfo.getDisplayName());
5 System.out.println("这是第 "+ repetitionInfo.getCurrentRepetition()+ "次重复");
6
7 }

上面这个是对一个方法的重复执行并行，有时候我们是想让一个类中的多个方法并行，能不能做到？可以，改下配置就好了

1junit.jupiter.execution.parallel.enabled = true
2junit.jupiter.execution.parallel.mode.default = concurrent
3junit.jupiter.execution.parallel.mode.classes.default = same_thread

如果反过来呢？多个类并行，类中的方法串行 也可以，还是改配置：

1junit.jupiter.execution.parallel.enabled = true
2junit.jupiter.execution.parallel.mode.default = same_thread
3junit.jupiter.execution.parallel.mode.classes.default = concurrent

MockMVC

你测个 service 测个 dao 很简单，把 Bean 注入就可以了，Controller 怎么测？我们要利用下 MockMVC 了

“

MockMvc 实现了对 Http 请求的模拟，能够直接使用网络的形式，转换到 Controller 的调用，这样可以使得测试速度快、不依赖网络环境，而且提供了一套验证的工具，这样可以使得请求的验证统一而且很方便。

”

我们先看一个简单的例子：

 1import org.junit.jupiter.api.*;
 2import org.springframework.beans.factory.annotation.Autowired;
 3import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
 4import org.springframework.boot.test.context.SpringBootTest;
 5import org.springframework.test.web.servlet.MockMvc;
 6import static org.hamcrest.Matchers.containsString;
 7import static org.junit.jupiter.api.Assertions.assertTrue;
 8import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
 9import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;
10import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
11import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
12
13@SpringBootTest
14@AutoConfigureMockMvc
15class HelloControllerTest {
16
17 @Autowired
18 private MockMvc mockMvc;
19
20 @Autowired
21 private HelloController helloController;
22
23 @Test
24 public void shouldReturnDefaultMessage() throws Exception {
25
26 this.mockMvc.perform(get("/hello"))
27 .andDo(print())
28 .andExpect(status().isOk())
29 .andExpect(content().string(containsString("Hello World")));
30 }
31 }

解释下没见过的注解：

@AutoConfigureMockMvc：用于自动配置 MockMvc, 配置后 MockMvc 类可以直接注入

此外我们利用 @Autowired 注入了一个 MockMvc 的 Bean 实例。我们通过这个例子来模拟请求 /hello 这个 Controller 资源，并且通过判断返回的 content 内容是否包含 Hello World 字符串来决定这个用例的执行是否成功。

注意 imports 部分，我们导入了 MockMvcRequestBuilders 的一些静态方法。整个方法就一行代码，解释一下：

perform : 执行一个请求
andDo : 添加一个结果处理器，表示要对结果做点什么事情，比如此处使用 print()：输出整个响应结果信息
andExpect : 添加执行完成后的断言

我们看下执行结果：

 1MockHttpServletRequest:
 2 HTTP Method = GET
 3 Request URI = /hello
 4 Parameters = {}
 5 Headers = []
 6 Body = null
 7 Session Attrs = {}
 8
 9Handler:
10 Type = com.xiaobox.springbootdemo.controller.HelloController
11 Method = com.xiaobox.springbootdemo.controller.HelloController#hello(String)
12
13Async:
14 Async started = false
15 Async result = null
16
17Resolved Exception:
18 Type = null
19
20ModelAndView:
21 View name = null
22 View = null
23 Model = null
24
25FlashMap:
26 Attributes = null
27
28MockHttpServletResponse:
29 Status = 200
30 Error message = null
31 Headers = [Content-Type:"text/plain;charset=UTF-8", Content-Length:"12"]
32 Content type = text/plain;charset=UTF-8
33 Body = Hello World!
34 Forwarded URL = null
35 Redirected URL = null
36 Cookies = []

我们来看下一个例子

 1
 2@WebMvcTest
 3class HelloControllerTest {
 4
 5 @Autowired
 6 private MockMvc mockMvc;
 7
 8 @Autowired
 9 private HelloController helloController;
10
11 @Test
12 public void shouldReturnDefaultMessage() throws Exception {
13
14 this.mockMvc.perform(get("/hello"))
15 .andDo(print())
16 .andExpect(status().isOk())
17 .andExpect(content().string(containsString("Hello World")));
18 }
19 }

你发现我们只是把 class 头上的注解换成了 @WebMvcTest，其实的没变，是的。但却比上一段代码快 3 倍。为什么？

因为之前的写法会把 Spring 完整的应用上下文全启动了，而 @WebMvcTest 是将测试范围缩小到仅启动 web 层，所以会快。当你只想测试 http 到 controller 这层的时候，可以用 @WebMvcTest 注解。

你甚至还可以告诉框架只启动某一个 controller 这样更快，比如：@WebMvcTest(HomeController.class)

上面是 WebMvcTest 的第一个场景，我们来看第二个场景：也是测 controller ，但 controller 调用的 service 我们也 mock，不走真正 service 代码逻辑。这在有时你的 service 没准备好，或者不方便直接调用时会很有用。

 1@WebMvcTest
 2class HelloControllerTest {
 3
 4 @Autowired
 5 private MockMvc mockMvc;
 6
 7 @Autowired
 8 private HelloController helloController;
 9
10 @Test
11 public void greetingShouldReturnMessageFromService() throws Exception {
12
13 Mockito.when(service.greet()).thenReturn("Hello, Mock");
14 
15 this.mockMvc.perform(get("/greeting")).andDo(print()).andExpect(status().isOk())
16 .andExpect(content().string(containsString("Hello, Mock")));
17 }
18 
19 }

上面的代码我们用到了 Mockito，可能你听过周杰伦一首新歌叫 Mojito ，对，Mockito 的命名就是对 Mojito（一种传统的古巴高球鸡尾酒）的戏称

简单来说 Mockito 是一个 java 做单元测试的 Mock 框架：https://site.mockito.org/

解释下我们上面这行代码 Mockito.when(service.greet()).thenReturn("Hello, Mock");

意为：当调用 service 的 greet 方法的时候，返回值为 “Hello Mock”，其实没真调那个方法，就是 Mock 了一下，直接给了个返回值。用英文说就是：When the x method is called then return y

当然 Mockito 在假造上是很有实力的，它有丰富的 API 供你组合使用，有兴趣可以看一看文档和源码注释。

讲到这儿，一定有同学会问，只测 Controller ，那我就用 Postman 就行了，甚至 curl 都行，为啥要写用例，我不写用例。

哈哈，我相信很多后端同学都没认认真真把用例写完，尤其是 controller 这层的，不装逼，我也是。那我们有必要讨论一下 到底是用 Postman 还是用 MockMVC ？

首先说说 MockMVC 的好处：

可编程，这就给了你无限的自由空间，想怎么折腾随便你，你是上帝
除了写的时候花点时间外，调试的时候速度快，而且可配置，你要想只测 controller，就只启动 controller 的上下文就行了
顺便把测试用例写了，测试同学省心了，给自动化测试提供了基础
间接提高代码质量

其他的我不说，我就说最后一点。我注意到一个现象，很多开发同学拿测试同学当工具人，自己写的代码自己不怎么测试，直接交给测试让他们提 BUG，然后改，BUG 多也不觉得害臊。开发是爽了，由于代码质量差，整个项目的进度都被拖慢了。你可能会说这是软件质量管理的问题，是规则制定的有问题，如果出 BUG 扣钱就没这事儿了。

我要说的是，在软件开发这个领域，很多事情不是刻板的死规则，即便是制定了这样的规则，也不一定有效。更多的时候是整个团队的文化和风气，领导者有责任将整个研发团队的文化和风气带向正轨。什么是正轨？其实我们都知道！我们都知道应该写高质量的代码，bug 少的代码，设计合理的代码，不断重构、不断维护的代码，我们都知道要做好自己的事就会提高整个团队的效率，我们都知道应该写注释、写文档，我们都知道…..

我们都知道，但我们也知道项目时间紧，而且专门有人一遍遍强调 deadLine ，有人关心你的开发进度，关心功能实现了没有，关心老板有没有意见，没有人关心你累不累，关心你几点下的班，关心规划合不合理，关心代码质量高不高，关心与软件真正有关系的一切。所以做一个真正的软件研发团队的 Leader 不容易，遇到好 Leader 是你的福气。

扯多了，我们回头来看 Postman ,Postman 的好处好像也不用我多说了，确实，如果只是简单的做 Controller 连通测试，用 Postman 一点儿问题没有，也比写程序快，但如果你的需求时有正好是 MockMVC 的优点可以覆盖的地方，那么就动动手，写写程序吧。

测试报告

想成一份漂亮的测试报告？后端同学说了，整那花里胡哨的有啥用呢，简单一点儿不好吗？

好，简单点儿当然可以，但 UI 带给我们的价值不就是一图胜千言嘛，让无论是前端、后端、测试同学都能一目了然，减轻大脑处理信息的成本。

来，我们先上成果

怎么样，还挺好看的吧，我们用的是 Allure 来生成了一个 web 页面，这个页面还有一些简单的交互，整体简洁好看、易用。

下面我们说一下 Allure 怎么和 JUnit 集成的

我们仍然使用 SpringBoot 以及 JUnit 5 ，先修改一下 pom.xml 文件，添加依赖

 1 <dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-test</artifactId>
 4 <scope>test</scope>
 5 <exclusions>
 6 <exclusion>
 7 <groupId>org.junit.vintage</groupId>
 8 <artifactId>junit-vintage-engine</artifactId>
 9 </exclusion>
10 </exclusions>
11</dependency>
12 <!--测试报告 allure -->
13 <dependency>
14 <groupId>io.qameta.allure</groupId>
15 <artifactId>allure-junit5</artifactId>
16 <version>2.18.1</version>
17 <scope>test</scope>
18 </dependency>

然而我们添加在 build 中两个 plugin

 1 <plugin>
 2 <artifactId>maven-surefire-plugin</artifactId>
 3 <version>2.21.0</version>
 4 <configuration>
 5 <testFailureIgnore>false</testFailureIgnore>
 6 <argLine>
 7 -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
 8 </argLine>
 9 <systemProperties>
10 <property>
11 <name>junit.jupiter.extensions.autodetection.enabled</name>
12 <value>true</value>
13 </property>
14 </systemProperties>
15 </configuration>
16 <dependencies>
17 <dependency>
18 <groupId>org.junit.platform</groupId>
19 <artifactId>junit-platform-surefire-provider</artifactId>
20 <version>1.2.0</version>
21 </dependency>
22 <dependency>
23 <groupId>org.aspectj</groupId>
24 <artifactId>aspectjweaver</artifactId>
25 <version>${aspectj.version}</version>
26 </dependency>
27 </dependencies>
28
29 </plugin>
30 <plugin>
31 <groupId>io.qameta.allure</groupId>
32 <artifactId>allure-maven</artifactId>
33 <version>2.11.2</version>
34 <configuration>
35 <reportVersion>2.4.1</reportVersion>
36 </configuration>
37 </plugin>

我们用 brew 在本地安装一下 Allure （我是 mac 就用这个装了，如果你是其他环境参考后面说的文档）

1brew install allure

接着我们调整项目中的测试用例，然后执行：

1mvn clean test

接着找到你项目中 surefire-reports 的目录位置

然后执行类似如下命令：

1# 注意路径改成你自己项目的，这里只是示例
2allure serve /home/path/to/project/target/surefire-reports/

显示如下信息会自动跳转到浏览器，打开测试报告页面。

是不是很简单？

有关 Allure 安装和使用说明请参考：https://docs.qameta.io/allure-report

有关 JUnit5 就聊到这儿，日常一般的开发是够用了。更多的细节和功能，绍假设、断言等，请看官方文档，当然备不注它也有错的时候。

TestNG

TestNG is a testing framework inspired from JUnit and NUnit but introducing some new functionalities that make it more powerful and easier to use, such as:

Annotations.
Run your tests in arbitrarily big thread pools with various policies available (all methods in their own thread, one thread per test class, etc…).
Test that your code is multithread safe.
Flexible test configuration.
Support for data-driven testing (with @DataProvider).
Support for parameters.
Powerful execution model (no more TestSuite).
Supported by a variety of tools and plug-ins (Eclipse, IDEA, Maven, etc…).
Embeds BeanShell for further flexibility.
Default JDK functions for runtime and logging (no dependencies).
Dependent methods for application server testing.

上面是 TestNG 的官方介绍，看起来比 JUnit 功能还强大。有了前面 Junit 作为引子，你再看 TestNG，就好理解的多，因为概念上都差不多，只是功能和细节的不同而已。在这里我们不会展开讲 TestNG 了，但是会讨论一下选型的问题。

如果在 JUnit 5 没出来之前，比如 JUnit4 和 3 的时代，我会毫不犹豫地选择 TestNG，为什么？功能强大，好用啊。但是现在 JUnit5 来了，而且推广的势头也很猛，重要的是从功能上也不输 TestNG，那么怎么选呢？

个人觉得：

如果是后端开发，一般还是选 JUnit 5 写单元测试方便简单些，SpringBoot 也内置了 JUnit 开箱即用，从生态和社区上讲即使有坑也好解决些
如果是搞自动化测试的同学，更多的可能还是用 TestNG 方便些，之前很多遗留项目都是用的 TestNG，另外它和自动化测试工具 selenium 的搭配也早已深入人心。从设计理念到 API，都更符合测试同学的思维。

参考

动态清零？这不就是GC吗

Mon, 09 May 2022 10:56:47 +0000

GC(垃圾回收)的原因是：总会有垃圾出现需要回收，释放内存。

动态清零的原因是：总有感染者出现，需要控制。

目前看来，动态清零用的方法是 Mark-Sweep，即标记（核酸）-清理（方舱）

类比垃圾回收器有点儿像 CMS，但由于内部网格化管理实际上更像G1 这种分区回收的垃圾回收器，比如上海。

我们都知道无论是CMS还是G1都会有STW（stop the world），垃圾回收器们一般都是在高吞吐和低延迟之间做权衡。没有最好，只有最合适。

然而动态清零看起来却不是，这是个区别，它有着明显的停顿（STW），又有着比较低的吞吐。希望能够在算法上进行优化，我们的特点是内存大（人口基数大），是不是可以借鉴ZGC，ZGC 和 G1 一样是基于 reigon 的，几乎所有阶段都是并发的，整堆扫描，部分收集。它的停顿时间也明显优于G1和CMS。

目前来看北京的模式有点儿像ZGC 的特点，整堆扫描（核酸），部分收集（封控）。

另外从隔离性上讲，上海类似 docker，把自己整体容器化，资源隔离了，北京类似K8S的 Pod，对外还能保证可用性，只不过部分Pod 可能会出现问题，那就解决Pod的问题就好了。只要不全挂，因为没有冗余设备（也不可能有）。

看来动态清零是一个长期的事儿了，就像GC虽然程序员不需要时刻注意垃圾回收的问题，但它一直在后台默默运行着，帮我们解决着内存回收的问题。希望动态清零也能够优化到“静默”运行，在高吞吐和低延迟间做好 trade off。

我们能够接受和它长期并存，现实世界不是程序，希望它能够少些 STW，祝所有“容器化”的朋友们好运，宿主机会好的，等待你们重启的那一天。祝所有人平安、健康。

Java 序列化那些事儿

Fri, 06 May 2022 13:53:56 +0000

Questions

序列化与反序列化是什么？

序列化对象序列化的最主要的用处就是在传递和保存对象的时候，保证对象的完整性和可传递性。序列化是把对象转换成有序字节流，以便在网络上传输或者保存在本地文件中。核心作用是对象状态的保存与重建。
反序列化客户端从文件中或网络上获得序列化后的对象字节流，根据字节流中所保存的对象状态及描述信息，通过反序列化重建对象。

为什么需要序列化与反序列化？

对象序列化可以实现分布式对象。

主要应用例如：RMI（即远程调用 Remote Method Invocation) 要利用对象序列化运行远程主机上的服务，就像在本地机上运行对象时一样。
java 对象序列化不仅保留一个对象的数据，而且递归保存对象引用的每个对象的数据。

可以将整个对象层次写入字节流中，可以保存在文件中或在网络连接上传递。利用对象序列化可以进行对象的"深复制"，即复制对象本身及引用的对象本身。序列化一个对象可能得到整个对象序列。
序列化可以将内存中的类写入文件或数据库中。

比如：将某个类序列化后存为文件，下次读取时只需将文件中的数据反序列化就可以将原先的类还原到内存中。也可以将类序列化为流数据进行传输。

总的来说就是将一个已经实例化的类转成文件存储，下次需要实例化的时候只要反序列化即可将类实例化到内存中并保留序列化时类中的所有变量和状态。
对象、文件、数据，有许多不同的格式，很难统一传输和保存。

序列化以后就都是字节流了，无论原来是什么东西，都能变成一样的东西，就可以进行通用的格式传输或保存，传输结束以后，要再次使用，就进行反序列化还原，这样对象还是对象，文件还是文件。

如何实现 Java 序列化与反序列化

只有实现 Serializable 或 Externalizable 接口的类的对象才能被序列化

实现 Serializabel 接口

让可序列化的对象实现 Serializable 接口，然后再创建一个 ObjectOutputStream 输出流，再调用 ObjectOutputStream 对象的 writeObject() 方法进行输出可序列化对象即可

 1public class Person implements Serializable {
 2
 3 private String name;
 4
 5 private int age;
 6
 7 public Person() {
 8 }
 9
10 public Person(String name, int age) {
11 this.name = name;
12 this.age = age;
13 }
14
15 @Override
16 public String toString() {
17 return "Person{" +
18 "name='" + name + '\'' +
19 ", age=" + age +
20 '}';
21 }
22 
23 public static void main(String[] args) throws IOException {
24
25 Person person = new Person("张三", 18);
26
27 ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("/Users/xxx/logs/person.txt"));
28 // 写入对象
29 oos.writeObject(person);
30 oos.close();
31 }
32}

此外，在实现 Serializable 接口的同时，还可以重写 writeObject() 和 readObject() 方法，这样一旦对象被序列化或被反序列化，就会自动的调用这两个方法，而不会使用默认的序列化机制。

 1private void writeObject(ObjectOutputStream out) throws IOException{
 2 out.defaultWriteObject();
 3 //...
 4 System.out.println("自定义序列化方法");
 5 }
 6 
 7 private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException{
 8 in.defaultReadObject();
 9 //...
10 System.out.println("自定义反序列化方法");
11 }

还有其他三个方法，可供我们定制自己的序列化反序列化过程：

readObjectNoData() : 用于初始化反序列化对象，当发生一些情况导致反序列化对象不能获得数据时调用；
writeReplace() ：指派其他对象写入序列化的流中；
readResolve()：返回的对象替换反序列化创建的实例；

反序列化对象时，需要创建一个 ObjectInputStream 输入流，然后调用ObjectInputStream对象的 readObject() 方法得到序列化的对象即可。

1 ObjectInputStream ois = new ObjectInputStream(new FileInputStream("/Users/helong/logs/person.txt"));
2 Person p = (Person) ois.readObject();
3 System.out.println(p);

需要注意的是：

反序列化的对象是由 JVM 自己生成的对象，而不会通过构造方法生成。
如果对同一对象执行多次序列化操作，并不会得到多个对象。因为保存到磁盘的对象都有一个序列化编号，当程序试图进行序列化时，会检查该对象是否序列化过，只有该对象从未被序列化过，才会将此对象序列化为字节序列，如果此对象已经序列化过，则直接输出其序列化编号
如果一个可序列化的类的成员不是基本类型，而是引用类型，则这个引用类型也必须实现 Serializable 接口。

transient

对于不想序列化的字段可以再字段类型之前加上 transient 关键字修饰（反序列化时会被赋予默认值）

1 private transient int age;

此时将其进行反序列化后，如果该属性是引用数据类型，则返回的是 null，如果该属性是基本数据类型（如 int 类型），则会返回默认值 0（boolean 的默认值是 false）

服务器端给客户端发送序列化对象数据时，对象中有一些数据是敏感的（比如密码字符串等），如果希望对该密码字段在序列化时进行加密，而客户端如果拥有解密的密钥，只有在客户端进行反序列化时，才可以对密码进行读取，这样可以一定程度保证序列化对象的数据安全。

serialVersionUID

在进行序列化时，会把当前类的serialVersionUID写入到字节序列中（也会写入序列化的文件中），在反序列化时会将字节流中的serialVersionUID同本地对象中的serialVersionUID进行对比，一样的话进行反序列化，不一致则失败报错（报InvalidCastException异常）

serialVersionUID 如果不显式指定，VM 默认生成一个（耗费资源），如同上文中的程序。

serialVersionUID的生成有三种方式（private static final long serialVersionUID = -85899347900852467L）：

显式声明：默认的 1L
显式声明：根据包名、类名、继承关系、非私有的方法和属性以及参数、返回值等诸多因素计算出的 64 位的 hash 值
隐式声明：未显式的声明serialVersionUID时 java 序列化机制会根据 Class 自动生成一个serialVersionUID（最好不要这样，因为如果 Class 发生变化，比如新增或修改了属性，自动生成的serialVersionUID可能会随之发生变化，导致匹配不上）

序列化类增加属性时，最好不要修改serialVersionUID，避免反序列化失败

Externalizable

自定义序列化的策略

如果我们在序列化的过程中有一些别的需求，或者说，我们希望对象的一部分可以被序列化，而另一部分不被序列化，此时可以实现 Externalizable 接口，并且实现它的两个方法：writeExternal() 和 readExternal()，这两个方法会在序列化和反序列化的过程中被自动调用以便执行一些特殊的操作。

需要注意的是：

如果一个类实现了 Serializable 接口，此时对于 Serializable 对象，其对象是与二进制位的构建有关的，而不会调用构造器（正如之前的例子可知）；
而对于一个 Externalizable 对象，其所有的构造函数都会被调用，因此需要给出类的无参和有参构造才可以。

 1import java.io.*;
 2
 3public class ExPerson implements Externalizable {
 4 private String name;
 5 private int age;
 6
 7 public ExPerson() {
 8 System.out.println("无参构造。");
 9 }
10
11 public ExPerson(String name, int age) {
12 this.name = name;
13 this.age = age;
14 System.out.println("有参构造。");
15 }
16
17 @Override
18 public String toString() {
19 return name + age;
20 }
21
22 @Override
23 public void writeExternal(ObjectOutput out) throws IOException {
24 System.out.println("writeExternal() method.");
25 out.writeObject(name);
26 out.writeInt(age);
27 }
28
29 @Override
30 public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
31 System.out.println("readExternal() method.");
32 name = (String) in.readObject();
33 age = in.readInt();
34 }
35
36 public static void main(String[] args) throws IOException, ClassNotFoundException {
37 ExPerson exPerson = new ExPerson("zhangsan", 25);
38 System.out.println(exPerson);
39 // 序列化
40 ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("123.txt"));
41 System.out.println("保存对象：");
42 oos.writeObject(exPerson);
43 oos.close();
44
45 // 反序列化
46 ObjectInputStream ois = new ObjectInputStream(new FileInputStream("123.txt"));
47 System.out.println("接收对象：");
48 exPerson = (ExPerson) ois.readObject();
49 System.out.println(exPerson);
50 }
51}

总结：使用 Externalizable 进行序列化时，当读取对象时，会调用被序列化类的无参构造器去创建一个新的对象，然后再将被保存对象的字段的值分别填充到新对象中。因此，必须提供一个无参构造器，访问权限为 public；否则会抛出 java.io.InvalidClassException 异常。

静态变量

对象序列化时并不会序列化静态变量，这是因为对象序列化操作是序列化的是对象的状态，而静态变量属于类变量，也就是类的状态。因此，对象序列化并不会保存静态的变量。序列化保存的是对象的状态，而静态变量属于类的状态。

对单例的影响

序列化会通过反射调用无参的构造方法创建一个新的对象，所以序列化会破坏单例模式。

解决办法是：在单例类中手写 readResolve() 函数，直接返回单例对象：

 1public class Singleton implements Serializable {
 2
 3 private static final long serialVersionUID = -1576643344804979563L;
 4
 5 private Singleton() {
 6 }
 7
 8 private static class SingletonHolder {
 9 private static final Singleton singleton = new Singleton();
10 }
11
12 public static synchronized Singleton getSingleton() {
13 return SingletonHolder.singleton;
14 }
15 
16 private Object readResolve() {
17 return SingletonHolder.singleton;
18 }
19}

这样一来，当反序列化从流中读取对象时，readResolve() 会被调用，用其中返回的对象替代反序列化新建的对象。

其他序列化方式

JSON 序列化

主流的库有

Gson
fastJson
Jackson

fastJson 是阿里巴巴的开源 JSON 解析库。

 1 Person person = new Person("张三", 18);
 2 String str = JSON.toJSONString(person);
 3 System.out.println(str);
 4
 5 Person person1 = JSON.parseObject(str, Person.class);
 6 System.out.println(person1);
 7 
 8 输出 ========
 9 {"age":18,"name":"张三"}
10 Person(name=张三，age=18)

Gson 是 Google 公司发布的一个开源的 Java 库，也是一个高效的 JAVA 对象序列化、反序列化框架

1 Person person = new Person("张三", 18);
2 
3 Gson gson=new Gson();
4 String json=gson.toJson(person);
5 log.info("json={}",json);
6 
7 Person person2=gson.fromJson(json,Person.class);
8 log.info("person2={}",person2);

Jackson 也是 java 语言实现的开源工具，它是 Spring 中 Json 的默认实现，虽然多年未维护了，但依旧使用广泛。

有三个核心模块

Streaming (jackson-core 包）：定义了低级流式 API，包括了特定 json 的实现。
Annotations (jackson-annotations 包）：包含标准的 Jackson 注解。
Databind (jackson-databind 包）：实现了数据绑定，依赖于 Streaming 和 Annotations。（导入 jackson-databind 包会自动导入其他两个包）

1 Person person = new Person("张三", 18);
2
3 ObjectMapper objectMapper = new ObjectMapper();
4 String str = objectMapper.writeValueAsString(person);
5 
6 log.info("str = {}", str);
7 
8 Person person1 = objectMapper.readValue(str, Person.class);
9 log.info("person1 = {}", person1);

Hessian

Hessian 是一个基于二进制的协议，Hessian 支持很多种语言，例如 Java、python、c++,、net/c#、D、Erlang、PHP、Ruby、object-c 等，它的序列化和反序列化也是非常高效，与 Java 原生序列化一样，被序列化/反序列化的对象也必须实现 Serializable 接口，实现代码的写法也很像 Java 原生序列化。

注意：

hessian 是一个轻量级的 RPC 框架，序列化只是其中的功能之一，其通讯效率高于 WebService 和 Java 自带的序列化
hessian 同时也是一个远程通信的协议，Dubbo 基于 Hessian 实现了自己的 Hessian 协议，可以直接通过 Dubbo 进行远程调用

 1 Person person = new Person("张三", 18);
 2
 3 ByteArrayOutputStream os = new ByteArrayOutputStream();
 4 //Hessian 的序列化输出
 5 HessianOutput ho = new HessianOutput(os);
 6 ho.writeObject(person);
 7 byte[] bytes = os.toByteArray();
 8 log.info("bytes={}", bytes);
 9
10 //Hessian 的反序列化输出
11 ByteArrayInputStream is = new ByteArrayInputStream(bytes);
12 HessianInput ho2 = new HessianInput(is);
13 Person person2 = (Person) ho2.readObject();
14 log.info("person2={}", person2);
15

Kryo

Kryo 是一个快速高效的 Java 序列化框架，旨在提供快速、高效和易用的 API。无论文件、数据库或网络数据 Kryo 都可以随时完成序列化。Kryo 还可以执行自动深拷贝（克隆）、浅拷贝（克隆）。这是对象到对象的直接拷贝，而不是对象->字节->对象的拷贝。

Kryo 是一种非常成熟的序列化实现，已经在 Twitter、Groupon、Yahoo 以及多个著名开源项目（如 Hive、Storm）中广泛的使用。

dubbo RPC 默认的序列化用的是 hessian2，未来，当 Kryo 或者 FST 在 dubbo 中当应用足够成熟之后，dubbo 很可能会将 dubbo RPC 的默认序列化从 hessian2 改为它们中间的某一个。

 1 Person person = new Person("张三", 18);
 2
 3 Kryo kryo = new Kryo();
 4 kryo.register(Person.class);
 5
 6 Output output = new Output(1024, -1);
 7 kryo.writeObject(output, person);
 8
 9 Input input = new Input(output.getBuffer(), 0, output.position());
10 Person object2 = kryo.readObject(input, Person.class);
11 log.info("object2 = {}", object2);

Kryo 自带了很多 java 基本类的 Serializer，所以尽管不知道 Serializer，Kryo 也会自动匹配：

 1 Kryo kryo=new Kryo(); 
 2 HashMap h=new HashMap();
 3 h.put("k1", "v1");
 4 h.put("k2", "v2");
 5 Output output=new Output(1, 1024); 
 6 kryo.writeObject(output, h);
 7 output.close();
 8 byte[] data=output.toBytes();
 9 
10 Input i=new Input(data);
11 i.close();
12 HashMap h2= (HashMap)kryo.readObject(i, HashMap.class);
13 System.out.println(h2.get("k2"));

虽然 kryo 的性能很好，但目前来看在类似 SpringBoot SpringCloud 的应用中还没有实践，例如 springCloud 默认是利用 jackson（当然你也可以换成 fastJson）来进行的序列化。可能的是因为：

有改造成本，而且越底层的东西改造成本越高，搞不好就崩了，不能轻易动
远程通信的量在没有那么大情况下，一般来说 json 的性能并不是瓶颈。所以在序列化不是瓶颈的情况下也没有驱动力改。但如果序列化是瓶颈的地方，可能也就不用 Json 而改换其他协议了，比如二进制协议。

目前来看 kryo 的应用可以在与 Redis 的应用交互上。像 Redis 这样的存储工具，是可以安全地存储二进制数据的，所以可以直接把 Kryo 序列化出来的数据存进去。这里有一个例子。

MessagePack

“

It’s like JSON.but fast and small.

”

MessagePack 是一个高效的二进制序列化格式。它让你像 JSON 一样可以在各种语言之间交换数据。但是它比 JSON 更快、更小。小的整数会被编码成一个字节，短的字符串仅仅只需要比它的长度多一字节的大小。

注意，使用 messagePack 需要加 @message 注释

 1@Data
 2@Message
 3public class Person implements Serializable {
 4
 5 private static final long serialVersionUID = -2008259768794734414L;
 6
 7 private String name;
 8
 9 private int age;
10
11 public Person() {
12 }
13
14 public Person(String name, int age) {
15 this.name = name;
16 this.age = age;
17 }
18}
19
20 Person person = new Person("张三", 18);
21
22 MessagePack messagePack = new MessagePack();
23 //序列化
24 byte[] bs = messagePack.write(person);
25 System.out.println("byte array's length is : " + bs.length);
26 //反序列化
27 Person person1 = messagePack.read(bs, Person.class);
28 System.out.println(person1);

FST

FST 序列化全称是 Fast Serialization Tool，它是对 Java 序列化的替换实现。既然前文中提到 Java 序列化的两点严重不足，在 FST 中得到了较大的改善，FST 的特征如下：

JDK 提供的序列化提升了 10 倍，体积也减少 3-4 倍多
支持堆外 Maps，和堆外 Maps 的持久化
支持序列化为 JSON

1FSTConfiguration conf = FSTConfiguration.createAndroidDefaultConfiguration();
2 
3 Person person = new Person("张三", 18);
4 byte[] bytes = conf.asByteArray(person);
5 Person newObject = (Person) conf.asObject(bytes);
6 System.out.println("deSerialization, " + newObject);

Dubbo 中对 FstObjectInput 和 FstObjectOutput 重新包装解决了序列化和反序列化空指针的问题。

并且构造了 FstFactory 工厂类，使用工厂模式生成 FstObjectInput 和 FstObjectOutput。其中同时使用单例模式，控制整个应用中 FstConfiguration 是单例，并且在初始化时将需要序列化的对象全部注册到 FstConfiguration。

对外提供了统一的序列化接口 FstSerialization，提供 serialize 和 deserialize 能力。

Protobuf

Protocol buffers 是由 Google 公司发布的数据交换格式，提供跨语言、跨平台的序列化和反序列化实现，底层由 C++实现

基于 java 使用 protobuf 还是有些麻烦的，可以参考：https://developers.google.com/protocol-buffers/docs/javatutorial

步骤是：

定义 .proto 文件
编译 proto 文件
利用 protobuf API 开始读写

引入

 1<properties>
 2 <protoc.version>3.17.2</protoc.version>
 3</properties>
 4
 5<dependencies>
 6
 7 <dependency>
 8 <groupId>com.google.protobuf</groupId>
 9 <artifactId>protobuf-java</artifactId>
10 <version>${protoc.version}</version>
11 </dependency>
12</dependencies>

在 src/main 下新建目录 proto，proto 目录下新建文件student.proto

 1syntax="proto3";
 2
 3option java_package="com.example.proto";
 4option java_multiple_files = false;
 5option java_outer_classname="StudentProto";
 6
 7message Student {
 8
 9 int32 id = 1;
10
11 string name = 2;
12
13 string email = 3;
14
15 string friends = 4;
16}
17
18message StudentArray {
19 repeated Student student = 1;
20}

下载 protoc，使用 protoc 命令编译 proto 文件，编译到 java 目录下

1protoc student.proto --java_out=../java/

使用 mvn protobuf:compile编译 proto 文件

 1<properties>
 2 <protoc.version>3.17.2</protoc.version>
 3</properties>
 4
 5<dependencies>
 6
 7 <dependency>
 8 <groupId>com.google.protobuf</groupId>
 9 <artifactId>protobuf-java</artifactId>
10 <version>${protoc.version}</version>
11 </dependency>
12</dependencies>
13
14<build>
15 <extensions>
16 <extension>
17 <groupId>kr.motd.maven</groupId>
18 <artifactId>os-maven-plugin</artifactId>
19 <version>1.5.0.Final</version>
20 </extension>
21 </extensions>
22 <plugins>
23 <plugin>
24 <groupId>org.xolstice.maven.plugins</groupId>
25 <artifactId>protobuf-maven-plugin</artifactId>
26 <version>0.5.1</version>
27 <extensions>true</extensions>
28 <configuration>
29 <protocArtifact>com.google.protobuf:protoc:${protoc.version}:exe:${os.detected.classifier}</protocArtifact>
30 <pluginId>protoc-java</pluginId>
31 <protoSourceRoot>${project.basedir}/src/main/proto</protoSourceRoot>
32 <outputDirectory>${project.build.sourceDirectory}</outputDirectory>
33 <clearOutputDirectory>false</clearOutputDirectory>
34 </configuration>
35 <executions>
36 <execution>
37 <goals>
38 <goal>compile</goal>
39 </goals>
40 </execution>
41 </executions>
42 </plugin>
43 </plugins>
44</build>

使用

 1@Test
 2public void test1() throws InvalidProtocolBufferException {
 3 StudentProto.Student student1 = StudentProto.Student.newBuilder()
 4 .setId(10)
 5 .setName("zhangsan")
 6 .setEmail("activepirate@163.com")
 7 .setFriends("lisi")
 8 .build();
 9
10 // byte[] studentBytes1 = student1.toByteArray();
11 // System.out.println(new String(studentBytes1));
12
13 StudentProto.Student student2 = StudentProto.Student.newBuilder()
14 .setId(11)
15 .setName("zhangsan")
16 .setEmail("activepirate@163.com")
17 .setFriends("lisi")
18 .build();
19
20 StudentProto.StudentArray studentArray = StudentProto.StudentArray.newBuilder()
21 .addStudent(student1)
22 .addStudent(student2)
23 .build();
24
25 byte[] bytes = studentArray.toByteArray();
26 System.out.println(new String(bytes));
27
28 List<StudentProto.Student> studentList = StudentProto.StudentArray.newBuilder().mergeFrom(bytes).build().getStudentList();
29}

protobuf 优缺点：

优点：

性能好/效率高

时间开销：XML 格式化（序列化）的开销还好；但是 XML 解析（反序列化）的开销就不敢恭维了。但是 protobuf 在这个方面就进行了优化。可以使序列化和反序列化的时间开销都减短。空间开销：也减少了很多
有代码生成机制

比如你你写个一下类似结构体的内容

1 message testA 
2 { 
3
4 required int32 m_testA = 1; 
5
6 }
7
8像写一个这样的结构，protobuf 可以自动生成它的。h 文件和点。cpp 文件。protobuf 将对结构体 testA 的操作封装成一个类。

支持向后兼容和向前兼容

当客户端和服务器同事使用一块协议的时候，当客户端在协议中增加一个字节，并不会影响客户端的使用
支持多种编程语言

在 Google 官方发布的源代码中包含了 c++、java、Python 三种语言

缺点

二进制格式导致可读性差

为了提高性能，protobuf 采用了二进制格式进行编码。这直接导致了可读性差。这个直接影响开发测试时候的效率。当然，一般情况下，protobuf 非常可靠，并不会出现太大的问题。
缺乏自描述

一般来说，XML 是自描述的，而 protobuf 格式则不是。给你一段二进制格式的协议内容，不配合你写的结构体是看不出来什么作用的。
通用性差

protobuf 虽然支持了大量语言的序列化和反序列化，但仍然并不是一个跨平台和语言的传输标准。在多平台消息传递中，对其他项目的兼容性并不是很好，需要做相应的适配改造工作。相比 json 和 XML，通用性还是没那么好。

Protostuff

使用 protobuf，我们还要写 proto 文件，并且我们还要使用工具来编译生成 java 文件，实在太麻烦。protostuff能够很好的解决这个问题。
protostuff 也是谷歌的产品，它是基于 protobuf 发展而来的，相对于 protobuf 提供了更多的功能和更简易的用法。
其实 protostuff 也是有局限性的，比如说在序列化的文件在 10M 以下的时候，还是使用 java 自带的序列化机制比较好，但是文件比较大的时候还是 protostuff 好一点，这里的 10M 不是严格的界限。

 1 Person person = new Person("张三", 18);
 2
 3 Schema<Person> schema = RuntimeSchema.getSchema(Person.class);
 4
 5 // Re-use (manage) this buffer to avoid allocating on every serialization
 6 LinkedBuffer buffer = LinkedBuffer.allocate(512);
 7
 8 // 序列化
 9 final byte[] protostuff;
10 try {
11 protostuff = ProtostuffIOUtil.toByteArray(person, schema, buffer);
12 } finally {
13 buffer.clear();
14 }
15
16 // 反序列化
17 Person personParsed = schema.newMessage();
18 ProtostuffIOUtil.mergeFrom(protostuff, personParsed, schema);
19 System.out.println(personParsed.toString());

Thrift

Thrift 是一套包含序列化功能和支持服务通信的 RPC 框架，主要包含三大部分：代码生成、序列化框架、RPC 框架，大致相当于 protoc + protobuffer + grpc，并且支持大量语言，保证常用功能在跨语言间功能一致，是一套全栈式的 RPC 解决方案。Thrift 最初由 FaceBook 开发，之后由 ASF 管理。

Thrift 支持多种序列化协议，常用的有：Binary、Compact、JSON

thrift 的序列化和反序列化步骤：

创建 thrift 接口定义文件；
将 thrift 的定义文件转换为对应语言的源代码；
选择相应的 protocol，进行序列化和反序列化

看起来步骤有点儿像 protobuf，所以还是相对麻烦的。这里就不做代码演示了。

Avro

Avro（读音类似于 [ævrə]）是 Hadoop 的一个子项目，由 Hadoop 的创始人 Doug Cutting（也是 Lucene，Nutch 等项目的创始人）牵头开发。Avro 是一个基于二进制数据传输高性能的中间件。在 Hadoop 的其他项目中例如 HBase 和 Hive 的 Client 端与服务端的数据传输也采用了这个工具。Avro 是一个数据序列化的系统。Avro 可以将数据结构或对象转化成便于存储或传输的格式。Avro 设计之初就用来支持数据密集型应用，适合于远程或本地大规模数据的存储和交换。它的主要特点有：

丰富的数据结构类型；
快速可压缩的二进制数据形式，对数据二进制序列化后可以节约数据存储空间和网络传输带宽；
存储持久数据的文件容器；
可以实现远程过程调用 RPC；
简单的动态语言结合功能。

Avro 提供了两种序列化和反序列化的方式，一种是通过 Schema 文件来生成代码的方式，一种是不生成代码的通用方式。

性能对比

解析性能

序列化之空间开销

Json 序列化性能比较

三种 Json 序列化实现里，fastJson 最好，jackson 其次，gson 最差

各序列化框架对 Java 数据类型支持的对比

选型建议

以上描述的序列化和反序列化协议都各自具有相应的特点，适用于不同的场景：

基于 Web browser 的 Ajax，以及 Mobile app 与服务端之间的通讯，JSON 协议是首选。对于性能要求不太高，或者以动态类型语言为主，或者传输数据载荷很小的的运用场景，JSON 也是非常不错的选择。
对于调试环境比较恶劣的场景，采用 JSON 或 XML 能够极大的提高调试效率，降低系统开发成本。
当对性能和简洁性有极高要求的场景，Protobuf，Thrift，Avro 之间具有一定的竞争关系。
对于 T 级别的数据的持久化应用场景，Protobuf 和 Avro 是首要选择。如果持久化后的数据存储在 Hadoop 子项目里，Avro 会是更好的选择。
由于 Avro 的设计理念偏向于动态类型语言，对于动态语言为主的应用场景，Avro 是更好的选择。
对于持久层非 Hadoop 项目，以静态类型语言为主的应用场景，Protobuf 会更符合静态类型语言工程师的开发习惯。
如果需要提供一个完整的 RPC 解决方案，Thrift 是一个好的选择。
如果序列化之后需要支持不同的传输层协议，或者需要跨防火墙访问的高性能场景，Protobuf 可以优先考虑。

附录

以上代码中所有相关库的 maven 依赖如下：

 1 <!-- fastjson -->
 2 <dependency>
 3 <groupId>com.alibaba</groupId>
 4 <artifactId>fastjson</artifactId>
 5 <version>1.2.80</version>
 6 </dependency>
 7
 8 <!-- gson -->
 9 <dependency>
10 <groupId>com.google.code.gson</groupId>
11 <artifactId>gson</artifactId>
12 <version>2.8.6</version>
13 </dependency>
14
15 <!-- jackson-databind -->
16 <dependency>
17 <groupId>com.fasterxml.jackson.core</groupId>
18 <artifactId>jackson-databind</artifactId>
19 <version>2.13.2.2</version>
20 </dependency>
21
22 <!-- hessian -->
23 <dependency>
24 <groupId>com.caucho</groupId>
25 <artifactId>hessian</artifactId>
26 <version>4.0.66</version>
27 </dependency>
28
29 <!-- kryo -->
30 <dependency>
31 <groupId>com.esotericsoftware</groupId>
32 <artifactId>kryo</artifactId>
33 <version>5.3.0</version>
34 </dependency>
35
36 <!-- msgPack -->
37 <dependency>
38 <groupId>org.msgpack</groupId>
39 <artifactId>msgpack</artifactId>
40 <version>0.6.12</version>
41 </dependency>
42
43 <!-- protostuff-->
44 <dependency>
45 <groupId>io.protostuff</groupId>
46 <artifactId>protostuff-core</artifactId>
47 <version>1.7.4</version>
48 </dependency>
49 <dependency>
50 <groupId>io.protostuff</groupId>
51 <artifactId>protostuff-runtime</artifactId>
52 <version>1.7.4</version>
53 </dependency>
54 <!-- FST -->
55 <dependency>
56 <groupId>de.ruedigermoeller</groupId>
57 <artifactId>fst</artifactId>
58 <version>2.56</version>
59 </dependency>

JVM on 小盒子的技术分享

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

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

定义

什么时候用?

不要滥用

实现方式

枚举

静态内部类

Spring 是如何实现单例的？

1. 核心数据结构：ConcurrentHashMap

2. Spring 创建单例的流程

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

今日 AI 情报（2025-11-10）

Shopify 构建生产级 Agentic 系统的方法分析

概述

Sidekick

Sidekick 是什么

Sidekick 能做什么

关键工程挑战与应对策略

1. 工具集成扩张导致的复杂性激增

2. 系统可靠性与评估难题

3. 推理控制与模型优化（强化学习反馈回路）

Shopify 的设计选择及对业界的启示

1. 单智能体架构与 Agentic Loop 模式

2. 核心组件的模块化解耦

3. 工具与智能体解耦，严格边界管理

4. 引入持续反馈的评估与测试机制

5. 训练和推理闭环的结合

总结

搞懂 ThreadLocal，其实就三件事：它是谁？它在哪？用完它咋办？

缘起

ThreadLocal 它根本上是干嘛的？

反向存储

内部存储

隔离机制

内存泄露风险

弱引用

键没了，变成 null 了，那不是正好吗？

那为啥不干脆把那个 value 也用弱引用呢？

这对开发者意味着什么 ？

java 新版本

java 17

java 21

总结

Java老兵的十字路口：坚守还是突围？

Java在技术江湖中的现状：稳固基石还是夕阳西下？

Java 面临的核心挑战：笨重背后的突围

微服务部署压力

启动速度与样板代码

并发与性能困境

GraalVM 与原生执行

用舍之道：哪些场景放弃 Java，哪些场景坚持 Java？

场景一：边缘计算与Serverless – 谨慎使用 Java。

场景二：高性能微服务 – 视情况取舍

场景三：大型核心系统 – 坚定拥抱 Java

Java老兵的自我进化：坚守阵地or华丽转型？

拥抱Java新特性，跟上生态演进

拓展多元技能栈，成为“T型”人才

深入业务和架构，提升不可替代性

考虑转型技术管理或其他新领域

最后

Java 和 JVM 自 JDK 8 至 21 的特性概览

引言

Java 的历史和发展

JDK 8 至 21 的重要性

本文的目的和结构

新语言特性详细解析

模式匹配（Pattern Matching）

未命名变量和未命名模式

封闭类和记录类

其他重要语言特性

新 APIs 的探索

集合和数学函数 API

其他重要 API 更新

性能改进的深入分析

内存管理和垃圾回收

JIT 编译器和运行时性能

安全改进的全面审视

加密和认证 API

这对开发者意味着什么？

动态清零？这不就是GC吗