1. 概述

随着技术的发展，现代应用程序越来越多地采用自然语言界面来简化用户与系统的交互。这种方式在数据检索场景中尤其实用，让非技术用户也能通过简单的自然语言提问来获取所需信息。

文本转 SQL 聊天机器人就是这样一个典型应用。它就像是人类语言和数据库之间的翻译官，通过大型语言模型（LLM）将用户的自然语言问题转换为可执行的 SQL 查询，然后在数据库中执行查询并返回结果。

本文将带你使用 Spring AI 构建一个文本转 SQL 聊天机器人。我们会从零开始配置数据库模式和初始数据，然后实现一个能够理解自然语言并生成 SQL 查询的智能聊天机器人。

2. 项目搭建

在开始实现聊天机器人之前，我们需要先添加必要的依赖项并完成应用程序的基础配置。

本文将使用 Anthropic 的 Claude 模型来构建文本转 SQL 聊天机器人。当然，你也可以选择其他 AI 模型，比如通过 Hugging Face 或 Ollama 使用本地 LLM，因为具体的 AI 模型选择并不影响整体实现方案。

2.1. 添加依赖

首先，我们需要在项目的 pom.xml 文件中添加必要的依赖：

这个 Anthropic starter 依赖是 Anthropic Message API 的封装，我们将通过它来与 Claude 模型进行交互。

接下来，在 application.yaml 文件中配置 Anthropic API 密钥和聊天模型：

这里使用 ${} 属性占位符从环境变量中加载 API 密钥，这是一种安全的配置方式。

我们选择了 Claude 4 Opus 模型，这是 Anthropic 目前最智能的模型，对应的模型 ID 是 claude-opus-4-20250514。你也可以根据实际需求选择其他模型。

完成上述配置后，Spring AI 会自动创建 ChatModel 类型的 Bean，这样我们就可以直接与指定的模型进行交互了。

2.2. 使用 Flyway 设计数据库表

接下来，我们需要设计数据库模式。这里使用 Flyway 来管理数据库迁移脚本，确保数据库结构的版本控制。

我们将在 MySQL 数据库中创建一个简单的巫师管理系统数据库。和 AI 模型选择一样，具体的数据库类型并不影响我们的实现方案。

首先，在 src/main/resources/db/migration 目录下创建名为 V01__creating_database_tables.sql 的迁移脚本，用于创建核心数据表：

这里创建了两个核心表：hogwarts_houses 表用于存储霍格沃茨各学院的信息，wizards 表用于存储巫师的详细信息。wizards 表通过外键约束与 hogwarts_houses 表关联，形成一对多的关系。

接下来，创建 V02__adding_hogwarts_houses_data.sql 文件来初始化 hogwarts_houses 表的数据：

这里通过 INSERT 语句插入四个霍格沃茨学院的基础信息，包括创始人、学院颜色和象征动物。

同样地，创建 V03__adding_wizards_data.sql 迁移脚本来初始化 wizards 表的数据：

定义好这些迁移脚本后，Flyway 会在应用程序启动时自动发现并按顺序执行这些脚本。

3. 配置 AI 提示词

为了让 LLM 能够针对我们的数据库模式生成准确的 SQL 查询，我们需要精心设计一个系统提示词。

在 src/main/resources 目录下创建 system-prompt.st 文件：

在这个系统提示词中，我们明确指示 LLM 只能生成 SELECT 查询，并且要能识别和拒绝 SQL 注入和 DoS 攻击。

注意提示词模板中的 ddl 占位符，我们会在后续步骤中将其替换为实际的数据库结构信息。

另外，为了进一步保障数据库安全，建议为应用程序创建一个只读权限的 MySQL 用户：

上述 SQL 命令创建了一个只读用户，并仅授予其对相关数据表的查询权限，这样即使出现意外情况也不会对数据造成破坏。

4. 构建文本转 SQL 聊天机器人

完成基础配置后，现在我们可以开始构建文本转 SQL 聊天机器人了。

4.1. 定义核心 Bean

首先，我们需要为聊天机器人定义必要的 Bean 组件：

首先定义 PromptTemplate Bean，通过 @Value 注解注入系统提示模板文件和数据库 DDL 脚本。关键是要用实际的数据库结构信息填充 ddl 占位符，这样 LLM 就能准确理解我们的数据库结构并生成正确的 SQL 查询。

然后基于 ChatModel 和 PromptTemplate 创建 ChatClient Bean。ChatClient 是我们与 Claude 模型交互的核心组件。

4.2. 实现业务服务

接下来，我们需要实现核心的业务服务来处理 SQL 生成和执行流程。

首先创建 SqlGenerator 服务类，负责将自然语言转换为 SQL 查询：

在 generate() 方法中，我们接收用户的自然语言问题，通过 chatClient 发送给 LLM 进行处理。

为了确保安全性，我们会验证返回的结果确实是 SELECT 查询。如果 LLM 返回的不是 SELECT 查询，就抛出自定义的 InvalidQueryException 异常。

接下来创建 SqlExecutor 服务类，负责执行生成的 SQL 查询：

在 execute() 方法中，我们使用 EntityManager 来执行原生 SQL 查询并返回结果。如果查询结果为空，则抛出自定义的 EmptyResultException 异常。

4.3. 提供 REST API

完成服务层的实现后，我们需要提供 REST API 接口供外部调用：

POST /query 接口的处理流程是：接收自然语言问题 → 通过 sqlGenerator 生成 SQL 查询 → 使用 sqlExecutor 执行查询获取结果 → 将结果封装在 QueryResponse 中返回。

5. 测试聊天机器人

现在我们可以通过 API 接口来测试文本转 SQL 聊天机器人的功能了。

为了便于调试，先在 application.yaml 文件中开启 SQL 日志，这样可以在控制台看到生成的 SQL 语句：

接下来，使用 HTTPie CLI 工具来调用 API 接口，测试聊天机器人的功能：

这里我们向聊天机器人发送了一个自然语言问题，来看看它的响应结果：

可以看到，聊天机器人成功理解了我们关于斯莱特林学院巫师的查询需求，并准确返回了三个巫师的姓名和血统信息。

我们再来看看应用程序日志中 LLM 生成的 SQL 查询语句：

生成的 SQL 查询完美地理解了我们的自然语言需求，通过 JOIN 操作关联 wizards 和 hogwarts_houses 表来查找斯莱特林学院的巫师，并使用 LIMIT 限制返回三条记录。

6. 总结

本文详细介绍了如何使用 Spring AI 构建一个文本转 SQL 聊天机器人。

我们从项目搭建开始，完成了 AI 模型和数据库的配置工作。然后构建了一个能够理解自然语言并生成准确 SQL 查询的智能聊天机器人，并基于霍格沃茨巫师管理系统进行了实际演示。最后通过 REST API 提供服务接口，并验证了整个系统的可用性。

这种文本转 SQL 的解决方案可以大大降低数据查询的技术门槛，让非技术用户也能轻松获取数据库中的信息，在实际业务场景中具有很高的应用价值。

Spring Boot 作为构建现代 Java 应用程序的强大框架，为开发者提供了多种处理并发和可扩展性的解决方案。其中最受关注的两种方案是 Spring Boot 虚拟线程（Java 21 引入）和 Spring Boot WebFlux（基于响应式编程）。虽然两者都致力于优化资源利用率和提升高并发处理能力，但在编程范式、复杂度和适用场景方面却存在显著差异。本文将深入对比这两种技术方案，帮助您为项目选择最合适的解决方案。

技术方案概览

Spring Boot 虚拟线程

虚拟线程是 Java 21 中 Project Loom 项目的核心成果，它是一种由 JVM 管理的轻量级线程。相比于直接映射到操作系统线程、资源开销较大的传统平台线程，虚拟线程能够让数百万个线程在少量操作系统线程池上高效运行。这一特性使其特别适合 I/O 密集型工作场景，比如包含数据库调用、API 请求或文件操作的 Web 应用程序。

在 Spring Boot 3.2+ 版本中，虚拟线程实现了无缝集成。只需简单配置应用程序启用虚拟线程（如设置 spring.threads.virtual.enabled=true），每个 HTTP 请求就能在独立的虚拟线程上运行，既简化了并发处理，又无需改变传统的阻塞式编程模型。

Spring Boot WebFlux

Spring WebFlux 于 Spring 5 版本引入，基于 Project Reactor 构建的响应式编程理念。它专门针对非阻塞、异步处理场景设计，通过事件循环和背压机制，让单个线程能够处理多个请求。WebFlux 在高并发、低延迟场景下表现卓越，特别适合流数据处理或大量 I/O 操作的微服务架构。

WebFlux 要求开发者转向响应式编程模式，需要使用 Mono 和 Flux 等响应式类型，并通过函数式编程进行操作链接。相比传统 Spring MVC 的命令式编程风格，这种转变会带来一定的学习成本和复杂度。

核心对比维度

1. 编程模式

• 虚拟线程：延续了熟悉的命令式、阻塞编程模式。开发者可以编写传统的顺序代码（如使用 Thread.sleep、JDBC 或阻塞式 HTTP 客户端），无需关心并发处理细节。虚拟线程在底层自动处理可扩展性问题，让代码更易于维护和调试。
• WebFlux：必须采用响应式、非阻塞编程模式。开发者需要从流处理、背压控制和异步操作的角度思考问题。这对不熟悉响应式编程的团队来说学习曲线较陡，链式操作（如 flatMap、subscribe）也会增加代码阅读难度。

优势方：虚拟线程，凭借其简洁性和易用性胜出。

2. 性能与可扩展性

• 虚拟线程：在 I/O 密集型场景下表现优异，如包含数据库查询或外部 API 调用的 Web 应用。虚拟线程大幅降低了线程管理开销，使应用能够处理成千上万甚至数百万的并发请求。早期基准测试（如 Spring Boot 3.2 配合 Java 21）显示，虚拟线程在典型 Web 场景中能达到与 WebFlux 相当的吞吐量，某些情况下内存占用更低。
• WebFlux：专为高并发、低延迟场景优化，特别是在处理流数据或长连接（如 WebSockets）时。在特定场景下，WebFlux 能够超越虚拟线程，比如在有限硬件资源上处理海量并发连接时，其事件循环模型优势明显。不过，响应式技术栈通常需要精心调优，以避免回调地狱或资源泄漏等问题。

优势方：平分秋色，具体取决于应用场景。虚拟线程适合通用 Web 应用；WebFlux 更适合流处理或超低延迟场景。

3. 生态兼容性

• 虚拟线程：与现有 Spring MVC 应用和阻塞式类库（如 JPA、JDBC、RestTemplate）完全兼容。开发者只需最少的代码修改就能迁移到虚拟线程，是遗留项目的理想升级方案。不过，虚拟线程仅支持 Java 21+，需要升级 JVM 版本。
• WebFlux：需要配套的响应式类库（如 R2DBC、WebClient），必须摒弃阻塞式 API。许多传统类库（如 JPA、JDBC）无法直接使用，开发者被迫采用响应式替代方案或寻找变通办法。这会限制生态系统支持，增加现有项目的重构工作量。

优势方：虚拟线程，凭借更广泛的兼容性和更低的迁移成本获胜。

4. 开发效率

• 虚拟线程：让开发者专注于业务逻辑，无需纠结并发处理或响应式编程模式，显著提升开发效率。调试过程简单直观，堆栈跟踪清晰易读。虚拟线程还减少了复杂线程池配置的需求。
• WebFlux：响应式编程的学习曲线和额外复杂度可能拖慢开发进度。调试响应式代码更具挑战性，堆栈跟踪往往涉及反应器操作符和异步边界。团队可能需要专门培训才能熟练使用 WebFlux。

优势方：虚拟线程，在开发速度和维护便利性方面更胜一筹。

5. 适用场景

• 虚拟线程：非常适合传统 Web 应用、REST API 和包含 I/O 密集型操作（如数据库查询、HTTP 调用）的微服务。对于需要升级现有 Spring MVC 应用或构建低复杂度新应用的团队来说，是绝佳选择。
• WebFlux：最适合高并发、低延迟应用场景，如实时数据流、即时通讯应用或需要长连接的系统。在非阻塞 I/O 至关重要的微服务架构中也表现出色。

优势方：因场景而异，需要根据具体项目需求判断。

实战代码对比

让我们通过简单的 REST 接口来对比两种技术方案。

虚拟线程（Spring MVC）

• 代码简洁，采用命令式风格。
• 配置后自动运行在虚拟线程上。
• 兼容 JPA 等阻塞式 API。

WebFlux 方案

• 需要响应式服务和 Mono 返回类型。
• 非阻塞处理，但编写和维护更复杂。
• 需要配套的响应式类库（如 R2DBC）。

技术选型指南

选择虚拟线程的情况：

• 构建或维护传统 Web 应用或 REST API
• 团队偏好简单的命令式编程模式
• 需要升级现有 Spring MVC 应用
• 工作负载以中高并发的 I/O 密集型为主
• 希望保持广泛的生态兼容性，避免大规模重构

选择 WebFlux 的情况：

• 构建高并发、低延迟应用（如流处理、WebSocket 应用）
• 架构要求端到端的非阻塞 I/O
• 团队具备响应式编程经验
• 启动全新项目，可以采用响应式技术栈

总结

Spring Boot 虚拟线程和 WebFlux 都是构建可扩展应用的强大工具，但各自适用于不同的需求场景。虚拟线程 凭借其简洁性、兼容性和以最小改动实现高并发处理的能力，成为大多数项目的首选方案。它为传统 Spring MVC 应用带来了革命性改变，在保持简单性的同时提供了接近响应式的性能表现。而 WebFlux 在需要超低延迟或流处理的特殊场景中仍然具有不可替代的价值，其响应式模型在这些领域表现卓越。

对于 2025 年的大多数开发者而言，虚拟线程在性能和开发效率之间找到了最佳平衡点，使其成为默认选择。除非项目有特殊需求必须使用 WebFlux 的响应式特性，否则虚拟线程都是更明智的选择。建议根据项目需求、团队技术储备和生态系统约束来做出最终决策。

说实话，文件上传问题是后端开发中最令人头疼的 bug 之一。我至今还记得第一次遇到 Spring Boot 应用拒绝上传大于 10MB 文件的情况。小文件上传一切正常，但当我尝试上传更大的文件时——砰！各种错误接踵而至。如果你也遇到过这种情况，相信我，你绝对不是一个人在战斗。

接下来我会详细解释问题的原因、解决方案，以及如何让你的 Spring Boot 应用顺利处理大文件上传。

问题一："为什么超过 10MB 就报错？"

用户们愉快地上传头像和文档，一切都很顺利。直到有人尝试上传一个大约 12MB 的 PDF 文件，他们没有看到成功提示，而是收到了 "413 Payload Too Large" 错误。日志中显示：

当时想："小文件明明可以正常上传，为什么大文件就不行了？"

经验总结： Spring Boot 默认将文件上传大小限制为 10MB。

问题二：如何解决上传限制？

经过一番搜索，我找到了解决方案：需要调整应用配置。在 application.properties 或 application.yaml 中添加：

或者使用 YAML 格式：

配置完成后，50MB 以内的文件上传就能正常工作了。

经验总结： 你可以自由控制上传限制，只需要将配置属性调整为所需的大小即可。

问题三："配置了还是不行，为什么？"

几周后，有用户尝试上传一个 20MB 的文件，应用又崩溃了，出现了奇怪的 "connection reset" 错误，后端没有明确的错误信息。这次我意识到问题出在服务器层面。如果你的 Spring Boot 应用运行在反向代理（如 Nginx 或 Apache）后面，这些服务器也有自己的文件大小限制。

对于 Nginx，需要设置：

对于 Apache，需要设置：

解决这个问题后，文件上传终于对所有用户都正常工作了。

经验总结： 不仅仅是 Spring Boot 的问题——你的 Web 服务器或代理服务器也可能有文件大小限制。

问题四：上传大文件时出现 "OutOfMemoryError"

最后，我发现当有人尝试上传真正的大文件（比如 200MB）时，应用会因为 "OutOfMemoryError" 而崩溃。即使提高了文件大小限制，应用也无法正常处理。

解决方案很简单：

• 保持文件大小限制在合理范围内。除非确实需要，否则不要让用户上传超大文件。
• 直接将上传的文件保存到磁盘，而不是加载到内存中。使用流式处理。

经验总结： 大文件上传会消耗服务器内存，需要谨慎处理！

核心要点

• Spring Boot 有默认的文件大小限制（10MB）
• 可以通过 application.properties 或 application.yaml 提高限制
• Web 服务器（如 Nginx 或 Apache）也有自己的限制——记得一并配置！
• 对于超大文件，使用流式处理并注意内存使用情况

总结

如果你的文件上传在 10MB 后持续失败，不要慌张。检查你的 Spring Boot 配置、Web 服务器设置和内存使用情况。调整相关配置，并用真实文件进行测试。这样可以为你（和你的用户）节省大量的麻烦！

刚开始学习 Spring Boot 的时候，我对 DTOs（数据传输对象）和 Entities（实体类）没有太深入的思考。通常的做法就是创建一个类，然后到处使用——数据库操作、API 接口、业务服务等等。看起来一切都很顺利……直到问题出现。

在这篇文章中，我想分享一下关于 DTOs 和 Entities 的一些经验教训。我会解释它们各自的作用，为什么需要将它们分离，以及忽略这一点会带来哪些实际问题。

最初的错误做法

在某个项目的初期，我创建了一个 User 类，包含 id、name、email 和 password 等字段。然后在以下所有场景中都使用这同一个类：

• 数据库持久化（作为 JPA 实体）
• 接收前端传递的数据
• 返回 API 响应结果

开发速度确实很快，代码量也不多。但随着项目的发展，问题逐渐暴露出来。

问题的出现

有一天，产品经理提出了新需求：前端需要展示用户的公开资料，但不能包含邮箱和密码信息。

听起来很简单，对吧？

但问题是，我的 API 直接返回完整的 User 实体对象，响应中包含了敏感数据，比如密码哈希值。

我们只能临时用 @JsonIgnore 注解来解决，但接下来另一个确实需要返回邮箱的 API 又出现了问题。

这时候才意识到，一个类已经无法满足所有需求了。

DTO 的解决方案

我创建了一个新的 UserDTO 类，只包含需要在响应中返回的字段——比如 id、name，可能还有 profilePicture。

现在可以精确控制哪些数据可以进入或离开系统。

示例代码：

数据映射的方式：

后来，我开始使用 MapStruct 来自动化这个映射过程，不过那是后话了。

为什么混合使用 DTO 和 Entity 是个坏习惯

以下是我在混合使用 DTOs 和 Entities 时遇到的实际问题：

1. 在 API 接口中意外暴露敏感数据（如密码或内部 ID）
2. 修改某个字段时影响多个 API 接口
3. 数据库重构时难以避免对前端的影响
4. 接受了不应该直接保存到数据库的用户输入

另一个案例：输入 DTO vs. Entity

在处理 API 输入时我也遇到了类似问题。我有一个实体类包含 createdAt、isAdmin 和 status 等字段，但我不希望用户能够为这些字段传值。

由于在 API 请求中直接使用了实体类，结果有人发送了一个包含 "isAdmin": true 的 POST 请求，而系统竟然真的生效了！

从那时起，我为用户创建操作单独创建了一个输入 DTO。它只包含我们期望用户提供的字段：name、email、password。其他字段都在后端自动设置。

血的教训

• Entities 专门用于数据库操作
• DTOs 专门用于 API 接口和业务逻辑
• 不要混合使用，即使看起来更简单
• 根据需要为输入和输出创建不同的 DTOs
• 如果不想手写映射代码，可以使用 MapStruct 或 ModelMapper 等工具

刚开始的时候，创建单独的 DTO 类确实感觉像是额外的工作量。但后来发现，它为我节省了大量的调试时间，并且让我对应用程序的行为有了更好的控制。

总结

刚入门的时候，没有人告诉我要分离 DTOs 和 Entities。我只能通过踩坑来学习——各种 bug、奇怪的行为、接口异常等等。

如果你正在开发 Spring Boot 应用，建议尽早创建专门的 DTOs。相信我，未来的你会感谢现在的决定。

你在混合使用 DTOs 和 Entities 时遇到过类似问题吗？欢迎在评论区分享你的经验。

本文是关于 Spring Framework 中 @Transactional 注解的完整教程，面向有一定基础的开发者，将详细介绍注解功能、使用场景、核心特性、优缺点，并配有清晰的图表说明。

✅ @Transactional 是什么？

@Transactional 是 Spring 提供的事务注解，用于声明式事务管理。它可以确保被标记的方法（或代码块）运行在数据库事务环境中。

🛠️ 什么时候使用

