동시성 문제 및 Java에서의 해결방법

wontaekoh·2024년 9월 29일

항해 플러스

목록 보기

1/7

멀티 스레드 환경에서는 여러 사용자가 동시에 동일한 데이터에 접근하거나 수정할 때 다양한 동시성 문제가 발생할 수 있습니다. 이 프로젝트에서는 자바에서 발생할 수 있는 대표적인 동시성 문제를 정의하고, 이를 해결하기 위한 다양한 동시성 제어 기법을 소개합니다. 또한, 자바에서 제공하는 다양한 동기화 방법을 활용해 동시성 문제를 해결하고 테스트하는 방법에 대해 설명합니다.

GitHub 소스 코드 : https://github.com/onetaek/test-driven-development

📌 동시성 문제 정의 및 유형

1. Lost Update (갱신 손실)

설명: 두 트랜잭션이 동시에 같은 데이터를 수정할 때, 한 트랜잭션의 수정 사항이 다른 트랜잭션에 의해 덮어쓰여지는 문제입니다. 이 문제는 서로 다른 스레드가 동일한 데이터를 조회하고 수정할 때 발생합니다.
예시: 두 개의 스레드가 같은 사용자의 포인트를 조회한 후 동시에 업데이트를 실행하면, 마지막으로 완료된 스레드의 작업만 적용됩니다. 예를 들어, 사용자 포인트가 1000인 상황에서 스레드 A와 스레드는 500포인트, B는 300 포인트를 충전하려 할 때, 마지막에 완료된 작업에 따라 포인트가 1300으로 기록되고 나머지 충전 작업은 사라질 수 있습니다.

2. Dirty Read (오손 읽기)

설명: 아직 커밋되지 않은 트랜잭션의 데이터를 다른 트랜잭션이 읽는 경우 발생하는 문제입니다. 이 문제는 데이터가 확정되지 않았음에도 다른 트랜잭션이 중간 값을 참조하게 되어 발생합니다.
예시: 트랜잭션 A가 사용자 포인트를 1000에서 1500으로 수정했으나 아직 커밋하지 않은 상황에서, 트랜잭션 B가 이 중간 상태의 데이터를 읽어가면 문제가 발생할 수 있습니다. 만약 트랜잭션 A가 롤백된다면, 트랜잭션 B가 잘못된 데이터를 기반으로 작업을 수행하게 됩니다.

3. Non-Repeatable Read (반복 불가능한 읽기)

설명: 한 트랜잭션 내에서 같은 데이터를 두 번 읽었을 때 다른 결과를 얻는 문제입니다. 이 문제는 한 트랜잭션에서 데이터를 읽고 있을 때, 다른 트랜잭션이 데이터를 수정하는 경우 발생합니다.
예시: 트랜잭션 A가 사용자의 포인트를 처음 조회했을 때 1000을 얻고 500 포인트를 충전하고, 이후에 다른 트랜잭션 B가 포인트를 1800으로 수정한 후 커밋한 경우, 트랜잭션 A가 다시 포인트를 조회하면 1800이 됩니다. 이처럼 같은 트랜잭션 내에서 동일 데이터를 두 번 읽었지만 서로 다른 값을 얻게 되어 일관성이 깨질 수 있습니다.

4. Phantom Read (유령 읽기)

설명: 한 트랜잭션 내에서 동일한 쿼리를 여러 번 수행했을 때, 중간에 다른 트랜잭션이 데이터를 추가하거나 삭제하여 결과가 달라지는 문제입니다.
예시: 트랜잭션 A가 500을 충전 후 충전 이력을 조회를 했고, 이후 트랜잭션 B가 새로운 사용자에 포인트를 1500으로 삽입하면, 트랜잭션 A가 동일한 조건으로 다시 조회할 때 새로운 충전 이력이 추가된 것을 볼 수 있습니다. 이는 처음 조회와 다른 결과를 유발합니다.

📌 자바에서의 동시성 문제 해결 방법

자바에서는 위에서 설명한 동시성 문제를 해결하기 위해 다양한 동기화 기법을 제공합니다. 아래는 자바에서 이러한 동시성 문제를 해결하기 위해 사용되는 대표적인 기법들입니다.

1. synchronized 키워드

synchronized는 자바의 가장 기본적인 동기화 방법입니다. 메서드 전체 혹은 특정 블록을 동기화하여 한 번에 하나의 스레드만 접근할 수 있도록 합니다.

해결하는 문제: Lost Update와 같은 문제를 방지하기 위해, 동일한 자원에 대해 접근을 제한합니다.

public synchronized void charge(long amount) {
    // 로직 생략
}

2. ReentrantLock

