前言
Spring Boot配置優化,每個配置都附有代碼和詳解,即使剛接觸也能輕鬆上手(注:具體配置需結合實際使用的Spring Boot版本進行調整)。
一、Tomcat連接池配置:應對高併發的“交通指揮官”
Spring Boot默認集成Tomcat服務器,但默認連接池參數偏保守,高併發時容易出現“請求排隊、響應變慢”的問題,就像“窄馬路容不下太多車”。我們需要調整參數,讓Tomcat能“容納更多請求、快速處理任務”。
配置方案
server:
tomcat:
max-connections: 10000 # 最大連接數 默認:8192
threads:
max: 800 # 最大工作線程數 默認:200
min-spare: 100 # 最小空閒線程數 默認:10
accept-count: 100 # 等待隊列長度 默認:100
connection-timeout: 20000 # 連接超時時間(毫秒),默認未配置
參數解釋
max-connections:Tomcat能同時處理的最大連接數,默認8192,高併發場景可調至10000;threads.max:處理請求的“最大工作人員數量”,線程越多,同時處理的請求越多,默認200,根據服務器CPU核數調整(一般設為CPU核數的2-4倍);threads.min-spare:即使沒請求,也保留的“空閒工作人員數量”,避免請求突然增多時“沒人幹活”;connection-timeout:請求等待超時時間,超過這個時間就拒絕請求,防止“無效請求佔用資源”。
二、數據庫連接池配置:給數據庫“配好接待員”
Spring Boot默認用HikariCP作為數據庫連接池(性能最優的連接池之一),但默認最大連接數僅10,若項目併發高,會出現“數據庫連接不夠用,請求卡殼”的情況,就像“餐廳只有10個服務員,客人多了要排隊”。
配置方案
spring:
datasource:
hikari:
maximum-pool-size: 50 # 最大連接數,默認:10
minimum-idle: 10 # 最小空閒連接,默認:10
connection-timeout: 30000 # 連接超時時間(毫秒)
idle-timeout: 600000 # 空閒連接超時時間,默認:600000(10分鐘)
max-lifetime: 1800000 # 連接最大存活時間,默認:1800000(30分鐘)
leak-detection-threshold: 60000 # 連接泄露檢查閾值,默認:0(關閉)
參數解釋
maximum-pool-size:連接池裏的“最大服務員數量”,根據數據庫性能調整(比如MySQL建議設為20-50),太多會給數據庫造成壓力;minimum-idle:連接池裏“常駐的空閒服務員”,保證隨時有連接可用,不用每次都“臨時招人”;idle-timeout:空閒連接“多久沒活幹就釋放掉”,避免“佔着位置不幹活”;leak-detection-threshold:開啓“連接泄露檢查”,若連接超過60秒沒歸還,就報警提示,防止代碼bug導致連接浪費。
三、Jackson時區序列化:解決分佈式“時間混亂”
Spring Boot默認用Jackson處理JSON序列化,但會用系統時區——如果項目部署在不同時區的服務器(比如一台在上海、一台在北京),會出現“同一時間顯示不同”的問題,就像“有的表走北京時間,有的走格林尼治時間”。
配置方案
spring:
jackson:
time-zone: GMT+8
date-format: yyyy-MM-dd HH:mm:ss
serialization:
write-dates-as-timestamps: false
參數解釋
time-zone: GMT+8:強制用東八區(北京時間),不管服務器在哪個時區,時間顯示都統一;date-format:指定時間格式為“年-月-日 時:分:秒”,避免返回“時間戳”(數字),前端更易處理;write-dates-as-timestamps: false:關閉“時間戳模式”,用上面指定的格式返回時間。
四、日誌配置:給日誌“裝個管家”
Spring Boot默認用Logback日誌框架,但默認配置不會“滾動清理日誌”——日誌文件會一直變大,最終佔滿硬盤,就像“垃圾不分類不清理,堆滿房間”。我們需要讓日誌“按大小滾動、定時清理”。
配置方案
logging:
file:
name: app.log # 日誌文件名
logback:
rollingpolicy:
max-file-size: 100MB # 單個日誌文件最大大小
max-history: 30 # 日誌保留30天
total-size-cap: 3GB # 所有日誌文件總大小上限
參數解釋
max-file-size:單個日誌文件最大100MB,滿了就自動生成新文件(比如app.log→app.1.log→app.2.log);max-history:30天前的日誌自動刪除,不用手動清理;total-size-cap:所有日誌文件加起來不超過3GB,避免佔滿硬盤。
五、緩存配置:替代默認緩存,避免“內存爆炸”
Spring Boot的@Cacheable註解默認用ConcurrentHashMap實現緩存,但這個實現是“沒有管理員”的,導致緩存會無限堆積,高併發時會導致內存溢出,就像“倉庫無限囤貨,最終塌了”。推薦用Caffeine替代,它能“限大小、定時清理”。
配置方案
spring:
cache:
type: caffeine # 指定緩存類型為Caffeine
caffeine:
spec: maximumSize=10000,expireAfterWrite=600s # 緩存規則
參數解釋
type: caffeine:告訴Spring Boot不用默認緩存,改用Caffeine;maximumSize=10000:緩存最多存10000條數據,滿了就淘汰“最久不用的”;expireAfterWrite=600s:數據存入緩存後,600秒(10分鐘)後自動過期,避免數據過時。
六、監控端點配置:暴露必要信息,避免“隱私泄露”
Spring Boot Actuator默認暴露很多監控端點(比如健康檢查、配置信息、環境變量),若全部開放,可能泄露敏感信息(比如數據庫密碼),就像“家門不鎖,陌生人能進客廳”。我們只需暴露必要端點,並控制訪問權限。
配置方案
management:
endpoints:
web:
exposure:
include: health,info,metrics # 只暴露3個必要端點
endpoint:
health:
show-details: when-authorized # 健康詳情只給授權用户看
參數解釋
include: health,info,metrics:只開放3個安全端點:health(服務健康狀態)、info(項目基本信息)、metrics(服務指標,如CPU使用率);show-details: when-authorized:健康檢查的詳細信息(比如數據庫是否連接成功),只給授權用户看,避免陌生人獲取。
七、文件上傳大小限制:突破“1MB瓶頸”
Spring Boot默認的文件上傳限制極嚴格:單個文件只能傳1MB,整個請求最大10MB——傳張高清圖片、一個壓縮包都會失敗,就像“水管太細,大水流不過來”。我們需要擴大限制。
配置方案
spring:
servlet:
multipart:
max-file-size: 100MB # 單個文件最大大小
max-request-size: 100MB # 整個請求最大大小
file-size-threshold: 2KB # 超過2KB的文件先存硬盤(不佔內存)
location: /tmp # 臨時文件存儲路徑
resolve-lazily: false # 不延遲解析請求(默認false)
參數解釋
max-file-size:單個文件最大100MB,滿足大部分場景(如傳高清圖、Excel表格);max-request-size:整個請求(比如一次傳多個文件)最大100MB,避免請求過大;file-size-threshold:小於2KB的文件存在內存(快),大於的存硬盤(省內存)。
八、異步線程池配置:避免“線程氾濫”
用@Async註解實現異步任務時,Spring Boot默認用SimpleAsyncTaskExecutor——這個執行器“每次都新創建線程”,高併發時會生成大量線程,導致“系統資源耗盡”,就像“每次辦事都找新臨時工,人太多管理不過來”。我們需要配置線程池,實現“線程複用”。
配置方案
spring:
task:
execution:
pool:
core-size: 8 # 核心線程數(常駐線程)
max-size: 16 # 最大線程數
queue-capacity: 100 # 任務隊列容量
keep-alive: 60s # 空閒線程存活時間
thread-name-prefix: async-task- # 線程名前綴(方便排查問題)
scheduling:
pool:
size: 4 # 定時任務線程池大小
thread-name-prefix: scheduling- # 定時任務線程名前綴
參數解釋
core-size:線程池裏“常駐的工作人員”,即使沒任務也不銷燬,保證快速響應;max-size:線程池裏“最多能有多少工作人員”,任務太多時臨時加人,任務少了再減到核心數;queue-capacity:任務太多時,先放進“等待隊列”,避免直接創建新線程;thread-name-prefix:給線程起個統一前綴(如async-task-1),排查日誌時能快速識別異步線程。
九、靜態資源緩存策略:讓頁面加載“飛起來”
Spring Boot默認不給靜態資源(CSS、JS、圖片)設置HTTP緩存頭——瀏覽器每次訪問都要重新下載這些文件,頁面加載慢,就像“每次看同一本書都要重新買一本”。我們需要配置緩存,讓瀏覽器“重複利用已下載的資源”。
配置方案
spring:
web:
resources:
cache:
cachecontrol:
max-age: 365d # 靜態資源緩存365天
cache-public: true # 允許公共緩存(如CDN)
chain:
strategy:
content:
enabled: true # 開啓內容版本化
paths: /** # 所有靜態資源都生效
cache: true # 開啓資源鏈緩存
static-locations: classpath:/static/ # 靜態資源存放路徑
參數解釋
max-age: 365d:瀏覽器下載靜態資源後,365天內不用重新請求,直接用本地緩存;content: enabled: true:開啓“內容版本化”——Spring Boot會根據文件內容生成MD5哈希值(如style-abc123.css),文件變了哈希值也變,瀏覽器會自動下載新文件;文件沒變則用緩存,兼顧“快”和“新”。
十、數據庫事務超時配置:避免“長事務鎖表”
用@Transactional註解時,Spring Boot默認不設置事務超時時間——如果事務裏處理大量數據(比如批量導入10萬條數據),會“長時間持有數據庫鎖”,導致其他操作卡住,就像“佔着廁所不出來,別人沒法用”。我們需要給事務設超時,並分批處理數據。
配置方案
@Transactional(timeout = 30, rollbackFor = Exception.class)
public void batchProcess(List<Data> dataList) {
// 分批處理,避免長事務
int batchSize = 100;
for (int i = 0; i < dataList.size(); i += batchSize) {
List<Data> batch = dataList.subList(i,
Math.min(i + batchSize, dataList.size()));
processBatch(batch);
}
}
參數通俗解釋
timeout = 30:事務超時時間設為30秒,若30秒內沒完成,自動回滾,釋放數據庫鎖;rollbackFor = Exception.class:遇到任何異常都回滾事務,避免數據不一致;- 分批處理:把10萬條數據分成每100條一批,每批處理完就提交事務,縮短單次事務時長,減少鎖表時間。
總結:配置的核心是“適配需求”
Spring Boot的配置沒有“萬能模板”,本文的參數是基於常見場景的優化建議——實際項目中,你需要結合自己的Spring Boot版本、服務器性能、業務併發量進行調整(比如小項目不用把Tomcat最大連接數設到10000)。