以下场景建议使用 @Transactional：

当你需要执行多个数据库操作，且这些操作必须具备原子性（要么全部成功，要么全部失败）。

• 需要在出现错误或异常时自动回滚操作。
• 希望避免手动管理事务（比如直接使用 JDBC 或 EntityManager 的事务 API）。

⚙️ @Transactional 的核心特性

🔁 事务传播机制（常用类型）

🔒 事务隔离级别

✅ 主要优点

• 简单易用，支持声明式事务管理。
• 与 JPA、Hibernate、Spring Data 等框架完美集成。
• 异常时自动回滚，无需手动处理。
• 减少样板代码，提高开发效率。
• 支持嵌套事务等高级特性。

❌ 使用限制

• 使用不当容易踩坑，需要充分理解其原理。
• 基于代理实现：对 private 方法和同类内部调用无效。
• 默认只对运行时异常回滚，检查异常需要额外配置。
• 复杂的嵌套调用中排查回滚原因比较困难。

📦 代码示例

🔁 自定义回滚配置

📉 不使用事务的风险

• 部分数据库操作成功，部分失败。
• 导致数据不一致问题。

🧪 最佳实践

• 建议在Service 层的公共方法上使用。
• 避免在 Controller 层或 DAO 层使用 @Transactional。
• 注意代理失效问题：不要在同一个类内部调用 @Transactional 方法。

你是否注意到创建新 Spring Boot 项目时出现的最新选项？Spring Boot 4.0.0 预览版现已发布，基于最新的 Spring Framework 7.0.0 🌱。这个版本引入了众多激动人心的新特性，不仅提升了开发效率，改善了空值安全性，还简化了 Web 应用程序的开发流程。本文将深入探讨这些重要变化，并提供完整的代码示例和单元测试，帮助你快速上手这个预览版本。让我们一起来探索吧！🔍

注意：作为预览版本，Spring Boot 4.0.0 尚未达到生产就绪状态。在关键业务应用中使用前，请务必进行充分测试。

1. 优雅的API版本控制 📚

Spring Framework 7.0.0 引入了强大的 API 版本控制支持，开发者可以通过 @RequestMapping 注解中的 version 参数来管理同一端点的多个版本。这一特性大大简化了 REST API 向后兼容性的维护工作。

示例：

工作原理：

• 对 /api/user 的请求如果带有版本头（如 Accept: application/vnd.api.v1+json）会路由到 getUserV1 方法
• 带有版本 2 的请求会路由到 getUserV2 方法
• 这种方式保持了代码库的整洁性，避免了为不同版本重复创建端点

优势：简化了 API 演进过程，让开发者能够在不影响现有客户端的前提下轻松引入新功能 🌟。

2. 使用 BeanRegistrar 实现便捷的 Bean 注入 🛠️

Spring Framework 7.0.0 新增的 BeanRegistrar 接口支持灵活的编程式 Bean 注册，可以根据活动配置文件等条件动态注册多个 Bean。

示例：

单元测试：
为了验证 Bean 是否正确注册，这里使用 Spring Boot 的测试框架编写一个单元测试：

工作原理：

• MyBeansRegistrar 无条件注册一个 User Bean，仅在 dev 配置文件激活时注册 Order Bean
• 单元测试验证了当 dev 配置文件激活时，这两个 Bean 在应用程序上下文中都可正常使用

优势：简化了动态 Bean 注册流程，特别适用于具有特定配置文件的复杂应用场景 📦。

3. 使用 JSpecify 注解提升空值安全性 🛡️

Spring Framework 7.0.0 通过采用 JSpecify 注解（@Nullable 和 @NonNull）来增强空值安全性，替代了已弃用的 JSR 305 注解。这些注解可以帮助 IntelliJ IDEA 2024 等 IDE 在开发阶段捕获潜在的空指针异常问题。

示例：

工作原理：

• @NonNull 确保 setName 中的 name 参数不能为 null，如果传递 null 值会触发 IDE 警告
• @Nullable 表示 getName 方法可能返回 null，提醒开发者进行适当的空值处理
• IntelliJ IDEA 2024 会针对空值安全违规显示警告或错误，从而提高代码可靠性

优势：通过在开发阶段提前发现问题，有效减少运行时 NullPointerException 异常，增强代码健壮性 🔐。

4. 使用 @ImportHttpServices 轻松创建 HTTP 代理 🌐

新增的 @ImportHttpServices 注解简化了为 HTTP 接口创建代理的过程，支持以声明式方式对 HTTP 服务进行分组和配置。

示例：

工作原理：

• @ImportHttpServices 为指定的接口注册 HTTP 代理，分别归属于 weather 和 user 组
• RestClientHttpServiceGroupConfigurer 为组内所有服务应用通用配置，如请求头信息

优势：简化了与外部 HTTP 服务的集成流程，有效减少了样板代码 📡。

5. 其他值得关注的新特性 🎉

Spring Boot 4.0.0 和 Spring Framework 7.0.0 还包含了以下几个重要的增强功能：

a. SpEL 表达式升级 📝

SpEL 现在支持空值安全和 Elvis 操作符（?:），进一步简化了属性注入的过程。

示例：

这行代码会注入 pop3.port 系统属性，如果该属性未定义则使用默认值 25。

b. GraalVM 原生应用支持 ⚡

Spring AOT 技术可以将应用程序编译为原生镜像，显著减少启动时间和内存占用，特别适合云原生环境部署。

c. Jackson 3.x 支持 📊

对 Jackson 2.x 的支持已被弃用，Jackson 3.x（使用 tools.jackson 包）成为新的默认选择，提供了更优的性能和更丰富的功能。

d. Servlet 和 WebSocket 升级 🌐

Spring Framework 7.0.0 采用了 Jakarta Servlet 6.1 和 WebSocket 2.2 规范，需要使用现代容器，如 Tomcat 11+ 或 Jetty 12.1+。

e. HttpHeaders API 优化 🔍

HttpHeaders API 已完成现代化改造，新增了 firstValue 和 forEach 等方法，使请求头操作更加便捷。

示例：

f. 已移除的功能 🗑️

• Spring MVC 的 XML 配置已被弃用，推荐使用基于 Java 的配置方式
• Spring TestContext Framework 中对 JUnit 4 的支持已被弃用
• Spring JCL 已被移除，由 Apache Commons Logging 1.3.0 替代

g. 最低版本要求 📋

• Jakarta EE 11 (Tomcat 11+)
• Kotlin 2.x
• JSONassert 2.0
• GraalVM 23

完整的变更列表请参考 Spring Framework 7.0 发布说明。

实际示例：在 Spring Boot 4.0.0 中构建版本化 API 🌟

下面我们通过一个完整的 Spring Boot 4.0.0 应用程序示例，来展示如何使用 API 版本控制和空值安全 Bean。

控制器：

配置：

测试：

这个示例完整演示了 API 版本控制和 Bean 注册的功能，并通过单元测试验证了其正确性。

总结 📚

基于 Spring Framework 7.0.0 的 Spring Boot 4.0.0 预览版带来了众多革命性的新特性：

• API 版本控制：通过 @RequestMapping 实现优雅的端点版本管理
• BeanRegistrar：支持灵活的编程式 Bean 注册
• 空值安全：采用 JSpecify 注解构建更健壮的代码
• HTTP 代理：使用 @ImportHttpServices 简化服务集成
• 技术栈现代化：全面支持 Jackson 3.x、Servlet 6.1、WebSocket 2.2 和 GraalVM 原生镜像

更多升级信息，请参考官方文档：

https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.0-Release-Notes

最近我们翻译了Spring Boot和Spring AI的中文文档，有需要的小伙伴可以收藏，后续Spring Boot 4.0发布我们也会第一时间进行翻译

• Spring Boot 3.4中文文档
• Spring Boot 3.5中文文档
• Spring AI 1.0.0中文文档

这些变化让 Spring Boot 4.0.0 成为构建现代云原生应用的强大选择。建议在你的项目中尝试这个预览版本，但在生产环境中请务必谨慎使用。欢迎在评论区分享你的使用体验，如果这篇文章对你有帮助，请不要忘记点赞支持 👏！

感谢你耐心阅读这篇文章！如果内容对你有所帮助，请点赞 👏、收藏 ⭐ 并分享给需要的朋友。

多年来，@MockBean 一直被广泛用于 Spring Boot 单元测试中来模拟依赖项。

然而，在 Spring Boot 3.2 中，@MockBean 由于性能和可维护性方面的问题已被标记为废弃。

🔴 @MockBean 存在的问题

✔ 创建不必要的 Spring 上下文代理 → 拖慢测试执行速度 ✔ 全局模拟 Bean → 可能在多个测试中产生副作用 ✔ 未针对 Spring Boot 3.2 的测试改进进行优化

✅ 解决方案：使用 @MockitoBean

Spring Boot 3.2 引入了 @MockitoBean，它提供了： ✔ 更快的测试执行速度 - 直接集成 Mockito ✔ 更好的测试组件隔离 ✔ 更可靠的单元测试体验

1️⃣ 什么是 @MockitoBean？

@MockitoBean 是 Spring Boot 3.2 中的一个新注解，它是 @MockBean 的直接替代品。

✔ 它为依赖项创建模拟实例 ✔ 它与 JUnit 5 和 Mockito 有更好的集成 ✔ 它不需要完整的 Spring 上下文重新加载

2️⃣ 将 @MockBean 替换为 @MockitoBean

让我们通过一个在服务测试中模拟存储库的示例来演示。

📝 示例 1：使用 @MockBean 的旧方法（已废弃）

❌ 这种方法中 @MockBean 的问题：

• 需要初始化 Spring 上下文，使测试变慢
• 由于全局模拟会影响其他测试

✅ 示例 2：使用 @MockitoBean 的新方法（Spring Boot 3.2+）

✅ 使用 @MockitoBean 的优势：
✔ 执行更快 – 不会重新加载 Spring 上下文
✔ 作用域模拟 – 仅在测试类中进行模拟
✔ 更稳定的单元测试体验

3️⃣ 使用 @MockitoBean 和 MockMvc 进行 REST 控制器单元测试

Spring Boot 还允许测试 REST 控制器而无需启动完整的应用程序。

✅ 示例：测试 UserController

✅ 使用 MockMvc 高效测试 API 接口 ✅ 模拟 UserService 而无需加载完整应用程序

4️⃣ 核心差异：@MockBean vs. @MockitoBean

@MockBean vs. @MockitoBean 对比

🚀 在 Spring Boot 3.2+ 的单元测试中请始终使用 @MockitoBean！

5️⃣ Spring Boot 3.2+ 单元测试最佳实践

✔ 使用 @MockitoBean 而不是 @MockBean 以获得更快的测试速度 ✔ 使用 @WebMvcTest 进行控制器测试 ✔ 仅在集成测试中使用 @SpringBootTest ✔ 模拟依赖项而不是使用真实的数据库连接 ✔ 使用 Mockito.when() 和 verify() 来验证方法调用

🎯 总结：为什么要切换到 @MockitoBean？

通过切换到 @MockitoBean，你将获得：
✅ 更快的测试执行（无需重新加载 Spring 上下文） ✅ 更好的测试隔离（按测试的模拟作用域） ✅ 更高效的 Mockito 集成

🚀 你在 Spring Boot 3.2+ 项目中使用 @MockitoBean 了吗？欢迎在评论区分享你的经验！

🔗 将这个指南分享给开发者朋友们，帮助他们从 @MockBean 迁移到 @MockitoBean！ 🚀

还在用冗长的if-else或switch语句管理多个服务实现？

相信不少Spring Boot开发者都遇到过这样的场景：需要根据不同条件动态选择不同的服务实现。

如果告诉你可以完全摆脱条件判断，让Spring自动选择合适的实现——只需要一个注解，你是否感兴趣？

本文将详细介绍这种优雅的实现方式。

💡 实际开发中的痛点

假设你在开发一个支付系统，需要支持多种支付方式：

• PaypalPaymentService
• StripePaymentService
• RazorpayPaymentService

传统做法是根据用户选择的支付方式进行条件判断：

❌ 这种写法存在明显问题：代码冗余、难以维护、扩展性差。

接下来看看如何优化。

优雅的解决方案：注解 + Map容器

实现思路：

• 定义自定义注解标识不同的实现类
• 利用Spring的依赖注入机制，通过Map容器动态获取对应的实现

步骤1：定义通用接口

步骤2：创建自定义注解

步骤3：标注具体实现类

步骤4：构建服务工厂类

步骤5：在控制器中使用

🎯 方案优势

• 告别条件判断地狱：无需编写冗长的if-else语句
• 扩展性强：新增实现只需添加注解即可
• 符合开闭原则：对扩展开放，对修改封闭
• 代码简洁：逻辑清晰，便于维护和测试

进阶技巧：结合Spring Profile

如果需要根据不同环境自动切换实现（如测试环境和生产环境），可以这样做：

将@PaymentType与@Profile("prod")结合使用，Spring会根据当前激活的配置文件自动选择对应的实现。

总结

这种基于注解的动态服务选择模式，能够显著提升代码质量和可维护性，特别适用于大型项目中复杂的服务发现场景。

告别意大利面条式的代码，拥抱注解驱动的动态、优雅的服务注入方式。

设想这样一个未来：编写单元测试不再是开发者的负担，AI 能理解你的代码，自动生成全面的测试用例，并在问题演变为 bug 之前就将其发现。这个未来并非遥不可及，它已然成为现实。

在 Spring Boot 开发中，JUnit 测试长期以来都是测试驱动开发（TDD）和质量保障的核心支柱。然而，手动编写这些测试往往重复、枯燥且易于出错。如今，AI 驱动的测试生成正带来一场颠覆性的变革，人工智能模型能够分析你的 Java 代码，并自动生成单元测试。

本文将深入探讨 AI 如何重塑 Spring Boot 应用的测试格局。我们将详细解析其工作原理、主流工具、优势与局限，并指导你如何在自己的项目中快速应用 AI 生成的 JUnit 测试。

为什么要自动化 JUnit 测试生成？

在深入探讨 AI 解决方案之前，理解自动化测试生成的内在动因至关重要：

• 提升开发效率：开发者可以将更多精力投入到核心业务逻辑的实现上，而测试则由 AI 自动生成。
• 扩大测试覆盖：AI 模型能够更全面地分析源代码，发现开发者可能忽略的边缘案例。
• 确保测试一致性：AI 生成的测试遵循统一的标准模式，从而减少测试代码结构上的不一致性。
• 降低人为错误率：有效避免了在手动编写重复性测试用例时可能引入的疏忽和错误。

AI 如何助力测试生成

AI 模型，特别是像 OpenAI 的 GPT、Google 的 Codey 这类大型语言模型（LLM），具备理解源代码并生成相应测试用例的能力。其工作流程如下：

1. 代码解析：AI 读取 Java 类或方法，并理解其输入、输出及行为逻辑。
2. 行为分析：基于代码逻辑，模型预测其预期行为和潜在的测试场景。
3. 测试结构生成：AI 按照 JUnit 框架的规范，格式化测试代码，包括方法注解、模拟（mock）设置和断言。
4. 依赖感知：针对 Spring Boot 应用，AI 会自动利用 Mockito 或 MockMvc 等库来模拟依赖项。

Spring Boot 测试生成的关键环节

AI 在生成 Spring Boot 测试时，通常会覆盖以下几个核心层面：

1. Service 层测试

这类测试专注于业务逻辑，不涉及 Web 层。AI 生成的 Service 层测试通常包括：

• 使用 @Mock 和 @InjectMocks 进行依赖模拟。
• 测试各种边界情况。
• 验证返回值和异常处理场景。

示例概念：

2. Controller 层测试

AI 生成的 Controller 层测试会利用 MockMvc 模拟 HTTP 请求，并验证响应状态码和 JSON 内容。

示例概念：

3. Repository 层测试

对于数据库交互测试，AI 通常会生成集成测试，并利用 H2 等内存数据库以及 @DataJpaTest 注解。

支持 AI 测试生成的工具

目前已涌现出多款利用 AI 和 LLM 自动生成测试的工具：

• GitHub Copilot：虽然并非专为测试设计，但它能在编码过程中智能地提供测试代码片段建议。
• Diffblue Cover：一款专为 Java 设计的商业工具，能够利用 AI 自动编写单元测试。
• ChatGPT：开发者可以将代码粘贴到 ChatGPT 中，并提示其生成 JUnit 测试。
• CodiumAI：提供 IDE 扩展，直接在开发环境中智能生成测试。

使用 AI 生成 JUnit 测试的优势

• 显著节省时间：大幅减少编写样板测试代码所需的工作量。
• 提升测试覆盖率：AI 模型往往能生成开发者容易忽视的边缘测试用例。
• 支持代码重构：当代码发生变更时，利用 AI 重新生成测试比手动更新更为高效。
• 加速新成员上手：新团队成员可以通过阅读 AI 生成的测试，快速理解代码的行为和功能。

局限与挑战

尽管 AI 模型功能强大，但也存在一些局限性：

• 代码理解并非完美：对于复杂或高度抽象的逻辑，AI 可能存在误解意图的情况。
• 测试维护成本：自动生成的测试在代码变更后，可能仍需要手动进行调整和维护。
• 数据准备复杂性：AI 未必总能正确地设置数据库或外部系统的初始化和清理逻辑。
• 盲目信任的风险：开发者必须始终审慎审查和验证生成的测试，以确保其准确性和相关性。

最佳实践

为有效利用 AI 生成 Spring Boot JUnit 测试，建议遵循以下实践：

1. 保持代码模块化：小巧、职责单一的方法更容易被 AI 理解并生成测试。
2. 采用描述性命名：AI 模型依赖于方法和变量的名称来推断其行为。
3. 循序渐进地集成：建议从 Service 层测试开始，逐步扩展到 Controller 和 Repository 层。
4. 严格审查所有生成测试：切勿盲目接受，务必仔细审查和验证生成的代码。
5. 将 AI 视为辅助工具而非替代品：让 AI 增强你的测试流程，但不要取代批判性思维和人工判断。

ChatGPT 测试生成示例流程

1. 复制你的 Service 或 Controller 类。

2. 粘贴到 ChatGPT，并附上类似如下的提示：

   请为以下 Spring Boot Service 类使用 Mockito 生成 JUnit 5 测试用例。

3. 审查生成的代码，根据需要调整输入、模拟设置和断言。

4. 将代码复制到你的测试套件中，并通过 Maven 或 Gradle 运行。

总结

AI 模型为软件开发带来了全新的生产力工具，其中自动化 JUnit 测试生成无疑是最具实用价值的应用之一。在 Spring Boot 应用中，由于其分层架构和复杂的依赖管理，手动编写测试可能变得繁琐。此时，AI 工具能成为强大的助力，显著提升测试的效率和准确性。

尽管这些工具并非尽善尽美，但它们在测试速度、覆盖率和标准化方面带来了显著的提升。只要进行审慎的集成并辅以人工监督，AI 生成的 JUnit 测试必将成为任何 Spring Boot 项目测试体系中的宝贵资产。

随着 Java 21 的发布，虚拟线程（Virtual Threads）成为了正式特性，彻底改变了 Java 的并发编程方式。它们为传统线程提供了更轻量、更易扩展的替代方案，让开发者能够编写出更加简洁高效的并发代码。

虚拟线程

虚拟线程为异步 Java 开发带来了革命性的变化。它们让 JVM 拥有了类似 Go 的并发能力，使高吞吐量应用的代码结构更加简洁、易于维护。如果你正在开发 Web 服务、文件处理器或任何 I/O 密集型应用，虚拟线程会成为你的得力助手。

虚拟线程是由 Java 虚拟机（JVM）直接管理的轻量级线程，而不是由操作系统管理。与平台线程（也称为内核线程或本地线程）相比，平台线程的创建和管理成本较高，而虚拟线程则极为廉价，可以轻松支持成千上万甚至上百万的并发线程。

虚拟线程依然基于熟悉的 java.lang.Thread API，这意味着你无需学习新的并发模型或库。

传统线程与操作系统线程是一一对应的：

• 每个 Java 线程对应一个操作系统线程
• 阻塞线程（如 I/O 操作）会占用操作系统资源

而虚拟线程采用多对一模型，允许大量虚拟线程共享少量操作系统线程。当虚拟线程遇到阻塞操作（如 sleep() 或 read()）时，JVM 会自动挂起该线程，让底层的承载线程去执行其他任务。

虚拟线程项目示例

下面的代码演示了如何配置 Tomcat（Spring Boot 默认的 Web 服务器）使用虚拟线程来处理请求任务，替代传统的平台线程。

创建生成二维码的接口：

创建交互界面：

运行效果：

