CAS - 동기화와 원자적 연산, 원자적 연산(소개, 시작, volatile, synchronized, AtomicInteger, 성능 테스트), CAS 연산, CAS 락 구현

출처 : 인프런 - 김영한의 실전 자바 - 고급1편 (유료) / 김영한님  
유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용

---

1. 원자적 연산

1) 소개

(1) 원자적 연산

• 컴퓨터 과학에서 사용하는 원자적 연산(atomic operation)의 의미는 해당 연산이 더 이상 나눌 수 없는 단위로 수행된다는 것을 의미함
• 즉, 원자적 연산은 중단되지 않고 다른 연산과 간섭 없이 완전히 실행되거나 전혀 실행되지 않는 성질을 가지고 있으며 멀티스레드 상황에서 다른 스레드의 간섭 없이 안전하게 처리되는 연산이라는 뜻임

** 참고

• 과거에 원자는 더 이상 나눌 수 없는 가장 작은 단위로 여겨졌으므로 더는 나눌 수 없다는 뜻으로 원자적 연산이라는 단어를 사용함
• 현대 물리학에서는 원자가 더 작은 입자들로 구성되어 있다고 밝혀졌지만 원자적 연산이라는 단어는 그대로 사용함

(2) 예시

• volatile int i = 0; 이라는 필드가 있을 때 i = 1의 연산은 오른쪽에 있는 1의 값을 왼쪽의 i변수에 대입하는 단 하나의 순서로 실행되기 때문에 둘로 쪼갤 수 없는 원자적 연산임
• 그러나 i = i + 1은 다음 순서로 나누어 실행되기 때문에 원자적 연산이 아님
  1.  오른쪽에 있는 i의 값을 읽고
  2.  읽은 값에 1을 더한 후
  3. 더한 값을 왼쪽의 i의 변수에 대입
• 원자적 연산은 멀티 스레드 상황에서 아무런 문제가 발생하지 않음
• 원자적 연산이 아닌 경우에는 synchronized 블록이나 Lock 등을 사용하여 안전한 임계 영역을 만들어야 함
• 기존에도 다뤄보았지만 i = i + 1의 상황을 멀티스레드 상황에서 수행하게 되면 i값을 읽을 때 여러 스레드들이 동시에 읽게 되고 동시에 연산을 하여 같은 변수에 대입하게 되므로 여러 스레드가 각각 i의 값에 1을 더했으므로 값이 스레드들이 연산한 수만큼 증가되어야 하지만 i의 값은 0 -> 1이 됨
• 멀티스레드의 연산이 사라진 것임
• i++의 연산도 원자적 연산처럼 보이겠지만 이 연산은 i = i + 1을 축약한 것이기 때문에 원자적 연산이 아님

2) 시작

(1) IncrementInteger

• 값을 증가하는 기능을 가진 숫자 기능을 제공하는 인터페이스를 생성
• increment(): 값을 하나 증가
• get(): 값을 조회

package thread.cas.increment;

public interface IncrementInteger {
    void increment();
    int get();
}

 

(2) BasicInteger

• IncrementInteger의 가장 기본적인 구현체를 생성
• increment()를 호출하면 value++를 통해서 값을 하나 증가하고 get()은 value의 값을 반환함
• 여기서 value 값은 인스턴스의 필드이기 때문에 여러 스레드가 공유할 수 있고 이렇게 공유 가능한 자원에 ++와 같은 원자적이지 않은 연산을 사용하면 멀티스레드 상황에 문제가 될 수 있음

package thread.cas.increment;

public class BasicInteger implements IncrementInteger {

    private int value;
    
    @Override
    public void increment() {
        value++;
    }

    @Override
    public int get() {
        return value;
    }
}

 

(3) IncrementThreadMain

• THREAD_COUNT 수만큼 스레드를 생성하고 incrementInteger.increment()를 호출
• 스레드를 1000개 생성했다면 increment() 메서드도 1000번 호출하기 때문에 1000이 되어야 하지만 이미 join()에서 테스트해보았듯이 여러 스레드가 원자적이지 않은 value++을 호출했기 때문에 더 적은 숫자가 출력되는 것을 확인할 수 있음
• 참고로 스레드가 너무 빨리 실행되기 때문에 여러 스레드가 동시에 실행되는 상황을 확인하기 어려워서 의도적으로 sleep(10)을 두어서 최대한 많은 스레드가 동시에 increment()를 호출하도록 하였음

package thread.cas.increment;

public class IncrementThreadMain {
    public static final int THREAD_COUNT = 1000;

    public static void main(String[] args) throws InterruptedException {
        test(new BasicInteger());
    }

    private static void test(IncrementInteger incrementInteger) throws InterruptedException {
        Runnable runnable = new Runnable() {

            @Override
            public void run() {
                sleep(10);  // 너무 빨리 실행되기 때문에 다른 스레드와 동시에 실행 되도록 잠깐 쉬었다가 실행
                incrementInteger.increment();
            }
        };

        List<Thread> threads = new ArrayList<>();
        for (int i = 0; i < THREAD_COUNT; i++) {
            Thread thread = new Thread(runnable);
            threads.add(thread);
            thread.start();
        }

        for (Thread thread : threads) {
            thread.join();
        }

        int result = incrementInteger.get();
        System.out.println(incrementInteger.getClass().getSimpleName() + " result: " + result);
    }

}
/* 실행 결과 
BasicInteger result: 959
*/

 

3) volatile, synchronized

(1-2) VolatileInteger

• 문제 해결을 위해 기존의 BasicInteger와 동일한 구조의 코드에 공유 변수인 value에 volatile을 적용

package thread.cas.increment;

public class VolatileInteger implements IncrementInteger {

    volatile private int value;

    // ... 나머지 코드 동일
}

 

(1-2) IncrementThreadMain

