06 · 现代栈与前沿

6.1Boot 4.0 改了什么（2025-11 GA，4.0.6 / 2026-04）

Boot 4.0 于 2025-11 发布 GA，当前最新稳定版为 4.0.6（2026-04）。底层依赖升至 Spring Framework 7 + Jakarta EE 11——所有包名从 javax.* 改为 jakarta.*，这是自 Boot 3.0 以来的第二次命名空间迁移。

主要破坏性变更：Jackson 3 成为默认序列化库（Jackson 2 的 DeserializationFeature 等 API 有不兼容变动）；内嵌服务器中 Undertow 已移除，选项只剩 Tomcat（默认）和 Jetty，响应式栈仍用 Netty；Spock 测试框架支持移除；Java 17 是最低运行时（构建链路用到 Java 25 特性）。

并行维护的 3.5.x 仍在接收补丁（长期维护分支）；4.1.0-RC1（2026-04） 已发布，GA 在即，带入 Java 25 AOT cache 支持（见 6.4 节）。

6.2可观测性：Micrometer 取代 Sleuth（3.0 起稳定）

可观测性的统一入口是 Micrometer Observation API——它把 metrics 和 traces 收归同一个埋点模型。

Spring Cloud Sleuth 已于 2022-12 进入 attic（归档），未移植到 Boot 3+。Boot 3.0 起，分布式追踪由 Micrometer Tracing 承接，底层可对接 Zipkin、Jaeger、OTLP 等后端。Trace context 默认遵循 W3C Trace Context 规范，traceId 为 128-bit。

埋点方式：直接使用 ObservationRegistry 或注解 @Observed（Boot 3.2+ 自动为 Spring MVC 控制器、Spring Data 方法、Kafka listener 等织入 observation）。Actuator 的 /actuator/metrics 和 /actuator/httptrace（Boot 4.0 已更名为 /actuator/httpexchanges）继续可用。

6.3虚拟线程（3.2 起）与瓶颈转移

开启虚拟线程后，服务器线程数不再是吞吐上限——新瓶颈是 HikariCP 的连接池大小。

Java 21 正式发布虚拟线程（Project Loom GA）。Boot 3.2（2023-11）随即引入一行配置支持：

spring:
  threads:
    virtual:
      enabled: true   # Java 21+；Tomcat 改用虚拟线程派发请求

效果：Tomcat 的请求派发线程由平台线程换成虚拟线程。虚拟线程是 JVM 层面轻量级调度单元，阻塞 I/O 时不占用 OS 线程，因此 server.tomcat.threads.max（默认 200）这个上限几乎不再成为瓶颈——系统可以并发数千个请求，每个请求阻塞等待数据库时不耗 OS 线程。

但瓶颈立刻转移到 HikariCP。 HikariCP 默认连接池大小为 10。当 5000 个虚拟线程同时发起数据库调用时，999 个在 HikariCP 的等待队列里排队，超时抛出 Connection is not available, request timed out after 30000ms。

正确做法：开虚拟线程的同时按预期并发量调大连接池。

spring:
  threads:
    virtual:
      enabled: true
  datasource:
    hikari:
      maximum-pool-size: 50   # 按实际 DB 并发承载量设置，非越大越好

6.4三条快启动路线

降低启动时间与内存占用有三条正交路线，各有不同的成本结构（2026-06 现状）：

CDS（Class Data Sharing，Boot 3.3+）

JVM 的 CDS 把已解析的类元数据持久化到共享归档文件，下次启动直接 mmap 进内存，跳过类加载与字节码校验。Boot 3.3（2024-05）通过 spring-boot:process-aot + JVM flag 自动化 CDS 归档生成。启动时间缩短约 20–40%，无"闭世界"约束，对反射友好。代价：归档文件与应用版本绑定，每次升级 jar 需重新生成；容器镜像须固定 JVM 版本。

GraalVM 原生镜像（stable since Boot 3.0，2022-11）

