很多开发者还在用十年前的习惯写现在的 Spring Boot 应用。这种技术代差不仅让代码显得臃肿，更是在浪费服务器的真金白银。本文整理了一些进阶技巧，帮助优化 Spring Boot 应用的运行效率与代码质量。
准备工作：快速搭建 Java 环境
编写代码前需要安装 JDK。但对新手来说，手动配置环境变量和切换版本其实挺浪费时间的。
而 ServBay 提供了集成化的解决方案，支持一键部署 Java 环境，这样开发者可以快速切换不同的 JDK 版本，无需手动调整系统配置，让开发环境的搭建变得高效且规范。
精细化配置 JVM 内存降低云端成本
很多 Spring Boot 应用在云服务器上裸奔。默认的 JVM 配置往往会申请过多的内存，导致账单金额飙升。
如果我们运行的是微服务，其实根本不需要动辄 4GB 的堆空间。我通常会把初始内存和最大内存压到一个合理的范围。
# 限制内存并指定垃圾回收线程数
export JAVA_OPTS="-Xms512m -Xmx1024m -XX:+UseContainerSupport -XX:ParallelGCThreads=2 -XX:MaxMetaspaceSize=256m"
java $JAVA_OPTS -jar app-service.jar
加上 -XX:+UseContainerSupport 后，JVM 能准确识别容器的边界。同时，我会手动限制 Tomcat 的线程池大小，因为默认的 200 个线程对大多数中小型业务来说完全是浪费。
# application.yaml 里的精简配置
server:
tomcat:
threads:
max: 60
通过这些设置，单个容器的内存占用通常能降低 20% 以上，从而减少云服务器的节点数量。
采用现代 Java 语法精简业务逻辑
如果代码库里到处是冗长的 Getter 和 Setter，或者还在用复杂的 if-else 处理枚举，那就赶紧升级新版 Java。
使用 Record 定义数据模型
Record 适合用于 DTO 或 API 返回对象。我现在的 API 数据传输对象全部改用 Record。
// 这一行代码就搞定了构造、Getter 和 toString
public record UserResponse(Long id, String nickname, String email) {}
文本块与 Switch 表达式
文本块解决了多行字符串拼接时的转义符困扰，而 Switch 表达式则提供了更安全的返回值方式。
// 使用文本块编写 SQL
String sql = """
SELECT * FROM product_info
WHERE category = 'ELECTRONICS'
AND stock > 0
""";
// Switch 表达式直接返回结果
String categoryName = switch (typeCode) {
case 1 -> "电子产品";
case 2 -> "家居生活";
default -> "其他类型";
};
Switch 的模式匹配
Java 17 引入的模式匹配让类型判断更加直观，减少了显式的强制类型转换。所以，处理复杂的业务分支时，我会用增强型的 Switch 配合模式匹配。
// 处理不同类型的事件消息
static String handleEvent(Object event) {
return switch (event) {
case OrderEvent o -> "订单编号：" + o.id();
case UserEvent u -> "用户名称：" + u.name();
case null -> "空消息";
default -> "未知事件";
};
}
善用 Stream API 的增强功能
Stream API 在数据处理方面持续进化。新版增加了更丰富的收集器与过滤逻辑，使得内存中的数据聚合与转换更加高效。合理使用并行流处理大规模数据集，可以充分利用多核 CPU 的性能，缩短复杂逻辑的执行时间。
启用现代垃圾回收器减少停顿
在高并发场景下，我更倾向于使用 ZGC 这种低延迟垃圾回收器。它能把停顿时间压减到 1 毫秒以内，用户几乎感知不到卡顿。
如果对启动速度有极端要求，比如在函数计算场景下，我会利用 GraalVM 将 Spring Boot 编译为原生镜像（Native Image）。
# 构建原生执行文件
./mvnw native:compile -Pnative
这样编译出来的程序启动时间从几秒缩短到几十毫秒，内存占用甚至能砍掉 80%。虽然编译过程变久了，但运行时换来的性能增益它值得。
耗时任务必须异步化
在 Controller 里同步生成 PDF 或者发送复杂的邮件的都叉出去，这会直接堵死 Web 线程。
现在的做法是把这些重活直接扔进消息队列，让主流程瞬间返回。
// 投递到 RabbitMQ 或 Kafka@PostMapping("/submit-report")
public ResponseEntity<String> handleReport(@RequestBody ReportConfig config) {
taskQueue.send("report_gen_topic", config);
return ResponseEntity.accepted().body("报告生成任务已启动，请稍后查看");
}
把计算压力转移到后端的 Worker 节点上，这样主 API 就能保持极高的响应速度，即便在高并发流量下也不会崩溃。
总结
优化 Spring Boot 应用是一个系统性的工程。如果你还在忍受冗长的编译等待、高昂的云端开支和莫名其妙的停顿，现在就应该改变做法了。快来试试这些技巧吧。