如果你用过 Spring Boot，一定很熟悉“铁三角”：@Controller、@Service 和 @Repository。每加一个实体，通常就会有对应的 Controller 来处理 CRUD 和业务逻辑——至少对于同步操作来说如此。

创建 POST、PUT、DELETE 这些接口很简单：校验、业务逻辑一接，接口就能用了。

但 GET 呢？

来看一个简单的 Employee 实体：

现在我们要查所有指定状态的员工，很简单：

清爽利落，对吧？

我们继续下一个需求：

“API 能不能也按角色过滤？”

当然可以，改一下：

又一次上线、又一次版本号递增。

然后又有同事说：

“我们想按 status 或 role 查询，还能不能加个 department 过滤？”

糟了，问题来了：组合太多，维护太累。

Spring Data Specification 登场

Spring Specification 提供了一种动态、可复用的方式，用 JPA Criteria API 构建查询。

可以把 Specification<T> 理解为运行时构建 Predicate 的工具，让你对查询条件有极高的灵活性。

我们来用 Specification<T> 搭一个灵活的查询解析器。

动态搜索构建器

最终 API 接口

查询示例

现在，这一个接口就能支持所有这些用例：

为什么值得这样做

• 不用为每种过滤组合新建接口
• 不用为每个新字段扩展 repository 接口
• 简单过滤逻辑无需重新部署
• 对业务友好，易扩展

这种模式可以轻松适配任何实体，让你的代码库保持一致性和可维护性。

一个接口，无限查询。如果没有复杂业务逻辑，这就是最终答案。

RestClient 是 Spring Framework 6 引入的一个现代化、流式、类型安全的 HTTP 客户端，在 Spring Boot 3.2+ 中可用。它旨在替代较旧的 RestTemplate，更好地适应现代 HTTP 使用模式，并提供更简洁、直观的 API。

🔍 什么是 RestClient？

RestClient 是构建在 Spring 的 WebClient 之上的新抽象，但它提供了简化的流式 API——非常适合阻塞式、同步的 HTTP 调用。可以将其视为现代化的 RestTemplate。

RestClient 的主要优势

✅ 流式 API 更清晰、更易读的代码

✅ 内置 JSON（反）序列化 无需手动使用 ObjectMapper

✅ 异常处理 与 RestClientException 集成

✅ 类型安全的响应 直接将响应映射到 DTO

✅ 复用底层 WebClient 共享连接池和资源

✅ 更容易测试 与 MockRestServiceServer 配合良好

🔧 基本设置

确保你使用的是 Spring Boot 3.2+。

Bean 定义示例（可选）

基本用法

🎯 使用场景

1. GET 请求

2. POST 请求

3. PUT 请求

4. DELETE 请求

5. 使用 ResponseEntity 和 Headers 进行交换

🔐 认证和请求头

添加请求头

添加 Bearer Token

📦 处理 JSON 数组和泛型类型

⚠️ 错误处理

你可以使用 .onStatus(...) 处理 HTTP 错误

🧪 单元测试

使用 MockRestServiceServer 进行测试：

支持流式期望和验证。

🔁 重试和超时（Spring Retry + WebClient 自定义）

如果需要重试或超时：

• 配置 RestClient 使用的底层 WebClient。
• 可以通过注解或编程方式集成 Spring Retry。

🏁 何时使用 RestClient

✅ 在以下情况使用：

• 需要简洁的同步 HTTP 调用
• 不想处理响应式编程
• 正在构建现代化的 Spring Boot 3.2+ 应用
• 需要可测试性和可读性

❌ 在以下情况避免使用：

• 需要高并发或非阻塞 I/O
• 已经深入使用响应式流（继续使用 WebClient）

上个季度，我带着越来越焦虑的心情盯着我们公司的 AWS 账单。尽管服务的客户数量基本持平，但我们的云成本在过去一年里持续攀升。作为负责后端基础设施的技术负责人，我必须在下一个预算评审前找到解决方案。

我没想到的是，一次看似例行的 Spring Boot 升级，加上一些有针对性的配置调整，竟然让我们的 AWS 开支几乎减半。以下是我们如何发现问题、实施变更，并彻底提升应用资源效率的全过程。

云成本加剧的危机

我们公司运营着一个 SaaS 平台，帮助中型企业管理多渠道的库存。我们不是巨头（大约 5,000 个客户，每天处理 120,000 个订单—），但 AWS 账单已经涨到了令人头疼的每月 27,000 美元。_

CFO 在季度会议上说："我们要么削减成本，要么涨价。"但在当前市场，涨价根本不现实。"

挑战很明确：在不影响应用性能和可靠性的前提下，找到显著的基础设施节省空间。但从哪里下手？

找出资源消耗大户

我们的应用架构对现代 Java 项目来说很常见：

• Spring Boot 2.7 后端服务
• PostgreSQL RDS 实例做持久化存储
• Redis 做缓存
• EC2 实例组成自动伸缩组，挂在负载均衡器后面

第一步是搞清楚钱都花在哪了。我设置了详细的成本分配标签，并用 AWS Cost Explorer 分析了我们的支出模式。

结果令人惊讶：

• EC2 实例：占 58%
• RDS PostgreSQL：占 25%
• 数据传输：占 12%
• 其他服务（Redis、S3 等）：占 5%

EC2 成本成了首要目标，深入分析后发现更有意思的现象：我们运行的实例数量远超实际流量需求。自动伸缩经常被触发，启动的新实例大多处于低利用率。

资源利用率之谜

监控数据显示出一种奇怪的模式。每台 EC2 实例启动时各项指标都很健康，但随后会逐步出现：

1. CPU 利用率逐步升高（最终达到 70–80%）
2. JVM 堆内存持续增长
3. 响应时间变慢
4. 吞吐量下降

大约 12 小时后，指标恶化到自动伸缩被触发，启动新实例。但这些新实例并没有处理更多流量，只是在弥补已有实例性能下降的问题。

"看起来像是某种资源泄漏。"我对团队说，"但不是典型的内存泄漏，而是应用效率在逐步下降。"

数据库连接的真相

开启详细性能监控和日志分析后，我们发现了惊人的问题：应用创建了过多的数据库连接，且很多连接没有被正确关闭。

典型的 API 请求流程应该是：

但实际连接使用却是：

这些泄漏的连接会不断积累，直到连接池耗尽，导致性能下降，最终触发自动伸缩。

罪魁祸首？我们的应用用的是 Spring Data JPA，并有一些自定义的 repository 实现，没有正确管理事务边界和连接生命周期。

Spring Boot 3.5 的启示

就在这时，Spring Boot 3.5 发布了，带来了数据库连接管理和 ORM 性能的多项改进。发布说明中提到"资源利用率显著提升"，这引起了我的注意。

进一步研究后，我发现 Spring Boot 3.5 包含：

1. 更强的连接池集成
2. 改进的事务管理
3. 更智能的资源清理
4. 更好地处理懒加载场景

升级能解决我们的问题吗？值得一试。

关键配置变更带来的转机

我们决定升级到 Spring Boot 3.5，并针对数据库连接管理做了几项关键配置调整。以下是最有影响力的具体变更：

1. 连接池优化

我们将默认的 HikariCP 配置调整为更适合我们负载的参数：

关键新增项是 leak-detection-threshold，帮助我们识别和记录潜在的连接泄漏。降低 minimum-idle 也避免了在低峰期保留过多空闲连接。

2. 事务管理改进

我们优化了事务管理配置：

DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION 这个设置堪称"神器"，它确保数据库连接在真正需要时才获取，并在事务结束后立即释放。

3. JPA 查询优化

我们做了多项 JPA 和 Hibernate 优化：

Spring Boot 3.5 的新查询优化器，显著减少了常用操作所需的数据库查询次数。

4. 语句缓存

我们开启了预编译语句缓存，对数据库性能提升明显：

这些设置确保常用 SQL 语句被缓存，减少了语句准备的开销。

5. 针对场景的连接管理

对于最消耗资源的接口，我们实现了针对性的事务和连接设置：

这样可以针对不同操作设置不同的事务和抓取行为，而不是一刀切。

实施与即时成效

这些变更需要仔细测试，因为数据库连接问题往往隐蔽且依赖环境。我们的做法：

1. 搭建与生产一致的预发环境
2. 升级到 Spring Boot 3.5 并应用新配置
3. 进行大量压力测试验证变更
4. 对比前后连接使用模式

初步结果令人振奋：

• 单实例平均数据库连接数从 7.8 降到 3.2
• 连接获取时间降低 68%
• 72 小时压力测试期间未检测到连接泄漏

但真正的考验在生产环境。

上线与 AWS 成本影响

我们在维护窗口将变更上线，并立即开始监控。实际效果比预发还要明显：

• EC2 集群平均 CPU 利用率从 62% 降到 28%
• JVM 垃圾回收暂停减少 76%
• 单实例吞吐量提升 120%
• 平均响应时间从 187ms 降到 74ms

最重要的是，自动伸缩事件几乎消失。原本高峰期需要 20–24 台 EC2，现在只需 9–10 台即可稳定运行。

AWS 成本立竿见影：

节省明细：

• EC2 成本降低 58%（实例数减少，CPU 利用率下降）
• RDS 成本降低 32%（连接数减少，查询效率提升）
• 数据传输成本降低 15%（API 响应更高效）

技术细节解析：为何如此有效

要真正理解这些变更为何如此有效，必须了解 Spring Boot 3.5 的技术改进，以及我们的配置如何充分利用了这些特性。

连接生命周期的改进

Spring Boot 3.5 从根本上改变了数据库连接的管理方式。旧版本往往过早获取连接且持有时间过长。新设置 DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION 保证：

1. 只有在即将执行 SQL 时才获取连接
2. 事务结束后立即释放连接

这样大大缩短了连接持有时间，让更小的连接池也能应对同样的负载。

查询优化引擎

Spring Boot 3.5 的新查询优化器解决了多种常见低效问题：

1. N+1 查询预防：检测潜在 N+1 查询模式并自动转为高效批量查询
2. 连接优化：分析实体关系，选择更优的连接策略
3. 抓取大小调优：根据结果集大小自动调整 JDBC fetch size

我们的配置已启用并调优了该优化器：

语句缓存

数据库语句准备开销不容小觑。开启语句缓存后，常用查询可跳过准备阶段：

对于我们这种查询模式较为固定的应用，显著降低了数据库 CPU 占用并提升响应速度。

泄漏检测与预防

泄漏检测配置对定位剩余问题至关重要：

该设置会在连接持有超时后记录详细堆栈，帮助我们定位和修复代码中的连接管理问题。

代码优化

虽然配置变更带来了主要提升，我们也做了几项代码优化作为补充：

1. 简化 Repository 方法

我们重构了复杂的 repository 方法，充分利用 Spring Data JPA 的查询派生能力：

在 Spring Boot 3.5 的新查询优化器下，简化后的方法性能更好，框架能做出更优的抓取决策。

2. 显式事务边界

我们让事务边界更明确，尤其是只读操作：

readOnly = true 提示 Spring 和数据库进一步优化查询执行。

3. 批量操作异步处理

对于资源密集型操作，我们采用异步处理并控制资源消耗：

这样保证批量操作不会占用过多数据库连接或 CPU。

总结与最佳实践

在这个过程中，我们总结出几条对其他团队也有参考价值的最佳实践：

1. 连接池大小要与数据库连接数匹配

最大连接池大小应按如下公式计算：

比如 RDS 最大连接 100，5 个应用实例：

我们取整到 20，留有余地。

2. 监控并记录连接使用

开启详细连接监控：

这样能清晰看到连接使用模式，便于排查问题。

3. 区分环境配置

不同环境需求不同。我们为不同环境设置了专属 profile：

这样开发环境不会占用多余资源。

4. 定期审查查询性能

我们实现了 SQL 性能监控，记录慢查询及其执行计划：

帮助我们及时发现和优化最耗资源的查询。

意外收获：超越成本的好处

虽然降低 AWS 成本是首要目标，但我们还发现了不少额外好处：

1. 开发体验提升

连接管理更好，错误信息更清晰，开发过程中遇到的超时和连接问题大幅减少。

2. 压测更准确

我们的压力测试结果更可预测、更贴近生产，有助于容量规划。

3. 运维事件减少

变更后六个月内，我们得到了这样的改变：

• 连接相关告警减少 87%
• 自动伸缩事件减少 92%
• 数据库连接相关的生产事故为零

4. 环保效益

服务器数量从 24 台降到 10 台，不仅省钱，也大幅减少了能耗和碳排放。

结语：把配置当作一等优化手段

作为软件工程师，面对性能挑战时我们常常关注代码优化、算法改进和架构调整。我们的经验表明，配置（尤其是数据库连接相关配置）同样值得作为一等优化手段。

Spring Boot 3.5 的改进是基础，而我们精细的配置调优则释放了这些提升的全部潜力。最终收获的不只是成本节省，还有更可靠、高效、环保的应用。

对于面临类似挑战的团队，我的建议是：

1. 先彻底分析当前资源使用模式
2. 理解框架的数据库连接行为
3. 针对性地调整配置
4. 持续监控并迭代优化

我们实现 45% AWS 账单削减，并不是靠大刀阔斧重构或彻底换架构，而是通过理解和优化已有系统——有时，最有效的提升就藏在你应用的配置文件里。

作者：DevDecoded，原文：https://medium.com/@vermatanisha666/the-spring-boot-3-5-configuration-that-cut-our-aws-bill-by-45-e32118706ea7

Spring AI 1.0 GA版本终于正式发布！第一个正式版本，超多内容，每个Java开发者都必须了解一下！

核心功能包括支持20个AI模型的ChatClient接口、适配20个向量数据库的检索模块、支持滑动窗口和向量搜索的对话记忆功能、基于@Tool注解的工具调用机制，以及模型评估、可观测性和Model Context Protocol（MCP）支持。此外，新增RAG流水线、ETL框架、工作流驱动和自主代理功能，并提供与微软Azure、AWS、Google Cloud等云服务商的集成案例。

1. ChatClient核心接口

• 作为与AI模型交互的主要接口，支持20个AI模型（如Anthropic、ZhiPu、DeepSeek、MiniMax等），涵盖多模态输入输出（若模型支持）和JSON格式结构化响应。
• 各支持模型的横向特性对比如下：

2. 检索增强生成（RAG）与向量数据库

• 向量存储抽象：适配20个向量数据库（如Azure Cosmos DB、Weaviate），支持SQL-like过滤语言及原生查询回退。
• ETL框架：通过可插拔DocumentReader支持本地文件、网页、GitHub、云存储（AWS S3、Azure Blob等）及数据库输入，内置分块、元数据 enrichment 和嵌入生成。
• RAG流水线：基础QuestionAnswerAdvisor和模块化RetrievalAugmentationAdvisor，参考案例Retrieval Augmented Generation (R.A.G.) with Vector Stores

3. 对话记忆（ChatMemory）

• 基础实现：MessageWindowChatMemory通过滑动窗口存储最近N条消息，支持JDBC、Cassandra、Neo4j等持久化存储。
• 高级功能：VectorStoreChatMemoryAdvisor基于向量搜索检索语义相似历史消息，参考案例《Guide to chat memory implementation》。

4. 工具调用（Function Calling）

• 通过@Tool注解声明工具方法，支持动态注册Bean或编程式创建，可调用天气查询、数据库操作等外部功能，配套《Guide to local tool calling》。

5. 模型评估与可观测性

• 评估组件：RelevancyEvaluator验证响应相关性，FactCheckingEvaluator基于上下文校验事实准确性，引用Hugging Face专家指出“LLM作为裁判”的局限性（如模式崩溃、冗长偏见）。
• 可观测性：集成Micrometer追踪模型延迟、Token使用、工具调用等指标，支持日志记录和Micrometer Tracing。

6. 模型上下文协议（MCP）

• 客户端：通过spring-ai-starter-mcp-client快速连接MCP服务器，支持stdio和HTTP-SSE端点，示例连接Brave搜索引擎。
• 服务器：使用spring-ai-starter-mcp-server和@Tool注解构建MCP服务器，集成Spring Batch/Cloud Config提供企业级工具，支持OAuth安全认证。

7. 代理支持

• 工作流驱动代理：包含评估优化（自评估响应）、路由（智能分配请求）、编排（动态任务分解）、链式（分步处理）、并行化（批量调用聚合结果）等模式。
• 自主代理：通过MCP动态发现工具，维护执行记忆，支持递归策略优化，孵化项目Spring MCP Agent演示相关能力。

小结

这次 Spring AI 的正式发布，对于 Java 开发者来说，是一次重大的升级。它不仅提供了强大的 AI 能力，还提供了丰富的工具和框架，帮助开发者更轻松地构建 AI 应用。DD也一直有在用Spring AI，最近也会第一时间把项目升级到正式版本，如果遇到问题，再继续分享。

最后，做个小调研，你现在用什么框架来构建AI应用呢？留言区聊一聊吧～

感谢阅读！如果您学习过程中如遇困难？可以加入我们超高质量的技术交流群，参与交流与讨论，更好的学习与进步！

Spring AI支持的模型横向对比：

感谢阅读！如果您学习过程中如遇困难？可以加入我们超高质量的技术交流群，参与交流与讨论，更好的学习与进步！

容器化Spring Boot应用很简单，但低效的Docker镜像会导致部署臃肿、启动缓慢和安全风险。

本文我们将使用多阶段构建、Spring Boot的Layer工具和类数据共享(CDS)来优化Docker镜像，将体积缩小达60%，启动时间减少30%。

为什么要优化Docker Layer？

• 更小的镜像：加速CI/CD流程并降低云存储成本
• 更快的启动：对无服务和自动扩展环境至关重要
• 安全性：通过排除构建时依赖来最小化攻击面
• 高效缓存：通过隔离频繁变更的代码来优化重建

1. 多阶段构建：分离构建与运行时

多阶段构建会从最终镜像中丢弃不必要的构建工具(如Maven、JDK)。

未优化的Dockerfile

使用多阶段优化后的Dockerfile

关键优势:

• 从最终镜像中移除了构建工具(Maven、JDK)
• 使用更小的JRE基础镜像而非JDK

2. Spring Boot Layer工具：分离依赖

虽然多阶段构建减小了镜像体积，但Spring Boot的Layer工具通过将依赖与应用程序代码分离进一步优化了缓存，最小化开发过程中的重建。layertools模式将JAR分为：

1. dependencies：已发布的库（很少变化）
2. spring-boot-loader：Spring内部组件
3. snapshot-dependencies：SNAPSHOT库（偶尔变化）
4. application：您的代码（频繁变化）

步骤1：提取 layer

步骤2：分层优化的 Dockerfile

优势:

• 对application层的更改不会使缓存的依赖失效
• 最终镜像：~300MB（额外减少33%）

3. 类数据共享(CDS)：加速启动

类数据共享(CDS)通过将核心Java类预加载到共享存档中，减少JVM启动时间，避免JVM每次运行时重新解析这些类。

步骤1：生成CDS存档

运行应用一次以创建类列表和存档：

**注意：**需要在受控环境中生成存档，因为这需要运行应用程序。

步骤2：上传 Dockerfile

结果：启动时间从2.1秒降至1.05秒(提速40%)

在现代云原生应用中，指标数据是系统可观测性的命脉。它们能准确反映应用的健康状态是运行良好还是濒临崩溃。Spring Boot 结合 Prometheus 和 Grafana，构建了一套强大的指标采集、存储与可视化解决方案。

本文将指导您将Spring Boot应用打造成指标生成引擎，并构建令运维团队惊艳的监控仪表盘。

第一步：使用Micrometer和Prometheus导出指标

添加相关依赖

首先在项目中添加micrometer-registry-prometheus依赖。

该依赖使Spring Boot Actuator能够以Prometheus可抓取的格式暴露指标。

Maven:

Gradle:

暴露Prometheus端点

在application.properties中启用端点：

• /actuator/prometheus 端点现在以 Prometheus 格式提供指标数据。
• management.metrics.tags.application 为所有指标添加自定义标签（在多服务架构中很有用）。

验证端点：

您将看到原始指标数据，如 jvm_memory_used_bytes（JVM内存使用字节数）和 http_server_requests_seconds_count（HTTP请求计数）。

第二步：配置Prometheus抓取指标

创建一个prometheus.yml配置文件来配置抓取您的Spring Boot应用指标：

通过Docker运行Prometheus:

访问http://localhost:9090/targets确认运行成功。

第三步：构建Grafana仪表盘

使用Grafana连接Prometheus

安装运行Grafana:

访问 http://localhost:3000 登录Grafana (默认账密: admin/admin).

增加Prometheus数据源：

• URL地址：http://host.docker.internal:9090（Docker环境使用）或 http://localhost:9090（非Docker环境）

