본문 바로가기
Java Spring

ReentrantReadWriteLock vs ReentrantLock

by Bill Lab 2024. 12. 21.
728x90

Java의 ReentrantReadWriteLock과 ReentrantLock에 대한 비교분석 글을 작성해보려한다.

( JDK 5.0 이상에서 Java 동시성 유틸리티의 일부로 제공되고 있으며, 둘다 나온지가 상당히 오래되서 다들 잘알겠지만...)

 

우선 결혼만 이야기하면 둘다 쓰레드를  기반으로한 Lock 제어 방식으로, DB나 분산락, MQ로 동시성제어 외에

Lock 이 필요할 경우 사용하면 된다.

 

두개의 가장 큰 차이는 Data 정합성 측면과, Reading 이 많냐? Writing이 많냐? 의 상황 이 두가지일 것이다.

 

1. Data 정합성 측면

    : 절대적으로 정합성이 보장되어야하면, ReentrantLock 사용이 필요하다.

      (한번에, 오직 하나의 쓰레드만 락획득이 가능하기 때문이다.)

 

2. Reading 보다 Writing 이 많을경우

     : 이경우도 ReentrantLock 을 사용해야 한다.

    

 

3. Writing 보다 Reading이 많을 경우

     : ReentrantReadWriteLock 을 사용해서 한번에, 여러 쓰레드에서 각각의 락을 제어해서 사용하도록 하자

     1) 동시에 여러개의 쓰레드에서 lock 을 획득할 수 있기때문에, 처리속도가 빨라진다.

     2) Lock Downgrade 허용(write lock을 획득한 "다음" read lock을 위해 해제하는 프로세스)

     3) Lock Upgrade 허용(read lock을 획득한 "다음" write lock을 위해 해제하는 프로세스)

     4) Write Lock 해제 시 Read Lock 요청이 있을경우 바로 lock 획득(우선순위 증가)

         (단, Write Lock 의 요청에는 모든 쓰레드의 Lock이 해제될 때까지 대기)

 

 

ReentrantReadWriteLock 예제소스로는...

 

import java.util.concurrent.locks.ReentrantReadWriteLock;

public class LockExample {

    private static final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

    public void readLock() {
        lock.readLock().lock();
        try {
            //business logic
        } finally {
            lock.readLock().unlock();
        }
    }

    public void writeLock() {
        lock.writeLock().lock();
        try {
            //business logic
        } finally {
            lock.writeLock().unlock();
        }
    }
}































728x90