멀티스레드 Part.11 동시성 컬렉션

cwchoiit 2024. 7. 27. 15:31

2024. 7. 27. 15:31

728x90

SMALL

참고자료:

김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성 강의 | 김영한 - 인프런

김영한 | 멀티스레드와 동시성을 기초부터 실무 레벨까지 깊이있게 학습합니다., 국내 개발 분야 누적 수강생 1위, 제대로 만든 김영한의 실전 자바[사진][임베딩 영상]단순히 자바 문법을 안다?

www.inflearn.com

동시성 컬렉션이 필요한 이유

java.util 패키지에 있는 컬렉션 프레임워크는 원자적 연산을 제공할까? 예를 들어 하나의 ArrayList 인스턴스에 여러 스레드가 동시에 접근해도 괜찮을까? 참고로 여러 스레드가 동시에 접근해도 괜찮은 경우를 스레드 세이프(Thread Safe)하다고 한다. 그렇다면 ArrayList는 스레드 세이프 할까?

컬렉션에 데이터를 추가하는 add() 메서드를 생각해보면, 단순히 컬렉션에 데이터를 하나 추가하는 것 뿐이다. 따라서 이것은 마치 연산이 하나만 있는 원자적인 연산처럼 느껴진다. 원자적 연산은 쪼갤 수 없기 때문에 멀티스레드 상황에 문제가 되지 않는다. 물론 멀티스레드는 중간에 스레드의 실행 순서가 변경될 수 있으므로 [A, B] 또는 [B, A]로 데이터의 저장 순서는 변경될 수 있지만 결과적으로 데이터는 모두 안전하게 저장될 것 같다.

하지만, 컬렉션 프레임워크가 제공하는 대부분의 연산은 원자적인 연산이 아니다.

컬렉션을 아주 간단하게 직접 만들어보자.

SimpleList

package thread.collections.simple.list;

public interface SimpleList {
    int size();

    void add(Object o);

    Object get(int index);
}

직접 만들 컬렉션의 인터페이스이다.
크기 조회, 데이터 추가, 데이터 조회의 3가지 메서드만 가진다.

BasicList

package thread.collections.simple.list;

import java.util.Arrays;

import static util.ThreadUtils.sleep;

public class BasicList implements SimpleList {

    private static final int DEFAULT_CAPACITY = 5;
    private Object[] elements;
    private int size = 0;

    public BasicList() {
        elements = new Object[DEFAULT_CAPACITY];
    }

    @Override
    public int size() {
        return size;
    }

    @Override
    public void add(Object o) {
        elements[size] = o;
        sleep(100); // 멀티 스레드 문제를 쉽게 확인하는 코드
        size++;
    }

    @Override
    public Object get(int index) {
        return elements[index];
    }

    @Override
    public String toString() {
        return Arrays.toString(Arrays.copyOf(elements, size)) + ", size = " + size + ", capacity = " + elements.length;
    }
}

가장 간단한 컬렉션의 구현이다. 내부에서는 배열을 사용해서 데이터를 보관한다.
ArrayList의 최소 구현 버전이라 생각하면 된다.
DEFAULT_CAPACITY: 최대 5개의 데이터를 저장할 수 있다.
size: 저장한 데이터의 크기를 나타낸다.
add(): 컬렉션에 데이터를 추가한다.
- sleep(100): 잠시 대기한다. 이렇게 하면 멀티스레드 상황에 발생하는 문제를 확인하기 쉽다.

일단은 단일 스레드로 잘 동작하는지 확인해보자.

SimpleListMainV1

package thread.collections.simple;

import thread.collections.simple.list.BasicList;
import thread.collections.simple.list.SimpleList;

public class SimpleListMainV1 {

    public static void main(String[] args) {
        SimpleList basicList = new BasicList();
        basicList.add("A");
        basicList.add("B");

        System.out.println("basicList = " + basicList);
    }
}

실행 결과

basicList = [A, B], size = 2, capacity = 5