GraalVM 的 native-image 工具在构建期做闭世界分析（closed-world analysis）：把可达代码、反射元数据、资源清单全部静态分析并编译进单一可执行文件。结果：启动 50–100ms（JVM 同等应用 2–8s），RSS 减半。

代价是"闭世界"约束：运行时反射需要 AOT hints。Boot 的 RuntimeHintsRegistrar 和 @RegisterReflectionForBinding 用于声明反射需求；Boot 自身及主流 starter 已内置 hints，但自定义代码（尤其是动态类加载、第三方库的非注册反射）需手动补充，否则 native 镜像运行时抛 MissingReflectionDataException。验证手段：native:test goal 在 native 镜像内跑测试套件。

Java 25 AOT cache（Boot 4.1，2026-04 RC1）

Java 25 引入应用层 AOT 缓存（JEP 483），把 JIT 编译后的代码缓存到磁盘，下次启动直接加载已编译代码，跳过 JIT 热身阶段。Boot 4.1.0-RC1（2026-04）已对接此特性。与 GraalVM native 相比，无闭世界约束，仍是标准 JVM，但热身阶段缩短显著。GA 时间待定。

6.5Spring AI（1.0 GA 2025-05，1.1 GA 2025-11）

Spring AI 是同一套自动配置模型的延伸——starter + @Conditional + 自动装配的 ChatClient，没有引入新的容器机制。

Spring AI 1.0 于 2025-05 发布 GA；1.1 于 2025-11 发布 GA，新增 MCP（Model Context Protocol）集成。核心 API：

• ChatClient（1.0 重命名自 ChatModel）：统一跨 20+ 模型提供商（OpenAI、Anthropic、Google Gemini、Ollama 等）的对话接口，通过 spring-ai-{provider}-spring-boot-starter 引入对应实现
• EmbeddingModel：文本向量化；VectorStore：向量相似度检索（对接 pgvector、Chroma、Redis、Qdrant 等）
• 工具/函数调用：通过 @Tool 注解将 Spring Bean 方法暴露给模型
• QuestionAnswerAdvisor（RAG 检索增强生成）：内置 Advisor 链，自动把向量检索结果注入 prompt context
• MCP 集成（1.1）：spring-ai-mcp-spring-boot-starter，把 Spring 应用作为 MCP Server 或 MCP Client 暴露/消费工具

它的自动配置完全遵循第 3 章的机制：ChatClientAutoConfiguration 带 @ConditionalOnClass(ChatModel.class)，只在对应 provider starter 在 classpath 上时激活；用户自定义 ChatClient.Builder Bean 会触发 @ConditionalOnMissingBean back-off（见第 3 章 3.5 节）。

如果对 MCP 协议的 wire-level 机制感兴趣，可参考同系列教程：MCP 协议深挖；RAG 的向量检索与召回机制参见：RAG 系统设计。

<!-- Spring AI 1.1 BOM (GA 2025-11) -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.ai</groupId>
      <artifactId>spring-ai-bom</artifactId>
      <version>1.1.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <!-- OpenAI provider -->
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
  </dependency>
  <!-- MCP integration (1.1+) -->
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-mcp-spring-boot-starter</artifactId>
  </dependency>
</dependencies>

6.6选型轴：Spring vs Quarkus / Micronaut

三个框架在 DI 机制上的根本差异（2026-06）：

Spring 的 AOT + 原生镜像路线（Boot 3.0+）缩小了启动差距，但构建时间与闭世界调试成本仍高于 Quarkus/Micronaut。决策轴：

• 已有大量 Spring 代码或生态依赖（Spring Data、Spring Security、Spring AI）→ Boot + CDS 或 Boot + Native
• 全新项目、Serverless / FaaS、对启动时间极敏感、团队愿意接受编译期约束 → Quarkus 或 Micronaut
• 需要 GraalVM native 但又不想处理反射 hints → Quarkus（其 ArC 容器天生无运行时反射）