导入预置仪表盘

Grafana 社区为 Spring Boot 提供了丰富的仪表盘模板。以下是一些推荐：

JVM 指标：使用仪表盘 ID 4701。

• 跟踪内存、线程、GC和CPU使用情况。

HTTP 指标：使用仪表盘 ID 6756。

• 监控请求率、延迟和错误百分比。

导入方式：

• 点击 "+" → "Import" → 输入仪表盘 ID。

第四步：创建自定义指标

让我们来跟踪一个业务相关的指标：登录尝试次数。

使用MeterRegistry定义自定义指标

注入MeterRegistry并创建计数器：

在服务中使用指标

这将生成三个时间序列：

• login_attempts_total{type="auth"} — 跟踪登录尝试总次数
• login_attempts_total{type="auth", result="success"} — 跟踪成功登录尝试次数
• login_attempts_total{type="auth", result="failure"} — 跟踪失败登录尝试次数

第五步：在Grafana中可视化自定义指标

创建跟踪登录尝试的仪表盘：

新增一个新的面板 → “Add panel”.

Query:

• 使用 rate() 函数计算5分钟内的每秒平均请求率

可视化配置：

• 选择"Graph"图表类型以查看趋势。
• 将"result"标签分成独立的线条显示。

专业建议：添加统计面板展示总尝试次数：

生产环境最佳实践

1. 避免高基数：不要使用无界标签（如用户ID）
2. 使用层级化指标：按http.requests.total格式组织指标名称
3. 端点安全：使用Spring Security保护/actuator/prometheus端点
4. 设置告警：针对错误率激增或JVM内存溢出配置Grafana告警

小结

通过Prometheus和Grafana，您不仅是在监控应用——更是在深入理解系统运行。指标数据将转化为可读性极强的运维叙事，比如：

• "为什么昨天的登录尝试次数下降了？
• "新版本发布对GC暂停有什么影响？"

通过添加自定义指标，您可以将原始数据转化为可执行的洞察。现在就开始全面埋点监控——当你在深夜调试系统故障时，未来的你会感谢现在的决定！

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

1. @Formula注解是什么？

1.1 动态计算字段值

Hibernate中的**@Formula注解允许您在实体中映射计算字段。不同于直接将数据库列映射到Java字段，@Formula**可定义SQL表达式用于字段值的动态计算。该特性特别适用于依赖其他列或表数据的只读字段。

例如，在Employee实体中需要根据first_name和last_name列生成全名，使用**@Formula**即可实现无需数据库存储全名：

1.2 实现原理

Hibernate在查询实体时会将**@Formula**定义的SQL表达式直接注入SELECT语句。每次实体加载时都会重新计算表达式值，非常适合基于其他列或关联表数据的动态字段。

上例中，每次加载Employee时Hibernate会执行SQL：SELECT concat(first_name, ' ', last_name) AS full_name FROM employee 来计算fullName字段。

1.3 只读特性

@Formula的核心特性是只读性。虽然可以映射计算字段到实体，但无法通过修改该字段值来更新数据库。这种特性有利于性能优化，因为字段值在每次查询时都会重新计算。

2. @Formula实战应用

2.1 聚合值计算

复杂场景示例：需要从多个订单明细计算订单总价。使用**@Formula**创建计算字段自动汇总明细价格：

该案例中，@Formula通过子查询计算关联OrderLine实体的总价，避免数据库冗余存储，每次订单查询时自动重新计算。

2.2 多表数据整合

@Formula可整合多表数据。例如根据PerformanceReview和Training相关实体计算员工综合评分：

2.3 最佳实践

SQL表达式优化：由于**@Formula**在每次实体加载时执行，需确保SQL表达式高效。复杂子查询可能影响性能，应谨慎使用。

只读场景专用：适用于派生字段计算，写入场景建议直接映射列或使用@Transient进行Java端计算。

结合延迟加载：当公式依赖复杂查询时，建议使用延迟加载策略避免不必要的性能消耗。

排序限制：使用**@Formula**字段排序可能导致性能问题，因排序需依赖数据库层SQL表达式计算。

2.4 效果演示

实际订单查询SQL示例：

查询结果示例：

可见totalPrice字段根据OrderLine表数据动态计算生成。

3. 总结

本文详细解析了Hibernate**@Formula注解，展示了从简单字段拼接至复杂SQL表达式应用场景。作为增强Hibernate映射灵活性的利器，需注意性能优化与适用场景。遵循本文最佳实践，可有效简化实体映射并保持数据库结构整洁。如有关于@Formula**或Hibernate的疑问，欢迎留言讨论！

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

当你的 Spring Boot 应用响应迟缓，且已采用缓存、数据库索引和异步处理优化后，下一个优化方向在哪里？我的答案是 JVM 本身。

经过性能分析和深入研究，我发现合理配置 JVM 参数可以带来显著的性能提升——在负载压力下实现高达 300% 的响应速度提升，且无需修改任何应用代码。

本文将详解：

• 实际采用的 JVM 参数配置
• 这些参数生效的原理
• 优化前后的基准测试对比
• 安全调优的实施方法

基准测试：性能瓶颈在哪？

我的应用是一个典型的 Spring Boot REST API，使用 PostgreSQL 数据库和 Hibernate ORM。主要处理 CPU 密集的 JSON 转换和中等强度的数据库查询。

使用 wrk 进行压力测试：

优化前性能指标

常规负载下表现尚可，但在生产级流量下延迟峰值难以接受。

第一步：启用 G1 垃圾回收器

Spring Boot 应用通常内存消耗较大，特别是在处理 JSON 数据和 Hibernate 会话时。G1 垃圾回收器专为需要大堆内存和低暂停时间的应用设计。

G1 将堆内存划分为多个区域并行回收，有效减少「全局停顿」时间。

进阶调优：降低延迟

这些参数要求 JVM 将 GC 停顿控制在 100ms 以内，并通过并行引用处理降低长尾延迟。

第二步：压缩类与对象元数据

减少内存占用可为应用数据腾出更多空间，同时降低 GC 频率。

多数 64 位 JVM 默认启用这些参数，显式声明可确保跨环境一致性。

第三步：调整线程栈大小

每个线程默认占用 1MB 栈内存。当应用创建数百个线程（如数据库连接池、异步工作线程）时，内存消耗将显著增加。

将线程栈调整为 256KB（经负载测试验证安全），释放堆内存同时避免栈溢出。

第四步：启动时预分配内存

强制 JVM 在启动时完成内存分配，避免运行时因内存分页导致的性能波动。

第五步：预热 JIT 编译器

JVM 性能会随着 JIT 编译器对热点代码的优化逐步提升。以下参数可加速优化过程：

字符串去重功能可减少处理大型 JSON 数据时的内存重复占用。

完整 JVM 参数清单

最终采用的优化配置：

可在 application.properties 或 Dockerfile 中配置：

优化后性能表现

实施建议

1. 环境适配测试 - JVM 行为因工作负载和硬件差异可能不同
2. 启用 GC 日志：

• -Xlog:gc*:file=gc.log:time,uptime,level,tags

3. 根据容器内存限制或实例规格调整堆大小 (-Xms, -Xmx)

结论

对于生产环境的 Spring Boot 应用，合理配置 JVM 参数能释放巨大性能潜力。通过本文的调优方案，我实现了 3 倍性能提升——完全无需修改 Java 代码。

建议从 -XX:+UseG1GC 和 -XX:MaxGCPauseMillis=100 开始，再根据具体性能表现逐步添加其他参数。

请谨记：JVM 绝非黑盒。通过恰当调优，这台强大的机器定能展翅高飞。

本文翻译自：https://medium.com/@kanishks772/i-boosted-my-spring-boot-apps-performance-by-300-with-these-jvm-flags-4935cb442e9b

如果你曾经在Java企业级代码库中工作过，你很可能遇到过一个Controller或Service做了太多事情 — 业务逻辑、日志记录、验证、认证、指标统计、重试等。所有这些都在一个方法中。

结果如何？代码难以阅读，更难测试，几乎不可能干净地扩展。

所以，我要做出一个大胆的声明： 在企业级应用中，如果没有面向切面编程（AOP），编写干净、可维护的Java代码是不可能的。

让我来解释原因，以及如何使用AOP为最混乱的Spring后端带来清晰和秩序。

什么是AOP？

**面向切面编程（AOP）**是一种编程范式，它允许你将横切关注点（日志记录、安全、事务等）与业务逻辑分开模块化。

在Java中，AOP通常使用注解和代理来实现 — 特别是通过Spring AOP或AspectJ。

问题：横切关注点

让我们看一个典型的Spring服务：

现在想象这个方法在20个服务中。每一个都混合了：

• 日志记录
• 验证
• 监控
• 错误处理
• 重试逻辑

每个关注点都被重复和纠缠在一起，违反了单一职责原则，使得关注点的清晰分离变得不可能。

解决方案：AOP来拯救

通过Spring AOP，你可以将这些横切关注点提取到可组合、可重用的切面中。

日志切面

验证切面

指标切面

干净的服务代码

现在你的服务只关注业务逻辑：

这才是干净代码应该有的样子 — 简短、专注且可测试。

真实基准测试：使用和不使用AOP

测试设置

• 100,000次服务方法调用
• 关注点：日志记录、验证、指标
• 使用和不使用AOP的Spring Boot应用

AOP每个方法增加了约300ns的开销。但可维护性、可重用性和可测试性得到了显著改善。

对AOP的常见反对意见

"它难以调试。"

只有在过度使用时才会如此。保持切面小而专注，并始终为它们编写测试。Spring的AOP日志功能（@EnableAspectJAutoProxy(proxyTargetClass = true, exposeProxy = true)）使调试变得可预测。

"它太魔幻了。"

当有文档记录且保持一致时，魔幻就变得可维护。相比之下，在每个方法中硬编码每个关注点是你将来必须偿还的技术债务。

什么时候不该使用AOP

• 你需要底层控制（例如，微优化）
• 你的团队不熟悉AOP且缺乏约定
• 你在Spring生态系统之外（例如，普通Java SE应用）

在这些情况下，显式装饰器或函数组合可能更好。

最后的思考

AOP不是为了抽象而抽象。它是关于干净地分离关注点的代码编写。

当正确使用时：

• 你的服务变得可读
• 你的关注点变得可重用
• 你的代码库变得可测试

如果你在2025年还在编写企业级Java代码，仍然在每个方法中手动复制日志记录、验证和指标，你写的不是干净的代码 — 你写的是杂乱的代码。

本文翻译自：https://medium.com/@kanishksinghpujari/why-writing-clean-java-code-is-impossible-without-aop-change-my-mind-535e89489909

Spring AI 提供了对模型上下文协议（简称 MCP）的支持，该协议允许人工智能模型以结构化的方式与外部工具和资源进行交互并访问它们。

借助 Spring AI，开发人员只需几行代码就可以创建自己的 MCP 服务器，并向人工智能模型公开功能。

MCP 中的授权与安全

MCP 服务器可以使用标准输入输出（STDIO）传输方式在本地运行。要将 MCP 服务器暴露到外部，它必须公开一些标准的 HTTP 端点。虽然私人使用的 MCP 服务器可能不需要严格的身份验证，但企业部署需要对暴露的端点进行完备的安全和权限管理。上周发布的最新版本的 MCP 规范（2025 年 3 月 26 日）解决了这一挑战。它利用广泛使用的OAuth2 框架，为确保客户端与服务器之间的通信安全奠定了基础。

虽然我们不会在这篇博客文章中对 OAuth2 进行全面回顾，但快速复习一下可能会很有用。在该规范草案中，MCP 服务器既是资源服务器，也是授权服务器。

作为资源服务器，它通过检查 “Authorization” 标头对传入的请求进行授权检查。该标头必须包含一个 OAuth2 “access_token”（访问令牌），这是一个表示客户端 “权限” 的字符串。该令牌可以是 JSON Web Token（JWT），也可以是一个本身不携带信息的不透明字符串。如果令牌缺失或无效（格式错误、过期、接收方错误等），资源服务器将拒绝该请求。使用这些令牌，一个典型的请求可能如下所示：

作为授权服务器，MCP 服务器还必须能够以安全的方式为客户端颁发 “access_token”（访问令牌）。在颁发令牌之前，服务器将验证客户端的凭据，在某些情况下，还会验证试图访问服务器的用户身份。授权服务器将决定令牌的属性：有效期、作用域、目标受众等。

使用 Spring Security 和 Spring Authorization Server，我们可以轻松地将这两种功能添加到现有的 Spring MCP 服务器中。

为 MCP Server 添加 OAuth2 支持

在这个示例中，我们将为一个示例 MCP 服务器添加 OAuth 2 支持，该服务器是我们 Spring AI 示例仓库中的“天气” MCP 工具。我们不会探讨交互的客户端方面，只确保我们的服务器能够颁发令牌并验证它们。

首先，我们在 pom.xml 中导入所需的 Spring Boot 启动器：

然后，我们在 application.properties 中配置一个 OAuth2 客户端，以便我们可以请求访问令牌：

这是最简单的客户端。我们可以通过发送 POST 请求直接与授权服务器交互，无需浏览器，并使用硬编码的凭据 mcp-client / secret。

最后一步是启用授权服务器和资源服务器功能。我们通过为安全功能创建一个配置类（例如 SecurityConfiguration）来实现这一点，在该类中我们公开一个 SecurityFilterChain bean：

这个过滤器链将执行以下多项操作：

• 确保每个请求都经过身份验证。有了这一点，我们的 MCP 服务器将只允许带有 “access_token”（访问令牌）的请求。
• 启用 Spring Authorization Server 和 Spring Resource Server。
• 关闭跨站请求伪造（CSRF）防护。MCP 服务器不是为基于浏览器的交互而设计的，不需要 CSRF 防护。
• 启用跨域资源共享（CORS）支持，这样我们就可以使用 MCP 检查器对服务器进行演示。

有了这些设置，我们的应用程序就得到了保护，只会接受带有访问令牌的请求。否则，请求将被拒绝，并返回 HTTP 401 Unauthorized（未经授权）错误。例如：

要使用我们的 MCP 服务器，我们首先需要获取一个访问令牌。我们使用 client_credentials 这种 OAuth2 授权类型，它用于 “机器对机器” 或 “服务账户” 场景：

复制 access_token 的值。它以字母 “ey” 开头。现在我们可以使用这个访问令牌发出请求，并且这些请求应该会成功。例如，使用 curl，你可以将 YOUR_ACCESS_TOKEN 替换为你上面复制的值：

自 0.6.0 版本起，也可以直接在 MCP 检查器中使用访问令牌。只需启动检查器，然后将访问令牌粘贴到左侧菜单的 “Authentication > Bearer”（身份验证 > 承载令牌）字段中。然后点击 “Connect”（连接）：你应该能够进行 MCP 调用。

如果你想自己运行这个示例，可以查看 spring-ai-examples 仓库中的示例代码。

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring专题技术分享点击直达！，欢迎收藏与转发支持！

本文中的示例和模式基于全面的提示工程指南，该指南涵盖了有效的提示工程的理论、原则和模式。本文展示了如何使用Spring AI流畅的ChatClient API将这些概念转化为可运行的Java代码。

为方便起见，示例的结构遵循原始指南中概述的相同模式和技术。本文中使用的演示源代码可在以下地址获取：

• https://github.com/spring-projects/spring-ai-examples/tree/main/prompt-engineering/prompt-engineering-patterns

1. 配置

配置部分概述了如何使用Spring AI设置和调整大型语言模型（LLM）。它涵盖了为你的用例选择合适的LLM提供商，以及配置控制模型输出质量、风格和格式的重要生成参数。

LLM提供商选择

对于提示工程，你首先要选择一个模型。Spring AI支持多个LLM提供商（如OpenAI、Anthropic、Google Vertex AI、AWS Bedrock、Ollama等），这使你无需更改应用程序代码即可切换提供商，只需更新配置。只需添加所选的启动器依赖项spring-ai-starter-model-<MODEL-PROVIDER-NAME>。例如，以下是启用Anthropic Claude API的方法：

同时还需要一些连接属性：spring.ai.anthropic.api-key=${ANTHROPIC_API_KEY}

你可以这样指定特定的LLM模型名称：

在参考文档中可以找到启用和配置首选AI模型的详细信息。

LLM输出配置

在深入探讨提示工程技术之前，了解如何配置大型语言模型（LLM）的输出行为至关重要。Spring AI 提供了多个配置选项，通过 ChatOptions 构建器可以控制生成过程的各个方面。

所有配置都可以通过编程方式应用，如下面的示例所示，也可以在启动时通过 Spring 应用程序属性进行配置。

温度

温度控制模型响应的随机性或 “创造性”。

• 较低的值（0.0 - 0.3）：响应更具确定性和针对性。适用于事实性问题、分类或对一致性要求较高的任务。
• 中等的值（0.4 - 0.7）：在确定性和创造性之间取得平衡。适用于一般用例。
• 较高的值（0.8 - 1.0）：响应更具创造性、多样性，可能会带来惊喜。适用于创意写作、头脑风暴或生成多样化的选项。

理解温度对于提示工程至关重要，因为不同的技术受益于不同的温度设置。

输出长度（MaxTokens）

maxTokens参数限制模型在响应中可以生成的令牌（词元）数量。

• 较低的值（5 - 25）：适用于单个单词、短短语或分类标签。
• 中等的值（50 - 500）：适用于段落或简短解释。
• 较高的值（1000+）：适用于长篇内容、故事或复杂解释。

设置合适的输出长度对于确保获得完整的响应且不过于冗长非常重要。

采样控制（Top-K和Top-P）

这些参数使你能够在生成过程中对令牌选择过程进行精细控制。

• Top-K：将令牌选择限制为接下来最可能的K个令牌。较高的值（例如40 - 50）会引入更多的多样性。
• Top-P（核采样）：动态地从累积概率超过P的最小令牌集中进行选择。常见的值如0.8 - 0.95。

这些采样控制与温度一起作用，塑造响应的特征。

结构化响应格式

除了纯文本响应（使用.content()）之外，Spring AI还通过.entity()方法轻松地将LLM响应直接映射到Java对象。

当与指示模型返回结构化数据的系统提示结合使用时，此功能特别强大。

特定模型选项

虽然可移植ChatOptions为不同的LLM提供商提供了一致的接口，但Spring AI还提供特定模型的选项类，这些类公开了提供商特定的功能和配置。这些特定模型的选项使你能够利用每个LLM提供商的独特功能。

每个模型提供商都有自己的聊天选项实现（例如OpenAiChatOptions、AnthropicChatOptions、MistralAiChatOptions），这些实现公开了提供商特定的参数，同时仍然实现了通用接口。这种方法使你可以灵活地使用可移植选项以实现跨提供商的兼容性，或者在需要访问特定提供商的独特功能时使用特定模型的选项。 请注意，当使用特定模型的选项时，你的代码会与该特定提供商绑定，降低了可移植性。这是在访问高级提供商特定功能与保持应用程序中提供商独立性之间的权衡。

2. 提示工程技术

以下每个部分都实现了指南中的一种特定提示工程技术。通过同时遵循 “提示工程” 指南和这些实现，你将不仅深入了解可用的提示工程技术，还将了解如何在生产Java应用程序中有效地实现它们。

2.1 零样本提示

零样本提示是指在不提供任何示例的情况下要求AI执行任务。这种方法测试模型从零开始理解和执行指令的能力。大型语言模型在大量文本语料库上进行训练，使它们能够理解 “翻译”、“总结” 或 “分类” 等任务的含义，而无需明确的演示。 零样本提示适用于简单直接的任务，在这些任务中模型可能在训练期间见过类似的示例，并且当你希望最小化提示长度时也适用。然而，性能可能会因任务的复杂性以及指令的制定方式而有所不同。

此示例展示了如何在不提供示例的情况下对电影评论的情感进行分类。注意使用较低的温度（0.1）以获得更具确定性的结果，以及直接使用.entity(Sentiment.class)映射到Java枚举。

参考文献：Brown, T. B., 等人 (2020). "Language Models are Few-Shot Learners." arXiv:2005.14165. https://arxiv.org/abs/2005.14165

2.2 一样本和少样本提示

少样本提示为模型提供一个或多个示例，以帮助指导其响应，这对于需要特定输出格式的任务特别有用。通过向模型展示所需的输入 - 输出对示例，它可以学习模式并将其应用于新的输入，而无需进行显式的参数更新。

一样本提供单个示例，当示例成本高昂或模式相对简单时很有用。少样本使用多个示例（通常为3 - 5个），以帮助模型更好地理解更复杂任务中的模式，或说明正确输出的不同变体。

