Spring Singleton 陷阱：基類注入用戶上下文導致多用戶數據錯亂

問題場景重現

項目使用 Spring + Acegi Security。為便捷獲取當前登錄用戶，在 BaseService/BaseDao 提供：

protected UserContext getUserContext() {
    Authentication auth = SecurityContextHolder.getContext().getAuthentication();
    return (UserContext) auth.getPrincipal();
}
protected UserInfo getUserInfo() { return getUserContext().getUserInfo(); }

子類 SomeService 為「優化」在字段緩存用戶信息：

public class SomeService extends BaseService {
    private UserInfo user = super.getUserInfo(); // 陷阱在此！
    
    public void someMethod() {
        int uid = this.user.getUserId(); // 永遠是第一個登錄用戶
        ...
    }
}

根因分析

• Spring Bean 默認 singleton 作用域，容器僅創建一個 SomeService 實例
• 字段 user 在 Bean 初始化/依賴注入階段賦值（第一次調用 getUserInfo()）
• 後續所有請求復用同一實例，字段不再更新，導致所有用戶看到第一個用戶的數據
• 單元測試通常單線程單用戶，無法暴露此問題

正確姿勢：方法級獲取，拒絕字段緩存

public class SomeService extends BaseService {
    public void someMethod() {
        // 每次調用實時從 ThreadLocal (SecurityContextHolder) 獲取
        int uid = super.getUserInfo().getUserId();
        String name = super.getUserInfo().getUserName();
        ...
    }
}

SecurityContextHolder 內部使用 ThreadLocal 隔離線程上下文，每次調用獲取的是當前請求線程綁定的用戶，天然線程安全。

擴展：Spring Bean 作用域與狀態管理原則

最佳實踐清單

1. Service/DAO 必須無狀態：不聲明非 final 實例字段保存業務數據
2. 請求上下文數據（用戶、權限、參數）通過方法參數或 ThreadLocal 獲取，不緩存到實例字段
3. 若確需有狀態組件，聲明 @Scope("prototype") 或 request/session，並配合 @Lookup 或 ObjectFactory 注入
4. 代碼審查重點檢查：Base 類便利方法是否被子類誤用為字段初始化
5. 壓力測試/多用戶並發測試驗證無數據串聯

總結

Spring Singleton 是性能優化選擇，而非架構免死金牌。無狀態設計是分佈式、高併發系統的基石。將「便利」的基類方法誤用為字段初始化，本質是將請求級數據錯誤提升為實例級狀態。牢記：super.getXxx() 必須寫在方法體內，而非字段聲明處。

1. 上一篇文章： Struts Logic 標簽庫完全指南：條件判斷、迭代與消息控制
2. 下一篇文章： Java 設計模式學習筆記：工廠方法與抽象工廠的演進之路

Java 程式設計入門

Java 驗證碼生成與驗證完整實現：Servlet、Spring MVC、前端交互一體化方案

前言：驗證碼在 Web 安全中的定位 驗證碼是防禦暴力破解、

MIDP 聯網應用程式開發教學：HTTP 通訊完整指南

引言 上一講介紹了如何利用 Record Store 在終端

Java 系統托盤開發完整指南：從核心 API 到生產級實戰

前言 系統托盤功能讓 Java 桌面應用能常駐後台、最小化不

Java 入門筆記（一）：JDK 下載、安裝與環境配置圖文教程

學習目標 掌握 JDK 官方下載流程 完成 JDK 安裝與