[Java] synchronized와 Lock

Java에서 Lock을 사용하는 방법과 그 종류에 대해 정리해본다.

멀티스레드와 Data Race 문제

Lock는 멀티스레드 환경에서 발생하는 대표적인 부작용인 동시성 쓰기, Data race 문제를 해결하기 위해 존재한다. 이 문제에 대해 안다면 무시하고 넘어가도 된다.

package org.example;

class SharedObject {
    public int count = 0;
}

public class Main {
    public static void main(String[] args) {
         var shared = new SharedObject();

        // 스레드를 5개 생성해서 count를 증가시킴
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    shared.count++;
                }
            });
            thread.start();
        }

        // 모든 스레드가 종료될 때까지 대기
        while (Thread.activeCount() > 1) {
            Thread.yield();
        }

        System.out.println(shared.count);
    }
}

코드를 보면, 스레드를 5개 띄우고 공유 자원에 대해서 계속해서 +1 연산을 가하고 있는 것을 볼 수 있다.
스레드 5개에서 1000번씩 증가 연산을 때리니, 일반적으로는 최종 결과값이 5000이 될 것이라고 기대할 수 있다.

하지만 실제 결과는 그렇지 않다.

여러개의 스레드에서 n+1 연산을 가하는데, 그게 동시에 중첩된다면 2개 이상의 스레드에서 동일한 값을 쓰면서 하나를 제외한 스레드의 write가 버려질 수 있기 때문이다.

물론 이건 아주 단순한 경우고, 실제 프로그램에서 동시성 문제는 보통 좀 더 복잡한 형태로 드러난다.

아무튼 여기서 중요한 것은, 여러개의 스레드에서 "동시에 쓰는 행위" 자체가 매우 위험하다는 것이다.

synchronized를 이용한 Lock

Java는 드물게 동기화에 대한 지원을 언어 신택스부터 지원하는 언어다.
synchronized 키워드를 메서드에 붙이면, 그 메서드는 완벽하게 동기화되는 메서드가 된다.

동일한 객체에 대해서 저 메서드를 실행하면, 저 메서드 자체는 동시에 하나씩만 수행되는 것이 보장된다.

좀 더 원리를 자세하게 설명하자면, 메서드가 시작될때 저 객체(this)를 기준으로 Mutex.lock을 걸고, 메서드가 끝나면 Mutex.unlock을 거는 것이다.

그렇게 동기화된 메서드를 만들고 그걸로 대체하면

기대한 대로 충돌은 더 이상 발생하지 않을 것이다.

package org.example;

class SharedObject {
    public int count = 0;

    // synchronized 키워드를 사용하면 메소드 전체에 락이 걸림
    public synchronized void increment() {
        count++;
    }
}

public class Main {
    public static void main(String[] args) {
         var shared = new SharedObject();

        // 스레드를 5개 생성해서 count를 증가시킴
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    shared.increment();
                }
            });
            thread.start();
        }

        // 모든 스레드가 종료될 때까지 대기
        while (Thread.activeCount() > 1) {
            Thread.yield();
        }

        System.out.println(shared.count);
    }
}

synchronized 블럭을 통한 동기화

이것도 synchronized 메서드와 동작방식은 거의 동일하다.
그 범위가 메서드 범위에서 블록 범위로 좁혀진 것일 뿐이다.

메서드가 길고, 락을 잡아야할 범위가 한정적이라면 메서드 전체에 대해서 거는 것은 처리량을 떨어뜨리는 짓이기 때문에, 락을 걸어야할 범위에 대해서만 걸어주는 것이 좋다.

사용 방법은 어렵지 않다.

이런 느낌으로 lock 블럭을 잡고 그 안에서만 동시성 쓰기를 하면 된다.
소괄호에 들어가는 인자가 lock을 잡는 기준값인데, 보통 this를 넣어서 저 객체 자체에 대해서만 보장한다. 애초에 synchronized method도 synchronized(this)가 내부 동작이다.

synchronized의 문제

synchronized가 간단하고 사용이 편리하긴 하지만, 단점도 많다.
이건 정말 아주 단순한 사용사례에서만 쓸만하고, 최적화가 필요한 영역에서는 한계가 크다.

