題目詳細答案
Spring事務失效的場景主要有以下幾種。
非public方法使用@Transactional
場景描述：Spring事務管理是基于AOP實現的，而AOP對于JDK動態代理或CGLib動態代理只會代理public方法。如果事務方法的訪問修飾符為非public，SpringAOP無法正確地代理該方法，從而導致事務失效。
示例代碼：事務方法的訪問修飾符被設置為private、default或protected。
解決方案：將需要事務管理的方法設置為public。
在同類中的非事務方法調用事務方法
場景描述：Spring的事務管理是通過動態代理實現的，只有通過代理對象調用的方法才能享受到Spring的事務管理。如果在同一個類中，一個沒有標記為@Transactional的方法內部調用了一個標記為@Transactional的方法，那么事務是不會起作用的。
解決方案：盡量將事務方法放在不同的類中，或者使用Spring的AopContext.currentProxy()來獲取當前類的代理對象，然后通過代理對象調用事務方法。
事務傳播級別屬性設置不當
場景描述：在Spring的事務管理中，如果在一個支持當前事務的方法（比如，已經被標記為@Transactional的方法）中調用了一個需要新事務的方法，如果后者方法拋出了異常，但異常并未被Spring識別為需要回滾事務的異常，那么后者的事務將不會回滾。
異常類型不匹配
場景描述：默認情況下，Spring只有在方法拋出運行時異常或者錯誤時才會回滾事務。對于檢查性異常，即使你在方法中拋出了，Spring也不會回滾事務，除非你在@Transactional注解中顯式地指定需要回滾哪些檢查性異常。
解決方案：了解Spring事務管理對異常的處理，必要時在@Transactional注解中指定需要回滾的異常類型。
事務攔截器配置錯誤
場景描述：如果沒有正確地配置事務攔截器，例如沒有指定切入點或指定了錯誤的切入點，就會導致Spring事務失效。
@EnableTransactionManagement
@Configuration
public class TxConfig {@Beanpublic Advisor transactionAdvisor() {AspectJExpressionPointcut pointcut = new AspectJExpressionPointcut();pointcut.setExpression("execution(* com..service.*.*(..))"); // 包路徑錯誤return new DefaultPointcutAdvisor(pointcut, transactionInterceptor());}
}事務超時配置錯誤
場景描述：如果事務超時時間設置得太短，就有可能在事務執行過程中出現超時，從而導致Spring事務失效。
Spring事務超時是通過JDBC的java.sql.Connection#setNetworkTimeout()實現的，底層流程：
if (System.currentTimeMillis() - startTime > timeoutMillis) {throw new TransactionTimedOutException("Transaction timed out");
}Spring事務失效場景深度解析
一、非public方法失效的本質原因
底層機制：
- 代理生成限制：
// Spring源碼中的判斷邏輯
if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {return null; // 直接返回不創建事務屬性
}- JDK動態代理只能代理接口中的public方法
- CGLIB雖然能代理類方法，但Spring主動限制了非public方法的事務支持
- 設計考量：
- 非public方法通常被視為內部實現細節
- 保持事務邊界清晰（public方法才是服務契約）
典型錯誤示例：
@Service
public class PaymentService {@Transactionalprotected void processPayment() { // protected方法// 事務不會生效！}
}二、同類調用失效的代理機制
核心問題圖解：
[客戶端] --> [Spring代理對象] --> [真實對象]調用createOrder() this.validate()繞過代理字節碼層面分析：
- 代理對象生成后，方法調用流程：
- 外部調用：
proxy.createOrder() - 內部調用：
realObject.validate()（直接調用，不走代理）
- 外部調用：
解決方案對比：
方案 | 優點 | 缺點 |
拆分類 | 符合單一職責原則 | 增加類數量 |
自注入 | 改動最小 | 存在循環依賴風險 |
AopContext.currentProxy() | 靈活 | 需配置exposeProxy=true |
三、傳播行為配置陷阱
REQUIRES_NEW的隔離性：
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void auditLog() {// 即使外層事務回滾，此操作仍會提交// 但會創建新連接，可能耗盡連接池
}NESTED的數據庫支持：
- 支持：MySQL、PostgreSQL
- 部分支持：Oracle（行為差異）
- 不支持：MyISAM引擎
四、異常處理不當的判定邏輯
Spring回滾決策樹：
- 檢查
rollbackFor/noRollbackFor明確指定的異常 - 默認規則：
- RuntimeException及其子類 → 回滾
- Error及其子類 → 回滾
- 檢查型異常（Exception） → 提交
易錯場景示例：
@Transactional
public void importData() throws IOException {try {parseFile(); // 可能拋出IOException} catch (IOException e) {throw new BusinessException(e); // 必須轉換為RuntimeException}
}五、數據庫引擎關鍵影響
事務支持矩陣：
引擎特性 | InnoDB | MyISAM | Memory |
事務支持 | ?? | ?? | ?? |
行級鎖 | ?? | ?? | ?? |
外鍵支持 | ?? | ?? | ?? |
檢查方法：
SHOW TABLE STATUS WHERE Name='table_name';六、靜態/最終方法限制
JVM方法調用機制：
- final方法：靜態綁定，編譯期確定調用目標
- static方法：類級別調用，與對象實例無關
- 二者都無法被動態代理攔截
事務調試四步法
- 檢查代理類型：
System.out.println(service.getClass().getName());
// 應輸出包含$$EnhancerBySpringCGLIB$$或$Proxy的類名- 驗證事務狀態：
TransactionSynchronizationManager.isActualTransactionActive();
TransactionSynchronizationManager.getCurrentTransactionName();- 開啟事務日志：
logging.level.org.springframework.transaction.interceptor=TRACE
logging.level.org.springframework.jdbc=DEBUG- 數據庫監控：
SHOW ENGINE INNODB STATUS; -- MySQL
SELECT * FROM V$TRANSACTION; -- Oracle最佳實踐清單
- 編碼規范：
- 所有事務方法必須為public
- 避免在事務方法中捕獲所有異常
- 顯式指定
rollbackFor
- 配置檢查：
@EnableTransactionManagement(proxyTargetClass = true)
@Configuration
public class TxConfig {@Beanpublic PlatformTransactionManager transactionManager() {return new DataSourceTransactionManager(dataSource());}
}- 測試驗證：
@Test
@Transactional
public void testWithRollback() {// 測試后自動回滾assertThrows(Exception.class, () -> service.method());
}理解這些原理后，可以系統性地避免事務失效問題，而不僅是記住表面現象。實際開發中建議結合日志監控和單元測試，確保事務行為符合預期。
)