少样本提示对于需要特定格式设置、处理边缘情况的任务特别有效，或者当任务定义在没有示例的情况下可能不明确时也很有用。示例的质量和多样性会显著影响性能。

参考文献：Brown, T. B., 等人 (2020). "Language Models are Few-Shot Learners." arXiv:2005.14165. https://arxiv.org/abs/2005.14165

2.3 系统提示、上下文提示和角色提示

系统提示

系统提示为语言模型设置了整体上下文和目的，定义了模型应该执行的 “大局”。它为模型的响应建立了行为框架、约束和高级目标，与特定的用户查询分开。

系统提示在整个对话中充当持久的 “使命声明”，使你能够设置全局参数，如输出格式、语气、道德边界或角色定义。与专注于特定任务的用户提示不同，系统提示框架了所有用户提示应如何被解释。

当系统提示与Spring AI的实体映射功能结合使用时特别强大：

系统提示对于多轮对话特别有价值，可确保在多个查询中行为一致，并用于建立适用于所有响应的格式约束，如JSON输出。

参考文献：OpenAI. (2022). "System Message." https://platform.openai.com/docs/guides/chat/introduction

角色提示

角色提示指示模型采用特定的角色或身份，这会影响它生成内容的方式。通过为模型分配特定的身份、专业知识或视角，你可以影响其响应的风格、语气、深度和框架。

角色提示利用了模型模拟不同专业领域和通信风格的能力。常见的角色包括专家（例如，“你是一位经验丰富的数据科学家”）、专业人士（例如，“扮演一名导游”）或风格化角色（例如，“像莎士比亚一样解释”）。

角色提示可以通过风格指令进行增强：

这种技术对于专业领域知识、在响应中实现一致的语气以及与用户创建更引人入胜、个性化的交互特别有效。

参考文献：Shanahan, M., 等人 (2023). "Role-Play with Large Language Models." arXiv:2305.16367. https://arxiv.org/abs/

2.4 退后提示（Step-Back Prompting）

退后提示通过首先获取背景知识，将复杂请求分解为更简单的步骤。该技术鼓励模型在回答具体问题之前，先“退后一步”，考虑更广泛的上下文、基本原理或与问题相关的一般知识。

通过将复杂问题分解为更易管理的部分并首先建立基础知识，模型能够对困难问题提供更准确的回答。

退后提示在复杂推理任务、需要专业领域知识的问题以及希望获得更全面和深思熟虑的回答而非即时答案 时尤其有效。

参考文献： Zheng, Z., 等 (2023)。《退后一步：通过抽象激发大型语言模型的推理》。arXiv:2310.06117。 https://arxiv.org/abs/2310.06117

2.5 思维链（Chain of Thought, CoT）

思维链提示鼓励模型通过逐步推理来解决问题，从而提高复杂推理任务的准确性。通过明确要求模型展示其工作过程或以逻辑步骤思考问题，可以显著提升需要多步推理的任务表现。 CoT 通过鼓励模型在生成最终答案之前生成中间推理步骤，类似于人类解决复杂问题的方式。这使得模型的思考过程显式化，并帮助其得出更准确的结论。

关键短语“让我们一步步思考”触发模型展示其推理过程。CoT 对于数学问题、逻辑推理任务以及任何需要多步推理的问题尤其有价值。它通过显式化中间推理步骤来减少错误。

参考文献： Wei, J., 等 (2022)。《思维链提示激发大型语言模型的推理》。arXiv:2201.11903。 https://arxiv.org/abs/2201.11903

2.6 自我一致性（Self-Consistency）

自我一致性涉及多次运行模型并聚合同一问题的结果，以获得更可靠的答案。该技术通过为同一问题采样不同的推理路径并通过多数投票选择最一致的答案，解决了大型语言模型输出的变异性。 通过使用不同的温度或采样设置生成多个推理路径，然后聚合同一问题的最终答案，自我一致性提高了复杂推理任务的准确性。这本质上是一种针对语言模型输出的集成方法。

自我一致性在高风险决策、复杂推理任务以及需要比单一响应更自信的答案时尤其有价值。代价是由于多次 API 调用而增加的计算成本和延迟。

参考文献： Wang, X., 等 (2022)。《自我一致性改进语言模型中的思维链推理》。arXiv:2203.11171。 https://arxiv.org/abs/2203.11171

2.7 思维树（Tree of Thoughts, ToT）

思维树（ToT）是一种高级推理框架，通过同时探索多个推理路径扩展了思维链。它将问题解决视为搜索过程，模型生成不同的中间步骤，评估其潜力，并探索最有前景的路径。

该技术对于具有多种可能方法或需要探索各种替代方案以找到最优路径的复杂问题尤其强大。

注意：原始的“提示工程”指南未提供 ToT 的实现示例，可能是因为其复杂性。以下是一个简化的示例，展示其核心概念。 游戏解决 ToT 示例：

参考文献： Yao, S., 等 (2023)。《思维树：使用大型语言模型进行深思熟虑的问题解决》。arXiv:2305.10601。 https://arxiv.org/abs/2305.10601

2.8 自动提示工程（Automatic Prompt Engineering）

自动提示工程利用 AI 生成和评估替代提示。这种元技术利用语言模型本身来创建、优化和基准测试不同的提示变体，以找到特定任务的最优表述。 通过系统地生成和评估提示变体，自动提示工程可以找到比手动工程更有效的提示，特别是在复杂任务中。这是一种利用 AI 提升自身表现的方法。

自动提示工程对于优化生产系统中的提示、解决手动提示工程已达极限的挑战性任务以及系统性地大规模提升提示质量尤其有价值。

参考文献： Zhou, Y., 等 (2022)。《大型语言模型是人类级别的提示工程师》。arXiv:2211.01910。 https://arxiv.org/abs/2211.01910

2.9 代码提示（Code Prompting）

代码提示是指针对代码相关任务的专门技术。这些技术利用大型语言模型理解和生成编程语言的能力，使其能够编写新代码、解释现有代码、调试问题以及在不同语言之间翻译。

有效的代码提示通常涉及明确的规格、适当的上下文（库、框架、风格指南），有时还包括类似代码的示例。温度设置通常较低（0.1-0.3），以获得更确定的输出。

代码提示对于自动化代码文档、原型设计、学习编程概念以及在编程语言之间翻译尤其有价值。结合少样本提示或思维链等技术可以进一步增强其效果。

参考文献： Chen, M., 等 (2021)。《评估在代码上训练的大型语言模型》。arXiv:2107.03374。 https://arxiv.org/abs/2107.03374

结论

Spring AI 提供了一个优雅的 Java API，用于实现所有主要的提示工程技术。通过将这些技术与 Spring 强大的实体映射和流畅的 API 结合，开发者可以构建复杂且易于维护的 AI 驱动应用程序。 最有效的方法通常是将多种技术结合使用，例如使用系统提示结合少样本示例，或将思维链与角色提示结合。Spring AI 的灵活 API 使这些组合易于实现。

对于生产应用程序，请记住：

• 使用不同参数（温度、top-k、top-p）测试提示
• 考虑在关键决策中使用自我一致性
• 利用 Spring AI 的实体映射实现类型安全的响应
• 使用上下文提示提供特定于应用程序的知识

凭借这些技术和 Spring AI 强大的抽象，开发者可以创建提供一致、高质量结果的强大 AI 驱动应用程序。如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring专题技术分享点击直达！，欢迎收藏与转发支持！

现代 Web 应用正加速与大语言模型（LLMs）深度融合，构建超越传统问答场景的智能解决方案。为突破模型知识边界，增强上下文理解能力，开发者普遍采用多源数据集成策略，将 LLM 与搜索引擎、数据库、文件系统等外部资源互联。然而，异构数据源的协议差异与格式壁垒，往往导致集成复杂度激增，成为制约 AI 应用规模化落地的关键瓶颈。因此，Anthropic公司推出了模型上下文协议（Model Context Protocol, MCP），通过标准化接口为 AI 应用与外部数据源建立统一交互通道。这一协议体系不仅实现了数据获取与操作的规范化，更构建起可扩展的智能体开发框架，使开发者能够基于原生 LLM 能力快速构建复杂工作流。

本文我们就来尝试通过 Spring AI 框架来构建MCP 客户端 - 服务器架构的实现方法。

什么是MCP

关于MCP的架构，这里可以看看ByteByteGo的这张架构图：

MCP遵循客户端 - 服务器架构，围绕几个关键组件：

• MCP Host：用户使用的应用程序，比如：Claude客户端、Cursor这样的AI应用程序，它与大语言模型集成，提供 AI 交互环境以访问不同工具和数据源。
• MCP Client：与MCP Server建立并维护一对一连接的组件。它属于AI应用程序的内部组件，使其能够与 MCP Server通信。例如，若需要 PostgreSQL 数据，MCP 客户端会将请求格式化为结构化消息发送给 MCP 服务器。
• MCP Server：外部数据源集成并公开与之交互功能的组件。作为中间件连接 AI 模型与外部系统（如 PostgreSQL、Google Drive 或 API）。例如，当 Claude 分析 PostgreSQL 中的销售数据时，PostgreSQL 的 MCP 服务器会充当 Claude 与数据库之间的连接器。

下面我们就参考Spring AI的官方文档，来尝试应用简单的MCP，想要了解更多，读者可以点击链接查看官方文档。

创建MCP Host

下面我们将使用Anthropic的Claude模型构建一个聊天机器人，该模型将充当我们的MCP Host。

引入相关依赖

首先，将必要的依赖项添加到项目的pom.xml文件中：

• 下面的案例使用Anthropic的Claude模型，所以使用spring-ai-anthropic-spring-boot-starter，如果你使用其他模型，也可以使用其他启动器依赖项，比如：使用deepseek的话也可以参考之前的《Spring AI + Ollama 实现 deepseek的API服务和调用》去引入相关链接和调用实现。
• spring-ai-mcp-client-spring-boot-starter是引入MCP的重点，用来实现将Spring Boot应用程序与MCP服务器保持一对一连接的客户端。
• 由于Spring AI M6是一个里程碑版本，所以增加了相关repository的配置

接下来，在application.yaml文件中配置调用大模型的密钥和模型名称：

• 使用${}属性占位符从环境变量中加载API密钥的值。
• 模型使用claude-3-7-sonnet-20250219, 你也可以根据需要使用其他模型。

配置上述属性后，Spring AI会自动创建一个ChatModel类型的bean，使我们能够与指定的模型进行交互。

为Brave Search和文件系统服务器配置MCP Client

现在，让我们为两个预构建的MCP服务器实现（Brave Search和文件系统）配置MCP客户端。这些服务器将使我们的聊天机器人能够执行网络搜索和文件系统操作。

首先，在application.yaml文件中为Brave Search MCP Server注册一个MCP Client：

在这里，我们配置了一个使用stdio传输的客户端，使用npx命令来下载并运行@modelcontextprotocol/server-brave-search，并使用-y标志自动确认所有安装提示。

接下来，为文件系统MCP Server配置一个MCP Client：

与之前的配置类似，我们通过命令行参数启动文件系统MCP服务器。该配置允许机器人在指定目录执行文件创建、读写操作（默认当前目录，可通过参数扩展多目录）。Spring AI启动时会自动扫描配置，创建MCP客户端连接服务器，并生成包含所有可用工具的SyncMcpToolCallbackProvider Bean。

构建简单的聊天机器人

配置好人工智能模型和MCP Client后，让我们构建一个简单的聊天机器人：

我们首先使用ChatModel和SyncMcpToolCallbackProvider创建一个ChatClient，它将作为我们与模型交互的主要入口点。

接下来，创建一个新的ChatbotService类，chat()方法将用户的问题传递给聊天客户端bean，并简单返回人工智能模型的响应。：

再创建一个Controller，暴露一个REST API来实现聊天的交互：

构建 MCP Server

除了使用预构建的MCP服务器外，我们还可以创建自己的MCP服务器，用我们的业务逻辑扩展聊天机器人的功能。下面我们创建一个新的Spring Boot应用程序来尝试构建一个简单的MCP Server

引入相关依赖

首先，在pom.xml文件中包含必要的依赖项：

定义并暴露自定义工具

接下来，定义一些我们的MCP服务器将暴露的自定义工具。

我们创建一个AuthorRepository类，该类提供获取作者详细信息的方法：

这里使用@Tool注解对两个方法进行注解，并为每个方法提供简要描述。该描述有助于人工智能模型根据用户输入决定是否调用以及何时调用这些工具，并将结果纳入其响应中。

为了演示，这里直接硬编码返回信息，在实际应用程序中，这些工具通常会与数据库或外部API进行交互。

接下来，向MCP Server注册我们的作者工具：

我们使用MethodToolCallbackProvider从AuthorRepository类中定义的工具创建一个ToolCallbackProvider。应用程序启动时，用@Tool注解的方法将作为MCP工具暴露出来。

构建 MCP Client

最后，为了在聊天机器人应用程序中使用我们的自定义MCP服务器，我们需要针对它配置一个MCP客户端：

在application.yaml文件中，我们针对自定义MCP服务器配置了一个新客户端。请注意，这里我们使用的是sse传输类型。

此配置假设MCP服务器在http://localhost:8081上运行，如果它在不同的主机或端口上运行，请确保更新url。

通过此配置，我们的MCP客户端现在除了可以调用Brave Search和文件系统MCP服务器提供的工具外，还可以调用我们的自定义服务器暴露的工具。

测试聊天效果

现在我们已经构建了聊天机器人并将其与各种MCP Server集成，让我们与它进行交互并进行测试。

我们将使用HTTPie CLI调用聊天机器人的API端点：

在这里，我们向聊天机器人发送一个关于大语言模型知识截止日期之后发生的事件的简单问题。让我们看看得到的响应是什么：

正如我们所见，聊天机器人能够使用配置的Brave Search MCP服务器执行网络搜索，并提供准确的答案以及来源。

接下来，让我们验证聊天机器人是否可以使用文件系统MCP服务器执行文件系统操作：

我们指示聊天机器人创建一个名为mcp-demo.txt的文件，并包含特定内容。让我们看看它是否能够完成请求：

聊天机器人给出了成功的响应。我们可以验证文件是否在我们在application.yaml文件中指定的目录中创建。

最后，让我们验证聊天机器人是否可以调用我们的自定义MCP服务器暴露的工具之一。我们将通过提及文章标题来询问作者详细信息：

让我们调用API，看看聊天机器人的响应是否包含硬编码的作者详细信息：

上述响应验证了聊天机器人使用我们的自定义MCP服务器暴露的getAuthorByArticleTitle()工具获取了作者详细信息。

结论

在本文中，我们探索了模型上下文协议，并使用Spring AI实现了MCP的Client-Server架构，就从Client-Server这一侧其实也挺简单的吧，核心难的其实还是能力的提供方，也就是Server段能调用到多少能力，往往一些专业的能力是由专业软件提供的，这就需要对方有API的支持，然后通过MCP协议来调用。

最后，灵魂一问，你目前有在AI应用中使用MCP Server吗？把你觉得好用的MCP Server在评论推荐一波吧！

最近DeepSeek开源了对openai-o1的第一代开源推理大模型：deepseek-r1，因其极低的成本和与openai-o1相当的性能引发了国内外的激烈讨论。DD在做独立产品的时候也一直都有用DeepSeek的API来实现一些功能，比如：TransDuck中的字幕翻译、视频翻译，效果也是非常不错的。但是，最近因为收到一些私有化的需求，所以对于API的调用就不可行了，不得不转向本地部署大模型，然后提供API的方式来实现。本文就针对这样的情况，尝试了一下使用 Ollama 在本地运行 DeepSeek-R1 并提供 API 服务，然用再使用Spring Boot + Spring AI 实现对 DeepSeek-R1 的调用，有类似需求或者感兴趣的小伙伴也可以根据下面的内容来实践。

使用 Ollama 运行 deepseek-r1

通过 Ollama 来运行 deepseek-r1 非常简单，在Linux服务器上的话，只需要两步：

1. 安装 Ollama

如果本地MacOS或者Windows开发环境使用的话，也可以从前往官网下载客户端版本：

2. 运行 deepseek-r1

如果你的环境没有足够的资源运行671b模型，那么也可以根据你的算力资源情况选择其他几个小参数版本，命令如下：

更多关于信息可查看：https://ollama.com/library/deepseek-r1

使用Spring Boot + Spring AI

在使用Ollama把deepseek-r1跑起来之后，我们就可以开始使用Spring Boot + Spring AI来调用了。

1. 使用 https://start.spring.io/ 构建一个Spring Boot项目。点击ADD DEPENDENCIES，搜索Ollama添加依赖，这是Spring AI对Ollama的实现支持。

2. 打开生成的项目，查看pom.xml，可以看到核心依赖：

如果你要在现有项目中集成的话，就可以直接添加这个依赖即可。

3. 配置Ollama的相关信息：

• spring.ai.ollama.base-url: Ollama的API服务地址，如果部署在非本机，就需要做对应的修改
• spring.ai.ollama.chat.model: 要调用的模型名称，对应上一节ollama run命令运行的模型名称

4. 写个单元测试，尝试调用Ollama中的deepseek-r1模型，这里尝试实现一个翻译的功能。

4. 运行单元测试，结果如下：

可以看到结果响应分成两部分，先是<think>标签包含的内容，这是模型根据提供的提示，生成了一个思考的过程，最后才输出了翻译后的结果。

最后，如果需要本文案例工程的话，可以关注公众号“程序猿DD”，发送关键词：spring-ai-ollama-deepseek-r1获取。

Spring Boot 3.2 于 2023 年 11 月大张旗鼓地发布，标志着 Java 开发领域的一个关键时刻。这一突破性的版本引入了一系列革命性的功能，包括：

• 虚拟线程：利用 Project Loom 的虚拟线程释放可扩展性，从而减少资源消耗并增强并发性。
• Native Image支持：通过Native Image编译制作速度极快的应用程序，减少启动时间并优化资源利用率。
• JVM 检查点：利用 CRaC 项目的 JVM 检查点机制实现应用程序的快速重启，无需冗长的重新初始化。
• RestClient：采用新的 RestClient 接口的功能方法，简化 HTTP 交互并简化代码。
• Spring for Apache Pulsar：利用 Apache Pulsar 的强大功能实现强大的消息传递功能，无缝集成到您的 Spring Boot 应用程序中。

其中，虚拟线程是最近 Java 版本中引入的最具变革性的特性之一。正如官方文件所述：虚拟线程是轻量级线程，可减少编写、维护和调试高吞吐量并发应用程序的工作量。线程是可以调度的最小处理单元。它与其他此类单位同时运行，并且在很大程度上独立于其他此类单元运行。它是 java.lang.Thread 的一个实例。有两种线程：平台线程和虚拟线程。平台线程是作为操作系统 （OS） 线程的瘦包装器实现的。平台线程在其底层操作系统线程上运行 Java 代码，平台线程在平台线程的整个生命周期内捕获其操作系统线程。因此，可用平台线程数限制为操作系统线程数。与平台线程一样，虚拟线程也是 java.lang.Thread 的实例。但是，虚拟线程不绑定到特定的操作系统线程。虚拟线程仍在操作系统线程上运行代码。但是，当在虚拟线程中运行的代码调用阻塞 I/O 操作时，Java 运行时会挂起虚拟线程，直到它可以恢复为止。与挂起的虚拟线程关联的操作系统线程现在可以自由地对其他虚拟线程执行操作。虚拟线程适用于运行大部分时间被阻塞的任务，通常等待 I/O 操作完成。但是，它们不适用于长时间运行的 CPU 密集型操作。

虽然人们普遍认为虚拟线程在 I/O 密集型方案中表现出色，但它们在 CPU 密集型任务中的性能仍然是一个问号。本系列文章深入探讨了虚拟线程在各种用例中的潜在优势，从基本的“hello world”到静态文件服务（I/O 密集型）、QR 码生成（CPU 密集型）和多部分/表单数据处理（混合工作负载）等实际应用。

在本系列的开头文章中，我们已经了解了虚拟线程与物理线程相比在最简单（且不切实际）的 hello world 情况下的性能。物理线程和虚拟线程之间几乎没有任何性能或资源使用差异。在本文中，我们将更加“实用”，并针对静态文件服务器情况进行比较。这绝对是一个常见且“真实世界”的案例。让我们看看这次我们发现了什么。

测试环境

所有测试均在配备 16G RAM、8 个物理内核和 4 个效率内核的 MacBook Pro M2 上执行。测试工具是 Bombardier，它是更快的 HTTP 负载测试器之一（用 Go 编写）。

软件版本为：

• Java v21.0.1
• Spring Boot 3.2.1

程序配置