가장 큰 문제는 Lock을 잡는 범위를 세밀하게 조절할 수 없다는 것이다.
그래서 해당 객체에 별개의 흐름을 갖는 동기화 포인트가 2개 이상 있을 경우에는 유연하게 처리를 할 수가 없다.

게다가 다른 Lock 구현체가 제공하는 lock 타임아웃, 공정성 처리, 디버깅 수준에서 부족한 부분이 많다.

ReentrantLock을 통한 명시적 Lock

ReentrantLock은 Java의 대표적인 Lock 구현체 중 하나다.
쉽게 말하면 그냥 Mutex 구현인데, 그 외에도 자잘한 기능들이 조금 붙어있다.

한번 성능비교를 해보면서 ReentrantLock이 적절한 경우를 예로 들어보겠다.

이번 객체에는 2개의 공유 변수가 있고, 각각의 증가를 처리하는 함수를 만들었다.

그리고 스레드 잔뜩 띄워서 돌리면,

package org.example;

class SharedObject {
    public int a_count = 0;
    public int b_count = 0;

    public synchronized void increment_a() {
        a_count++;
    }

    public synchronized void increment_b() {
        b_count++;
    }
}

public class Main {
    public static void main(String[] args) {
         var shared = new SharedObject();

         var start = System.currentTimeMillis();

        // 스레드를 5개 생성해서 count를 증가시킴
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> {
                for (int j = 0; j < 10000000; j++) {
                    shared.increment_a();
                    shared.increment_b();
                }
            });
            thread.start();
        }

        // 모든 스레드가 종료될 때까지 대기
        while (Thread.activeCount() > 1) {
            Thread.yield();
        }

        var end = System.currentTimeMillis();

        System.out.println("a_count: " + shared.a_count);
        System.out.println("b_count: " + shared.b_count);

        System.out.println("실행 시간: " + (end - start) + "ms");
    }
}

동작 자체는 기대한 대로 될 것이다.

근데 문제는 속도다. synchronized는 객체 전체를 잠그는 건데, 저 사용 사례에서는 굳이 전체를 잠글 필요는 없다.
a는 a대로 잠그면 되고, b는 b대로 잠그면 되는데, a에 접근하는데도 b까지 잠가버리는 문제가 발생하는 것이다.

a와 b에 대해 별도의 Lock 처리를 더하면 불필요한 Lock으로 인한 유실 시간을 줄일 수 있다.

각각의 Lock을 명시적으로 추가하고

접근 지점에 lock을 걸어준다.

그러면

package org.example;

import java.util.concurrent.locks.ReentrantLock;

class SharedObject {
    public int a_count = 0;
    public int b_count = 0;

    public ReentrantLock a_lock = new ReentrantLock();
    public ReentrantLock b_lock = new ReentrantLock();

    public void increment_a() {
        a_lock.lock();
        a_count++;
        a_lock.unlock();
    }

    public void increment_b() {
        b_lock.lock();
        b_count++;
        b_lock.unlock();
    }
}

public class Main {
    public static void main(String[] args) {
         var shared = new SharedObject();

         var start = System.currentTimeMillis();

        // 스레드를 5개 생성해서 count를 증가시킴
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> {
                for (int j = 0; j < 10000000; j++) {
                    shared.increment_a();
                    shared.increment_b();
                }
            });
            thread.start();
        }

        // 모든 스레드가 종료될 때까지 대기
        while (Thread.activeCount() > 1) {
            Thread.yield();
        }

        var end = System.currentTimeMillis();

        System.out.println("a_count: " + shared.a_count);
        System.out.println("b_count: " + shared.b_count);

        System.out.println("실행 시간: " + (end - start) + "ms");
    }
}

전에는 2초쯤 걸리던게 이제 1초 미만으로 처리되는 것을 볼 수 있다.

ReenterantLock: 공정성 (fairness)

Lock 경합이 매우 심한 상황에서는, 운이 좋지 못하다면 특정 스레드만 계속해서 Lock을 점유하지 못할 수 있다.
이런 현상을 불공정(unfair)하다고 한다.

ReenterantLock은 공정한 Lock 기능을 제공한다.
생성자에 true를 넘기면 공정 모드로 작동해서, 스레드들이 공정하게 Lock을 점유하도록 유도한다.
예를 들면, 가장 오래 기다린 스레드에게 Lock 우선순위를 주는 것이다.