단일 스레드로 실행했기 때문에 전혀 문제 없이 잘 동작한다. 이제 멀티 스레드로 이 자료구조에 데이터를 추가해보자!

SimpleListMainV2

package thread.collections.simple;

import thread.collections.simple.list.BasicList;
import thread.collections.simple.list.SimpleList;

import static util.MyLogger.log;

public class SimpleListMainV2 {


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

    private static void test(SimpleList list) throws InterruptedException {
        log(list.getClass().getSimpleName());

        Runnable addA = new Runnable() {
            @Override
            public void run() {
                list.add("A");
                log("Thread-1: list.add(A)");
            }
        };

        Runnable addB = new Runnable() {
            @Override
            public void run() {
                list.add("B");
                log("Thread-2: list.add(B)");
            }
        };

        Thread thread1 = new Thread(addA, "Thread-1");
        Thread thread2 = new Thread(addB, "Thread-2");

        thread1.start();
        thread2.start();

        thread1.join();
        thread2.join();

        log(list);
    }
}

실행 결과

2024-07-27 20:08:37.266 [     main] BasicList
2024-07-27 20:08:37.371 [ Thread-1] Thread-1: list.add(A)
2024-07-27 20:08:37.371 [ Thread-2] Thread-2: list.add(B)
2024-07-27 20:08:37.371 [     main] [B, null], size = 2, capacity = 5

실행 결과를 보면, size는 2인데, 데이터는 B 하나만 입력되어 있다. 어떻게 된 것일까?

참고로, 어떤 스레드가 먼저 실행됐냐에 따라 [A, null]이 결과가 될 수 있다.

@Override
public void add(Object o) {
    elements[size] = o;
    sleep(100); // 멀티 스레드 문제를 쉽게 확인하는 코드
    size++;
}

스레드1, 스레드2가 element[size] = o; 이 코드를 동시에 수행한다. 여기서는 스레드1이 약간 빠르게 수행했다.

스레드1 수행: element[0] = A, element[0]의 값은 A가 된다.
스레드2 수행: element[0] = B, element[0]의 값은 A → B가 된다.
결과적으로 element[0]의 값은 B가 된다.

스레드1, 스레드2가 sleep()에서 잠시 대기한다. 여기서 sleep()을 사용한 이유는 동시성 문제를 쉽게 확인하기 위해서다. 이 코드를 제거하면 size++이 너무 빨리 호출되기 때문에 스레드1이 add()메서드를 완전히 수행하고 나서 스레드2가 add()메서드를 수행할 가능성이 높다. 당연한 이야기지만 sleep() 코드를 제거해도 멀티스레드 동시성 문제는 여전히 발생하고 있다. (확률을 더 높였을 뿐이다)

결론은 무엇이냐면 컬렉션 프레임워크 대부분은 스레드 세이프 하지 않다는 것이다.

우리가 일반적으로 자주 사용하는 ArrayList, LinkedList, HashSet, HashMap 등 수 많은 자료 구조들은 단순한 연산을 제공하는 것처럼 보인다. 예를 들어, 데이터를 추가하는 add()와 같은 연산은 마치 원자적 연산처럼 느껴진다. 하지만 그 내부에서는 수 많은 연산들이 함께 사용된다. 배열에 데이터를 추가하고, 사이즈를 변경하고, 배열을 새로 만들어서 배열의 크기도 늘리고, 노드를 만들어서 링크에 연결하는 등 수 많은 복잡한 연산이 함께 사용된다.

따라서, 일반적인 컬렉션들은 절대로! 스레드 세이프 하지 않다!

단일 스레드가 컬렉션에 접근하는 경우라면 아무런 문제가 되지 않지만, 멀티 스레드 상황에서 여러 스레드가 동시에 컬렉션에 접근하는 경우라면 java.util 패키지가 제공하는 일반적인 컬렉션들은 사용하면 안된다. (물론 일부 예외도 있다. 뒤에서 알아보자.)

동시성 컬렉션이 필요한 이유

