섹션 10. CAS - 동기화와 원자적 연산 (3)

[ljh468]

1. CAS 락 구현 1 - 문제점 확인

CAS 연산을 사용하지 않고 일반적인 volatile 변수만으로 락을 구현했을 때 발생하는 동시성 문제를 확인

SpinLockBad 클래스 (원자적이지 않은 구현)

public class SpinLockBad {
    private volatile boolean lock = false;

    public void lock() {
        log("락 획득 시도");
        while(true) {
            if (!lock) { // 1. 락 사용 여부 확인
                sleep(100); // 문제 상황 재연을 위한 대기
                lock = true; // 2. 락의 값 변경
                break;
            } else {
                log("락 획득 실패 - 스핀 대기");
            }
        }
    }

    public void unlock() {
        lock = false;
        log("락 반납 완료");
    }
}

• 발생하는 문제
  • 두 스레드가 동시에 lock()을 호출하면, 둘 다 if(!lock) 조건을 통과한 후 각각 lock = true를 수행하게 됨
• 원인
  • 1) 락 사용 여부 확인과 2) 락의 값 변경이라는 두 연산이 하나의 원자적인 단위로 묶여 있지 않기 때문임
• 결과
  • 결국 여러 스레드가 동시에 임계 영역에 진입하는 동시성 문제가 발생함

---

2. CAS 락 구현 2 - 원자적 락 구현 (Spin Lock)

CAS 연산을 지원하는 AtomicBoolean을 사용하여 안전하고 가벼운 락을 구현할 수 있음

SpinLock 클래스 (CAS 활용)

import java.util.concurrent.atomic.AtomicBoolean;

public class SpinLock {
    private final AtomicBoolean lock = new AtomicBoolean(false);

    public void lock() {
        log("락 획득 시도");
        // 락 사용 여부 확인 + 값 변경을 하나의 원자적 연산으로 처리
        while (!lock.compareAndSet(false, true)) {
            // 락을 획득할 때까지 RUNNABLE 상태로 무한 루프 (바쁜 대기)
            log("락 획득 실패 - 스핀 대기");
        }
        log("락 획득 완료");
    }

    public void unlock() {
        lock.set(false); // 원자적 연산으로 락 해제
        log("락 반납 완료");
    }
}

• 구현 원리
  • compareAndSet(false, true)를 사용하여 "락이 false인 경우에만 true로 바꿔라"라는 명령을 CPU 차원에서 원자적으로 수행하게 함
• 스핀 락(Spin Lock)
  • 스레드가 락을 획득하지 못했을 때 대기(BLOCKED) 상태로 가지 않고, 루프를 돌며 계속 획득을 시도하는 방식
• 장점
  • 스레드 상태 변경(컨텍스트 스위칭) 오버헤드가 없으므로, 아주 짧은 연산에서 매우 효율적임
• 단점
  • 락을 기다리는 동안 CPU 자원을 계속 소모하는 바쁜 대기(Busy-wait) 현상이 발생할 수 있음

---

3. 정리: 동기화 락(Lock) vs CAS

• 상황에 따라 적절한 동기화 전략을 선택하는 것이 중요

비교 요약 표

구분	동기화 락 (synchronized, Lock)	CAS (AtomicXxx, Spin Lock)
접근 방식	비관적 동기화: 일단 락부터 건다.	낙관적 동기화: 충돌이 없을 것이라 가정한다.
스레드 상태	획득 실패 시 BLOCKED/WAITING 전환	획득 실패 시 RUNNABLE 유지하며 재시도
CPU 자원	대기 중에는 CPU를 거의 사용 안 함	대기 중에도 루프를 돌며 CPU 계속 사용
오버헤드	컨텍스트 스위칭 비용 발생 18181818	충돌 시 반복 재시도 오버헤드 발생

실무에서 사용할때

• CAS가 유리한 경우

  • 숫자 값 증가, 자료 구조의 데이터 추가/삭제 등 연산이 매우 짧게(나노 초 단위) 끝날 때.
  • 실무의 주문 수 카운트처럼 실제 충돌 가능성이 낮은 대부분의 경우.

• 동기화 락이 유리한 경우

  • 데이터베이스 결과 대기, 외부 서버 요청 등 작업 시간이 긴 경우.
  • 충돌이 빈번하게 발생하여 CAS 재시도 비용이 컨텍스트 스위칭 비용보다 커질 때.

참고: 실무에서는 직접 CAS를 구현하기보다, 이미 CAS로 최적화된 AtomicInteger 등 자바 표준 라이브러리를 잘 활용하는 것이 중요