단, 공정성이 반드시 보장되는 것은 아니다. 가장 오래 기다린 스레드를 선호(favor)하는 것일 뿐이다.

그리고 공정성은 공짜로 주어지는게 아니라, 추가적인 동기화나 로직이 들어가는 것이다.
그래서 기본 동작보다 훨씬 느려질 수 있다.

ReenterantLock: 재진입 가능

사실 이걸 좋은 디자인이라 할 수 있는지는 모르겠는데... synchronized와 ReenterantLock은 재진입 기능을 제공한다.
이게 무슨 말이나면, 이미 Lock을 잡은 스레드가 Lock을 중복해서 또 잡을 수 있다는 말이다.

그래서 이래도 잘 동작한다.

근데 이런 코드를 좋은 코드라고 할 수 있을지는 잘 모르겠다.

ReentrantLock: timeout 기반 Lock

기존의 Lock 기능들은 Lock을 점유할 때까지 하염없이 기다린다.
근데 경우에 따라서는 당장 Lock을 점유할 수 없다면 다른 작업을 더 처리하도록 구현을 하는게 처리량 측면에서 유리한 상황이 있을 수도 있다.

tryLock을 사용하면 Lock을 잡다가 timeout이 지나면 포기하고 나오도록 할 수 있다.

그리고 Lock을 잡는데 성공한다면 tryLock은 true를 반환한다.

ReentrantReadWriteLock를 통한 Lock

ReentrantReadWriteLock은 다른 언어의 Read-Write-Mutex와 동등한 Lock 구현체다.

ReentrantLock에는 조금 성능적인 단점이 있다.
읽기 비중이 매우 높은 경우에는 Lock으로 인한 성능 손실이 꽤 커질 수 있다는 것이다.

그런데 알다시피, read에 대한 동기화는 write에 비하면 꽤 저렴하다. 읽기를 하는데 write 수준의 Lock을 항상 걸 필요는 없는 것이다.

그래서 ReadWriteLock은 read와 write에 대한 Lock을 2단계로 제어하는 Lock이다. 이를 통해 read 부하가 높은 경우에는 일반 ReentrantLock보다 나은 성능을 기대할 수 있다.

기본적인 사용 원리는 크게 다르지 않다.

대신

writeLock과

readLock을 명시적으로 걸 수 있다.

writeLock을 걸면 다른 writeLock과 readLock이 모두 차단되지만, readLock은 다른 Lock을 차단하지 않는다.
어차피 writeLock을 많이 건다면 ReentrantLock만 쓰는게 더 단순하고 성능이 잘 나올 수도 있다.

StampedLock를 통한 Lock

StampedLock는 ReentrantReadWriteLock의 조금 더 낙관적인 버전이다.
스레드의 재진입을 허용하지 않는다.
그리고 write lock이 잡혀있는 상태라도 read lock을 느슨하게 잡을 수 있다는게 특징이다.

초기화 방법은 크게 다를게 없고

write Lock을 잡는 것도 ReentrantReadWriteLock와 크게 다르지 않다.

다른건 Read Lock을 잡는 부분이다.
Read Lock을 잡을때는 tryOptimisticRead을 주로 사용하는데, 이건 write lock이 잡혀있든 말든 일단 가져온다.

근데 당연히 write가 불완전하게 처리된 상황에서는 애매한 값이나 옛날 값을 참조할 수도 있다.

여기서 핵심은 lock.validate를 사용해서 스탬프 값 기반으로 검증을 할 수 있는 것이다.
검증에 실패한다면 그제서야 readLock으로 Lock을 대기하고 최신 값을 처리하게 하면 되고, 검증에 성공한다면 그대로 써도 된다.

참조
https://velog.io/@may_yun/JAVA-synchronized-VS-Reentrant-Lock-%EC%B0%A8%EC%9D%B4%EC%A0%90
https://stackoverflow.com/questions/60903107/understanding-fair-reentrantlock-in-java
https://stackoverflow.com/questions/57809112/reentrantlock-vs-reentrantreadwritelock
https://stackoverflow.com/questions/26094200/what-is-stampedlock-in-java
https://stackoverflow.com/questions/55766479/how-to-to-use-stampedlock-optimistic-locking-i-cant-understand-code-sample-fr