每秒百萬請求不是夢！Spring Boot 性能優化的七大實戰策略全揭秘
作者：路條編程
在進行系統優化之前，我首先建立了詳細的性能監控指標體系。你無法改進無法度量的東西，所以搞清楚現有性能瓶頸，是一切工作的基礎。
在進行系統優化之前，我首先建立了詳細的性能監控指標體系。你無法改進無法度量的東西，所以搞清楚現有性能瓶頸，是一切工作的基礎。
初始性能診斷結果如下：
- 最大并發吞吐量：50,000 req/s
- 平均響應時間：350ms
- P95 響應時間：850ms
- 峰值 CPU 占用：85%-95%
- 堆內存占用率：約為 75%
- 數據源連接池：頻繁打滿（最大連接數 100）
- 線程池：長時間處于滿負荷狀態
分析工具清單：
- JMeter用于壓力測試與吞吐率基準評估
- Micrometer + Prometheus + Grafana監控系統運行狀態
- JProfiler熱點方法剖析
- 火焰圖（Flame Graph）：查找 CPU 重度使用點
識別出的關鍵瓶頸：
- Tomcat 默認線程模型限制性能
- 數據庫連接配置不當，頻繁競爭連接
- Jackson 序列化耗費 CPU
- 外部服務調用引起線程阻塞
- GC 頻繁觸發，影響吞吐性能
接下來，我們逐一拆解并修復這些問題。
性能提升之路
摒棄阻塞式編程，擁抱響應式模型
傳統的阻塞服務：
@Service
public class ProductService {
public Product getProductById(Long id) {
return repository.findById(id)
.orElseThrow(() -> new ProductNotFoundException(id));
}
}響應式版本改造：
@Service
public class ProductService {
public Mono<Product> getProductById(Long id) {
return repository.findById(id)
.switchIfEmpty(Mono.error(new ProductNotFoundException(id)));
}
}控制器同步更新：
@RestController
@RequestMapping("/products")
public class ProductController {
@GetMapping("/{id}")
public Mono<ResponseEntity<Product>> getProduct(@PathVariable Long id) {
return service.getProductById(id)
.map(ResponseEntity::ok)
.defaultIfEmpty(ResponseEntity.notFound().build());
}
}關鍵依賴添加：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-r2dbc</artifactId>
</dependency>
<dependency>
<groupId>com.github.jasync-sql</groupId>
<artifactId>jasync-r2dbc-mysql</artifactId>
<version>2.1.24</version>
</dependency>?? 改造成果：吞吐能力翻倍，WebFlux 線程復用帶來巨大并發提升。
三重數據庫性能強化手段
精簡查詢邏輯
原始方式（自動派生查詢）：
List<Order>findByUserIdAndStatusAndCreateTimeBetween(...)優化后顯式編寫 SQL：
@Query("SELECT o FROM Order o WHERE o.userId = :userId "+
"AND o.status = :status "+
"AND o.createdDate BETWEEN :start AND :end "+
"ORDER BY o.createdDate DESC")
List<Order>findUserOrdersInDateRange(...);消除 N+1 查詢陷阱
@OneToMany(mappedBy ="order", fetch =FetchType.EAGER)
@BatchSize(size =30)
privateSet<OrderItem> items;合理配置連接池
阻塞式配置：
spring:
datasource:
hikari:
maximum-pool-size: 100
minimum-idle: 50
idle-timeout: 30000
connection-timeout: 2000
max-lifetime: 1800000響應式配置：
spring:
r2dbc:
pool:
initialSize: 30
maxSize: 10
max-acquire-time: 30s
max-idle-time: 30m添加緩存機制：Redis
@Cacheable(value ="products", key ="#id")
public Mono<Product> getProductById(Long id){...}配置緩存：
spring:
cache:
type: redis
redis:
cache-null-values: false
time-to-live: 120m序列化瘦身
通過 Jackson Afterburner 模塊極大壓縮序列化開銷：
@Configuration
public class JacksonConfig {
@Bean
public ObjectMapper objectMapper() {
ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new AfterburnerModule());
mapper.setSerializationInclusion(Include.NON_NULL);
mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);
return mapper;
}
}?? 如果極限性能是目標，請使用 Protocol Buffers 代替 JSON。
調整線程與連接設置
WebFlux 場景下優化 Netty：
spring:
reactor:
netty:
worker:
count: 32
connection:
provider:
pool:
max-connections: 10000
acquire-timeout: 5000傳統 Spring MVC 下優化 Tomcat：
server:
tomcat:
threads:
max: 200
min-spare: 50
max-connections: 8192
accept-count: 100
connection-timeout: 50002.5 Kubernetes + Istio：自動擴容與服務網格能力
Docker 鏡像配置（路徑為 Linux 風格）：
FROM openjdk:17-slim
COPY target/product-app.jar /app.jar
ENV JAVA_OPTS="-XX:+UseG1GC -XX:MaxGCPauseMillis=100"
ENTRYPOINT exec java $JAVA_OPTS -jar /app.jar自動擴縮容策略：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: product-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: product-app
minReplicas: 5
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70Istio 虛擬服務配置：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: product-vs
spec:
hosts:
- product-service
http:
- route:
- destination:
host: product-service
retries:
attempts: 3
perTryTimeout: 2s
timeout: 5s尾聲：性能，是系統穩定的護城河
以上策略全部落實后，服務性能穩定提升，系統吞吐能力提升了數倍。無論你是應對突發流量，還是追求更優的用戶體驗，這些實戰手段都能為你提供強大助力。
?? 提醒：優化永無止境，合理監控 + 持續調優，才是通往“百萬請求”大關的不二法門！
責任編輯：武曉燕
來源：
路條編程