• 실행을 위해 main() 메서드에 test(new VolatileInteger());를 한 줄 추가하고 실행해 보면 당연히 문제가 해결되지 않음
• volatile은 CPU의 캐시 메모리를 무시하고 메인 메모리를 직접 사용하도록 하여 여러 CPU 사이에 발생하는 캐시 메모리와 메인 메모리가 동기화되지 않는 문제를 해결할 뿐임
• 그러나 지금이 문제는 캐시 메모리가 영향을 줄 수는 있지만 캐시 메모리를 사용하지 않고 메인 메모리를 직접 사용하도록 메모리 가시성 문제를 해결하여도 여전히 발생함
• 이 문제는 연산 자체가 나누어져 있기 때문에 발생하는 문제인데 volatile은 연산 자체를 원자적으로 묶어주는 기능은 아님
• 이렇게 연산 자체가 나누어진 경우에는 synchronized 블록이나 Lock 등을 사용하여 안전한 임계 영역을 만들어야 함

package thread.cas.increment;

public class IncrementThreadMain {
    public static final int THREAD_COUNT = 1000;

    public static void main(String[] args) throws InterruptedException {
        test(new BasicInteger());
        test(new VolatileInteger());
    }

    // ... 기존 코드 동일 생략

}
/* 실행 결과
BasicInteger result: 961
VolatileInteger result: 965
*/

 

(2-1) SyncInteger

• volatile 키워드를 제거하고 공유 변수를 사용하는 메서드에 synchronized 키워드를 사용하여 안전한 임계 영역에서 수행되도록 설정하여 한 번에 하나의 스레드만 해당 연산을 수행할 수 있도록 변경

package thread.cas.increment;

public class SyncInteger implements IncrementInteger {

    private int value;

    @Override
    public synchronized void increment() {
        value++;
    }

    @Override
    public synchronized int get() {
        return value;
    }
}

 

(2-2) IncrementThreadMain

• SyncInteger를 사용하도록 코드를 추가하고 실행해 보면 드디어 1000개의 스레드가 안전하게 value++ 연산을 수행하여 정확히 1000이라는 결과가 나왔음

package thread.cas.increment;

public class IncrementThreadMain {
    public static final int THREAD_COUNT = 1000;

    public static void main(String[] args) throws InterruptedException {
        test(new BasicInteger());
        test(new VolatileInteger());
        test(new SyncInteger());
    }

    // ... 기존 코드 동일 생략

}
/* 실행 결과
BasicInteger result: 969
VolatileInteger result: 976
SyncInteger result: 1000
*/

4) AtomicInteger

(1) MyAtomicInteger

• 자바는 앞서 만든 SyncInteger와 같이 멀티스레드 상황에서 안전하게 증가 연산을 수행할 수 있는 AtomicInteger라는 클래스를 제공하며 이름 그대로 원자적인 Integer라는 뜻임
• new AtomicInteger(0): 초기값을 지정하여 생성, 생략하면 0부터 시작함
• incrementAndGet(): 값을 하나 증가하고 증가된 결과를 반환함
• get(): 현재 값을 반환함

package thread.cas.increment;

public class MyAtomicInteger implements IncrementInteger {

    AtomicInteger atomicInteger = new AtomicInteger(0);
    
    @Override
    public void increment() {
        atomicInteger.incrementAndGet();
    }

    @Override
    public int get() {
        return atomicInteger.get();
    }
}

 

(2) IncrementThreadMain

• 작성한 MyAtomicInteger를 사용하도록 코드를 추가하고 실행해보면 synchronized를 사용한 것처럼 정상적으로 결과가 1000이 출력된 것을 확인할 수 있음
• AtomicInteger는 멀티스레드 상황에 안전하고 다양한 값 증가, 감소 연산을 제공하므로 여러 스레드가 해당 값을 공유하는데 값을 증가하거나 감소한다면 AtomicInteger를 사용하면 됨

** 참고

• AtomicInteger, AtomicLong, AtomicBoolean, 등 다양한 AtomicXxx 클래스가 존재함

package thread.cas.increment;

public class IncrementThreadMain {
    public static final int THREAD_COUNT = 1000;

    public static void main(String[] args) throws InterruptedException {
        test(new BasicInteger());
        test(new VolatileInteger());
        test(new SyncInteger());
        test(new MyAtomicInteger());
    }

    // ... 기존 코드 동일 생략
}
/* 실행 결과 
BasicInteger result: 969
VolatileInteger result: 957
SyncInteger result: 1000
MyAtomicInteger result: 1000
*/

5) 성능 테스트

(1) IncrementPerformanceMain

• AtomicInteger의 진짜 모습을 알아보기 위해 직접 만든 Integer 클래스와 성능을 비교
• 단일 연산은 너무 빠르기 때문에 1억 번 값을 증가시키는 연산을 통해 성능 테스트를 실행해 보면 BasicInteger > VolatileInteger > MyAtomicInteger > SyncInteger 순으로 속도가 출력되는 것을 확인할 수 있음

package thread.cas.increment;

public class IncrementPerformanceMain {

    public static final long COUNT = 100_000_000;

    public static void main(String[] args) {
        test(new BasicInteger());
        test(new VolatileInteger());
        test(new SyncInteger());
        test(new MyAtomicInteger());
    }

    private static void test(IncrementInteger incrementInteger) {
        long startMs = System.currentTimeMillis();
        for (long i = 0; i < COUNT; i++) {
            incrementInteger.increment();
        }
        long endMs = System.currentTimeMillis();
        System.out.println(incrementInteger.getClass().getSimpleName() + ": ms =" + (endMs - startMs));
    }
}
/* 실행 결과
BasicInteger: ms=42
VolatileInteger: ms=622
SyncInteger: ms=946
MyAtomicInteger: ms=716
*/

 

(2) 클래스별 성능 정리