除了主 Java 类之外，不需要编写任何 Java 文件，静态文件服务器只能通过配置就能发挥作用。

application.properties文件如下：

使用虚拟线程时，我们将通过添加以下行来启用它们：

pom.xml内容：

测试数据

大小完全相同但数据不同的 100K 文件被放置在静态资源目录中。每个文件大小正好是 102400 字节。

文件的命名范围为 1 到 100000。

使用 Bombardier 的修改版本，为每次运行生成随机请求 URL: http://localhost:3000/static/<file-name>

应用场景

为了确保结果一致，每个测试在开始数据收集之前都会经历 5K 请求预热阶段。

然后，在不同范围的并发连接级别（50、100 和 300）中仔细记录测量结果，每个级别都承受 500 万个请求工作负载。

结果评估

除了简单地跟踪原始速度之外，我们还将采用详细的指标框架来捕获延迟分布（最小值、百分位数、最大值）和吞吐量（每秒请求数）。

CPU 和内存的资源使用情况监控将补充此分析，从而提供不同工作负载下系统性能的全面了解。

测试结果

结果以图表形式呈现如下：

总结

对静态文件服务的分析表明，物理线程在性能和资源效率方面略胜一筹（与我们的预期相反）。

不过，这种受 I/O 限制的场景可能并不是充分发挥虚拟线程潜力的理想场所。涉及数据库交互的任务可能会显示出更多令人信服的优势。也许负载不足以让虚拟线程发挥出最大的作用。为了找出答案，我们将在接下来的文章中介绍 URL短链（数据库驱动）、二维码生成（CPU受限）和混合工作负载场景（如表单数据处理），旨在揭示虚拟线程真正出类拔萃的案例。

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

深入研究微服务世界的 Java 开发人员经常发现自己面临着在两个著名框架之间做出选择：Micronaut 和 Spring Boot。

这两个框架都为构建微服务提供了强大的解决方案，但每个框架都有自己的优点和缺点。

在本文中，我们将探讨与 Spring Boot 相比使用 Micronaut 的一些潜在缺点，强调根据项目的特定需求调整您的选择的重要性。

生态系统的成熟度与规模

Spring Boot 在生态系统的成熟度与规模方面远远领先于 Micronaut。

Spring Boot 拥有完善的社区、丰富的库和广泛的工具支持。

另一方面，Micronaut 虽然受到关注，但可能无法提供相同水平的成熟度，并且可能缺乏 Spring Boot 生态系统中可用的第三方集成的广度。

学习曲线

Micronaut 引入了编译时依赖注入等创新概念，这可以为习惯更传统 Spring Boot 方法的开发人员提供更陡峭的学习曲线。

Spring Boot 庞大的社区和全面的文档有助于提供更易于访问的学习路径，使开发人员更容易找到资源和支持。

Annotation处理

Micronaut 在编译时使用Annotation处理可以提高性能，但可能会导致构建时间更长。

相比之下，Spring Boot 依赖运行时反射来进行依赖注入，这可能会导致更快的构建时间，但会牺牲一些运行时性能。

在评估这些框架时，构建时间和运行时效率之间的权衡是一个至关重要的考虑因素。

社区规模与成熟度

Spring Boot 拥有规模更大、更成熟的社区，为开发人员提供了丰富的资源、教程和第三方插件。

虽然 Micronaut 社区不断发展，但它可能无法提供同等水平的资源和支持，这可能会给寻求帮助或寻找最佳实践的开发人员带来挑战。

集成测试

Micronaut 的编译时依赖注入可能会在编写集成测试时带来挑战，而 Spring Boot 的运行时依赖注入使某些类型的测试更加简单。

尽管 Micronaut 提供了测试框架，但与 Spring Boot 中熟悉的方法相比，开发人员可能需要调整其测试策略。

配套工具支持

Spring Boot 受益于广泛的工具和全面的 IDE 支持，有助于实现无缝的开发体验。

Micronaut 虽然正在积极开发，但可能无法提供与各种开发工具相同级别的集成，这可能会给开发人员带来不便。

总结

总之，在 Micronaut 和 Spring Boot 之间进行选择应该以对项目需求、团队的学习偏好以及每个框架生态系统的当前状态进行全面评估为指导。

选择正确的框架是一项战略决策，可以显着影响微服务架构的成功。

本文翻译自：https://medium.com/@bubu.tripathy/micronaut-vs-spring-boot-c700bf721141

过去一年里，ChatGPT 和 Google Bard 这样的东西出现，为大众带来了生成式人工智能，似乎每个人都在梦想和计划如何在他们的项目甚至日常生活中利用人工智能。

如果您是 Spring 开发人员，您可能想知道如何在 Spring 应用程序中实现生成式 AI。如果是这样，那么接下来这个视频一定适合您。

为了构建生成式AI应用，需要完成两个部分：

• AI大模型服务：有两种方式实现，可以使用大厂的API，也可以自己部署，本文将采用ollama来构建
• 应用构建：调用AI大模型的能力实现业务逻辑，本文将采用Spring Boot + Spring AI来实现

Ollama安装与使用

进入官网：https://ollama.com/ ，下载、安装、启动 ollama

具体步骤可以参考我之前的这篇文章：手把手教你本地运行Meta最新大模型：Llama3.1

构建 Spring 应用

1. 通过spring initializr创建Spring Boot应用

2. 注意右侧选择Spring Web和Spring AI对Ollama的支持依赖

3. 点击“generate”按钮获取工程

4. 使用IDEA或者任何你喜欢的工具打开该工程，工程结构如下；

5. 写个单元测试，尝试在Spring Boot应用里调用本地的ollama服务

运行得到如下输出：

上述样例工程打包放公众号了，如果需要的话，关注"程序猿DD"，发送关键词spring+ollama获得下载链接。

小结

通过本文的介绍，我们就已经完成了Spring Boot应用与Ollama运行的AI模型之间的对接。剩下的就是与业务逻辑的结合实现，这里读者根据自己的需要去实现即可。

可能存在的一些疑问

1. 如何使用其他AI模型

通过ollama的 Models 页面，可以找到各种其他模型：

选择你要使用的模型来启动即可。

2. 如何植入现有应用？

打开上面工程的pom.xml，可以看到主要就下面两个依赖：

所以，如果要在现有工程引入的话只要引入spring-ai-ollama-spring-boot-starter依赖就可以了。

好了，今天的分享就到这里。最近较忙，分享较少，感谢持续的关注与支持 ^_^

如果您学习过程中如遇困难？可以加入我们超高质量的技术交流群，参与交流与讨论，更好的学习与进步！

就在昨晚，Spring AI发了个比较重要的更新。由于最近OpenAI推出了结构化输出的功能，可确保 AI 生成的响应严格遵守预定义的 JSON 模式。此功能显着提高了人工智能生成内容在现实应用中的可靠性和可用性。Spring AI 紧随其后，现在也可以对OpenAI的结构化输出完美支持了。

下图展示了本次扩展的实现结构，如果对于当前实现还不够满意，需要扩展的可以根据此图来着手理解分析进行下一步扩展工作。

使用样例

通过Spring AI，开发者可以很方便的来构建针对 OpenAI 结构化输出的请求和解析：

通过 OpenAiChatOptions中指定ResponseFormat来让OpenAI返回JSON格式。

Spring AI还提供了BeanOutputConverter来实现将JSON出转换成Java Bean，比如下面这样：

如果你整合了Spring AI针对OpenAI的Spring Boot Starter模块，那么也可以通过下面的方式来自动配置默认的JSON返回格式：

今天的分享就到这里，感谢阅读！码字不易，点赞、关注、收藏支持一下！随便转载，标注下出处链接即可。

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

昨晚（5月19日），Spring Boot官方发布了一系列Spring Boot的版本更新，其中包括：

• Spring Boot 3.0.0-M3
• Spring Boot 2.7.0
• Spring Boot 2.6.8
• Spring Boot 2.5.14

Spring Boot 3.0.0-M3

此版本包括74个bug修复、文档改进和依赖项升级，其中值得注意的新功能包括：

• Micrometer Observation、Tracing和OtlpMeterRegistry的自动化配置支持
• 恢复对REST Assured和Pooled JMS的支持

Spring Boot 2.7.0

2.7.0是2.x版本的一个重要的新特性版本，在该版本中有这些亮点可以关注一下：

• 增加了Spring GraphQL的自动化配置和Metrics
• 增加@DataCoubaseTest和@DataElasticsearchTest支持
• 可以在使用Cloud Native Buildpacks构建镜像时使用Podman
• 支持Cache2k
• 简化Jackson Mixins的注册
• Web服务器的SSL配置使用PEM编码证书

此外，在该版本中更新了Spring家族中的依赖项目，包括：

• Spring Data 2021.2
• Spring HATEOAS 1.5
• Spring LDAP 2.4
• Spring Security 5.7
• Spring Session 2021.2

更多该版本的更新内容可查看官方release notes：https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.7-Release-Notes

Spring Boot 2.5.14、2.6.8

2.5.14和2.6.8分别是2.5和2.6版本的常规问题修复版本，没有什么新鲜内容，所以这里就不具体介绍了，如果感兴趣的话，可以看看官方文档。

值得注意的是，2.5.14将是2.5版本的最后一个版本，后面不会再继续更新，如果您仍在使用此版本，请考虑尽早升级。

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

就在今天凌晨，Spring Boot 3.2正式发布了！该版本是在Java 21正式发布之后的重要支持版本，所以在该版本中包含大量对Java 21支持的优化。

下面，我们分别通过Spring官方发布的博文和Josh Long长达80+分钟的介绍视频，一起认识一下Spring Boot 3.2最新版本所带来的全新内容。

• 官方博文：https://spring.io/blog/2023/11/23/spring-boot-3-2-0-available-now
• Josh Long的视频：https://www.youtube.com/watch?v=dMhpDdR6nHw

最新特性

通过官方博文的介绍，可以有个大致的最新特性了解，其中包括：

• 支持虚拟线程
• 对JVM Checkpoint Restore的初步支持（CRaC项目）
• SSL 捆绑包重新加载
• 大量可观察性改进
• 支持 RestClient
• 支持 JdbcClient
• 支持 Jetty 12
• Apache Pulsar 对 Spring 的支持
• 对 Kafka 和 RabbitMQ 的 SSL 捆绑支持
• 重新设计的嵌套 Jar 处理
• Docker 镜像构建改进

此外，对于依赖的更新列表，因为比较长，这里DD就不列出来了，感兴趣的可以点击这里查看

视频介绍

下面，可以把关注点放到John Long的介绍视频里。一如既往的干货视频！通过在线编码的方式，直观的给大家展示新功能的魅力。

Tips：Josh Long的视频如果您不方便访问的话，DD这边给大家下载好了，同时也做了一份翻译字幕和中文配音视频。有需要观看的视频的小伙伴可以通过关注公众号：程序猿DD，发送关键词：springboot，获取下载链接。

下面是关于视频的总结，可以先大概看一下视频内容，感兴趣的话可以下载观看：

[00:16] Spring Boot 3.2带来了许多新功能，包括支持虚拟线程和Project Loom、改进的可观察性支持、可重载的SSL支持等。

• Spring Boot 3.2带来了许多新功能，包括虚拟线程和Project Loom。
• Java 21是Spring Boot 3.2的一个重要特性。
• Java 21引入了一些新的语法变化，如封闭类型、模式匹配、智能开关表达式和记录。
• Java 21被称为数据导向编程，旨在改进Java在大型单体应用中的表现。

[10:13] 使用字符串格式化和多行变量非常方便，还有一些新的特性，如模式匹配和解构操作符。

• 字符串格式化和多行变量是方便的选项。
• 新特性包括记录、密封类型、智能开关表达式和模式匹配。
• 目前还没有解构操作符，但正在开发中。
• 项目Loom虚拟线程是Java 21中的重要特性。

[20:27] 在这个片段中，演示了创建一个跳过重复项的集合，并使用线程来记录当前线程的名称和休眠100毫秒。

• 创建了一个跳过重复项的集合。
• 使用线程记录当前线程的名称。
• 休眠100毫秒。
• 演示了使用虚拟线程来执行Java代码。

[30:41] 在Spring Boot 3.2中，我们将使用Java 21、Maven和一些支持库来构建一个与SQL数据库通信的应用程序。

• 使用了test containers API来启动Docker镜像。
• 使用了spring boot starter jdbc依赖来连接PostgreSQL数据库。
• 通过添加特定的配置来启动PostgreSQL容器。

[40:57] 使用Spring Boot 3.0中的声明式接口可以更简化代码，提供一个给定URL请求的猫事实。

• 可以使用新的JDBC和REST客户端来调用端点。
• 使用Project Loom和Drava 21，可以在Spring应用程序的不同层级中获得一致的虚拟线程集成。
• 这种方法既具备了阻塞API的便利性，又不会丧失可用性。
• 可以使用声明式接口来实现给定URL请求的猫事实。

[51:09] Spring框架中有一个称为SmartLifeCycle的接口，可以用来表示典型Spring生命周期的方法。

• SmartLifeCycle是一个更智能的版本，用于让用户消费。
• SmartLifeCycle的方法与检查点方法对应。
• 可以使用SmartLifeCycle来管理应用程序的启动和停止。
• 在这个例子中，通过实现SmartLifeCycle接口，可以实现应用程序的启动和停止功能。

[01:01:23] 通过一个文件来生成唯一的键值对，并且配置了一个自签名的SSL证书。

• 在一个文件中写入数字，每次运行时递增并写入文件。
• 生成的键值对是唯一的，用于展示随时间变化。
• 配置了自签名的SSL证书，并通过指定端口号8443来使用。

[01:11:38] 在本地机器上，我们可以通过Zipkin来查看分布式追踪的图形

• 使用Docker compose启动Zipkin实例
• 在应用代码中增加采样概率
• 通过aop支持在类路径上添加注解来显示跟踪ID和跨度ID
• 通过Zipkin可以查看请求日志和服务之间的跳转

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

当我们想要封装一些自定义功能给别人使用的时候，创建Spring Boot Starter的形式是最好的实现方式。如果您还不会构建自己的Spring Boot Starter的话，本文将带你一起创建一个自己的Spring Boot Starter。

快速入门

1. 创建一个新的 Maven 项目。第三方封装的命名格式是 xxx-spring-boot-starter ，例如：didispace-spring-boot-starter。

2. 编辑pom.xml，添加spring-boot-autoconfigure和spring-boot-starter依赖

3. 创建一个用 @Configuration 注释的配置类，在这里您可以使用@Bean来创建使用@ConditionalOnClass、@ConditionalOnMissingBean等条件注释来控制何时应用配置。

4. 在src/main/resources/META-INF目录下创建spring.factories文件，并在org.springframework.boot.autoconfigure.EnableAutoConfiguration关键字下列出您的自动配置类，比如：

该配置的作用是让Spring Boot应用在引入您自定义Starter的时候可以自动这里的配置类。

注意：Spring Boot 2.7开始，不再推荐使用spring.factories，而是改用/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，文件内容直接放需要自动加载配置类路径即可。这个变更具体可见之前的这篇文章：《Spring Boot 2.7开始spring.factories不推荐使用了》

验证测试

在制作Spring Boot Starter的时候，一定记得使用单元测试来验证和确保自动化配置类在任何条件逻辑在启动器下能够按照正确的预期运行。

创建单元测试

使用@SpringBootTest加载完整的应用程序上下文，并验证启动程序是否正确配置了 Bean 和属性。

覆盖不同的配置

如果有不同的配置方案，那么还需要使用@TestPropertySource或@DynamicPropertySource覆盖属性以测试不同配置下的情况。

或者也可以直接简单的通过@SpringBootTest中的属性来配置，比如下面这样：

覆盖@Conditional的不同分支

如果您的启动器包含条件配置，比如：@ConditionalOnProperty、@ConditionalOnClass等注解，那么就必须编写测试来覆盖所有条件以验证是否已正确。

比如下面这样：

为了覆盖不同的条件分支，我们通常还需要使用@TestConfiguration注解来有选择地启用或禁用某些自动配置。

小结

本文介绍了两个Spring Boot的进阶内容：

1. 如何创建 Spring Boot Starter
2. 如何为 Spring Boot Starter 提供单元测试

掌握这项技能可以帮你更好的为Spring Boot提供模块划的功能封装。如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

最后再给大家推荐一些有关Spring Boot Starter和自动化配置的扩展阅读：

• Spring Boot Starter配置spring.factories的自动生成神器
• Spring Boot自动化配置的利弊及解决之道

如果你是Spring Boot用户的话，一定有这样的开发体验，当我们要引入某个功能的时候，只需要在maven或gradle的配置中直接引入对应的Starter，马上就可以使用了，而不需要像传统Spring应用那样写个xml或java配置类来初始化各种Bean。

如果你有探索过这些Starter的原理，那你一定知道Spring Boot并没有消灭这些原本你要配置的Bean，而是将这些Bean做成了一些默认的配置类，同时利用/META-INF/spring.factories这个文件来指定要加载的默认配置。

这样当Spring Boot应用启动的时候，就会根据引入的各种Starter中的/META-INF/spring.factories文件所指定的配置类去加载Bean。

而这次刚发布的Spring Boot 2.7中，有一个不推荐使用的内容就是关于这个/META-INF/spring.factories文件的，所以对于有自定义Starter的开发者来说，有时间要抓紧把这一变化改起来了，因为在Spring Boot 3开始将移除对/META-INF/spring.factories的支持。

那么具体怎么改呢？下面以之前我们编写的一个swagger的starter为例，它的/META-INF/spring.factories内容是这样的：

我们只需要创建一个新的文件：/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，内容的话只需要直接放配置类就可以了，比如这样：

注意：这里多了一级spring目录。

本期视频：https://www.bilibili.com/video/BV16t4y1W7fF/

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

本文我们一起看看Spring Boot中 JdbcClient 和 JdbcTemplate 之间的差异。

以下内容使用的Java和Spring Boot版本为：

• Java 21
• Spring Boot 3.2.1

假设我们有一个ICustomerService接口：

其中，涵盖了我们常见的数据CRUD操作。

下面就来一起看看，分别使用 JDBC Client 和 JDBC Template 的实现。

初始化对比

JdbcTemplate的初始化：

JdbcClient的初始化；

增删改查的实现对比

查询的实现对比

getAllCustomer查询返回集合数据的实现对比：

getCustomerById查询返回单条数据的实现对比：

insert插入数据的实现对比

update更新数据的实现对比

delete删除数据的实现对比

总结

上面我们分别演示了JdbcClient 和 JdbcTemplate从初始化到真正执行增删改查操作的代码样例。总体上来说，JdbcClient的实现更为简洁方便。如果不考虑其他ORM框架的情况下，在未来的Spring Boot版本中，我会更偏向于选择JdbcClient来操作数据库。那么您觉得怎么样呢？留言区一起聊聊～

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

之前分享了关于Spring新项目Spring AI的介绍视频。视频里演示了关于使用Spring AI将Open AI的能力整合到Spring应用中的操作，但有不少读者提到是否有博客形式的学习内容。所以，本文就将具体介绍如何使用 Spring AI 快速让您的Spring应用拥有生成式AI的强大能力。

动手试试

第一步：使用你最喜欢的IDE来生成一个基础的Spring Boot项目。如果您还不会这个，建议先前往Spring Boot快速入门学习。

第二步：pom.xml中引入依赖。当前分为两个，Azure OpenAI和OpenAI，选择其中一个你在用的即可。

另外，因为用的是SNAPSHOT版本，记得配置：

第三步：打开application.properties，配置您的openai api key

第四步：创建OpenAIController.java

第五步：使用AiClient对象来根据接口输入返回内容：

这是一个最简单的例子，而实际真正应用的时候，我们还需要Prompt来获得更精准的结果。比如，下面这样：

通过使用PromptTemplate创建一个模版，然后根据用户输入使用模版来创建具体的Prompt生成结果。

这里我们提到的Prompt类，其实是一系列Message对象的结构化持有者，每个对象代表完整Prompt的一部。每个Message都有着不同的内容和目的，这种设置有助于与人工智能模型进行复杂而细致的交流，因为Prompt由各种消息组成，每条消息在对话中都指定了特定的功能。

下面是一个更复杂的使用方式：

这里Prompt使用了List类型的Message，包含了多个不同级别的Prompt模版：SystemPromptTemplate和PromptTemplate，以完成更好的生成结果。

完成这几个API的构建之后，您可以尝试启动它，并用API测试工具调用试试，体验一下生成式AI的强大能力。

好了，今天的分享就到这里，感谢阅读！如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

使用Spring Boot开发API的时候，读取请求参数是服务端编码中最基本的一项操作，Spring Boot中也提供了多种机制来满足不同的API设计要求。

