事務(wù)管理在系統(tǒng)開發(fā)中舉足輕重，Spring提供了精妙細(xì)膩的事務(wù)管理機制，主要分為編程式事務(wù)和聲明式事務(wù)兩大架構(gòu)。

關(guān)于事務(wù)的根本概念，包括事務(wù)的本質(zhì)、數(shù)據(jù)庫中的事務(wù)特性以及Spring事務(wù)的ACID屬性、隔離級別、傳播規(guī)則和行為方式等，本文將不做深入探討。我也相信讀者對此有一定的了解。

筆者將以簡潔方式闡述聲明式事務(wù)和編程式事務(wù)的概念，隨后探討筆者不推崇使用聲明式事務(wù)的理由。

編程式事務(wù)

借助底層API，如PlatformTransactionManager、TransactionDefinition和TransactionTemplate等核心接口，開發(fā)者能夠以編程的方式精準(zhǔn)地進行事務(wù)管理。

在編程式事務(wù)模式中，開發(fā)者需在代碼中手動管理事務(wù)的啟動、提交和回滾等操作。

偽代碼：

public void test() {
    TransactionDefinition definition = new DefaultTransactionDefinition();
    TransactionStatus status = transactionManager.getTransaction(definition);

    try {
        // 執(zhí)行事務(wù)操作
        // 提交事務(wù)
        transactionManager.commit(status);
    } catch (DataAccessException e) {
        // 回滾事務(wù)
        transactionManager.rollback(status);
        throw e;
    }
}

如以上代碼，開發(fā)者可以通過API自己控制事務(wù)。

聲明式事務(wù)

聲明式事務(wù)管理方式允許開發(fā)者在配置的指引下進行事務(wù)管理，無需直接操作底層API進行硬編碼。開發(fā)者可以通過注解或基于配置的XML來便捷地管理事務(wù)。

@Transactional
public void test() {
    // 執(zhí)行事務(wù)操作  
}

如上使用@Transactional注解即可為test方法添加事務(wù)控制。

當(dāng)然，以上代碼只是簡化的版本，實際使用事務(wù)還需要進行一些配置。這里不展開詳細(xì)說明。

這兩種事務(wù)管理方式各有優(yōu)缺點，所適用的場景也各有不同。為什么有人會拒絕使用聲明式事務(wù)呢？

聲明式事務(wù)的優(yōu)點

通過上面的例子，我們很容易看出聲明式事務(wù)的優(yōu)點：它幫助我們節(jié)省大量代碼，自動處理事務(wù)啟動、提交和回滾等操作，使開發(fā)人員擺脫繁瑣的事務(wù)管理工作。

聲明式事務(wù)管理是通過AOP實現(xiàn)的，其本質(zhì)是在目標(biāo)方法執(zhí)行前后進行攔截。在執(zhí)行方法之前創(chuàng)建或加入一個事務(wù)，在方法執(zhí)行結(jié)束后根據(jù)情況選擇提交或回滾事務(wù)。

這種方式不會對代碼造成侵入性，方法內(nèi)只需編寫業(yè)務(wù)邏輯即可。

然而，是否聲明式事務(wù)就一定完美無缺呢？未必如此。

聲明式事務(wù)的粒度問題

首先，聲明式事務(wù)存在一個限制，即其最小作用粒度應(yīng)為方法級別。

換言之，若想向某段代碼塊添加事務(wù)，就需要將該代碼塊獨立出來作為一個獨立方法。

然而，正是由于這個粒度問題，我個人并不贊成過度使用聲明式事務(wù)。注意是不建議過度使用，是過度使用

首先，由于聲明式事務(wù)通常是通過注解或配置實現(xiàn)的，這可能導(dǎo)致一個問題，即開發(fā)者有可能忽略了該事務(wù)。

事務(wù)被忽略會帶來什么問題呢？

首先，如果開發(fā)者未注意到某個方法被包裹在事務(wù)中，就可能在方法內(nèi)執(zhí)行諸如RPC遠程調(diào)用、消息發(fā)送、緩存更新、文件寫入等操作。

我們知道，這些操作本身無法回滾，這會導(dǎo)致數(shù)據(jù)不一致。

• 例如，RPC調(diào)用成功但本地事務(wù)回滾，此時RPC調(diào)用無法回滾。
• 其次，在事務(wù)中存在遠程調(diào)用將延長整個事務(wù)周期。若這種操作過于頻繁，可能導(dǎo)致數(shù)據(jù)庫連接池耗盡。
• 有時，即使沒有遠程操作，某些人可能會不經(jīng)意地進行一些內(nèi)存操作或運算。或者在分庫分表情況下，可能會意外執(zhí)行跨庫操作。