• BasicInteger
  • CPU 적극 사용하기 때문에 가장 빠름, CPU 캐시의 위력을 알 수 있음
  • 안전한 임계 영역도 없고 volatile도 사용하지 않기 때문에 멀티스레드 상황에서는 사용할 수 없음
  • 단일 스레드가 사용하는 경우 효율적임
• VolatileInteger
  • volatile 키워드 하나만으로도 성능이 10배 이상 느려짐
  • CPU 캐시를 사용하지 않고 메인메모리를 사용함
  • 마찬가지로 안전한 임계 영역이 없기 때문에 멀티스레드 상황에는 사용할 수 없음
  • 단일 스레드가 사용하기에는 BasicInteger보다 느리고 멀티스레드 상황에도 안전하지 않음
  • 다만 멀티스레드 상황에서 원자적 연산을 사용하는 경우에는 사용할 수 있음(boolean flag를 사용하는 경우)
• SyncInteger
  • synchronized를 사용한 안전한 임계 영역이 있기 때문에 멀티스레드 상황에도 안전하게 사용할 수 있음
  • 그러나 MyAtomicInteger보다 성능이 느림
• MyAtomicInteger
  • 자바가 제공하는 AtomicInteger를 사용하며 멀티스레드 상황에 안전하게 사용할 수 있음
  • 성능도 synchronized, Lock(ReentrantLock)을 사용하는 경우보다 1.5~2배 정도 빠름
  • SyncInteger처럼 락을 사용하는 경우보다 AtomicInteger가 더 빠른 이유는 AtomicInteger가 제공하는 incrementAndGet() 메서드가 synchronized나 Lock(ReentrantLock)처럼 안전한 임계 영역을 위해 락을 사용하지 않고 원자적 연산을 만들어내기 때문임

---

2. CAS 연산

**참고

• CAS 연산은 심화 내용이기 때문에 이해가 어렵다면 우리가 직접 CAS 연산을 사용하는 경우는 거의 없기 때문에 가볍게 듣고 넘어가도 괜찮음
• 대부분 복잡한 동시성 라이브러리들이 CAS 연산을 사용하며 우리는 AtomicInteger와 같은 CAS 연산을 사용하는 라이브러리들을 잘 사용하는 정도면 충분함

1) CAS 연산

(1) 락 기반 방식의 문제점

• 데이터를 보호하기 위해 락을 사용하는 synchronized, Lock(ReentrantLock) 등은 특정 자원을 보호하기 위해 스레드가 해당 자원에 접근하는 것을 제한함
• 락이 걸려 있는 동안 다른 스레드들은 해당 자원에 접근할 수 없고 락이 해제될 때까지 대기해야 하며 락 기반 접근에서는 락을 획득하고 해제하는데 시간이 소요됨
• 락을 사용하는 연산은 락이 있는지 확인하고, 락을 획득하고 임계 영역에 들어가고 작업을 수행한 후 락을 반납하는 방식으로 동작하는데 락을 획득하고 반납하는 과정이 계속 반복됨
• 만 번의 연산이 있다면 만 번 계속 락을 확인하고 획득하고 반납하는 과정을 반복해야만 하므로 락을 사용하는 방식은 직관적이지만 상대적으로 무거운 방식임

(2) CAS

• 이런 문제를 해결하기 위해 락을 걸지 않고 원자적인 연산을 수행할 수 있는 방법이 있는데 이것을 CAS(Compare-And-Swap, Compare-And-Set) 연산이라 함
• 락을 사용하지 않기 때문에 락 프리(lock-free) 기법이라고 함
• CAS 연산은 락을 완전히 대체하는 것은 아니고 작은 단위의 일부 영역에 적용할 수 있어서 기본은 락을 사용하고 특별한 경우에 CAS를 적용할 수 있다고 생각하면 됨

(3) CasMainV1

• 자바는 AtomicXxx의 compareAndSet() 메서드를 통해 CAS 연산을 지원하므로 AtomicInteger를 생성하여 compareAndSet() 메서드를 사용
• compareAndSet(0, 1), compareAndSet(0, 2)
  • atomicInteger가 가지고 있는 값이 현재 0이라면 이 값을 두 번째 인자인 1로 변경하라는 단순한 메서드임
  • 만약 atomicInteger의 값이 현재 0이라면 atomicInteger의 값을 1로 변경되고 이 경우 true를 반환함
  • 만약 atomicInteger의 값이 0이 아니라면 값은 변경되지 않고 false를 반환하여 두번째 실행한 compareAndSet(0, 2)의 경우 이미 앞서 값을 1로 변경했기 때문에 false를 반환하고 계속 값이 1로 유지되고 있음을 확인할 수 있음
• 여기서 가장 중요한 내용은 이 메서드는 원자적으로 실행된다는 점이고 이 메서드가 제공하는 기능이 바로 CAS연산임

package thread.cas;

public class CasMainV1 {
    public static void main(String[] args) {
        AtomicInteger atomicInteger = new AtomicInteger(0);
        System.out.println("start value = " + atomicInteger.get());

        boolean result1 = atomicInteger.compareAndSet(0, 1);
        System.out.println("result1 = " + result1 + ", value = " + atomicInteger.get());

        boolean result2 = atomicInteger.compareAndSet(0, 2);
        System.out.println("result2 = " + result2 + ", value = " + atomicInteger.get());
    }
}
/* 실행 결과
start value = 0
result1 = true, value = 1
result2 = false, value = 1
*/

2) 실행 순서 분석

(1) CAS - 성공 케이스