ReentrantLock은 synchronized보다 유연한 동기화 방법을 제공합니다. 명시적으로 락을 획득하고 해제해야 하며, 타임아웃 설정과 같은 추가 기능을 제공합니다.

해결하는 문제: Lost Update, Dirty Read, Non-Repeatable Read 문제 해결에 유용합니다.

private final Lock lock = new ReentrantLock();

public void use(long amount) {
    lock.lock();
    try {
        // 로직 생략
    } finally {
        lock.unlock();
    }
}

3. ConcurrentHashMap

ConcurrentHashMap은 동시성에 안전한 해시맵을 제공하여, 자원을 효율적으로 관리합니다. 이를 통해 특정 키에 대한 접근만 동기화할 수 있습니다.

해결하는 문제: 여러 사용자가 동시에 다른 데이터를 접근할 때 발생하는 성능 문제를 줄이고, 특정 사용자에 대해서만 동기화할 수 있습니다.

private final ConcurrentHashMap<Long, Lock> userLocks = new ConcurrentHashMap<>();

public void charge(long userId, long amount) {
    Lock lock = userLocks.computeIfAbsent(userId, k -> new ReentrantLock());
    lock.lock();
    try {
        // 로직 생량
    } finally {
        lock.unlock();
    }
}

4. Atomic 클래스

자바의 java.util.concurrent.atomic 패키지에는 원자적 연산을 제공하는 AtomicInteger, AtomicLong 등의 클래스가 포함되어 있습니다. 이들은 원자적 CAS(Compare-And-Swap) 연산을 통해 동시성 문제를 해결합니다.

해결하는 문제: Lost Update, Dirty Read 문제를 방지합니다.
코드 예시:

private final AtomicLong point = new AtomicLong(0);

public void charge(long amount) {
    point.addAndGet(amount);
}

public void use(long amount) {
    /// 로직 생략
}

5. volatile 키워드

volatile 키워드는 변수에 대한 모든 읽기와 쓰기 작업이 메인 메모리에서 수행되도록 보장하여, 가시성 문제를 해결합니다. 여러 스레드가 동일한 변수를 읽고 쓸 때, 각 스레드가 변수의 최신 값을 즉시 반영할 수 있도록 합니다. 하지만 volatile은 원자성(Atomicity)을 보장하지 않으므로, 복합적인 읽기-수정-쓰기 작업에서 발생하는 동시성 문제를 완전히 해결하지 못합니다. 따라서, volatile은 단순한 상태 플래그와 같은 변수에 유용하게 사용됩니다.

private volatile boolean isActive = true;

