@Transactional과 synchronized를 같이 사용하면 왜 안 될까?

1. 개요

프로젝트에서 다음과 같은 로직이 있다. 모집 공고에 모집 인원을 초과하지 않는다면 모집된 인원을 증가시켜 주고 있다.  

public synchronized void plusRegisteredNum(Integer updateCount) {
    if (this.registeredNum + updateCount > this.recruitNum) {
        throw new CustomException(ErrorCode.APPLY_OVER_RECRUIT_NUM);
    }
    this.registeredNum += updateCount;
}

 

 

동시성 이슈를 방지하기 위해 synchronized 키워드를 넣어주었는데 테스트 코드를 작성해봤을 때 동시성 문제가 발생하고 있었다. 

 

원인을 찾아봤더니 @Transactional과 함께 사용할 시 동시성 문제를 해결할 수 없다고 한다.

 

왜 그런지 자세하게 알아보자. 

 

 

 

 

 

 

2. 문제 상황

@Test
public void 동시성_테스트() throws InterruptedException {
    int threadCount = 100;
    ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
    CountDownLatch latch = new CountDownLatch(threadCount);

    for (int i = 0; i < threadCount; i++) {
        executorService.submit(() -> {
            try {
                workDateTestService.plusRegisteredNum(1L);
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                latch.countDown();
            }
        });
    }

    latch.await();
    executorService.shutdown();

    WorkDate updatedWorkDate = workDateRepository.findById(1L).get();
    assertThat(updatedWorkDate.getRegisteredNum()).isEqualTo(threadCount);
}

 

 

모집 인원을 증가시키는 api의 로직은 많이 복잡해 해당 기능만 테스트 하기 위해 TestService를 만들어주었다. 

@Service
@RequiredArgsConstructor
@Transactional
public class WorkDateTestService {
    private final WorkDateRepository workDateRepository;

    public void plusRegisteredNum(Long workDateId) {
        WorkDate workDate = workDateRepository.findById(workDateId)
                .orElseThrow(() -> new CustomException(ErrorCode.WORK_DATE_NOT_FOUND));

        workDate.plusRegisteredNum(1);
    }
}

 

위 테스트 결과는 아래와 같다.

 

 

 

 

 

 

 

3. 문제 원인

synchronized를 사용했음에도 동시성 문제를 해결하지 못한 이유는 트랜잭션의 동작원리 때문이다.

 

사진과 함께 자세하게 살펴보자. 

 

 

@Transaction이 적용된 클래스는 CGLIB에 의해서 런타임에 해당 클래스 기반 프록시가 생성된다.

그리고 @Transactional 로직으로 진입하기 전/후에서 Transaction Begin & Commit/Rollback이 진행되는 것이다

 

이렇게 @Transactional이 걸려있는 비즈니스 로직에 synchronized 키워드를 붙이게 된다면 다음과 같이 동작한다

 

 

해당 비즈니스 로직에 synchronized가 걸려있으니 해당 로직으로 진입할때 Monitor Lock을 가지고 진입하게 되는것이다

 

 

 

그러면 Thread1을 제외한 나머지 쓰레드들은 비즈니스 로직에 접근하지 못하고 Lock을 얻기 위해서 대기한다 여기서 Thread1이 비즈니스 로직을 끝내고 커밋/롤백 시점으로 돌입한다고 가정하자

 

 

 

 

이 시점에 Thread2가 진입하게 되면 아직 Thread1의 로직이 commit되기 전이므로 DB에 존재하는 Ticket의 stock은 여전히 100이다.

그에 따라서 Thread2는 Ticket의 stock을 100으로 받게 되고 그에 따른 로직이 진행된다.

 

즉 트랜잭션이 시작 & 커밋,롤백 되는 시점엔 Lock이 걸리지 않게 되고 여기서 동시성 문제가 발생하게 되는 것이다. 

 

 

 

 

 

 

 

4. 결론

synchronized 키워드는 Java에서 스레드 동기화를 제공하는 강력한 도구이지만, 한계가 명확한 것 같다.

 

첫 번째로 트랜잭션과 함께 사용할 수 없는 것이다. 함께 사용하려면 컴포넌트를 분리하고..~~ 해서 사용할 수 있지만 코드 가독성도 떨어질 뿐더러 효율적이지 못하다는 생각이 들었다.

 

두번째로 모든 스레드 동작에 대해 락을 걸어버려 오버헤드가 발생할 수 있다.

 

세번째로 하나의 프로세스에서만 격리성을 보장하기 때문에 두 개 이상의 서버에서는 동시성 문제를 해결할 수 없다.