• AtomicInteger내부에 있는 value 값이 0이라면 1로 변경하기 위해 compareAndSet(0, 1)을 호출함, 여기서 매개변수의 왼쪽이 기대하는 값, 오른쪽이 변경하는 값임
• CAS 연산은 메모리에 있는 값이 기대하는 값이라면 원하는 값으로 변경함
• 이 명령은 먼저 메모리에 있는 값을 확인하고, 해당 값이 기대하는 값(0)이라면 원하는 값(1)으로 변경하는 2개로 나누어진 명령이기 때문에 원자적이지 않는 연산처럼 보임
• CAS 연산은 이렇게 원자적이지 않은 두 개의 연산을 CPU 하드웨어 차원에서 특별하게 하나의 원자적인 연산으로 묶어서 제공하는 기능임
• 즉, 소프트웨어가 제공하는 기능이 아니라 하드웨어가 제공하는 기능이며 대부분의 현대 CPU들은 CAS 연산을 위한 명령을 제공함
• CPU는 값을 확인하고 읽은 값이 0이면 1로 변경하는 과정을 묶어서 하나의 원자적인 명령으로 만들어버리기 때문에 중간에 다른 스레드가 개입할 수 없음
• 1초에 수억 번 연산을 수행하는 CPU 입장에서는 이 과정을 수행하는 시간은 매우 찰나의 순간이기 때문에 성능에 큰 영향을 끼치지 않음
• 성공적으로 value의 값이 0 -> 1로 변경이 되면 true를 반환함

(2) CAS - 실패 케이스

• 메모리에 있는 값이 기대하는 값이 아니라면 값 변경에 실패하고 false를 반환함

3) CAS 연산 활용

(1) CasMainV2

• CAS 연산을 활용하여 AtomicInteger가 제공하는 incrementAndGet() 메서드가 어떻게 만들어졌는지 직접 구현
• 여기서 직접 만은 incrementAndGet()은 atomicInteger 내부의 value의 값을 하나 증가하는 메서드로 atomicInteger도 동일한 이름으로 동일한 기능을 하는 메서드를 제공함
• CAS 연산을 사용하면 여러 스레드가 같은 값을 사용하는 상황에서도 락을 걸지 않고 안전하게 값을 증가할 수 있음
• getValue = atomicInteger.get()을 사용하여 value 값을 읽은 후 CAS 연산을 사용하여 compareAndSet(getValue, getValue + 1)을 사용하여 방금 읽은 value 값이 메모리의 value 값과 같다면 value값을 하나 증가시킴
• CAS 연산이 성공하면 true를 반환하고 do-while문을 빠져나오고, 실패하면 false를 반환한 후 do - while문을 다시 시작함
• 결과적으로 incrementAndGet()이 순차적으로 두 번 실행되어 최종값이 2로 출력되는 것을 확인할 수 있음
• 지금은 main 스레드 하나로 실행하기 때문에 CAS 연산이 실패하는 상황을 볼 수 없음

package thread.cas;

public class CasMainV2 {
    public static void main(String[] args) {
        AtomicInteger atomicInteger = new AtomicInteger(0);
        System.out.println("start value = " + atomicInteger.get());

        // incrementAndGet 구현
        int resultValue1 = incrementAndGet(atomicInteger);
        System.out.println("resultValue1 = " + resultValue1);

        int resultValue2 = incrementAndGet(atomicInteger);
        System.out.println("resultValue2 = " + resultValue2);
    }

    private static int incrementAndGet(AtomicInteger atomicInteger) {
        int getValue;
        boolean result;

        do {
            getValue = atomicInteger.get();
            log("getValue = " + getValue);
            result = atomicInteger.compareAndSet(getValue, getValue + 1);
            log("result = " + result);
        } while (!result);
        return getValue + 1;
    }
}
/* 실행 결과 
start value = 0
19:15:30.628 [     main] getValue = 0
19:15:30.629 [     main] result = true
resultValue1 = 1
19:15:30.629 [     main] getValue = 1
19:15:30.629 [     main] result = true
resultValue2 = 2
*/

 

(2) CasMainV3

• 멀티스레드를 사용하여 중간에 다른 스레드가 먼저 값을 증가시켜 버려서 CAS 연산이 실패하는 경우를 구현하여 이 경우에도 값을 정상적으로 증가시킬 수 있는지 분석
• 2개의 스레드가 incrementAndGet()을 호출해서 atomicInteger 내부의 value 값을 동시에 하나씩 증가 시킴
• 이때 두 스레드가 동시에 같은 값을 읽고 CAS 연산을 수행하는 상황을 쉽게 만들기 위해 sleep() 코드를 추가하였음
• 실행 결과를 보면 중간에 같은 값을 읽었을 때 다른 하나의 스레드는 처음 연산을 실패하지만 결과적으로는 AtomicIntege가 정상적으로 2로 증가된 것을 확인할 수 있음
• incrementAndGet() 메서드의 반환값을 값을 증가하고 atomicInteger.get()이 아니라 getValue + 1로 반환하는 이유는 멀티 스레드 상황에서 반환 시점에 atomicInteger.get()으로 반환한 값이 내가 연산한 값이 아닌 다른 스레드가 연산한 값을 반환할 수 있기 때문에 정확하게 내가 연산에서 사용한 값을 반환하기 위해 getValue + 1로 반환한 것임

package thread.cas;

public class CasMainV3 {

    private static final int THREAD_COUNT = 2;

    public static void main(String[] args) throws InterruptedException {
        AtomicInteger atomicInteger = new AtomicInteger();

        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                incrementAndGet(atomicInteger);
            }
        };

        List<Thread> threads = new ArrayList<>();
        for (int i = 0; i < THREAD_COUNT; i++) {
            Thread thread = new Thread(runnable);
            threads.add(thread);
            thread.start();
        }
        for (Thread thread : threads) {
            thread.join();
        }

        int result = atomicInteger.get();
        System.out.println(atomicInteger.getClass().getSimpleName() + " resultValue: " + result);
    }

    private static int incrementAndGet(AtomicInteger atomicInteger) {
        int getValue;
        boolean result;

        do {
            getValue = atomicInteger.get();
            sleep(100); // 스레드 동시 실행을 위한 대기
            log("getValue = " + getValue);
            result = atomicInteger.compareAndSet(getValue, getValue + 1);
            log("result = " + result);
        } while (!result);
        return getValue + 1;
    }
}
/* 실행 결과
20:22:24.505 [ Thread-0] getValue = 0
20:22:24.505 [ Thread-1] getValue = 0
20:22:24.507 [ Thread-0] result = true
20:22:24.507 [ Thread-1] result = false
20:22:24.611 [ Thread-1] getValue = 1
20:22:24.612 [ Thread-1] result = true
AtomicInteger resultValue: 2
*/

 

