Web 應用中 Java 效能迷思深度解析

迷思一：JVM 疊加架構導致效能低落？

常見論點認為：Java 跑在 JVM 上，JVM 再跑在作業系統（如 Windows/Linux）上，這層疊架構註定比原生程式慢。這其實是片面的。現代 JVM（HotSpot）擁有 JIT 即時編譯、逃逸分析、鎖消除等優化，熱點程式碼會被編譯成高效機器碼，效能往往能媲美甚至超越 C++。真正拖慢速度的，通常是宿主機環境「不乾淨」——如伺服器上運行過多無關服務、記憶體不足導致頻繁 Swap、CPU 被其他進程佔用等。

迷思二：架構設計決定成敗

「架構正確的專案 vs. 層疊過度的專案」是效能分水嶺。良好的分層（Controller/Service/DAO）配合快取策略，效能極佳；但若為了「解耦」而盲目疊加層次（如 Service 再包 Service、DTO 轉換層層包裹），會嚴重增加 CPU 與記憶體開銷。驗證技巧：嘗試將一個簡單功能從臃腫專案中剝離成獨立模組，若過程極度痛苦（依賴地獄、循環引用），即為架構腐化的鐵證。

迷思三：Stored Procedure 一定比 JDBC 快？

單看 SQL 執行耗時，Stored Procedure 確實可能較快（預編譯、減少網路往返）。但若納入「總擁有成本」：

• 開發/維護成本：商業邏輯分散在資料庫與 Java 兩端，除錯困難，版本控管弱。
• 移植成本：Oracle PL/SQL 轉 PostgreSQL/T-SQL 需大量改寫。
• 隱性 Bug：資料庫端邏輯常缺乏單元測試，事務邊界模糊。

這反映了「速度（Throughput）」與「速率（Velocity/交付效率）」的差異。

迷思四：不懂容器原理亂調參數

典型案例：WebSphere CPU 飆 100%，開發卻怪 Java 慢。實則多為：

• 執行緒池配置錯誤（過大導致上下文切換頻繁，過小導致請求排隊）。
• 資料庫連線池洩漏，導致新請求長時間等待連線。
• 未啟用動態快取或快取失效策略錯誤，造成大量重複運算。

深入理解 Servlet 容器生命週期、執行緒模型、類別載入機制，才是效能調優的正道。