小猿最近很苦惱：明明加了分布式鎖，為什么并發(fā)還是會出問題呢？

故事從接到需求開始說起。

接到需求

小猿前一陣接到一個小任務(wù)，里面有一個功能對應(yīng)的場景如下：

• 封裝一個對賬戶余額進行加減操作的方法；
• 所屬服務(wù)部署了多個實例；
• 這個方法可能會有并發(fā)調(diào)用。

注：實際業(yè)務(wù)場景比較復(fù)雜，已做簡化。

小猿略作思考，就抓住了關(guān)鍵點：余額操作——要注意事務(wù)，多實例——要注意并發(fā)。

小猿的原始代碼如下：

@Override
@Lock(key = "#accountNo")
@Transactional(rollbackFor = Exception.class)
public void updateBalance(String accountNo, AmountOperateParam param) {
    // do something
}

可以看到，這個方法上通過注解方式加了分布式鎖和事務(wù)，鎖的 key 是 accountNo，也就是賬戶業(yè)務(wù)主鍵。

自測和測試也沒發(fā)現(xiàn)啥問題，就高高興興發(fā)完版回家了。

出問題了

第二天一早，就接到少量用戶反饋，說自己的賬戶余額不對了。

小猿的第一反應(yīng)是：我這塊自測和測試都沒問題，其它功能導(dǎo)致的吧？本地又是一通自測，也沒有復(fù)現(xiàn)問題。但謹慎起見，還是往代碼里加了一些日志，來確認是不是自己的方法引發(fā)的。

當(dāng)又有用戶反饋時，小猿根據(jù)日志的情況確認了：還真是自己方法的問題，對同一個賬戶的余額操作，多個并發(fā)請求會同時執(zhí)行到方法體里面。

也就是說……分布式鎖沒鎖住？

冥思苦想了好久，又在本地做了大量的測試，終于讓小猿找到了問題所在：AOP 執(zhí)行順序問題。

小猿設(shè)計的時序：

但實際的時序：

也就是說期望是這樣的執(zhí)行順序：

但實際的執(zhí)行順序：

分布式鎖和事務(wù)，都是通過 AOP 來實現(xiàn)的，而 AOP 的執(zhí)行順序是根據(jù)切面的優(yōu)先級來的，而小猿的分布式鎖切面的優(yōu)先級比事務(wù)切面的優(yōu)先級低，所以就出現(xiàn)了上面的時序問題。

于是通過給分布式鎖的切面指定 Order 的方式，讓它的優(yōu)先級高于事務(wù)切面（注：Order 值越小，執(zhí)行優(yōu)先級越高），驗證完沒問題后，就又高高興興地更新完版本，修復(fù)好歷史問題數(shù)據(jù)后回家了。

還有問題

誰知道第二天一早，還是有極少量的用戶反饋賬戶余額不對的問題。

這次小猿就有點懵了，為什么還會出現(xiàn)這種情況呢？

經(jīng)過一番艱苦卓絕的排查，終于找到了問題所在：事務(wù)嵌套。

從前文中的示例代碼中可以看到，小猿的方法上加了事務(wù)注解 @Transactional(rollbackFor = Exception.class) 里，沒有指定事務(wù)的傳播行為，默認是 Propagation.REQUIRED，也就是說如果當(dāng)前沒有事務(wù)，就新建一個事務(wù)；如果當(dāng)前有事務(wù)，就加入到當(dāng)前事務(wù)中。

小猿自己寫的代碼里沒有在事務(wù)方法里嵌套調(diào)用這個方法的情況，但是同事寫的代碼里有，這樣就會導(dǎo)致前文的時序問題再次發(fā)生。

找到問題就好辦了，小猿將自己的方法上的事務(wù)傳播行為改成了 Propagation.REQUIRES_NEW，也就是說如果當(dāng)前沒有事務(wù)，就新建一個事務(wù)；如果當(dāng)前有事務(wù)，就將當(dāng)前事務(wù)掛起，新建一個事務(wù)。

這次更新完版本后，小猿就再也沒有收到用戶反饋了，終于可以安心回家睡覺了。

小結(jié)

在日常的開發(fā)過程中，如果涉及到并發(fā)和事務(wù)，一定要多留幾個心眼，考慮周全，確認以下要點是否都正確實現(xiàn)：

• 是否做了必要的并發(fā)控制？
• 事務(wù)的傳播行為是否符合預(yù)期？
• AOP 的執(zhí)行順序是否符合預(yù)期？
• 對并發(fā)的場景是否做了充分的測試？
• 對于比較關(guān)鍵的操作，是否打印了必要的日志？