컬렉션이 수많은 복잡한 연산으로 이루어져 있기 때문이다. 따라서 여러 스레드가 접근해야 한다면 synchronized, Lock등을 통해 안전한 임계 영역을 적절히 만들면 문제를 해결할 수 있다.

SyncList

package thread.collections.simple.list;

import java.util.Arrays;

import static util.ThreadUtils.sleep;

public class SyncList implements SimpleList {

    private static final int DEFAULT_CAPACITY = 5;
    private Object[] elements;
    private int size = 0;

    public SyncList() {
        elements = new Object[DEFAULT_CAPACITY];
    }

    @Override
    public synchronized int size() {
        return size;
    }

    @Override
    public synchronized void add(Object o) {
        elements[size] = o;
        sleep(100); // 멀티 스레드 문제를 쉽게 확인하는 코드
        size++;
    }

    @Override
    public synchronized Object get(int index) {
        return elements[index];
    }

    @Override
    public synchronized String toString() {
        return Arrays.toString(Arrays.copyOf(elements, size)) + ", size = " + size + ", capacity = " + elements.length;
    }
}

앞서 만든 BasicList를 복사해서 만든 SyncList에 synchronized 키워드만 추가했다.
모든 메서드가 동기화 되어 있으므로 멀티스레드 상황에 안전하게 사용할 수 있다.

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

BaiscList를 사용하는 코드 대신 SyncList를 사용하는 코드로 바꾸고 실행해보자.

실행 결과

2024-07-27 20:25:25.349 [     main] SyncList
2024-07-27 20:25:25.454 [ Thread-1] Thread-1: list.add(A)
2024-07-27 20:25:25.555 [ Thread-2] Thread-2: list.add(B)
2024-07-27 20:25:25.555 [     main] [A, B], size = 2, capacity = 5

아주 아주 잘 실행됐다. 이제 동시에 여러 스레드가 접근하더라도 걱정없이 사용할 수 있다. 근데! 문제가 있다.

BasicList 코드가 있는데, 이 코드를 거의 그대로 복사해서 synchronized 기능만 추가한 SyncList를 만들었다. 하지만 이렇게 되면 모든 컬렉션을 다 복사해서 동기화 용으로 새로 구현해야 한다. 이게 매우 비효율적이다.

프록시 도입

위에서 말한 문제를 다시 상기해보면, 고작 synchronized 키워드 하나를 추가하기 위해 같은 코드를 복사해서 새로운 클래스를 만들어내야 한다는 점이다. 그럼 다른 자료구조를 사용한다고 하면 그것 역시 또 새로운 클래스를 만들어야 한다. 즉, 단일 스레드용 클래스와 멀티 스레드용 클래스가 나뉘어진다는 점이다. 다음과 같이 말이다.

ArrayList → SyncArrayList
LinkedList → SyncLinkedList

원하는건 기존 코드를 그대로 사용하되 synchronized 기능만 살짝 추가하고 싶은 것이다. 이럴때 프록시를 사용하면 좋다.

프록시(Proxy)

대리자, 대체자라는 뜻으로 스프링에서도 굉장히 자주 등장하고 많이 사용된다. 요청을 하는 클라이언트와 요청을 받는 서버가 원래는 이런 형태였다면,

클라이언트 → 서버

다음과 같은 형태로 변형되는 것이다.

클라이언트 → 프록시 → 서버

중요한건 이렇게 변경이 되어도 클라이언트 코드는 바꿀게 하나도 없다는 것. 이게 바로 핵심이다.

SyncProxyList

package thread.collections.simple.list;

public class SyncProxyList implements SimpleList {

    private SimpleList target;

    public SyncProxyList(SimpleList target) {
        this.target = target;
    }

    @Override
    public synchronized int size() {
        return target.size();
    }

    @Override
    public synchronized void add(Object o) {
        target.add(o);
    }

    @Override
    public synchronized Object get(int index) {
        return target.get(index);
    }

    @Override
    public String toString() {
        return target.toString() + " by " + this.getClass().getSimpleName();
    }
}

