@Transactional遇上@synchronized的生產(chǎn)問題

近日遇到一個(gè)問題，就是一個(gè)訂單被兩個(gè)用戶搶了問題，排查后發(fā)現(xiàn)是由于 @Transactional和@synchronized注解的使用問題

一、問題點(diǎn)：數(shù)據(jù)重復(fù)讀

@Transactional注解用于開啟事務(wù)，當(dāng)在高并發(fā)情況下我們可能為了保證數(shù)據(jù)的安全使用悲觀鎖，可以在方法上使用@synchronized使用悲觀鎖。一個(gè)線程執(zhí)行完方法并釋放鎖后，事務(wù)并未提交，第二個(gè)線程又獲得了該鎖，導(dǎo)致數(shù)據(jù)出問題

@Transactional注解通過AOP實(shí)現(xiàn)事務(wù)管理，當(dāng)標(biāo)注該注解的方法執(zhí)行完成后才提交事務(wù)，而synchronized代碼塊又是在一個(gè)事務(wù)內(nèi)，就會(huì)出現(xiàn)第一個(gè)線程釋放鎖后但是事務(wù)還沒提交，第二個(gè)線程就進(jìn)入同步代碼塊獲取到未提交的數(shù)據(jù)庫數(shù)

@Transactional控制事務(wù)的范圍比sychronized 大，如圖：

思路：既然事務(wù)下不能使用鎖，那我們把鎖和事務(wù)進(jìn)行分開。使得在鎖環(huán)境下包含事務(wù)，最終依然是線程安全的

• 方法一：將鎖替換成數(shù)據(jù)庫的鎖比如select for update或者版本號version
• 方法二：在service下將事務(wù)代碼的抽取單獨(dú)使用，無事務(wù)方法調(diào)用有事務(wù)的方法

既然問題出在事務(wù)未提交，那么只要把對應(yīng)事務(wù)操作的代碼單獨(dú)抽取出來，封裝成一個(gè)單獨(dú)的方法，在synchronized中調(diào)用該方法即可

@Service
public class OrderServiceImpl implements OrderServiceI {
	@Autowired
	private OrderDao orderDao;

	public sychronized Order updateOrder(int id) {  //加鎖
		return updateOrderSafely(id); //調(diào)用數(shù)據(jù)庫
	}

	@Transactional
	public Order updateOrderSafely(int id) {
		return orderDao.updateOrder(id);
	}
}

看起來好像是解決了事務(wù)未提交的問題，但會(huì)存在新的問題，可能會(huì)出現(xiàn)@Transactional事務(wù)不生效的情況

二、問題點(diǎn) >》方法二引申：@Transactional事務(wù)不生效

在同一個(gè)類內(nèi)部調(diào)用@Transactional標(biāo)注的方法事務(wù)也不會(huì)開啟，原因是：

@Transactional事務(wù)管理是基于動(dòng)態(tài)代理對象的代理邏輯實(shí)現(xiàn)的，那么如果在類內(nèi)部調(diào)用類內(nèi)部的事務(wù)方法，這個(gè)調(diào)用事務(wù)方法的過程并不是通過代理對象來調(diào)用的，而是直接通過this對象來調(diào)用方法，繞過的代理對象，肯定就是沒有代理邏輯了

方法：將鎖提取到controller層，不包含任何事務(wù)

• Controller類

 @RestController
 public class TestController {
     @Resource 
     private TestService testService;
     @PostMapping("/test")
     public synchronized void testInterface() {
          testService.functionA(); // 調(diào)用數(shù)據(jù)庫操作方法
     }
 }

• Service類

 @Service("testService")
 public class TestServiceImpl implements TestService {
    @Transactional(rollbackFor = Exception.class, 
                  propagation = Propagation.REQUIRES_NEW)
     public void functionA() {
         //數(shù)據(jù)庫讀寫操作
     }
 }

注意點(diǎn)：

1、調(diào)用本類加@Transactional的方法時(shí)，要使用一個(gè)AOP對象來進(jìn)行代理，獲取到代理對象之后@Trasactional才會(huì)正常生效，否則是不生效的。

2、synchronized要比事務(wù)的粒度要大，否則還是會(huì)出現(xiàn)重復(fù)讀的現(xiàn)象。

3、被調(diào)用的functionA為什么要使用 REQUIRES_NEW的隔離級別呢？ 因?yàn)檫@樣就可以實(shí)現(xiàn)鎖的粒度大于事務(wù)的粒度啦。無論如何，都創(chuàng)建新的事務(wù)，外層事務(wù)不受內(nèi)層事務(wù)影響。但是有個(gè)問題，外層事務(wù)失敗了，內(nèi)層事務(wù)還是把記錄入庫了，有可能產(chǎn)生臟數(shù)據(jù)；

下面這段代碼有什么問題呢？

Lock lock = new ReentrantLock();

@Transactional
public void save(){
    try{
        lock.lock();
        //業(yè)務(wù)代碼……
    }finally{
        lock.unlock();
    }
}

1、顯而易見就可以看出，Spring 會(huì)在方法開始時(shí)開啟一個(gè)事務(wù)，并在方法結(jié)束時(shí)提交或回滾該事務(wù)。如果在方法內(nèi)部手動(dòng)加鎖，可能會(huì)導(dǎo)致鎖的持有時(shí)間超過事務(wù)的生命周期，這樣可能會(huì)引發(fā)死鎖或其他并發(fā)問題。

2、lock.lock()會(huì)阻塞線程，直至獲取到鎖為止，具體來說，如果鎖已經(jīng)被其他線程持有，調(diào)用 lock.lock() 的線程會(huì)被阻塞，直到持有鎖的線程釋放鎖

還有值得注意的一點(diǎn)，很多人看到@Transactional和try……在一起使用，就以為@Transactional會(huì)失效，其實(shí)并不是

①try-catch結(jié)構(gòu):

• 如果在try-catch塊中捕獲異常而不重新拋出，可能導(dǎo)致事務(wù)不按預(yù)期回滾。
• 解決方法：在@Transactional注解中指定rollbackFor屬性，或者在catch塊中重新拋出異常

②try-finally結(jié)構(gòu):

• 使用try-finally結(jié)構(gòu)來確保資源釋放（如鎖的解鎖）不會(huì)影響事務(wù)的正常行為，只要異常最終被拋出。
• 而上述代碼用的是try-finally結(jié)構(gòu)來確保鎖的釋放，這通常不會(huì)影響事務(wù)的正常行為。只要在業(yè)務(wù)代碼中拋出的異常沒有被捕獲，事務(wù)就會(huì)按照預(yù)期回滾

因此應(yīng)該修改成：

private final ReentrantLock lock = new ReentrantLock();

@Transactional(rollbackFor = Exception.class)
public void save() {
     if (!lock.tryLock()) {
          // 如果未能獲取鎖，可以記錄日志或采取其他措施
          System.out.println("Failed to acquire the lock.");
          return; // 或者拋出異常
      }

      try {
        // 業(yè)務(wù)代碼……
      } catch (Exception e) {
        // 處理異常
        throw e;
      } finally {
          lock.unlock();
      }
}
     

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評論