數(shù)據(jù)庫連接池就像演唱會檢票口。人不多時一切順暢，但當(dāng)300人同時涌來，系統(tǒng)就會崩潰——不是壞了，而是從沒為峰值設(shè)計過。Spring Boot官方文檔只給你看空無一人的檢票口，從不展示演唱會現(xiàn)場的混亂。

這是我在Lakaut Hub的真實經(jīng)歷。作為Lakaut AC數(shù)字認(rèn)證機(jī)構(gòu)的核心系統(tǒng)架構(gòu)師，我面對的是真實生產(chǎn)環(huán)境、真實負(fù)載、以及不會說謊的日志。

我的結(jié)論可能讓人不舒服：Spring Boot的文檔是為理想化環(huán)境寫的，那種環(huán)境在Railway這類PaaS平臺上根本不存在。默認(rèn)配置基于本地開發(fā)的無限資源假設(shè)，到了需要JVM調(diào)優(yōu)和PostgreSQL高負(fù)載的生產(chǎn)環(huán)境，這些默認(rèn)值會燒穿你的系統(tǒng)。我有日志為證。

spring.jpa.open-in-view：沒人認(rèn)真解釋的問題

剛接手Lakaut Hub時，應(yīng)用能啟動、能運(yùn)行，日志里有個警告被我忽略了幾周：

WARN o.s.b.autoconfigure.orm.jpa.JpaBaseConfiguration$JpaWebConfiguration - spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering.

open-in-view=true是默認(rèn)設(shè)置。實際含義是：Hibernate會話在整個HTTP請求生命周期內(nèi)保持打開，從請求進(jìn)入直到響應(yīng)渲染完成。文檔提到了它，卻沒告訴你高負(fù)載下它會如何吞噬數(shù)據(jù)源池連接。

我在Lakaut Hub用Actuator直接測量了這個問題。一個執(zhí)行多次JPA查詢的端點，每個請求從進(jìn)入直到JSON響應(yīng)輸出都占用著連接池中的連接——包括那些根本不需要數(shù)據(jù)庫的業(yè)務(wù)邏輯、驗證和序列化操作。Lakaut Hub峰值時段50個并發(fā)請求時，我們開始看到連接池獲取超時。這不是應(yīng)用bug，是默認(rèn)配置的問題。

修復(fù)只需一行，但理解才是關(guān)鍵：

spring.jpa.open-in-view: false # 用完數(shù)據(jù)庫立即歸還連接

同時調(diào)整Hikari連接池參數(shù)：maximum-pool-size設(shè)為10（不超過Railway套餐限制），minimum-idle設(shè)為5（避免每次峰值從零啟動），connection-timeout設(shè)為20000毫秒，idle-timeout設(shè)為300000毫秒。這些數(shù)字來自真實環(huán)境的反復(fù)調(diào)試，而非文檔推薦值。