프록시 역할을 하는 클래스이다.
SyncProxyList는 BasicList와 같은 SimpleList 인터페이스를 구현한다.
이 클래스는 생성자를 통해 SimpleList target을 주입받는다. 여기에 실제 호출되는 대상이 들어간다.
이 클래스는 빈 껍데기다. 이 클래스의 역할은 모든 메서드에 synchronized를 걸어주는 일 뿐이다. 그리고나서 target에 있는 같은 기능을 호출한다.
이 프록시 클래스는 synchronized만 걸고, 그 다음에 바로 실제 호출해야 하는 원본 대상(target)을 호출한다.

그리고 다음과 같이 호출하는 test() 메서드에 파라미터로 SyncProxyList를 던져주면 된다.

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

기존 구조: 클라이언트 → BasicList(서버)
변경 구조: 클라이언트 → SyncProxyList(프록시) → BasicList(서버)

실행 결과

2024-07-27 20:37:57.702 [     main] SyncProxyList
2024-07-27 20:37:57.807 [ Thread-1] Thread-1: list.add(A)
2024-07-27 20:37:57.908 [ Thread-2] Thread-2: list.add(B)
2024-07-27 20:37:57.908 [     main] [A, B], size = 2, capacity = 5 by SyncProxyList

실행 결과를 보면 원하는 의도에 맞게 잘 데이터가 들어간 것을 확인할 수 있다.

프록시 구조 분석

그림과 같이 정적인 클래스의 의존 관계를 정적 의존 관계라고 한다.
test() 메서드를 클라이언트라고 가정하면 test() 메서드는 SimpleList라는 인터페이스에만 의존한다. 이것을 추상화에 의존한다고 표현한다.
덕분에 SimpleList 인터페이스의 구현체인 BasicList, SyncList, SyncProxyList 중에 어떤 것을 사용하든 클라이언트인 test()의 코드는 전혀 변경하지 않아도 된다.
클라이언트인 test() 입장에서 생각해보면 BasicList가 넘어올지, SyncProxyList가 넘어올지 알 수 없다. 단순히 SimpleList의 구현체 중 하나가 넘어와서 실행된다는 정도만 알 수 있다. 그래서 클라이언트인 test()는 매우 유연하다. SimpleList의 어떤 구현체든지 다 받아들일 수 있다.

런타임 의존 관계 - BasicList

먼저 BasicList를 사용하는 예를 보자.

그림과 같이 실제 런타임에 발생하는 인스턴스의 의존 관계를 런타임 의존 관계라 한다. 먼저 간단한 BasicList를 직접 사용하는 경우부터 알아보자.

test(new BasicList())를 실행하면 BasicList(x001)의 인스턴스가 만들어지면서 test() 메서드에 전달된다.
test() 메서드는 BasicList(x001) 인스턴스의 참조를 알고 사용하게 된다.
- test(SimpleList list = x001)

test() 메서드에서 스레드를 만들고, 스레드에 있는 run()에서 list.add()를 호출한다.
그림은 간단하게 test()에서 호출하는 것으로 표현하겠다.
BasicList(x001) 인스턴스에 있는 add()가 호출된다.

런타임 의존 관계 - SyncProxyList

이번엔 BasicList가 아니라 SyncProxyList를 사용하는 예를 보자.

test(new SyncProxyList(new BasicList()));
- 먼저 BasicList(x001) 인스턴스가 만들어진다.
- 앞서 만든 BasicList(x001)의 참조를 SyncProxyList의 생성자에 전달하여 SyncProxyList(x002)가 만들어진다.
- 내부에는 원본 대상을 가르키는 target 변수를 포함하고 있다. 이 변수는 BasicList(x001)의 참조를 보관한다.
- test() 메서드는 SyncProxyList(x002) 인스턴스를 사용하게 된다.

SyncProxyList - add() 호출 과정