(2-1) Thread-0 실행 - 성공 케이스

/*
20:22:24.505 [ Thread-0] getValue = 0
20:22:24.507 [ Thread-0] result = true
*/

• atomicInteger.get()을 사용하여 value 값을 읽으면 getValue는 0이 됨
• compareAndSet(0, 1)을 수행하여 메모리의 값과 getValue의 값이 같은지 비교하고 같으면 1을 증가함
• CAS연산이 성공하여 value의 값은 0에서 1로 증가하고 true를 반환 후 do~while문을 빠져나감

(2-2) Thread-1 실행 - 실패 케이스

/*
첫 번째 시도
20:22:24.505 [ Thread-1] getValue = 0
20:22:24.507 [ Thread-1] result = false

두 번째 시도
20:22:24.611 [ Thread-1] getValue = 1
20:22:24.612 [ Thread-1] result = true
*/

• Thread-1은 반복문을 2번 수행하는데, 첫 번째 시도는 CAS 연산을 실패함
• atomicInteger.get()을 사용하여 value의 값을 0으로 읽고 compareAndSet(0,1) 연산을 수행하지만 중간에 Thread-0이 먼저 실행되면서 value의 값을 0 -> 1로 변경했으므로 연산이 실패함
• CAS 연산의 핵심은 내가 읽은 값이 중간에 변경하지 않았을 경우에만 값을 변경하는 것임
• CAS 연산이 실패했으므로 value 값을 변경하지 못하고 false를 반환하여 do-while문을 빠져나가지 못하고 다시 반복문을 시작함
• 다시 반복문을 돌면 atomicInteger.get()을 사용하여 값을 읽으면 이때는 Thread-0이 변경한 값인 1을 읽고 compareAndSet(1, 2) 연산을 수행함
• 두 번째는 CAS 연산이 성공했으므로 value값이 1에서 2로 증가하고 true를 반환하여 do-while문을 빠져나감

(3) 정리

• AtomicInteger가 제공하는 incrementAndGet() 코드도 직접 작성한 incrementAndGet() 코드와 똑같이 CAS를 활용하도록 작성되어 있음
• CAS를 사용하면 락을 사용하지 않지만 대신에 다른 스레드가 값을 먼저 증가해서 문제가 발생하는 경우 루프를 돌며 재시도를 하는 방식을 사용함
• 동작하는 방식을 정리하면 아래와 같음
  1. 현재 변수의 값을 읽어옴
  2. 변수의 값을 1 증가시킬 때 원래 값이 같은지 확인함(CAS 연산 사용)
  3. 동일하다면 증가된 값을 변수에 저장하고 종료함
  4. 동일하지 않다면 다른 스레드가 값을 중간에 변경한 것이므로 다시 처음으로 돌아가 위 과정을 반복함
• 두 스레드가 동시에 실행되면서 문제가 발생하는 상황을 스레드가 충돌했다고 표현함
• 이 과정에서 충돌이 발생할 때마다 반복해서 다시 시도하므로 결과적으로 락 없이 데이터를 안전하게 변경할 수 있음
• CAS를 사용하는 방식은 충돌이 드물게 발생하는 환경에서는 락을 사용하지 않으므로 높은 성능을 발휘할 수 있음
• 이는 락을 사용하는 방식과 비교했을 때 스레드가 락을 획득하기 위해 대기하지 않기 하지 않으므로 대기 시간과 오버헤드가 줄어드는 장점이 있음
• 그러나 충돌이 빈번하게 발생하는 환경에서는 CAS 연산이 자주 실패하고 재시도를 위해 반복문을 계속 수행해야 하여 CPU 자원을 많이 소모하게 되므로 성능 저하가 발생할 수 있음

(4) CAS(Compare-And-Swap)와 락 방식의 비교

• 락(Lock) 방식
  • 비관적(pessimistic) 접근법
  • 데이터에 접근하기 전에 항상 락을 획득하고 다른 스레드의 접근을 막음
  • "다른 스레드가 방해할 것이다"라고 가정
• CAS(Compare-And-Swap) 방식
  • 낙관적(optimistic) 접근법
  • 락을 사용하지 않고 데이터에 바로 접근하며 충돌이 발생하면 그때 재시도
  • "대부분의 경우 충돌이 없을 것이다"라고 가정
• 정리하면 충돌이 많이 없는 경우에 CAS 연산이 빠른 것을 확인할 수 있으며 간단한 CPU 연산은 너무 빨리 처리되기 때문에 충돌이 자주 발생하지 않으며 충돌이 발생하기도 전에 이미 연산을 완료하는 경우가 더 많음
• 앞서 직접 만든 숫자 클래스들의 스레드 충돌을 테스트하는 예제에서 최대한 많이 충돌하게 만들기 위해 sleep(10)을 통해 1000개의 스레드를 동시에 쉬게 만든 다음 실행했음에도 1000개 중 약 40 ~ 50개의 스레드만 충돌하였으며 만약 sleep()를 제거했다면 충돌 가능성은 100개 중에 1개도 안될 것임
• 이 경우 락 방식이라면 스레드 충돌을 방지하기 위해 1000개의 스레드가 모두 락을 획득하고 반환하는 과정을 거치며 락을 사용하기 때문에 1000개의 스레드는 순서대로 하나씩 수행됨
• 그러나 CAS 방식이라면 1000개의 스레드를 모두 한 번에 실행하고 충돌이 나는 50개의 경우만 재시도하므로 간단한 CPU 연산에는 락보다는 CAS를 사용하는 것이 효과적임