public void runTask() {
    while (isActive) {
    	// 로직 생략
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

public void deactivate() {
    isActive = false;
}

public boolean isActive() {
    return isActive;
}

6. ExecutorService와 Semaphore

ExecutorService는 스레드 풀을 관리하여 효율적인 스레드 사용을 가능하게 하고, 작업 제출 및 제어 기능을 제공합니다. Semaphore는 특정 자원에 대한 접근을 제한하여 제한된 수의 스레드만 자원에 접근할 수 있도록 합니다.

private final Semaphore semaphore = new Semaphore(3);

public void accessResource() throws InterruptedException {
    semaphore.acquire(); // 최대 3개의 스레드만 접근 가능
    try {
        // 로직 생략
    } finally {
        semaphore.release(); // 접근 후 자원을 해제
    }
}

위 코드에서 Semaphore는 동시에 3개의 스레드만 자원에 접근할 수 있도록 합니다. acquire() 메서드를 호출하여 접근 권한을 얻고, 작업이 끝나면 release()를 호출하여 접근 권한을 반환합니다. 이렇게 하면 동시 접근 제한을 통해 성능을 최적화하고, 불필요한 자원 경합을 방지할 수 있습니다.

7. StampedLock

StampedLock은 ReentrantReadWriteLock보다 더 높은 성능을 제공하며, 특히 읽기 위주의 상황에서 효율적입니다. StampedLock은 Optimistic Read 기능을 제공하여, 락의 경쟁을 줄이고 더 높은 성능을 구현할 수 있습니다.

private final StampedLock lock = new StampedLock();
private long point = 0;

public long readPoint() {
    long stamp = lock.tryOptimisticRead();
    long currentPoint = point;
    if (!lock.validate(stamp)) { // 다른 스레드에 의해 수정이 이루어졌는지 확인
        stamp = lock.readLock(); // 읽기 락 획득
        try {
            // 로직 생략
        } finally {
            lock.unlockRead(stamp); // 읽기 락 해제
        }
    }
    return currentPoint;
}

public void charge(long amount) {
    long stamp = lock.writeLock(); // 쓰기 락 획득
    try {
        // 로직 생략
    } finally {
        lock.unlockWrite(stamp); // 쓰기 락 해제
    }
}

StampedLock을 사용하면 Optimistic Read 기능을 통해 락을 걸지 않고 먼저 값을 읽은 후, 다른 스레드가 데이터를 수정했는지 확인할 수 있습니다. 만약 데이터가 변경되지 않았다면 락을 걸 필요 없이 읽기 작업을 완료하고, 변경된 경우에는 읽기 락을 획득하여 안전하게 읽습니다.

8. ReentrantReadWriteLock

ReentrantReadWriteLock은 읽기-쓰기 락을 제공하여 읽기 작업과 쓰기 작업 간의 동시성을 최적화하는 락입니다. 읽기 작업이 많은 경우, 여러 스레드가 동시에 읽기 락을 획득하여 읽기 작업을 병렬로 수행할 수 있습니다.

private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
private final ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
private final ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
private long point = 0;

public long readPoint() {
    readLock.lock(); // 읽기 락 획득
    try {
        // 로직 생략
    } finally {
        readLock.unlock(); // 읽기 락 해제
    }
}

public void charge(long amount) {
    writeLock.lock(); // 쓰기 락 획득
    try {
        // 로직 생략
    } finally {
        writeLock.unlock(); // 쓰기 락 해제
    }
}

ReentrantReadWriteLock을 사용하면, 여러 스레드가 동시에 읽기 락을 획득하여 읽기 작업을 병렬로 수행할 수 있습니다. 반면에 쓰기 락은 단독으로만 획득할 수 있어, 읽기-쓰기 충돌을 방지합니다.

📌 왜 `ConcurrentHashMap`과 `ReentrantLock`을 사용했는가?

이번 프로젝트에서는 포인트 충전 및 사용에 대한 동시성 문제를 해결하기 위해 ConcurrentHashMap과 ReentrantLock을 사용했습니다. 처음에는 synchronized를 사용했지만 성능 문제로 인해 최적화된 방법을 찾게 되었습니다.

1. 초기에는 synchronized를 사용(bad case)

처음 동시성 문제를 해결하기 위해 작성한 코드는 synchronized를 사용한 것이었습니다.

🔡 synchronized 를 사용한 코드

public synchronized UserPoint chargeSync(long id, long amount) {
	// 로직 생략
}

public synchronized UserPoint useSync(long id, long amount) {
	// 로직 생략
}

🚫 문제점

synchronized를 사용하여 포인트 충전 및 사용 로직을 동기화하면, 충전 및 사용 요청에 대해 동시성 문제가 해결되긴 합니다.
하지만 synchronized를 사용하면 모든 스레드에 대해 해당 메서드에 락이 걸리게 되므로, 한 사용자의 포인트 충전/사용 작업이 다른 사용자의 작업도 차단하게 됩니다.
충전과 사용은 각 사용자끼리만 동시성을 제어하면 되는데, synchronized는 모든 사용자에 대해 락을 걸기 때문에 병렬 처리 성능이 크게 저하됩니다.

🔍 성능 문제 발생

모든 요청에 대해 전역적인 락을 사용하므로, 성능이 매우 저하되고, 확장성이 떨어집니다.
사용자가 많아질수록, 스레드가 대기해야 하는 시간이 길어지고, 응답 속도가 늦어지는 문제를 유발했습니다.

2. ConcurrentHashMap 과 ReentrantLock을 사용

성능 문제를 해결하기 위해 ConcurrentHashMap과 ReentrantLock을 사용하여 사용자별로 동시성을 제어하도록 개선했습니다.

🔡 개선된 코드


private static final ConcurrentHashMap<Long, Lock> userLocks = new ConcurrentHashMap<>();

public UserPoint charge(long id, long amount) {
    Lock lock = getLockForUser(id);
    lock.lock();
    try {
        /// 로직 생략
    } finally {
        lock.unlock();
    }
}

private Lock getLockForUser(long id) {
    return userLocks.computeIfAbsent(id, key -> new ReentrantLock());
}

✅ 개선된 부분

ConcurrentHashMap: 사용자별로 Lock 객체를 관리하기 위해 사용했습니다. 각 사용자에 대해 고유한 Lock 객체를 할당하여, 각 사용자의 충전 및 사용 요청이 서로 충돌하지 않도록 보장했습니다.
- 이렇게 하면 사용자별로 별도의 락을 관리하므로, 동시 접근이 가능해져 성능이 크게 향상됩니다.
ReentrantLock: ReentrantLock을 사용해 명시적으로 락을 획득하고, 작업이 끝난 후에 반드시 락을 해제하도록 하였습니다. synchronized보다 세밀한 락 제어가 가능하고, 특정 상황에서 락 해제를 더 확실하게 보장할 수 있습니다.
- 각 사용자의 포인트를 충전하거나 사용할 때만 해당 사용자에 대한 락을 걸기 때문에, 동일한 사용자에 대해서만 락 경쟁이 발생하고, 다른 사용자의 작업은 병렬로 처리될 수 있습니다.

📌 테스트 결과 비교

1. synchronized 사용 시 (Bad Case)

테스트 환경: 100명의 사용자가 각각 포인트 충전과 포인트 사용 작업을 20회씩 실행.
결과: 2분 43초 소요

모든 요청에 대해 전역적으로 락을 사용하다 보니 대기 시간이 길어짐.

동시 처리 능력이 낮아지고, 병목 현상이 발생하여 성능이 매우 저하됨.

2. ConcurrentHashMap과 ReentrantLock 사용 시 (Good Case)

테스트 환경: 100명의 사용자가 각각 포인트 충전과 포인트 사용 작업을 20회씩 실행.
결과: 17초 소요

각 사용자의 포인트에 대해 별도의 락을 사용하여, 병렬 처리 능력이 크게 향상됨.

락 경쟁이 줄어들고, 다른 사용자의 작업은 독립적으로 수행되기 때문에 성능이 크게 개선됨.

🔍 결과 분석

synchronized는 간단한 구현으로 동시성 문제를 해결할 수 있지만, 모든 스레드에 대한 전역 락을 걸기 때문에, 병렬 처리가 불가능하며, 성능이 저하됩니다.
반면에, ConcurrentHashMap과 ReentrantLock을 사용하면 사용자별로 별도의 락을 할당하여 병렬 처리 성능을 높이고, 불필요한 대기를 줄일 수 있었습니다. 이로 인해 성능이 훨씬 우수한 결과를 얻을 수 있었습니다.

wontaekoh

주니어 백엔드 개발자, 오원택입니다!

다음 포스트

동시성 문제 및 Java에서의 해결방법

항해 플러스

📌 동시성 문제 정의 및 유형

1. Lost Update (갱신 손실)

2. Dirty Read (오손 읽기)

3. Non-Repeatable Read (반복 불가능한 읽기)

4. Phantom Read (유령 읽기)

📌 자바에서의 동시성 문제 해결 방법

1. synchronized 키워드

2. ReentrantLock

3. ConcurrentHashMap

4. Atomic 클래스

5. volatile 키워드

6. ExecutorService와 Semaphore

7. StampedLock

8. ReentrantReadWriteLock

📌 왜 `ConcurrentHashMap`과 `ReentrantLock`을 사용했는가?

1. 초기에는 synchronized를 사용(bad case)

🔡 synchronized 를 사용한 코드

🚫 문제점

🔍 성능 문제 발생

2. ConcurrentHashMap 과 ReentrantLock을 사용

🔡 개선된 코드

✅ 개선된 부분

📌 테스트 결과 비교

1. synchronized 사용 시 (Bad Case)

2. ConcurrentHashMap과 ReentrantLock 사용 시 (Good Case)

🔍 결과 분석

API First Design(Open API CodeGenerator를 활용)

0개의 댓글

동시성 문제 및 Java에서의 해결방법

항해 플러스

📌 동시성 문제 정의 및 유형

1. Lost Update (갱신 손실)

2. Dirty Read (오손 읽기)

3. Non-Repeatable Read (반복 불가능한 읽기)

4. Phantom Read (유령 읽기)

📌 자바에서의 동시성 문제 해결 방법

1. synchronized 키워드

2. ReentrantLock

3. ConcurrentHashMap

4. Atomic 클래스

5. volatile 키워드

6. ExecutorService와 Semaphore

7. StampedLock

8. ReentrantReadWriteLock

📌 왜 ConcurrentHashMap과 ReentrantLock을 사용했는가?

1. 초기에는 synchronized를 사용(bad case)

🔡 synchronized 를 사용한 코드

🚫 문제점

🔍 성능 문제 발생

2. ConcurrentHashMap 과 ReentrantLock을 사용

🔡 개선된 코드

✅ 개선된 부분

📌 테스트 결과 비교

1. synchronized 사용 시 (Bad Case)

2. ConcurrentHashMap과 ReentrantLock 사용 시 (Good Case)

🔍 결과 분석

API First Design(Open API CodeGenerator를 활용)

0개의 댓글

📌 왜 `ConcurrentHashMap`과 `ReentrantLock`을 사용했는가?