test() 메서드에서 스레드를 만들고, 스레드에 있는 run()에서 list.add()를 호출한다.
- SyncProxyList(x002)에 있는 add()가 호출된다.
- 그림은 간단하게 test()에서 호출하는 것으로 표현하겠다.
프록시인 SyncProxyList는 synchronized를 적용한다. 그리고 나서 target에 있는 add()를 호출한다.
원본 대상인 BasicList(x001)의 add()가 호출된다.
원본 대상의 호출이 끝나면 결과를 반환한다.
SyncProxyList에 있는 add()로 흐름이 돌아온다. 메서드를 반환하면서 synchronized를 해제한다.
test()로 흐름이 돌아온다.

프록시 정리

프록시인 SyncProxyList는 원본인 BasicList와 똑같은 SimpleList를 구현한다. 따라서 클라이언트인 test() 입장에서는 원본 구현체가 전달되든, 아니면 프록시 구현체가 전달되든 아무런 상관이 없다. 단지 수많은 SimpleList의 구현체 중 하나가 전달되었다고 생각할 뿐이다.
클라이언트 입장에서 보면 프록시는 원본과 똑같이 생겼고, 호출할 메서드도 똑같다. 단지 SimpleList의 구현체일 뿐이다.
프록시는 내부에 원본을 가지고 있다. 그래서 프록시가 필요한 일부의 일을 처리하고, 그 다음에 원본을 호출하는 구조를 만들 수 있다. 여기서 프록시는 synchronized를 통한 동기화를 적용한다.
프록시가 동기화를 적용하고 원본을 호출하기 때문에 원본 코드도 이미 동기화가 적용된 상태로 호출된다.

여기서 핵심은 원본 코드인 BasicList를 전혀 손대지 않고 프록시인 SyncProxyList를 통해 동기화 기능을 적용했다는 점이다. 또한 이후에 SimpleList를 구현한 BasicLinkedList 같은 연결 리스트를 만들더라도 서로 같은 인터페이스를 사용하기 때문에 SyncProxyList를 그대로 활용할 수 있다. 쉽게 이야기해서 SyncProxyList 프록시 하나로 SimpleList 인터페이스의 모든 구현체를 동기화 할 수 있다.

이런 프록시를 사용하는 걸 프록시 패턴이라고 하고 정말 자주 종종 사용되는 패턴이다. 특히 스프링의 AOP는 프록시의 끝판왕으로 생각하면 된다. 프록시 패턴의 주요 목적은 다음과 같다.

접근 제어: 실제 객체에 대한 접근을 제한하거나 통제할 수 있다.
성능 향상: 실제 객체의 생성을 지연시키거나 캐싱하여 성능을 최적화할 수 있다.
부가 기능 제공: 실제 객체에 추가적인 기능(로깅, 인증, 동기화 등)을 투명하게 제공할 수 있다.

그래서 자바는 어떤 동시성 컬렉션을 제공해왔을까? 알아보자!

자바 동시성 컬렉션 - synchronized

자바가 제공하는 java.util 패키지에 있는 컬렉션 프레임워크들은 대부분 스레드 안전하지 않다. 우리가 일반적으로 사용하는 ArrayList, LinkedList, HashSet, HashMap 등 수 많은 자료 구조들은 내부에서 수많은 연산들이 함께 사용된다. 그렇다면 처음부터 모든 자료 구조에 synchronized를 사용해서 동기화를 해두면 어떨까? synchronized, Lock, CAS등 모든 방식은 정도의 차이가 있지만 성능과 트레이드 오프가 있다. 결국 동기화를 사용하지 않는 것이 가장 빠르다.

그리고 컬렉션이 항상 멀티스레드에서 사용되는것도 아니다. 미리 동기화를 해둔다면 단일 스레드에서 사용할 때 동기화로 인해 성능이 저하된다. 따라서 동기화의 필요성을 정확히 판단하고 꼭 필요한 경우에만 동기화를 적용하는 것이 필요하다.

좋은 대안으로는 우리가 앞서 배운 것처럼 synchronized를 대신 적용해 주는 프록시를 만드는 방법이 있다. List, Set, Map 등 주요 인터페이스를 구현해서 synchronized를 적용할 수 있는 프록시를 만들면 된다. 이 방법을 사용하면 기존 코드를 유지하면서 필요한 경우에만 동기화를 적용할 수 있다.