接下来，就通过本文，为大家总结6种常用的请求参数读取方式。如果你发现自己知道的不到6种，那么赶紧来查漏补缺一下。如果你知道的不止6种，那么告诉大家，一起互相学习一下吧～

@RequestParam

这是最最最最最最常用的一个了吧，用来加载URL中?之后的参数。

比如：这个请求/user?name=didispace 就可以如下面这样，使用@RequestParam来加载URL中的name参数

@PathVariable

这是RESTful风格API中常用的注解，用来加载URL路径中的参数

比如：这个请求/user/1 就可以如下面这样，使用@PathVariable来加载URL中的id参数

@MatrixVariable

这个我们用的并不是很多，但一些国外系统有提供这类API参数，这种API的参数通过;分割。

比如：这个请求/books/reviews;isbn=1234;topN=5; 就可以如下面这样，使用@MatrixVariable来加载URL中用;分割的参数

@RequestBody

这也是最常用的一个注解，用来加载POST/PUT请求的复杂请求体（也叫：payload）。比如，客户端需要提交一个复杂数据的时候，就要将这些数据放到请求体中，然后服务端用@RequestBody来加载请求体中的数据

@RequestHeader

@RequestHeader注解用来加载请求头中的数据，一般在业务系统中不太使用，但在基础设施的建设中会比较常用，比如传递分布式系统的TraceID等。用法也很简单，比如，假设我们将鉴权数据存在http请求头中，那么就可以像下面这样用@RequestHeader来加载请求头中的Authorization参数

@CookieValue

当我们需要与客户端保持有状态的交互时，就需要用到Cookie。此时，服务端读取Cookie数据的时候，就可以像下面这样用@CookieValue来读取Cookie中的SessionId数据

好了，今天的分享就到这里。这些方式你都知道吗？如果有学到新知识，欢迎点赞支持。如果你还知道其他方式，也欢迎评论分享。如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

@Value注解相信很多Spring Boot的开发者都已经有接触了，通过使用该注解，我们可以快速的把配置信息加载到Spring的Bean中。

比如下面这样，就可以轻松的把配置文件中key为com.didispace.title配置信息加载到TestService中来使用

这个注解可以说非常的好用！但是为什么不推荐大家使用它呢？核心原因是：当我们使用@Value来直接提取配置信息使用的时候，会产生配置信息加载的碎片化。比如，同一个配置，可能背多个Service或者Controller使用，当我们再要修改它的时候，就会存在一个遗漏的风险。我们无法方便的维护这些配置加载而导致一些问题。

那么，如果不使用@Value，我们应该用什么来替代呢？

我比较推荐的就是使用@ConfigurationProperties来分类和加载各种配置信息，比如，我要加载关于com.didispace的相关配置时候，就写一个这样的实现：

这个DidispaceProperties就会加载com.didispace开头的配置。其他Service或者Controller要使用这些配置的时候，就通过注入DidispaceProperties就也可以了。如果要修改配置相关的逻辑，也只需要修改DidispaceProperties中的内容即可，而不是到处找@Value的配置。

另外，在这里，其实还可以增加对配置的校验，主要在pom.xml中引入spring-boot-starter-validation模块。然后修改配置类，增加@Validated注解和具体校验注解，比如：

这就轻松实现配置的校验了，是不是很方便呢？

今天的分享就到这里。如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

之前已经分享过多篇关于Spring Boot中使用Java 21新特性虚拟线程的性能测试案例：

• Spring Boot 3.2虚拟线程搭建静态文件服务器有多快？
• Spring Boot 虚拟线程与Webflux在JWT验证和MySQL查询上的性能比较

早上看到群友问到一个关于虚拟线程遇到MySQL连接不兼容导致的性能问题：

这个问题确实之前就有看到过相关的评测，顺着个这个问题，重新把相关评测找出来，给大家分享一下。

以下内容主要参考文章：https://medium.com/deno-the-complete-reference/springboot-physical-vs-virtual-threads-vs-webflux-performance-comparison-for-jwt-verify-and-mysql-23d773b41ffd

评测案例

评测采用现实场景中的处理流程，具体如下：

1. 从HTTP授权标头（authorization header）中提取 JWT
2. 验证 JWT 并从中提取用户的电子邮件
3. 使用提取到的电子邮件执行 MySQL 查询用户
4. 返回用户记录

这个场景其实是Spring Boot 虚拟线程与Webflux在JWT验证和MySQL查询上的性能比较测试的后续。前文主要对比了虚拟线程和WebFlux的，但没有对比虚拟线程与物理线程的区别。所以，接下来的内容就是本文关心的重点：在物理线程和虚拟线程下，MySQL驱动是否有性能优化。

测试环境

• Java 20（使用预览模式，开启虚拟线程）
• Spring Boot 3.1.3
• 依赖的第三方库：jjwt、mysql-connector-java

测试工具：Bombardier

采用了开源负载测试工具：Bombardier。在测试场景中预先创建 100,000 个 JWT 列表。

在测试期间，Bombardier 从该池中随机选择了JWT，并将它们包含在HTTP请求的Authorization标头中。

MySQL表结构与数据准备

User表结构如下：

准备大约10w条数据：

测试代码：使用物理线程

配置文件：

User实体定义：

数据访问实现：

API实现：

应用主类：

测试代码：使用虚拟线程

主要调整应用主类，其他一样，具体修改如下：

测试代码：使用WebFlux

数据访问实现：

业务逻辑实现：

API实现：

应用主类：

测试结果

每次测试都包含 100 万个请求，分别评估了它们在不同并发（50、100、300）水平下的性能。下面是结果展示：

分析总结

在这个测试案例中使用了MySQL驱动，虚拟线程的实现方式性能最差，WebFlux依然保持领先。所以，主要原因在于这个MySQL的驱动对虚拟线程不友好。如果涉及到数据库访问的情况下，需要寻找对虚拟线程支持最佳的驱动程序。另外，该测试使用的是Java 20和Spring Boot 3.1。对于Java 21和Spring Boot 3.2建议读者在使用的时候自行评估。

最后，对于MySQL驱动对虚拟线程支持好的，欢迎留言区推荐一下。如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

早上看到一篇关于Spring Boot虚拟线程和Webflux性能对比的文章，觉得还不错。内容较长，我就不翻译了，抓重点给大家介绍一下这篇文章的核心内容，方便大家快速阅读。

测试场景

作者采用了一个尽可能贴近现实操作的场景：

1. 从授权头信息中提取JWT
2. 验证JWT并从中提取用户的Email
3. 使用用户的Email去MySQL里执行查询
4. 返回用户记录

测试技术

这里要对比的两个核心技术点是：

1. 带有虚拟线程的Spring Boot：这不是一个跑在传统物理线程上的Spring Boot应用，而是跑在虚拟线程上的。这些轻量级线程简化了开发、维护和调试高吞吐量并发应用程序的复杂任务。虽然虚拟线程仍然在底层操作系统线程上运行，但它们带来了显着的效率改进。当虚拟线程遇到阻塞 I/O 操作时，Java 运行时会暂时挂起它，从而释放关联的操作系统线程来为其他虚拟线程提供服务。这个优雅的解决方案优化了资源分配并增强了整体应用程序响应能力。
2. Spring Boot Webflux：Spring Boot WebFlux是Spring生态系统中的反应式编程框架，它利用Project Reactor库来实现非阻塞、事件驱动的编程。所以，它特别适合需要高并发和低延迟的应用程序。依靠反应式方法，它允许开发人员有效地处理大量并发请求，同时仍然提供与各种数据源和通信协议集成的灵活性。

不论是Webflux还是虚拟线程，这两个都是为了提供程序的高并发能力而生，那么谁更胜一筹呢？下面一起看看具体的测试。

测试环境

运行环境与工具

• 一台16G内存的MacBook Pro M1
• Java 20
• Spring Boot 3.1.3
• 启用预览模式，以获得虚拟线程的强大能力
• 依赖的第三方库：jjwt、mysql-connector-java
• 测试工具：Bombardier
• 数据库：MySQL

数据准备

• 在Bombardier中准备100000个JWT列表，用来从中随机选取JWT，并将其放入HTTP请求的授权信息中。
• 在MySQL中创建一个users表，表结构如下：

• 为users表准备100000条用户数据

测试代码

带虚拟线程的Spring Boot程序

application.properties配置文件：

User实体类（为了让文章让简洁一些，这里DD省略了getter和setter）：

应用主类：

提供CRUD操作的UserRepository：

提供API接口的UserController类：

Spring Boot Webflux程序

application.properties配置文件：

User实体（这里DD也省略了构造函数、getter和setter）：

应用主类：

提供CRUD操作的UserRepository：

提供根据id查用户的业务类UserService：

提供API接口的UserController类：

测试结果

接下来是重头戏了，作者对两个技术方案都做了500w个请求的测试，评估的不同并发连接级别包含：50、100、300。

具体结果如下三张图：

最后，作者得出结论：Spring Boot Webflux要更优于带虚拟线程的Spring Boot。

似乎引入了虚拟线程还不如已经在用的Webflux？不知道大家是否有做过相关调研呢？如果有的话，欢迎在留言区一起聊聊～

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

如果您对这篇内容的原文感兴趣的话，可以通过下面的链接直达：

原文：https://medium.com/deno-the-complete-reference/springboot-virtual-threads-vs-webflux-performance-comparison-for-jwt-verify-and-mysql-query-ff94cf251c2c

在前几天分享的关于Spring Boot Starter中的spring.factories文件不再推荐使用的视频下，看到有网友问了这样一个问题：

这个文件也是位于/META-INF/目录下面：

里面的大概是这样的：

spring.factories的作用是让Spring Boot知道要加载这个Starter的哪些配置类，而这个文件又有啥用呢？

其实，之前我在Spring Boot教程中有具体讲过，这个内容是配置元数据。它的主要作用就是，当我们在配置文件中尝试编写配置信息的时候，IDE可以根据这个配置元数据给出了相关的提示信息，比如：

所以，要做一个体验良好的Starter，这个文件还是非常重要的，对于使用你封装的开发者来说，写配置的时候就会方便很多。

如何自动生成？

既然spring.factories可以自动生成，那么spring-configuration-metadata.json文件可以自动生成吗？

答案是肯定的，不然维护这个json文件都会累死人！

你只需要在你的pom.xml中加入这个依赖：

一切就都搞定了，当你再次编译的时候，spring-configuration-metadata.json文件就自动出现啦！不过，这里还有个前提，你在写配置属性类的时候，有好好写注释，那么自动提示就都会带上了，比如下面这样：

好了，今天的分享就到这里！如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

本期视频已发布：https://www.bilibili.com/video/BV1L54y1o7rC/，欢迎关注我的B站！

当在 Spring Boot 应用程序中使用Spring Data JPA 进行数据库操作时，配置Schema名称是一种常见的做法。然而，在某些情况下，模式名称需要是动态的，可能会在应用程序运行时发生变化。比如：需要做数据隔离的SaaS应用。

所以，这篇博文将帮助您解决了在 Spring Boot 应用程序中如何设置动态 Schema。

问题场景

假设，您的应用程序是一个SaaS软件，需要为多个租户提供服务，每个租户都需要一个单独的数据库架构。

在这种情况下，在应用程序属性中对Shema名称进行硬编码是不太可能的，这样有一个用户新增，就要去写代码更新。

所以，为了应对这一挑战，我们将探索一种允许在运行时动态配置模式名称的解决方案。

代码案例

让我们创建一个 Spring Boot 项目 首先设置一个具有必要依赖项的新 Spring Boot 项目。在项目配置中包括 Spring Web、Spring Data JPA 和关于数据库的依赖项。

定义Spring Data JPA的实体类，例如：

创建数据访问接口，以便您的实体提供 CRUD 操作：

创建一个用来处理业务逻辑，包括与数据库交互的方法：

实现API接口：

重点：配置动态Schema

重新打包该Spring Boot应用，然后当我们要为不同用户使用完全隔离的数据库、完全隔离的应用的时候，只需要通过下面的启动命令，就能轻松实现了：

这里，通过启动命令中的custom.schema.name参数，就能去指定不同的数据库Schema，而应用程序端都是同一套代码，由于启动了新的Spring Boot应用，所以应用端进程也是完全隔离的。这种方法，对于使用Spring Boot构建需要一定资源隔离SaaS软件来说，是个不错的实现方案。

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

昨晚我们讲了Spring Boot 2.7开始不再推荐使用spring.factories了，今天早上公众号（程序猿DD）上也推了，然后收到了不少反馈。其中有个网友说：要维护两个文件，太麻烦了。

作为一名优秀的程序员，当觉得麻烦的时候，第一反应就是要想办法偷懒！

所以，今天就给大家讲讲怎么样轻松的维护这两个文件！

开源项目：mica-auto

为了解决维护麻烦的问题，这里要给大家推荐一个开源项目：mica-auto。不要看Star不多，DD用下来感觉还是非常好的。

• GitHub地址：https://github.com/lets-mica/mica-auto

该项目的实现原理与Lombok类似，利用Java 6就开始支持的Annotation Processor，在编译期扫描注解和处理注解。这里mica-auto的主要解决问题是为Spring Boot自动生成spring.factories、spring-devtools.properties配置。

目前最新的2.3版本也支持Spring Boot 2.7之后推荐使用的org.springframework.boot.autoconfigure.AutoConfiguration.imports配置文件的自动生成。

使用mica-auto

下面以我自己的项目为例，看看怎么一步步整合：

第1步：pom.xml中加入依赖（注意，如果有lombok的话，要放到lombok后面）

第2步：替换一些老的自动化配置注解，比如，我这里用@AutoConfiguration替换了老的@Configuration，这样才能正常的生成出org.springframework.boot.autoconfigure.AutoConfiguration.imports配置，不然用老的配置注解的话，只会自动生成spring.factories

完成上面配置之后，重新编译马上就可以看到文件生成成功了：

本期视频：https://www.bilibili.com/video/BV19v4y1A7T1/

如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

我有一个需求，需要从外部系统获取用户数据。我通过 WebClient 实现的，作为声明性 HTTP 客户端的一部分。

有趣的是，在新的浏览器标签页中打开应用程序后，第一次请求返回了“Connection reset by peer”错误。

这个问题通过禁用对外请求的 keep-alive 解决了。

改造前的代码：

改造后的代码：

在查看了这个 GitHub Issue （https://github.com/reactor/reactor-netty/issues/388#issuecomment-704069492）后，似乎禁用连接池或禁用 keep-alive 并不推荐。

因此，我采用了该 GitHub Issue （https://github.com/reactor/reactor-netty/issues/1774#issuecomment-908066283）中提到的解决方案，设置了某些连接超时。

上述代码已经至少在生产环境中运行了两周。到目前为止，我还没有遇到任何错误。通过设置连接池，我希望能够提高应用程序的性能，特别是由于它经常需要向另一个服务发出大量请求以获取前端所需的所有数据。我计划继续长期监控这个解决方案，以评估其影响，并确定它是否确实提升了应用程序的性能。

本文翻译自原文：https://medium.com/@jskim1991/spring-boot-how-to-solve-webclient-connection-reset-by-peer-error-b1fa38e4106a

这篇博文是临时增加出来的内容，主要是由于最近连载《Spring Cloud Alibaba基础教程》系列的时候，碰到读者咨询的大量问题中存在一个比较普遍的问题：版本的选择。其实这类问题，在之前写Spring Cloud基础教程的时候，就已经发过一篇《聊聊Spring Cloud版本的那些事儿》，来说明Spring Boot和Spring Cloud版本之间的关系。

Spring Cloud Alibaba现阶段版本的特殊性

现在的Spring Cloud Alibaba由于没有纳入到Spring Cloud的主版本管理中，所以我们需要自己去引入其版本信息，比如之前教程中的例子：

而不是像以往使用Spring Cloud的时候，直接引入Spring Cloud的主版本（Dalston、Edgware、Finchley、Greenwich这些）就可以的。我们需要像上面的例子那样，单独的引入spring-cloud-alibaba-dependencies来管理Spring Cloud Alibaba下的组件版本。

由于Spring Cloud基于Spring Boot构建，而Spring Cloud Alibaba又基于Spring Cloud Common的规范实现，所以当我们使用Spring Cloud Alibaba来构建微服务应用的时候，需要知道这三者之间的版本关系。

下表整理了目前Spring Cloud Alibaba的版本与Spring Boot、Spring Cloud版本的兼容关系：

（上表截止于本文发布时间，如果已经过时，请查看Spring官网）

以上版本对应内容根据当前情况实时调整修改，以方便用户了解他们的对应关系变化情况

所以，不论您是在读我的《Spring Boot基础教程》、《Spring Cloud基础教程》还是正在连载的《Spring Cloud Alibaba系列教程》。

当您照着博子的顺序，一步步做下来，但是没有调试成功的时候，强烈建议检查一下，您使用的版本是否符合上表的关系。

简介

在您第1次接触和学习Spring框架的时候，是否因为其繁杂的配置而退却了？在你第n次使用Spring框架的时候，是否觉得一堆反复黏贴的配置有一些厌烦？那么您就不妨来试试使用Spring Boot来让你更易上手，更简单快捷地构建Spring应用！

Spring Boot让我们的Spring应用变的更轻量化。我们不必像以前那样繁琐的构建项目、打包应用、部署到Tomcat等应用服务器中来运行我们的业务服务。通过Spring Boot实现的服务，只需要依靠一个Java类，把它打包成jar，并通过java -jar命令就可以运行起来。这一切相较于传统Spring应用来说，已经变得非常的轻便、简单。

总结一下Spring Boot的主要优点：

• 为所有Spring开发者更快的入门
• 开箱即用，提供各种默认配置来简化项目配置
• 内嵌式容器简化Web项目
• 没有冗余代码生成和XML配置的要求

快速入门

本文我们将学习如何快速的创建一个Spring Boot应用，并且实现一个简单的Http请求处理。通过这个例子对Spring Boot有一个初步的了解，并体验其结构简单、开发快速的特性。

创建基础项目

Spring官方提供了非常方便的工具Spring Initializr来帮助我们创建Spring Boot应用。

使用Spring Initializr页面创建

第一步：访问Spring Initializr：https://start.spring.io/

如图所示，几个选项说明：

• Project：使用什么构建工具，Maven还是Gradle；本教程将采用大部分Java人员都熟悉的Maven，以方便更多读者入门学习。
• Language：使用什么编程语言，Java、Kotlin还是Groovy；本教程将采用Java为主编写，以方便更多读者入门学习。
• Spring Boot：选用的Spring Boot版本；这里将使用当前最新的2.1.3版本。
• Project Metadata：项目的元数据；其实就是Maven项目的基本元素，点开More options可以看到更多设置，根据自己组织的情况输入相关数据，比如：

• Dependencies：选择要加入的Spring Boot组件；本文将实现一个Http接口，所以可以选择Web组件，只需要输入Web，页面会自动联想显示匹配的可选组件：

点击”+“之后，就如下图所示：

第二步：点击”Generate Project“按钮生成项目；此时浏览器会下载一个与上面Artifact名称一样的压缩包。

第三步：解压项目包，并用编译器以Maven项目导入，以IntelliJ IDEA为例：

• 菜单中选择：File –> New –> Project from Existing Sources...

• 选择解压后的项目文件夹，点击OK
• 点击：Import project from external model，并选择Maven，点击Next到底为止。
• 若你的环境有多个版本的JDK，注意到选择Java SDK的时候请选择Java 8（具体根据你在第一步中选择的Java版本为准）

由于我们后续会有很多样例工程，您也可以像我们样例仓库那样，用一个基础仓库，每篇文章的样例以模块的方式保存，具体形式可见文末的案例仓库。

使用IntelliJ IDEA创建

如果是使用IntelliJ IDEA来写Java程序的话，那么还可以直接在编译器中创建Spring Boot应用。

第一步：菜单栏中选择：File => New => Project..，我们可以看到如下图所示的创建功能窗口。

其中Initial Service Url指向的地址就是Spring官方提供的Spring Initializr工具地址，所以这里创建的工程实际上也是基于它的Web工具来实现的。

第二步：点击Next，等待片刻后，我们可以看到如下图所示的工程信息窗口：

其实内容就跟我们用Web版的Spring Initializr是一模一样的，跟之前在页面上一样填写即可。

第三步：继续点击Next，进入选择Spring Boot版本和依赖管理的窗口：

在这里值的我们关注的是，它不仅包含了Spring Boot Starter POMs中的各个依赖，还包含了Spring Cloud的各种依赖。

第四步：点击Next，进入最后关于工程物理存储的一些细节。最后，点击Finish就能完成工程的构建了。

