비관적 락에대해서

[YuDeokRin]

동시성 문제 상황

쿠폰 재고: 100개
동시에 1000명이 다운로드 요청

Thread A: 재고 조회 (100개) → 재고 감소 (99개)
Thread B: 재고 조회 (100개) → 재고 감소 (99개) // 문제!
Thread C: 재고 조회 (100개) → 재고 감소 (99개) // 문제!

• 결과: 3명이 다운로드했는데 재고는 99개?
• 실제로는 97개여야 함!

해결 방법

동시성 문제를 해결하는 대표적인 두 가지 방법:

• 비관적 락 (Pessimistic Lock)
• 낙관적 락 (Optimistic Lock)

핵심 개념

"충돌이 발생할 거야! 미리 막자!"

데이터를 읽는 순간 락(lock)을 걸어서 다른 트랜잭션의 접근을 차단합니다.

동작 원리

[사용자 A]

1. SELECT ... FOR UPDATE ← 락 획득
2. 재고 확인 및 감소
3. UPDATE
4. COMMIT ← 락 해제

[사용자 B]

1. SELECT ... FOR UPDATE ← 대기...
2. (사용자 A가 끝날 때까지 대기)
3. 락 획득 후 진행

-- 트랜잭션 시작
START TRANSACTION;

-- 데이터 조회와 동시에 락 획득
SELECT * FROM coupon 
WHERE coupon_id = 1 
FOR UPDATE;  -- 이 순간 락!

-- 다른 트랜잭션은 여기서 대기

-- 재고 감소
UPDATE coupon 
SET quantity = quantity - 1 
WHERE coupon_id = 1;

-- 커밋 (락 해제)
COMMIT;

✅ 장점

• 데이터 정합성 보장: 100% 정확한 재고 관리
• 충돌 시 안정적: 대기만 하면 됨
• 구현이 단순: 락만 걸면 끝

✅단점

• 성능 저하: 대기 시간 발생
• 동시성 낮음: 순차적으로 처리
• 데드락 위험: 여러 자원 락 시 주의 필요

[Muawiya-contact]

💡 비관적 락(Pessimistic Lock) 실무 적용 및 보충 설명

작성해주신 동시성 문제와 비관적 락의 개념에 대해 깊이 공감하며, 실제 프로젝트(Spring Data JPA 환경 등)에서 이 기능을 어떻게 제어하고 최적화할 수 있는지 보충 답변을 드립니다.

---

1. JPA에서의 실전 구현

Spring Data JPA를 사용하신다면 @Lock 어노테이션을 사용하여 쿼리 수준에서 비관적 락을 제어할 수 있습니다.

public interface CouponRepository extends JpaRepository<Coupon, Long> {

    // SELECT ... FOR UPDATE 쿼리 생성
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select c from Coupon c where c.id = :id")
    Optional<Coupon> findByIdWithPessimisticLock(Long id);
}