자바는 컬렉션을 위한 프록시 기능을 제공한다.

SynchronizedListMain

package thread.collections.java;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class SynchronizedListMain {
    public static void main(String[] args) {
        List<String> list = Collections.synchronizedList(new ArrayList<>());
        list.add("data1");
        list.add("data2");
        list.add("data3");

        System.out.println(list.getClass());
        System.out.println("list = " + list);
    }
}

실행 결과

class java.util.Collections$SynchronizedRandomAccessList
list = [data1, data2, data3]

위에서 프록시를 직접 만들어 본 것처럼 이것도 역시 파리미터로 건네주는 자료 구조를 동기화 해주는 프록시 클래스이다.

예를 들어 이 클래스의 add() 메서드를 보면, synchronized 블록을 적용하고 그 다음에 원본 대상의 add()를 호출하는 것을 알 수 있다.

public boolean add(E e) {
    synchronized (mutex) {
        return c.add(e);
    }
}

Collections는 다음과 같이 다양한 synchronized 동기화 메서드를 지원한다. 이 메서드를 사용하면 List, Collection, Map, Set 등 다양한 동기화 프록시를 만들 수 있다.

synchronizedList()
synchronizedCollection()
synchronizedMap()
synchronizedSet()
synchronizedNavigableMap()
synchronizedNavigableSet()
synchronizedSortedMap()
synchronizedSortedSet()

Collections가 제공하는 동기화 프록시 기능 덕분에 스레드 안전하지 않은 수많은 컬렉션들을 매우 편리하게 스레드 안전한 컬렉션으로 변경해서 사용할 수 있다.

synchronized 프록시 방식의 단점

하지만 synchronized 프록시를 사용하는 방식은 다음과 같은 단점이 있다.

첫째, 동기화 오버헤드가 발생한다. 비록 synchronized 키워드가 멀티 스레드 환경에서 안전한 접근을 보장하지만, 각 메서드 호출 시마다 동기화 비용이 추가된다. 이로 인해 성능 저하가 발생할 수 있다.
둘째, 전체 컬렉션에 대해 동기화가 이루어지기 때문에, 잠금 범위가 넓어질 수 있다. 이는 잠금 경합(lock contention)을 증가시키고, 병렬 처리의 효율성을 저하시키는 요인이 된다. 모든 메서드에 대해 동기화를 적용하다 보면, 특정 스레드가 컬렉션을 사용하고 있을 때 다른 스레드들이 대기해야 하는 상황이 빈번해질 수 있다.
셋째, 정교한 동기화가 불가능하다. synchronized 프록시를 적용하면 컬렉션 전체에 대한 동기화가 이루어지지만, 특정 부분이나 메서드에 대해 선택적으로 동기화를 적용하는 것은 어렵다. 이는 과도한 동기화로 이어질 수 있다.

쉽게 이야기해서 이 방식은 단순 무식하게 모든 메서드에 synchronized를 걸어버리는 것이다. 따라서 동기화에 대한 최적화가 이루어지지 않는다. 자바는 이런 단점을 보완하기 위해 java.util.concurrent 패키지에 동시성 컬렉션을 제공한다.

자바가 제공하는 동시성 컬렉션

위 자바가 제공하는 Collections.synchronizedXxx() 프록시 방식은 여러 스레드가 동시에 접근해도 동시성 문제가 발생하지 않도록 해준다. 그래서 안전하게 멀티 스레드 환경에서 사용할 수 있다. 그러나, 단점이 있는데 모든 메서드가 다 synchronized가 걸려있어서 필요없을 때 조차도 병렬 처리가 불가능하고 한마디로 무겁고 비용이 많이 든다.