相比之下，如果使用編程式事務(wù)，業(yè)務(wù)代碼將清晰表示何處啟動、提交和回滾事務(wù)。這樣，修改代碼時，開發(fā)人員將被迫考慮所添加代碼是否應(yīng)該處于事務(wù)內(nèi)。

有人或許會認(rèn)為已經(jīng)存在聲明式事務(wù)，但是開發(fā)人員未留意，這該責(zé)怪誰。

盡管如此說，我們?nèi)韵Ｍㄟ^一些機制或規(guī)范，減少此類問題發(fā)生的可能性。

例如，建議大家使用編程式事務(wù)而非聲明式事務(wù)。我在多年的工作中多次遇到開發(fā)者未留意聲明式事務(wù)而導(dǎo)致故障。

因為有時，聲明式事務(wù)確實不夠顯著。

聲明式事務(wù)若用錯易失效

除了事務(wù)粒度問題外，聲明式事務(wù)還存在另一主要問題，即使看似簡化了大量代碼，一旦使用不當(dāng)，便很容易導(dǎo)致事務(wù)失效。

以下幾種情景可能導(dǎo)致聲明式事務(wù)失效：

1. 將 @Transactional 應(yīng)用于非公有（non-public）方法
2. @Transactional 注解中的 propagation 屬性設(shè)置錯誤
3. @Transactional 注解中的 rollbackFor 屬性設(shè)置錯誤
4. 同一類中的方法調(diào)用會使 @Transactional 失效
5. 異常被捕獲導(dǎo)致 @Transactional 失效
6. 數(shù)據(jù)庫引擎不支持事務(wù)

經(jīng)歷過聲明式事務(wù)失效問題

我們團隊不止一次遭遇聲明式事務(wù)失效的情況。或許您也曾有此經(jīng)歷，我是深受其害的一位。

由于Spring事務(wù)基于AOP實現(xiàn)，在編碼中，我們可能涉及多個切面，這些切面各自處理不同事務(wù)，相互影響。

在之前的一個項目中，我曾發(fā)現(xiàn)我們的Service層事務(wù)全部失效，一旦SQL操作失敗未能回滾。我們追查后才發(fā)現(xiàn)，是因為一位同事添加了一個切面，其中實施了異常統(tǒng)一捕獲，導(dǎo)致事務(wù)切面無法捕獲異常，從而無法回滾事務(wù)。

此類問題不僅一次發(fā)生，而且難以察覺。

許多人可能會辯解，畢竟問題源于自身能力不足，對事務(wù)理解還不夠透徹，因此出現(xiàn)誤用。

然而，我依舊堅持認(rèn)為，我們確實無法期望每個人都具備高超技能，也不可能要求所有開發(fā)者都能百分之百避免錯誤。我們能做的，是盡力通過機制或規(guī)范，減少或降低此類問題的發(fā)生幾率。

實際上，若對阿里巴巴發(fā)布的Java開發(fā)手冊有過深入研讀，便會發(fā)現(xiàn)其中很多規(guī)約非常珍貴，有些內(nèi)容可能不易理解，甚至顯得有些生硬。然而，這些規(guī)范實則由無數(shù)開發(fā)者在實戰(zhàn)中摸爬滾打后總結(jié)而來。其實有些東西都是實踐出真知。

關(guān)于@Transactional的用法，規(guī)約中也有提到過，只不過規(guī)約中的觀點沒有我這么鮮明。

文章最后

最后，本文觀點或許不會得到所有人的認(rèn)同，很多人可能會稱：Spring官方推崇無侵入的聲明式事務(wù)，你又有何資格質(zhì)疑。

老實說，初入職場的那幾年，我也鐘情于聲明式事務(wù)，認(rèn)為其簡潔、"優(yōu)雅"。覺得那些熱衷于編程式事務(wù)的前輩多此一舉，缺乏工匠精神。

然而，隨著線上遇到幾次問題后的反思，我們發(fā)現(xiàn)，有時候你的代碼確實優(yōu)雅無瑕。

然而，這種優(yōu)雅也常伴隨一些副作用，并且前輩們也無法指責(zé)我，因為我的做法確實無可指摘...

因此，有些事情，只能在切身體會后才能領(lǐng)悟。

當(dāng)然，本文并非要求每個人完全放棄聲明式事務(wù)，只是提議在未來使用事務(wù)時，考慮本文所提觀點，然后自行做出選擇。