Intellij中的Spring Initializr虽然还是基于官方Web实现，但是通过工具来进行调用并直接将结果构建到我们的本地文件系统中，让整个构建流程变得更加顺畅，还没有体验过此功能的Spring Boot/Cloud爱好者们不妨可以尝试一下这种不同的构建方式。

项目结构解析

通过上面步骤完成了基础项目的创建。如上图所示，Spring Boot的基础结构共三个文件（具体路径根据用户生成项目时填写的Group所有差异）：

• src/main/java下的程序入口：Chapter11Application
• src/main/resources下的配置文件：application.properties
• src/test/下的测试入口：Chapter11ApplicationTests

生成的Chapter11Application和Chapter11ApplicationTests类都可以直接运行来启动当前创建的项目，由于目前该项目未配合任何数据访问或Web模块，程序会在加载完Spring之后结束运行。

项目依赖解析

打开pom.xml，一起来看看Spring Boot项目的依赖：

如上所示，主要有四个部分：

• 项目元数据：创建时候输入的Project Metadata部分，也就是Maven项目的基本元素，包括：groupId、artifactId、version、name、description等
• parent：继承spring-boot-starter-parent的依赖管理，控制版本与打包等内容
• dependencies：项目具体依赖，这里包含了spring-boot-starter-web用于实现HTTP接口（该依赖中包含了Spring MVC）；spring-boot-starter-test用于编写单元测试的依赖包。更多功能模块的使用我们将在后面的教程中逐步展开。
• build：构建配置部分。默认使用了spring-boot-maven-plugin，配合spring-boot-starter-parent就可以把Spring Boot应用打包成JAR来直接运行。

编写一个HTTP接口

• 创建package命名为com.didispace.web（根据实际情况修改）
• 创建HelloController类，内容如下：

• 启动主程序，使用PostMan等工具发起请求：http://localhost:8080/hello，可以看到页面返回：Hello World

编写单元测试用例

打开的src/test/下的测试入口Chapter11ApplicationTests类。下面编写一个简单的单元测试来模拟http请求，具体如下：

使用MockServletContext来构建一个空的WebApplicationContext，这样我们创建的HelloController就可以在@Before函数中创建并传递到MockMvcBuilders.standaloneSetup()函数中。

注意引入下面内容，让status、content、equalTo函数可用

至此已完成目标，通过Maven构建了一个空白Spring Boot项目，再通过引入web模块实现了一个简单的请求处理。

本系列教程《Spring Boot 2.x基础教程》点击直达！。学习过程中如遇困难，建议加入Spring技术交流群，参与交流与讨论，更好的学习与进步！

代码示例

本文的相关例子可以查看下面仓库中的chapter1-1目录：

• Github：https://github.com/dyc87112/SpringBoot-Learning/
• Gitee：https://gitee.com/didispace/SpringBoot-Learning/

如果您觉得本文不错，欢迎Star支持，您的关注是我坚持的动力！

Spring Boot框架本身并没有对工程结构有特别的要求，但是按照最佳实践的工程结构可以帮助我们减少可能会遇见的坑，尤其是Spring包扫描机制的存在，如果您使用最佳实践的工程结构，可以免去不少特殊的配置工作。

典型示例

以下结构是比较推荐的package组织方式：

• root package：com.example.myproject，所有的类和其他package都在root package之下。
• 应用主类：Application.java，该类直接位于root package下。通常我们会在应用主类中做一些框架配置扫描等配置，我们放在root package下可以帮助程序减少手工配置来加载到我们希望被Spring加载的内容
• com.example.myproject.domain包：用于定义实体映射关系与数据访问相关的接口和实现
• com.example.myproject.service包：用于编写业务逻辑相关的接口与实现
• com.example.myproject.web：用于编写Web层相关的实现，比如：Spring MVC的Controller等

上面的结构中，root package与应用主类的位置是整个结构的关键。由于应用主类在root package中，所以按照上面的规则定义的所有其他类都处于root package下的其他子包之后。默认情况下，Spring Boot的应用主类会自动扫描root package以及所有子包下的所有类来进行初始化。

什么意思呢？举个例子，假设我们将com.example.myproject.web包与上面所述的root package：com.example.myproject放在同一级，像下面这样：

这个时候，应用主类Application.java在默认情况下就无法扫描到com.example.myproject.web中的Controller定义，就无法初始化Controller中定义的接口。

非典型结构下的初始化

那么如果，我们一定要加载非root package下的内容怎么办呢？

方法一：使用@ComponentScan注解指定具体的加载包，比如：

这种方法通过注解直接指定要扫描的包，比较直观。如果有这样的需求也是可以用的，但是原则上还是推荐以上面的典型结构来定义，这样也可以少写一些注解，代码更加简洁。

方法二：使用@Bean注解来初始化，比如：

这种方法在业务开发的时候并不是特别推荐，更适合用于框架封装等场景，关于更多封装上的技巧，后面我们在进阶教程中详细讲解。

本系列教程《Spring Boot 2.x基础教程》点击直达！。学习过程中如遇困难，建议加入Spring技术交流群，参与交流与讨论，更好的学习与进步！

代码示例

本教程配套仓库：

• Github：https://github.com/dyc87112/SpringBoot-Learning/
• Gitee：https://gitee.com/didispace/SpringBoot-Learning/

如果您觉得本文不错，欢迎Star支持，您的关注是我坚持的动力！

在昨天的《事务管理入门》一文发布之后，有读者联系说根据文章尝试，加了@Transactional注解之后，事务并没有回滚。

经过一顿沟通排查之后，找到了原因，在此记录一下，给后面如果碰到类似问题的童鞋一个参考。

问题原因

在前文的描述中，我漏了一个细节，其实在示例代码中，与之前拿的基础例子在配置中有一个关键属性没有提到，就是下面这个配置：

这里的spring.jpa.database-platform配置主要用来设置hibernate使用的方言。这里特地采用了MySQL5InnoDBDialect，主要为了保障在使用Spring Data JPA时候，Hibernate自动创建表的时候使用InnoDB存储引擎，不然就会以默认存储引擎MyISAM来建表，而MyISAM存储引擎是没有事务的。

所以，如果你的事务没有生效，那么可以看看创建的表，是不是使用了MyISAM存储引擎，如果是的话，那就是这个原因了！

扩展阅读

@Transactional注解不生效，是Spring使用者非常常见的一类问题，上面我们讲了一种，其他还有一些可能的原因，这里作为扩展阅读一并列出。

如果你当前碰到的原因不是上面的情况，那就看看下面这几种情况是否存在：

1. @Transactional注解修饰的函数中catch了异常，并没有往方法外抛。不过，也有一写复杂场景可能不一样，比如我这里出的四个题中的test4：我来出个题：这个事务会不会回滚？

2. @Transactional注解修饰的函数不是public类型

3. 异常类型错误，如果有通过rollbackFor指定回滚的异常类型，那么抛出的异常与指定的是否一致。

4. 数据源没有配置事务管理器

5. 在一个类中调用自己的方法。建议分开写，互相调用。

6. 对应数据库使用的存储引擎不支持事务，比如：MyISAM。

如果你想与更多有趣的灵魂碰撞，也可以加入我们的技术交流群一起探讨我们的技术人生！

今天看到群里有小伙伴问，这个异常要怎么解决：

异常原因

根据Exception MessageRequest header is too large，就可以判断这个错误原因是HTTP请求头过大导致的。

如何解决

解决方法主要两个方向：

方向一： 配置应用服务器使其允许的最大值 > 你实用实用的请求头数据大小

如果用Spring Boot的话，只需要在配置文件里配置这个参数即可：

方向二：规避请求头过大的情况

虽然上面的配置可以在解决，但是如果无节制的使用header部分，那么这个参数就会变得不可控。

对于请求头部分的数据其实本身并不建议放太大的数据，所以，还是建议把这些数据放到body里更为合理。

那么当你碰到这个异常的时候，是使用什么方法来解决的呢？Spring 开发遇到问题？来这里提问吧，有问必答！

在Spring Boot 2.0中推出了Relaxed Binding 2.0，对原有的属性绑定功能做了非常多的改进以帮助我们更容易的在Spring应用中加载和读取配置信息。下面本文就来说说Spring Boot 2.0中对配置的改进。

配置文件绑定

简单类型

在Spring Boot 2.0中对配置属性加载的时候会除了像1.x版本时候那样移除特殊字符外，还会将配置均以全小写的方式进行匹配和加载。所以，下面的4种配置方式都是等价的：

• properties格式：

• yaml格式：

Tips：推荐使用全小写配合-分隔符的方式来配置，比如：spring.jpa.database-platform=mysql

List类型

在properties文件中使用[]来定位列表类型，比如：

也支持使用逗号分割的配置方式，上面与下面的配置是等价的：

而在yaml文件中使用可以使用如下配置：

也支持逗号分割的方式：

注意：在Spring Boot 2.0中对于List类型的配置必须是连续的，不然会抛出UnboundConfigurationPropertiesException异常，所以如下配置是不允许的：

在Spring Boot 1.x中上述配置是可以的，foo[1]由于没有配置，它的值会是null

Map类型

Map类型在properties和yaml中的标准配置方式如下：

• properties格式：

• yaml格式：

注意：如果Map类型的key包含非字母数字和-的字符，需要用[]括起来，比如：

环境属性绑定

简单类型

在环境变量中通过小写转换与.替换_来映射配置文件中的内容，比如：环境变量SPRING_JPA_DATABASEPLATFORM=mysql的配置会产生与在配置文件中设置spring.jpa.databaseplatform=mysql一样的效果。

List类型

由于环境变量中无法使用[和]符号，所以使用_来替代。任何由下划线包围的数字都会被认为是[]的数组形式。比如：

另外，最后环境变量最后是以数字和下划线结尾的话，最后的下划线可以省略，比如上面例子中的第一条和第三条等价于下面的配置：

系统属性绑定

简单类型

系统属性与文件配置中的类似，都以移除特殊字符并转化小写后实现绑定，比如下面的命令行参数都会实现配置spring.jpa.databaseplatform=mysql的效果：

List类型

系统属性的绑定也与文件属性的绑定类似，通过[]来标示，比如：

同样的，他也支持逗号分割的方式，比如：

属性的读取

上文介绍了Spring Boot 2.0中对属性绑定的内容，可以看到对于一个属性我们可以有多种不同的表达，但是如果我们要在Spring应用程序的environment中读取属性的时候，每个属性的唯一名称符合如下规则：

• 通过.分离各个元素
• 最后一个.将前缀与属性名称分开
• 必须是字母（a-z）和数字(0-9)
• 必须是小写字母
• 用连字符-来分隔单词
• 唯一允许的其他字符是[和]，用于List的索引
• 不能以数字开头

所以，如果我们要读取配置文件中spring.jpa.database-platform的配置，可以这样写：

而下面的方式是无法获取到spring.jpa.database-platform配置内容的：

注意：使用@Value获取配置内容的时候也需要这样的特点

全新的绑定API

在Spring Boot 2.0中增加了新的绑定API来帮助我们更容易的获取配置信息。下面举个例子来帮助大家更容易的理解：

例子一：简单类型

假设在propertes配置中有这样一个配置：com.didispace.foo=bar

我们为它创建对应的配置类：

接下来，通过最新的Binder就可以这样来拿配置信息了：

例子二：List类型

如果配置内容是List类型呢？比如：

要获取这些配置依然很简单，可以这样实现：

代码示例

本文的相关例子可以查看下面仓库中的Chapter2-2-1目录：

• Github：https://github.com/dyc87112/SpringBoot-Learning
• Gitee：https://gitee.com/didispace/SpringBoot-Learning

Spring Booot 2.0 新特性详解正在连载，点击看看都有哪些解读

今天继续来聊Spring Boot 2.0的新特性。本文将具体说说2.0版本中的事件模型，尤其是新增的事件：ApplicationStartedEvent。

在Spring Boot 2.0中对事件模型做了一些增强，主要就是增加了ApplicationStartedEvent事件，所以在2.0版本中所有的事件按执行的先后顺序如下：

• ApplicationStartingEvent
• ApplicationEnvironmentPreparedEvent
• ApplicationPreparedEvent
• ApplicationStartedEvent <= 新增的事件
• ApplicationReadyEvent
• ApplicationFailedEvent

从上面的列表中，我们可以看到ApplicationStartedEvent位于ApplicationPreparedEvent之后，ApplicationReadyEvent之前。

下面我们通过代码的方式来直观的感受这个事件的切入位置，以便与将来我们在这个切入点加入自己需要的逻辑。

第一步：我们可以编写ApplicationPreparedEvent、ApplicationStartedEvent以及ApplicationReadyEvent三个事件的监听器，然后在这三个事件触发的时候打印一些日志来观察它们各自的切入点，比如：

第二步：在/src/main/resources/目录下新建：META-INF/spring.factories配置文件，通过配置org.springframework.context.ApplicationListener来加载上面我们编写的监听器。

此时，我们运行Spring Boot应用可以获得类似如下日志输出：

从日志中我们可以看到清晰的看到ApplicationPreparedEvent、ApplicationStartedEvent以及ApplicationReadyEvent三个事件的切入点。通过这个例子可能读者会感到疑问：ApplicationStartedEvent和ApplicationReadyEvent从事件命名和日志输出位置来看，都是应用加载完成之后的事件，它们是否有什么区别呢？

下面可以看看官方文档对ApplicationStartedEvent和ApplicationReadyEvent的解释：

An ApplicationStartedEvent is sent after the context has been refreshed but before any application and command-line runners have been called.An ApplicationReadyEvent is sent after any application and command-line runners have been called. It indicates that the application is ready to service requests

从文档中我们可以知道他们两中间还有一个过程就是command-line runners被调用的内容。所以，为了更准确的感受这两个事件的区别，我们在应用主类中加入CommandLineRunner的实现，比如：

最后，我们再运行程序，此时我们可以发现这两个事件中间输出了上面定义的DataLoader的输出内容，具体如下：

代码示例

本文的相关例子可以查看下面仓库中的Chapter1-2-1目录：

• Github：https://github.com/dyc87112/SpringBoot-Learning
• Gitee：https://gitee.com/didispace/SpringBoot-Learning

Spring Booot 2.0 新特性详解正在连载，点击看看都有哪些解读

Spring Framework 是一种流行的开源企业级框架，用于创建在 Java Virtual Machine (JVM) 上运行的独立、生产级应用程序。而Spring Boot 是一个工具，可以让使用 Spring 框架更快、更轻松地开发 Web 应用程序和微服务。随着 Spring Boot 的不断发展，开发人员必须跟上最新的升级和变化。

最近，Spring Boot 宣布发布 3.2.x 版本，该版本带来了多项新功能、错误修复和增强功能，鉴于对 Spring Boot 2.7.x 版本的支持已于 2023 年 11 月 18 日结束，这是一个非常重要且强制性的关注用于将 Spring Boot 应用程序升级到最新的 3.x 版本。

因此，在本文中，我们将讨论如何从 Spring Boot 2.x 迁移到 3.x，以及升级的优势以及开发人员在此过程中可能遇到的潜在困难。

升级指南

1. 升级 JDK 17

Spring Boot 3.0 需要 Java 17 作为最低版本。

如果您当前使用的是 Java 8 或 Java 11，则需要在 Spring Boot 迁移之前升级 JDK。

2. 升级到 Spring Boot 3

查看项目及其依赖项的状态后，请升级到 Spring Boot 3.0 的最新维护版本。

我们将使用 Spring Boot 3.2.0 进行升级。

打开项目的 pom.xml 并更新 Spring Boot 的版本，如下所示。

3. 配置属性迁移

在 Spring Boot 3.0 中，一些配置属性被重命名/删除，开发人员需要相应地更新其 application.properties/application.yml。

为了帮助您实现这一点，Spring Boot 提供了一个 spring-boot-properties-migrator 模块。

我们可以通过将以下内容添加到 Maven pom.xml 来添加迁移器：

4. 升级到 Jakarta EE

由于 Java EE 已更改为 Jakarta EE，Spring Boot 3.x 的所有依赖项 API 也从 Java EE 升级为 Jakarta EE。

简单来说，您需要将所有 javax 的 imports 都替换为 jakarta。具体如下：

5. 调整@ConstructorBinding注解

@ConstructorBinding 在 @ConfigurationProperties 类的类型级别不再需要，应将其删除。

当一个类或记录有多个构造函数时，它仍然可以在构造函数上使用，以指示应使用哪一个构造函数进行属性绑定。

6. Spring MVC 和 WebFlux的URL匹配更改

从 Spring Framework 6.0 开始，尾部斜杠匹配配置选项已为 deprecated，其默认值设置为 false。

这意味着以前，以下控制器将匹配GET /health和GET /health/

7. RestTemplate 中的 Apache HttpClient

Spring Framework 6.0 中已删除对 Apache HttpClient 的支持，现在由 org.apache.httpcomponents.client5:httpclient5 取代（注意：此依赖项具有不同的 groupId）。

如果您注意到 HTTP 客户端行为存在问题，则 RestTemplate 可能会回退到 JDK 客户端。

org.apache.httpcomponents:httpclient 可以由其他依赖项传递传递，因此您的应用程序可能依赖此依赖项而不声明它。

下面是迁移后的RestTemplate示例：

8. 升级 Spring Security

Spring Boot 3.0 已升级到 Spring Security 6.0。

因此，WebSecurityConfigurerAdapter 已被弃用。 Spring鼓励用户转向基于组件的安全配置。

为了演示新的配置风格，我们使用 Spring Security lambda DSL 和方法 HttpSecurity#authorizeHttpRequests 来定义我们的授权规则。

下面是使用 WebSecurityConfigurerAdapter 的示例配置，它通过 HTTP Basic 保护所有端点：

展望未来，推荐的方法是注册一个 SecurityFilterChain bean：

9. Spring Kafka 模板升级

KafkaTemplate 方法现在返回 CompleteableFuture 而不是 ListenableFuture，后者已被弃用。

Spring Boot 2.x 中带有 ListenableFuture 的 Kafka 模板:

Spring Boot 3.x 中带有 CompletableFuture 的 Kafka 模板：

10. Spring Doc OpenAPI 升级

springdoc-openapi用于为Spring Boot 项目自动生成 API 文档。

springdoc-openapi的工作原理是在运行时检查应用程序，以根据 spring 配置、类结构和各种注释推断 API 语义。

对于 spring-boot 3 支持，请确保使用 springdoc-openapi v2。

WebMVC 项目的 Spring Doc OpenAPI 升级

对于 WebMVC 项目，您需要在 pom.xml. 文件中包含以下依赖项。

WebFlux 项目的 Spring Doc OpenAPI 升级

对于 WebFlux 项目，您需要在 pom.xml. 文件中包含以下依赖项。

今日分享就到这里，感谢阅读！如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！更多Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

工作流是我们开发企业应用几乎必备的一项功能，工作流引擎发展至今已经有非常多的产品。最近正好在接触Camunda，所以来做个简单的入门整合介绍。如果您也刚好在调研或者刚开始计划接入，希望本文对您有所帮助。如果您是一名Java开发或Spring框架爱好者，欢迎关注我程序猿DD，持续非常技术干货。

Camunda简介

Camunda是一个灵活的工作流和流程自动化框架。其核心是一个运行在Java虚拟机内部的原生BPMN 2.0流程引擎。它可以嵌入到任何Java应用程序和任何运行时容器中。

• 官网网站: https://www.camunda.org/
• 入门文档: https://docs.camunda.org/get-started/

动手整合Camunda

下面就来一步步动手尝试一下吧。

准备工作

1. 使用Camunda提供的项目初始化工具Camunda Automation Platform 7 Initializr

如上图，包名之类的根据自己需要做好配置，最后输入管理账号和密码，点击Generate Project按钮，自动下载工程。

2. 解压下载后的工程，使用IntelliJ IDEA打开，其项目结构

3. 打开pom.xml文件，添加camunda依赖：

由于Camunda Automation Platform 7 Initializr默认的Spring Boot版本已经是3.1了，所以如果要做一些降级调整，可以手工修改pom.xml中dependencyManagement配置，比如下面这样：

4. 打开配置文件application.yaml，可以看到类似下面的内容

• spring.datasource.url：工作流引擎使用的数据库配置，您也可以根据官网文档去调整到其他数据库中（尤其生产环境）。
• camunda.bpm.admin-user：管理员账户配置，可以在这里修改用户名和密码

创建一个简单的工作流

下面我们尝试创建一个简单的工作流：

第一步，我们将请求用户提供两个输入：name和message 第二步，我们将这些输入传递给我们的服务以创建消息输出

开始编码：

1. 创建第一步提到的数据模型

2. 根据第二步，创建接收消息的接口