그래서 java.util.concurrent 패키지에는 고성능 멀티 스레드 환경을 지원하는 다양한 동시성 컬렉션 클래스들을 제공한다. 예를 들어, ConcurrentHashMap, CopyOnWriteArrayList, BlockingQueue 등이 있다. 이 컬렉션들은 더 정교한 잠금 메커니즘을 사용하여 동시 접근을 효율적으로 처리하며, 필요한 경우 일부 메서드에 대해서만 동기화를 적용하는 등 유연한 동기화 전략을 제공한다.

여기에 다양한 성능 최적화 기법들이 적용되어 있는데, synchronized, Lock(ReentrantLock), CAS, 분할 잠금 기술(segment lock)등 다양한 방법을 섞어서 매우 정교한 동기화를 구현하면서 동시에 성능도 최적화했다. 각각의 최적화는 매우 어렵게 구현되어 있기 때문에, 자세히 구현을 이해하는 것보다는 멀티스레드 환경에 필요한 동시성 컬렉션들을 잘 선택해서 사용할 수 있으면 충분하다.

동시성 컬렉션의 종류

List
- CopyOnWriteArrayList → ArrayList의 대안
Set
- CopyOnWriteArraySet → HashSet의 대안
- ConcurrentSkipListSet → TreeSet의 대안(정렬된 순서 유지, Comparator 사용 가능)
Map
- ConcurrentHashMap → HashMap의 대안
- ConcurrentSkipListMap → TreeMap의 대안(정렬된 순서 유지, Comparator 사용 가능)
Queue
- ConcurrentLinkedQueue: 동시성 큐, 비 차단 큐이다.
Deque
- ConcurrentLinkedDeque: 동시성 데크, 비 차단 큐이다.

참고로, LinkedHashSet, LinkedHashMap 처럼 입력 순서를 유지하는 동시에 멀티 스레드 환경에서 사용할 수 있는 Set, Map 구현체는 제공하지 않는다. 필요하다면 Collections.synchronizedXxx()를 사용해야 한다.

스레드를 차단하는 블로킹 큐도 알아보자.

BlockingQueue
- ArrayBlockingQueue
  - 크기가 고정된 블로킹 큐
  - 공정(fair) 모드를 사용할 수 있다. 공정 모드를 사용하면 성능이 저하될 수 있다.
- LinkedBlockingQueue
  - 크기가 무한하거나 고정된 블로킹 큐
- PriorityBlockingQueue
  - 우선순위가 높은 요소를 먼저 처리하는 블로킹 큐
- SynchronousQueue
  - 데이터를 저장하지 않는 블로킹 큐로, 생산자가 데이터를 추가하면 소비자가 그 데이터를 받을 때까지 대기한다. 생산자 - 소비자 간 직접적인 핸드오프 메커니즘을 제공한다. 쉽게 이야기해서 중간에 큐 없이 생산자 - 소비자가 직접 거래한다.
- DelayQueue
  - 지연된 요소를 처리하는 블로킹 큐로, 각 요소는 지정된 지연 시간이 지난 후에야 소비될 수 있다. 일정 시간이 지난 후 작업을 처리해야 하는 스케쥴링 작업에 사용된다.

ListMain (List 예시)

package thread.collections.java;

import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;

public class ListMain {

    public static void main(String[] args) {
        List<String> list = new CopyOnWriteArrayList<>();

        list.add("a");
        list.add("b");
        System.out.println("list = " + list);
    }
}

실행 결과

list = [a, b]

물론, 지금 실행 결과는 단일 스레드의 실행 결과이지만 이 CopyOnWriteArrayList는 ArrayList에 대한 동시성 접근을 잘 처리한 자료 구조이다. 지금처럼 이렇게 자바가 잘 만들어놓은 자료 구조를 사용하면 이렇게 list.add("a"), list.add("b") 와 같은 메서드만 있다면 굳이 synchronized 같은 동기화 기법을 사용할 필요가 없다. 내부적으로 동기화 기법이 잘 적용된 상태니까.