---

3. CAS 락 구현

1) CAS 락 구현 - 실패

(1) SpinLockBad

• 스레드가 락을 획득하면 lock의 값이 true가 되고 락을 반납하면 false가 됨
• 스레드가 락을 획득하면 while문을 탈출하고 스레드가 락을 획득하지 못하면 락을 획득할 때까지 while문을 계속 반복 실행함

package thread.cas.spinlock;

public class SpinLockBad {

    private volatile boolean lock = false;

    public void lock() {
        log("락 획득 시도");
        while (true) {
            if (!lock) {            // 1. 락 사용 여부 확인
                sleep(10);    // 문제 상황 확인용, 스레드 대기
                lock = true;        // 2. 락의 값 변경
                break;              // while 탈출
            } else {
                // 락을 획득할 때 까지 스핀 대기함
                log("락 획득 실패 - 스핀 대기");
            }
        }
        log("락 획득 완료");
    }
    
    public void unlock() {
        lock = false;
        log("락 반납 완료");
    }
}

 

(2) SpinLockMain

• 실행 결과를 보면 기대하는 바와 다르게 Thread-1, Thread-2 둘 다 동시에 락을 획득하고 비즈니스 로직을 동시에 수행해 버림
• 이 문제는 두 스레드가 동시에 수행되기 때문에 문제가 발생함

package thread.cas.spinlock;

public class SpinLockMain {
    public static void main(String[] args) {
        SpinLockBad spinLock = new SpinLockBad();

        Runnable task = new Runnable() {

            @Override
            public void run() {
                spinLock.lock();
                try {
                    log("비즈니스 로직 실행");
                } finally {
                    spinLock.unlock();
                }
            }
        };

        Thread t1 = new Thread(task, "Thread-1");
        Thread t2 = new Thread(task, "Thread-2");

        t1.start();
        t2.start();
    }
}
/* 실행 결과
21:37:33.380 [ Thread-1] 락 획득 시도
21:37:33.380 [ Thread-2] 락 획득 시도
21:37:33.395 [ Thread-1] 락 획득 완료
21:37:33.395 [ Thread-2] 락 획득 완료
21:37:33.395 [ Thread-2] 비즈니스 로직 실행
21:37:33.395 [ Thread-2] 락 반납 완료
21:37:33.395 [ Thread-1] 비즈니스 로직 실행
21:37:33.395 [ Thread-1] 락 반납 완료
*/

 

(3) 실행 결과 분석

• 두 스레드가 동시에 lock()을 호출해서 락을 획득을 시도하면 두 스레드의 lock의 값이 false이므로 모두 if문의 락의 사용여부를 확인하는 코드를 통과함
• 두 스레드가 lock = true를 호출해서 각각 false -> true, true -> true로 값을 변경하게 되고 break를 통해 while문을 탈출하며 락 획득을 완료한 후 비즈니스 로직을 수행한 다음에 락을 반납함
• 여기서 다음 두 부분이 원자적이지 않다는 문제가 있음
• 1. 락 사용 여부 확인
• 2. 락의 값 변경
• 이 둘은 한 번에 하나의 스레드만 실행해야 하므로 sychronized나 Lock을 사용해서 두 코드를 동기화하여 안전한 임계 영역을 만들어야 하지만 CAS 연산을 사용하면 두 연산을 하나로 묶어서 하나의 원자적인 연산으로 처리할 수 있음
• 락의 사용 여부를 확인하고 그 값이 기대하는 값과 같다면 변경하는 로직은 CAS 연산에 딱 들어맞음
• 참고로 unlock() 메서드의 lock=false; 로직은 연산이 하나인 원자적인 연산이므로 멀티스레드 상황에서도 문제가 되지 않음

2) CAS 락 구현 - CAS 적용

(1) SpinLock

• CAS 연산을 지원하는 AtomicBoolean을 사용하여 락을 구현
• 스레드가 락을 획득하면 lock의 값이 true가 되고 while문을 탈출함
• 락을 반납하면 lock의 값이 false가 되며 락을 획득할 때까지 while문을 계속 반복 실행함
• 락을 획득할 때 매우 중요한 점은 락 사용 여부를 확인하고 락의 값을 변경하는 두 가지의 연산을 하나로 만들어야 한다는 것인데 CAS 연산을 사용하여 lock.compareAndSet(false, true)로 두 연산을 하나의 원자적인 연산으로 만들었음

package thread.cas.spinlock;

public class SpinLock {

    private final AtomicBoolean lock = new AtomicBoolean(); // 초기값이 false

