1 問題描述
最近有小夥伴在做商品抽獎活動時,在對獎品庫存進行扣減,有執行緒安全的問題,遂加鎖synchronized進行同步,但發現加鎖後並沒有控制住庫存執行緒安全的問題,導致庫存仍被超發。
先簡單介紹下,各層的技術架構:
中間層框架:Spring 4.1.0
持久層:MyBatis 3.2.6
MVC框架:Spring MVC 4.1.0
存在問題的程式碼:
@Override
public void saveMemberTicket(ApplyTicketReq applyTicketReq) throws ServiceException {
synchronized (this.class) {
// 檢查庫存是否有剩餘
preCheck(applyTicketReq);
// 扣減庫存
modifyTicketAmount(applyTicketReq);
}
}
複製程式碼
庫存扣減超發問題具體描述:
當庫存剩餘為1時,執行緒1拿到鎖進入同步程式碼塊,扣減庫存,執行緒2等待鎖;
當執行緒1執行完同步程式碼塊時,執行緒2拿到鎖,執行同步程式碼塊,檢查到的庫存剩餘仍為1;【此時,庫存應該為0,產生庫存扣減超發問題】
2 排查問題
排查問題開始之前,簡單說下自己排查問題的幾個原則(僅供參考):
問題重現:一定要先重現問題,任何重現不了的問題,都不是問題。同理,任何存在的問題,都必然能再次重現。
由近及遠:先確認自己的程式碼無問題,然後再去確認外部程式碼無問題(如:框架程式碼,第三方程式碼等)。
由外到內:程式就是一個IPO,有輸入Input(如:引數、環境等)也有輸出Out(如:結果、異常等),輸出Out是問題的表象,先確定外部因素Input無問題,再確認程式程式碼邏輯無問題。
由淺入深:其實就是由易到難、自上向下,先從上層應用排查問題,如:上層API、應用層、HTTP傳輸等,然後再確認底層應用排查問題,如:底層API、網路層、系統層、位元組碼、JVM等;
-
確定synchronized關鍵字是否起作用;【建議:儘量慎用synchronized關鍵字,非常影響程式效能】
根據多執行緒併發測試,可以確認多執行緒之間是同步執行synchronized程式碼塊,確認synchronized同步執行沒問題。
-
確定Spring事務是否提交成功;檢視Spring 事務配置:
<!-- Transaction Support --> <tx:advice id="useTxAdvice" transaction-manager="txManager"> <tx:attributes> <tx:method name="*remove*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="*save*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="*modify*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="*update*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="create*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="fill*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="cancel*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="*chang*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="handleLotteryResult" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception" no-rollback-for="com.xxx.exception.ServiceException"/> <tx:method name="find*" propagation="SUPPORTS"/> <tx:method name="get*" propagation="SUPPORTS"/> <tx:method name="query*" propagation="SUPPORTS"/> <tx:method name="page*" propagation="SUPPORTS"/> <tx:method name="count*" propagation="SUPPORTS"/> </tx:attributes> </tx:advice> <!--把事務控制在Service層--> <aop:config> <aop:pointcut id="pc" expression="execution(public * com.xxx..service.*.*(..))" /> <aop:advisor pointcut-ref="pc" advice-ref="useTxAdvice" /> </aop:config> 複製程式碼
由於Spring事務是通過AOP實現的,所以在saveMemberTicket方法執行之前會有開啟事務,之後會有提交事務邏輯。而synchronized程式碼塊執行是在事務之內執行的,可以推斷在synchronized程式碼塊執行完時,事務還未提交,其他執行緒進入synchronized程式碼塊後,讀取的庫存資料不是最新的。
3 解決問題
將synchronized關鍵字加入到Controller層,使synchronized鎖的範圍大於事務控制的範圍。
@RequestMapping(value = "applyTicket")
@ResponseBody
public void applyTicket(@FromJson ApplyTicketReq applyTicketReq) throws Exception {
synchronized (String.valueOf(applyTicketReq.getMemberRoomId()).intern()) {
synchronized (String.valueOf(applyTicketReq.getTicketId()).intern()) {
service.saveMemberTicket(applyTicketReq);
}
}
responseMessage(ModelResult.CODE_200,ModelResult.SUCCESS);
}
複製程式碼
4 總結問題
根據以上的排查過程,已經很清楚的確認了事務與鎖之間存在的問題。由於事務範圍大於鎖程式碼塊範圍,在鎖程式碼塊執行完成後,此時事務還未提交,導致此時進入鎖程式碼塊的其他執行緒,讀到的仍是原有的庫存資料。
關於程式加鎖自己的一點見解:
建議程式中儘量不要加鎖;
儘量在業務和程式碼層,解決執行緒安全的問題,實現無鎖的執行緒安全;
如果以上兩點都做不到,一定要加鎖,儘量使用java.util.concurrent包下的鎖(因為是非阻塞鎖,基於CAS演算法實現,具體可以檢視AQS類的實現);
如果以上三點仍然都做不到,一定要加阻塞鎖:synchronized鎖,兩個原則:(1)儘量減小鎖粒度;(2)儘量減小鎖的程式碼範圍;