그러니까 쉽게 말해서, 자료 구조에 대한 작업을 위해서는 동기화 작업을 직접적으로 개발자가 따로 걸어줄 필요가 없다는 소리다. 당연히 그게 아니라 로직상에 원자적 연산이 아닌 코드가 있다면 그 부분에 대해서는 개발자가 직접 동기화 작업을 위한 코드를 작성해야 겠지만 위 코드처럼 이미 아주 효율적으로 동기화 작업이 되어 있는 자료 구조에 데이터를 추가하고 뭐 하고 하는 부분만 있으면 동기화 작업이 따로 필요 없다.

SetMain (Set 예시)

package thread.collections.java;

import java.util.Set;
import java.util.concurrent.ConcurrentSkipListSet;
import java.util.concurrent.CopyOnWriteArraySet;

public class SetMain {
    public static void main(String[] args) {
        Set<Integer> copySet = new CopyOnWriteArraySet<>();
        copySet.add(1);
        copySet.add(2);
        copySet.add(3);
        System.out.println("copySet = " + copySet);

        ConcurrentSkipListSet<Object> skipSet = new ConcurrentSkipListSet<>();
        skipSet.add(2);
        skipSet.add(1);
        skipSet.add(3);
        System.out.println("skipSet = " + skipSet);
    }
}

실행 결과

copySet = [1, 2, 3]
skipSet = [1, 2, 3]

CopyOnWriteArraySet은 HashSet의 대안이다.
ConcurrentSkipListSet은 TreeSet의 대안이다. 데이터의 정렬 순서를 유지한다. (Comparator 사용 가능)

MapMain (Map 예시)

package thread.collections.java;

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentSkipListMap;

public class MapMain {
    public static void main(String[] args) {

        Map<Integer, String> map = new ConcurrentHashMap<>();

        map.put(3, "data3");
        map.put(2, "data2");
        map.put(1, "data1");

        System.out.println("map = " + map);

        Map<Integer, String> map2 = new ConcurrentSkipListMap<>();
        map2.put(3, "data3");
        map2.put(2, "data2");
        map2.put(1, "data1");
        System.out.println("map2 = " + map2);
    }
}

실행 결과

map = {1=data1, 2=data2, 3=data3}
map2 = {1=data1, 2=data2, 3=data3}

ConcurrentHashMap은 HashMap의 대안이다.
ConcurrentSkipListMap은 TreeMap의 대안이다. 데이터의 정렬 순서를 유지한다. (Comparator 사용 가능)

정리

자바가 제공하는 동시성 컬렉션은 멀티 스레드 상황에 최적의 성능을 낼 수 있도록 다양한 최적화 기법이 적용되어 있다. 따라서 Collections.synchronizedXxx를 사용하는 것보다 더 좋은 성능을 제공한다. 당연한 이야기지만 동시성은 결국 성능과 트레이드 오프가 있다. 따라서 단일 스레드가 컬렉션을 사용하는 경우에는 동시성 컬렉션이 아닌 일반 컬렉션을 사용해야 한다.

반대로 멀티 스레드 상황에서 일반 컬렉션을 사용하면 정말 해결하기 어려운 버그를 만날 수 있다. 세상에서 가장 해결하기 어려운 버그가 멀티스레드로 인해 발생한 버그이다. 이러한 이유로 멀티스레드 환경에서는 동시성 컬렉션을 적절히 활용해서 버그를 예방하고 성능을 최적화하는 것이 중요하다. 동시성 컬렉션을 사용하면 코드의 안정성과 효율성을 높일 수 있으며, 예상치 못한 동시성 문제도 방지할 수 있다.

728x90

LIST

저작자표시

'JAVA의 가장 기본이 되는 내용' 카테고리의 다른 글

멀티스레드 Part.13 Executor 프레임워크 2 (0)	2024.07.30
멀티스레드 Part.12 스레드 풀과 Executor 프레임워크 1 (0)	2024.07.28
멀티스레드 Part.10 원자적 연산 (CAS) (0)	2024.07.26
멀티스레드 Part.9 생산자 소비자 문제 2 (0)	2024.07.25
멀티스레드 Part.8 생산자 소비자 문제 (0)	2024.07.24

programmer.cwchoiit