    public void lock() {
        log("락 획득 시도");
        while (!lock.compareAndSet(false, true)) {
            // 락을 획득할 때 까지 스핀 대기함
            log("락 획득 실패 - 스핀 대기");
        }
        log("락 획득 완료");
    }

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

 

(2) SpinLockMain

• SpinLockBad 대신에 SpinLock을 사용하도록 코드를 변경하고 실행해 보면 동시에 락 획득을 시도해도 하나의 스레드만 락 획득을 성공하고 비즈니스 로직을 수행하며 실패한 스레드는 스핀 대기를 하여 락이 잘 적용된 것을 확인할 수 있음

/* 실행 결과
22:01:16.762 [ Thread-1] 락 획득 시도
22:01:16.762 [ Thread-2] 락 획득 시도
22:01:16.763 [ Thread-1] 락 획득 완료
22:01:16.763 [ Thread-1] 비즈니스 로직 실행
22:01:16.763 [ Thread-2] 락 획득 실패 - 스핀 대기
22:01:16.764 [ Thread-1] 락 반납 완료
22:01:16.764 [ Thread-2] 락 획득 완료
22:01:16.764 [ Thread-2] 비즈니스 로직 실행
22:01:16.764 [ Thread-2] 락 반납 완료
*/

 

(3) 실행 결과 분석

• 두 스레드가 동시에 lock()을 호출해서 락 획득을 시도하면 두 스레드 중 하나만 while(!lock.compareAndSet(false, true))를 사용하여 락의 사용 여부를 확인하면서 변경을 시도함
• 실행 결과에서는 Thread-1이 먼저 CAS 연산을 시도하고 초기값이 false이므로 CAS true를 반환하며 CAS 연산이 성공함
• while의 조건이! true가 되어 최종적으로 false가 되므로 Thread-1은 while문을 빠져나오고 락 획득을 완료함
• 그 이후 Thread-2가 while(!lock.compareAndSet(false, true))를 사용하여 락의 사용 여부를 확인하면서 변경을 시도하면 lock의 값이 true이므로 CAS 연산이 실패함
• while문의 조건이 !false가 되어서 최종적으로 true가 되므로 Thread-2는 반복문을 빠져나오지 못하고 락 획득 실패라는 로그를 반복해서 출력하게 됨
• Thread-1이 비즈니스 로직을 수행하고 락을 반납하면 while문에서 스핀 대기하던 Thread-2가 락을 획득하고 비즈니스 로직을 수행한 다음 락을 반납함

(4) 정리

• 기존의 원자적이지 않았던 연산을 락을 사용하지 않는다면 락의 값을 변경하도록 하나의 원자적인 연산으로 바꾸어서 문제가 해결되었음
• 원자적인 연산은 스레드 입장에서 쪼갤 수 없는 하나의 연산이므로 여러 스레드가 동시에 실행해도 안전함
• 이렇게 CAS를 사용하여 원자적인 연산을 만든 덕분에 무거운 동기화 작업 없이 가벼운 락을 만들 수 있었음
• 동기화 락을 사용하는 경우 스레드가 락을 획득하지 못하면 BLOCKED, WAITING 등으로 상태가 변하며 대기 상태의 스레드를 깨워야 하고 컨텍스트 스위칭이 발생하는 등의 무겁고 복잡한 과정이 추가로 들어가기 때문에 CAS를 활용한 방식보다 상대적으로 느릴 수 있음
• CAS를 활용한 방식은 락이 없고 while문만 반복할 뿐이며 대기하는 스레드도 RUNNABLE 상태를 유지하면서 가볍고 빠르게 작동할 수 있음

(5) CAS 방식 단점

package thread.cas.spinlock;

public class SpinLockMain {
    public static void main(String[] args) {
    // ... 기존 코드 동일 생략
    
                try {
                    log("비즈니스 로직 실행");
                    sleep(1);   // 오래 걸리는 로직에서 스핀 락 사용X
                }
    // ... 기존 코드 동일 생략
}
/* 실행 결과
22:19:01.689 [ Thread-2] 락 획득 시도
22:19:01.689 [ Thread-1] 락 획득 시도
22:19:01.690 [ Thread-2] 락 획득 완료
22:19:01.690 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.690 [ Thread-2] 비즈니스 로직 실행
22:19:01.690 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.690 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.690 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.691 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.692 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.692 [ Thread-1] 락 획득 실패 - 스핀 대기
22:19:01.692 [ Thread-2] 락 반납 완료
22:19:01.692 [ Thread-1] 락 획득 완료
22:19:01.692 [ Thread-1] 비즈니스 로직 실행
22:19:01.693 [ Thread-1] 락 반납 완료
*/

 

• 이렇게 반복문과 CAS를 사용해서 락을 대체하는 방식에도 단점이 있는데 SpinLockMain 코드의 try 부분에 sleep(1)을 추가하고 실행해 보면 비즈니스 로직이 조금만 길어져도 스핀 대기하는 출력문이 상당히 많이 출력되는 것을 확인할 수 있음
• CAS를 사용하는 방식은 락을 기다리는 스레드가 BLOCKED, WAITING 상태로 빠지지는 않지만 RUNNABLE 상태로 락을 획득할 때까지 while문을 반복하여 락을 기다리는 스레드가 CPU를 계속 사용하면서 대기하기 때문에 CPU 자원을 계속해서 사용함
• 그래서 동기화를 사용하는 방식보다 스레드를 RUNNABLE로 살려둔 상태에서 계속 락 획득을 반복 체크하는 것이 더 효율적인 경우에만 이런 방식을 사용해야 하며 이 방식은 스레드의 상태가 변경되지 않기 때문에 매우 빠르게 락을 획득하고 바로 실행할 수 있는 장점이 있음
• 안전한 임계 영역이 필요하지만 연산이 길지 않고 매우! 짧게 끝날 때 사용해야 함(나노세컨드 단위)
• 예를 들어 숫자 값의 증가, 자료 구조의 데이터 추가와 같이 CPU 사이클을 금방 끝나는 연산에 사용하면 효과적인 반면 데이터베이스의 결과를 대기하거나 다른 서버의 요청을 기다린다거나 하는 것처럼 오래 기다리는 작업에 사용하면 CPU를 계속 사용하며 기다리는 최악의 결과가 나올 수 있음

(5) 스핀 락

• 스레드가 락이 해제되기를 기다리면서 반복문을 통해 계속해서 확인하는 모습이 마치 제자리에서 회전(spin)하는 것처럼 보여 이런 방식을 스핀 락이라고도 부름
• 그리고 이런 방식에서 스레드가 락을 획득할 때까지 대기하는 것을 스핀 대기(spin-wait) 또는 CPU 자원을 계속 사용하면서 바쁘게 대기한다고 해서 바쁜 대기(busy-wait)라 함
• 이런 스핀 락 방식은 아주 짧은 CPU 연산을 수행할 때 사용해야 효율적이며 잘못 사용하면 오히려 CPU 자원을 더 많이 사용할 수 있음
• 정리하면 락을 획득하기 위해 자원을 소모하면서 반복적으로 확인(스핀)하는 락 메커니즘을 의미하며 이런 스핀 락은 CAS를 사용하여 구현할 수 있음

3) 락 VS CAS 사용 방식

(1) CAS의 장점

• 낙관적 동기화: 락을 걸지 않고도 값을 안전하게 업데이트할 수 있음, CAS는 충돌이 자주 발생하지 않을 것이라고 가정하기에 충돌이 적은 환경에서 높은 성능을 발휘함
• 락 프리(Lock-Free): CAS는 락을 사용하지 않기 때문에 락을 획득하기 위해 대기하는 시간이 없어 스레드가 블로킹되지 않으며 병렬 처리가 더 효율적일 수 있음

(2) CAS의 단점

• 충돌이 빈번한 경우: 여러 스레드가 동시에 동일한 변수에 접근하여 업데이트를 시도할 때 충돌이 발생하면 CAS는 루프를 돌며 재시도해야 하며 이에 따라 CPU 자원을 계속 소모할 수 있음, 반복적인 재시도로 인해 오버헤드가 발생할 수 있음
• 스핀락과 유사한 오버헤드: CAS는 충돌 시 반복적인 재시도를 하므로 이 과정이 계속 반복되면 스핀락과 유사한 성능 저하가 발생할 수 있으며 충돌 빈도가 높을수록 이런 현상이 두드러짐

(3) 동기화 락의 장점

• 충돌 관리: 락을 사용하면 하나의 스레드만 리소스에 접근할 수 있으므로 충돌이 발생하지 않아 여러 스레드가 경쟁할 경우에도 안정적으로 동작함
• 안정성: 복잡한 상황에서도 락은 일관성 있는 동적을 보장함
• 스레드 대기: 락을 대기하는 스레드는 CPU를 거의 사용하지 않음

(4) 동기화 락의 단점

• 락 획득 대기 시간: 스레드가 락을 획득하기 위해 대기해야 하므로 대기 시간이 길어질 수 있음
• 컨텍스트 스위칭 오버헤드: 락을 사용하면 락 획득을 대기하는 시점과 락을 획득하는 시점에 스레드의 상태가 변경되는데 이때 컨텍스트 스위칭이 발생할 수 있으며 이로 인하여 오버헤드가 증가할 수 있음

(5) 결론

• 일반적으로는 동기화 락을 사용하고 아주 특별한 경우에 한정해서 CAS를 사용해서 최적화해야 함
• CAS를 통한 최적화가 더 나은 경우는 스레드가 RUNNABLE -> BLOCKED, WAITING 상태에서 다시 RUNNABLE 상태로 가는 것보다는 스레드를 RUNNABLE로 살려둔 상태에서 계속 락 획득을 반복 체크하는 것이 더 효율적인 경우에만 사용해야 함
• 대기하는 스레드가 CPU 자원을 계속 소모하기 때문에 대기 시간이 매우 짧아야 하므로 숫자 값이 증가라든가 자료 구조의 데이터 추가 및 삭제와 같이 CPU 사이클이 금방 끝나지만 안전한 임계 영역 또는 원자적인 연산이 필요한 경우에 사용해야 함
• 데이터 베이스를 기다린다거나 다른 서버의 요청을 기다리는 것처럼 오래 기다리는 작업에 CAS를 사용하면 CPU를 계속 사용하며 기다리는 최악의 결과가 나올 수 있으므로 이런 경우는 동기화 락을 사용해야 함
• 또한 CAS는 충돌 가능성이 낮은 환경에서 매우 효율적이지만 충돌 가능성이 높은 환경에서는 성능 저하가 발생할 수 있으므로 상황에 맞는 적절한 동기화 전략을 사용하는 것이 중요함
• 각 접근 방식의 특성을 이해하고 애플리케이션의 특정 요구사항과 환경에 맞는 방식을 선택하는 것이 필요함

(6) 실무 관점

• 실무 관점에서 보면 대부분의 애플리케이션들은 공유 자원을 사용할 때 충돌할 가능성보다 충돌하지 않을 가능성이 훨씬 높음
• 예를 들어 여러 스레드가 발생하는 주문 수를 실시간으로 증가하면서 카운트하고 특정 피크시간에 주문이 100만 건 들어오는 서비스라고 가정하면 1,000,000 / 60분으로 1분에 16,666건, 1초에 277건 정도 들어올 것임
• CPU가 1초에 얼마나 많은 연산을 처리하는지 생각해 보면 백만 건에 중에 충돌이 나는 경우는 아주 넉넉하게 해도 몇 십건 이하일 것이므로 실무에서는 주문 수 증가와 같은 단순한 연산의 경우 락을 걸고 시작하는 것보다 CAS처럼 낙관적인 방식이 더 나은 성능을 보임
• 여기서 중요한 핵심은 주문 수 증가와 같이 단순한 연산이라는 점이며 이런 경우 나노 초 단위로 발생하는 연산이므로 AtomicInteger와 같은 CAS 연산을 사용하는 방식이 효과적임
• 반면 데이터베이스를 기다린다거나 다른 서버의 요청을 기다리는 것처럼 수 밀리초 이상의 시간이 거리는 작업은 동기화 락을 사용하거나 스레드가 대기하는 방식이 더 효과적임
• 우리가 사용하는 많은 자바 동시성 라이브러리들, 동기화 컬렉션들은 성능 최적화를 위해 CAS 연산을 적극 활용함
• 덕분에 실무에서 CAS 연산을 직접 사용하는 일은 매우 드물어 CAS 연산을 사용해서 최적화되어 있는 라이브러리들을 이해하고 편리하게 사용할 줄 알면 충분함
• CAS의 개념을 알아두면 앞으로 멀티스레드와 관련된 다양한 라이브러리들을 분석할 때 이해가 쉽게 될 수 있음