김신건의 로그 - 위키 / java

[Java] Object

koa (김신건) — Fri, 17 Jul 2026 00:00:00 GMT

정의

java.lang.Object 는 Java 의 모든 클래스의 최상위 부모 (root) 클래스. extends 가 명시되지 않은 클래스는 컴파일러가 자동으로 extends Object 를 붙인다. 인터페이스는 클래스가 아니라 Object 를 직접 상속하지는 않지만, 인터페이스 구현체는 결국 Object 의 메서드를 호출 가능.

이 단일 root 가 Java 의 collection, reflection, equality, threading 의 기초가 된다. Object 의 메서드를 이해하지 않고는 [[java-collection|Collection]], [[java-hashmap|HashMap]], [[java-iterable|Iterable]] 어느 것도 정확히 쓸 수 없다.

사용 상황

상황	관련 메서드 / 접근법
객체를 Map/Set 키로 사용	`equals` + `hashCode` 동시 override 필수
로그, 디버깅 출력	`toString` override
멀티스레드 대기/신호	`wait` / `notify` / `notifyAll` (synchronized 내)
런타임 타입 판별	`getClass()` 또는 `instanceof`
복사본 생성	복사 생성자 권장 (`clone` 대신)
GC 이후 자원 해제	`AutoCloseable` + `try-with-resources` (`finalize` 대신)
하위 호환 컨테이너	`Object` 타입 (타입 erasure 이전 레거시)

상속 계층 시각화

Java 표준 라이브러리의 주요 클래스는 모두 Object 에서 출발한다.

flowchart TD
    O["java.lang.Object"]
    O --> S["java.lang.String"]
    O --> N["java.lang.Number"]
    O --> AL["AbstractList"]
    O --> AM["AbstractMap"]
    N --> IN["Integer"]
    N --> LO["Long"]
    N --> DB["Double"]
    AL --> ARL["ArrayList"]
    AL --> LL["LinkedList"]
    AM --> HM["HashMap"]
    AM --> TM["TreeMap"]

모든 클래스의 공통 조상이므로 obj instanceof Object 는 항상 true (null 제외).

핵심 메서드 11개

메서드	역할	자주 override?
`equals(Object)`	동등성 비교	✓
`hashCode()`	해시 코드 (Map/Set 용)	✓
`toString()`	문자열 표현	✓
`getClass()`	런타임 클래스 (`final`)	✗
`clone()`	얕은 복사 (`protected`)	△
`finalize()`	GC 직전 호출 (`deprecated`)	✗
`wait()`, `wait(long)`, `wait(long, int)`	모니터 대기 (`final`)	✗
`notify()`, `notifyAll()`	모니터 깨우기 (`final`)	✗

final 인 것은 override 불가, 나머지는 가능.

equals / hashCode 의 5가지 규약

equals(Object) 를 override 하면 hashCode() 도 반드시 override 해야 한다. JCF (Java Collections Framework) 의 [[java-hashmap|HashMap]], [[java-hashset|HashSet]] 이 두 메서드의 일관성에 의존하기 때문.

equals(Object) 규약:

반사 (reflexive): x.equals(x) == true
대칭 (symmetric): x.equals(y) 이면 y.equals(x)
추이 (transitive): x.equals(y) && y.equals(z) 이면 x.equals(z)
일관 (consistent): 객체가 변하지 않으면 같은 결과
null 비교: x.equals(null) == false

hashCode() 규약:

equals 가 true 인 두 객체는 같은 hashCode 를 반환해야 한다 (역은 아님)
객체가 변하지 않으면 같은 hashCode 반환

flowchart LR
    A["equals override?"]
    A -->|"yes"| B["hashCode 도 override 필수"]
    A -->|"no"| C["참조 동일 시에만 equal"]
    B --> D["같은 필드로 hashCode 계산"]
    D --> E["HashMap, HashSet 정상 동작"]
    C --> F["HashMap 키 오작동 위험"]

public class Point {
    private final int x;
    private final int y;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Point p)) return false;
        return x == p.x && y == p.y;
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}

[!IMPORTANT] equals 만 override 하고 hashCode 를 안 하면 HashMap, HashSet 이 조용히 잘못 동작 한다. 같은 점이 두 번 들어가거나, 넣은 값을 못 찾는 식. @Override annotation 으로 컴파일러 검사를 유도하라.

toString, 디버깅의 기본

기본 구현은 ClassName@hexHashCode 같은 형태로 거의 쓸모없다. 자기 자신을 의미있게 표현하도록 override 권장.

@Override
public String toString() {
    return "Point(%d, %d)".formatted(x, y);
}

Java 16+ 의 record 는 자동 생성. lombok 도 @ToString 으로 생성.

Objects 유틸리티 클래스

java.util.Objects 는 null-safe 헬퍼를 제공해 equals / hashCode / toString 구현을 간결하게 한다.


// null-safe equals: a == null 이어도 NPE 없음
Objects.equals(a, b);

// 복수 필드 hashCode 계산
Objects.hash(field1, field2, field3);

// null 이면 fallback 반환
Objects.toString(obj, "N/A");

// null 시 NPE + 메시지
Objects.requireNonNull(x, "x must not be null");

// 메서드 참조로 null 체크
stream.filter(Objects::nonNull).toList();

Java 16+ record 를 쓰면 equals, hashCode, toString 을 자동 생성하므로 이 헬퍼 없이도 된다.

wait / notify, monitor 패턴

wait(), notify(), notifyAll() 은 모니터 락 (monitor lock) 위에서만 호출 가능. 그래서 반드시 synchronized 블록 안에서 호출해야 한다.

synchronized (obj) {
    while (!condition) {
        obj.wait();   // 락 해제하고 대기
    }
    // condition 충족, 처리
}

// 다른 스레드
synchronized (obj) {
    condition = true;
    obj.notifyAll();  // 대기 중인 모든 스레드 깨움
}

규칙:

synchronized 밖에서 호출하면 IllegalMonitorStateException
조건은 항상 if 가 아닌 while 로 검사 (spurious wakeup 가능)
notify 보다 notifyAll 이 안전 (단일 wakeup 으로 누가 깨어났는지 알 수 없음)

[!CAUTION] 새 코드에서는 wait/notify 대신 [[java-reentrant-lock|ReentrantLock]] + Condition, [[java-countdown-latch|CountDownLatch]], [[java-semaphore|Semaphore]], [[java-blocking-queue|BlockingQueue]] 같은 고수준 동기화 도구 를 권장한다. wait/notify 는 미묘한 버그 (spurious wakeup, lost notification) 를 만들기 쉽다.

모든 컬렉션의 root 가 Object 인 이유

JCF 의 메서드는 거의 모두 Object 타입을 받는다.

public interface Collection<E> {
    boolean contains(Object o);   // ← Object, not E
    boolean remove(Object o);     // ← Object, not E
    boolean equals(Object o);
}

이는 타입 erasure 와 invariance 때문이다. List<Integer>.contains(double) 도 컴파일은 되지만 항상 false. 이런 미묘한 함정의 원인. Joshua Bloch Effective Java Item 65 가 이를 다룬다.

getClass, Reflection 의 입구

getClass() 는 final 이라 override 불가. 런타임에 정확한 클래스를 알려준다.

Object x = "hello";
Class<?> c = x.getClass();          // String.class
String name = c.getName();          // "java.lang.String"
Method[] methods = c.getMethods();   // public 메서드 목록

Reflection, Annotation 처리, Serialization 등의 진입점. Spring 의 DI 컨테이너도 결국 getClass() 기반으로 빈을 만든다. 자세한 내용은 [[java-reflection]] 참고.

clone, 거의 안 쓰는 것이 답

Object.clone() 은 protected 라 외부에서 호출 못 한다. 사용하려면 Cloneable 인터페이스를 구현하고 clone() 을 public 으로 override 해야 한다. 그런데 깊은 복사 (deep copy) 는 직접 처리해야 하므로 함정이 많다.

[!IMPORTANT] 대안: 복사 생성자 (new Foo(other)) 또는 정적 팩토리 메서드 (Foo.copyOf(other)) 가 훨씬 명확하다. Joshua Bloch Effective Java Item 13 이 “clone 은 피해라” 라고 단정.

finalize, deprecated

finalize() 는 GC 가 객체를 회수하기 직전에 호출되도록 설계됐지만:

호출 시점 불확실, 영원히 안 불릴 수도 있다
성능 저하, finalizer 가 있는 객체는 GC 가 두 번 본다
보안 취약점, finalizer attack
Java 9+ 에서 @Deprecated, Java 18+ 부터 --finalization=disabled 옵션

대안: AutoCloseable + try-with-resources, Cleaner 클래스 (java.lang.ref.Cleaner).

Object 만 받는 메서드와 제네릭

Collection.contains(Object) 처럼 제네릭이 도입된 뒤에도 Object 인자가 남아있다. 이는 하위 호환성 때문, JDK 1.0 코드가 그대로 동작해야 했다. Joshua Bloch 등 설계자들도 이를 후회한다고 밝힌 적이 있다.

함정

1. equals 만 override 하고 hashCode 빠뜨리기

// 위험: hashCode override 없이 equals 만 구현
class Key {
    String value;
    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Key k)) return false;
        return value.equals(k.value);
    }
    // hashCode 없음 → HashMap.get 이 null 반환
}

Map<Key, String> map = new HashMap<>();
map.put(new Key("x"), "hello");
map.get(new Key("x"));  // null (같은 내용인데 못 찾음)

2. instanceof 와 getClass() 의 혼용

class Animal {}
class Dog extends Animal {
    @Override
    public boolean equals(Object o) {
        // instanceof Animal 로 비교하면 Dog 와 Animal 간 대칭 규약 깨짐
        if (!(o instanceof Dog d)) return false;
        return true;
    }
}

Dog d = new Dog();
Animal a = new Animal();
// d.equals(a) 와 a.equals(d) 결과가 다를 수 있음

equals 에서 instanceof 를 쓸 때는 상속 관계에서 대칭 규약 이 깨지지 않도록 주의. getClass() 비교가 더 엄격한 동등성을 보장.

3. synchronized 없이 wait 호출

// 잘못된 코드
obj.wait();   // IllegalMonitorStateException 발생

// 올바른 코드
synchronized (obj) {
    obj.wait();
}

[Java] ArrayBlockingQueue

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.ArrayBlockingQueue<E> 는 고정 크기 원형 배열 기반의 [[java-blocking-queue|BlockingQueue]]. 생성 시 capacity 를 지정해야 하고 그 이상 늘어나지 않는다.

내부에 단일 [[java-reentrant-lock|ReentrantLock]] 을 사용 (head/tail 공유). 동시 throughput 은 [[java-linkedblockingqueue|LinkedBlockingQueue]] 보다 낮을 수 있지만 메모리 사용량이 예측 가능하고 GC 압력이 작다.

사용 상황

백프레셔(backpressure) 가 필요한 생산자-소비자 패턴: 큐가 가득 차면 생산자가 자동으로 block
메모리 한도 가 명확히 정해진 경우: 슬롯 수 = capacity 로 미리 확정
공정성(fairness) 이 중요한 상황: new ArrayBlockingQueue<>(n, true) 로 FIFO 보장
작은 capacity (수십~수백): [[java-linkedblockingqueue|LinkedBlockingQueue]] 대비 GC 압력 절감

내부 구조

public class ArrayBlockingQueue<E> ... {
    final Object[] items;          // 원형 배열
    int takeIndex;                  // head
    int putIndex;                   // tail (next slot)
    int count;
    final ReentrantLock lock;
    private final Condition notEmpty;
    private final Condition notFull;
}

notEmpty, notFull 두 [[java-reentrant-lock|ReentrantLock]] Condition 을 사용. take 가 비어 있으면 notEmpty 에서 대기, put 이 가득 차면 notFull 에서 대기.

시각화: 원형 배열 순환

flowchart LR
    subgraph arr["items[0..7]"]
        A["[0] 'A'"] --> B["[1] 'B'"] --> C["[2] 'C'"] --> D["[3] empty"]
        D --> E["[4] empty"] --> F["[5] empty"] --> G["[6] empty"] --> H["[7] empty"]
    end
    T["takeIndex=0"] -->|"dequeue"| A
    P["putIndex=3"] -->|"enqueue"| D

take 은 takeIndex 위치에서 꺼내고, put 은 putIndex 위치에 넣는다. 두 포인터 모두 capacity 로 wrap-around.

동작 흐름

flowchart TD
    PUT["put(e) 호출"] --> LOCK["lock 획득"]
    LOCK --> FULL{"count == capacity?"}
    FULL -->|"예"| WAIT["notFull.await() 대기"]
    WAIT --> LOCK
    FULL -->|"아니오"| ENQ["enqueue: items[putIndex++] = e"]
    ENQ --> SIGNAL["notEmpty.signal()"]
    SIGNAL --> UNLOCK["lock 해제"]

    TAKE["take() 호출"] --> LOCK2["lock 획득"]
    LOCK2 --> EMPTY{"count == 0?"}
    EMPTY -->|"예"| WAIT2["notEmpty.await() 대기"]
    WAIT2 --> LOCK2
    EMPTY -->|"아니오"| DEQ["dequeue: e = items[takeIndex++]"]
    DEQ --> SIGNAL2["notFull.signal()"]
    SIGNAL2 --> UNLOCK2["lock 해제"]

핵심 메서드 정리

메서드	동작	예외 / 반환
`put(e)`	블록 (가득 차면 대기)	`InterruptedException`
`take()`	블록 (비어 있으면 대기)	`InterruptedException`
`offer(e)`	즉시 시도, 실패 시 false	예외 없음
`offer(e, t, u)`	타임아웃 대기	`InterruptedException`
`poll()`	즉시 시도, 비어 있으면 null	예외 없음
`poll(t, u)`	타임아웃 대기	`InterruptedException`
`peek()`	head 확인 (꺼내지 않음)	null 가능

BlockingQueue<String> q = new ArrayBlockingQueue<>(4);

// 타임아웃 offer: 100ms 안에 못 넣으면 false
boolean ok = q.offer("item", 100, TimeUnit.MILLISECONDS);

// 타임아웃 poll: 200ms 안에 못 꺼내면 null
String val = q.poll(200, TimeUnit.MILLISECONDS);

복잡도

작업	시간
`put`, `take`	O(1)
`offer`, `poll`, `peek`	O(1)
`contains`, `remove(Object)`	O(n)
순회	O(n), weakly consistent

실전 코드: bounded 생산자-소비자

// Java 17+ : record for immutability
record Task(String name, int priority) {}

BlockingQueue<Task> queue = new ArrayBlockingQueue<>(100);

// 생산자: 큐가 가득 차면 자동 block -> backpressure
Thread producer = Thread.ofVirtual().start(() -> {
    try {
        for (int i = 0; i < 1000; i++) {
            queue.put(new Task("task-" + i, i % 5));
        }
        queue.put(new Task("POISON", -1));   // 종료 신호
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});

// 소비자: 비어 있으면 자동 block
Thread consumer = Thread.ofVirtual().start(() -> {
    try {
        while (true) {
            Task t = queue.take();
            if (t.priority() < 0) break;     // POISON 감지
            process(t);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});

공정성 옵션

// fair=true: FIFO 순서로 lock 경쟁 (writer starvation 방지)
BlockingQueue<String> fair = new ArrayBlockingQueue<>(50, true);

[!IMPORTANT] 공정 모드는 처리량이 크게 떨어진다. starvation 이 실제 문제로 관찰된 경우에만 활성화.

ArrayBlockingQueue vs LinkedBlockingQueue

| 항목 | ArrayBlockingQueue | [[java-linkedblockingqueue|LinkedBlockingQueue]] | |:---|:---|:---| | 크기 | 항상 bounded | optionally bounded | | 백킹 | 원형 배열 | linked list | | 락 | 단일 ReentrantLock | takeLock + putLock 분리 | | 동시 throughput | 낮음 (락 경합) | 높음 | | 메모리 / 원소 | 슬롯 1개 | 노드 객체 1개 | | GC 압력 | 작음 (배열 고정) | 큼 (노드 생성/소멸) | | 공정성 옵션 | ✓ | ✗ |

[!IMPORTANT] 메모리 예측이 중요한 환경, 또는 capacity 가 작은 경우 ArrayBlockingQueue 가 자연스럽다. 대량 throughput 이 필요하면 LinkedBlockingQueue.

함정

1. capacity 를 너무 크게 잡기

capacity 를 과도하게 크게 잡으면 backpressure 효과가 사라진다. 생산자가 한없이 쌓을 수 있어 OOM 으로 이어질 수 있다. 적절한 capacity 는 소비자의 처리 속도 × 수용 가능한 지연 으로 추정.

2. `offer()` 결과 무시

queue.offer(item);   // ❌ 큐가 가득 찬 경우 false 반환, 데이터 유실
if (!queue.offer(item)) {
    log.warn("큐 포화: {}", item);   // ✓ 처리해야 함
}

3. `contains()` / `remove(Object)` 는 O(n)

선형 탐색이다. 빈번하게 호출하면 성능 저하. 존재 여부 빠른 조회가 필요하면 별도 Set 유지.

[!WARNING] 순회 도중 큐를 수정하면 ConcurrentModificationException 이 아니라 weakly consistent 보장으로 일부 원소가 보이거나 안 보일 수 있다.

Thread Pool 연동: 작업 큐로 활용

ThreadPoolExecutor 는 생성자에 BlockingQueue<Runnable> 을 받는다. ArrayBlockingQueue 를 주면 큐가 가득 찰 때 RejectedExecutionHandler 가 호출된다.

// 최대 4스레드, 큐 최대 20개, 초과 시 호출자 스레드에서 실행
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2,                                            // corePoolSize
    4,                                            // maxPoolSize
    60, TimeUnit.SECONDS,                         // keepAliveTime
    new ArrayBlockingQueue<>(20),                 // bounded queue
    new ThreadPoolExecutor.CallerRunsPolicy()     // reject policy
);

executor.submit(() -> process(task));
// 큐 가득 + 스레드 maxPoolSize 도달 시:
//   CallerRunsPolicy -> 제출한 스레드가 직접 실행 (자연스러운 backpressure)

멀티 Producer-Consumer 패턴

// Java 21 virtual threads + ArrayBlockingQueue
int CAPACITY = 50;
BlockingQueue<String> queue = new ArrayBlockingQueue<>(CAPACITY);
String POISON = "__DONE__";

// 3개 생산자
for (int i = 0; i < 3; i++) {
    final int pid = i;
    Thread.ofVirtual().start(() -> {
        try {
            for (int j = 0; j < 100; j++) {
                queue.put("P" + pid + "-" + j);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    });
}

// 2개 소비자 + poison pill 종료
for (int i = 0; i < 2; i++) {
    Thread.ofVirtual().start(() -> {
        try {
            while (true) {
                String item = queue.take();
                if (POISON.equals(item)) {
                    queue.put(POISON);   // 남은 소비자에게 전달
                    break;
                }
                process(item);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    });
}

// 생산자 종료 후 poison 투입
queue.put(POISON);

[Java] ArrayDeque

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.ArrayDeque<E> 는 원형 배열 (circular buffer) 기반의 [[Deque]] 구현. JDK 1.6 도입.

Stack 으로 쓰면 java.util.Stack 보다 빠르고, Queue 로 쓰면 [[LinkedList]] 보다 빠르다. Stack / Queue / Deque 가 필요할 때 거의 항상 첫 번째 선택.

사용 상황

상황	권장
LIFO 스택 (재귀 대신 반복 DFS)	`push` / `pop`
FIFO 큐 (BFS, 작업 처리)	`offer` / `poll`
양방향 삽입/삭제 (슬라이딩 윈도우)	`offerFirst` / `pollLast`
괄호/수식 파싱	스택으로 활용
단조 덱 (Monotone Deque)	슬라이딩 윈도우 최댓값

null 이 필요하거나 인덱스 기반 접근이 필요하면 [[LinkedList]] 또는 [[ArrayList]].

시각화

{}

원형 배열 동작

flowchart LR
    INIT["초기: head=0, tail=0"]
    ADD["addLast(a,b,c): tail=3"]
    FIRST["addFirst(x): head=7, tail=3"]
    GROW["grow: 용량 초과 시 2배 확장 + 복사"]

    INIT --> ADD --> FIRST
    FIRST -->|"가득 찼을 때"| GROW

head 와 tail 은 같은 방향으로 이동하되, 끝에 도달하면 0 으로 되돌아온다. 인덱스 계산: (head - 1 + length) % length (addFirst), tail % length (addLast).

내부 구조

public class ArrayDeque<E> extends AbstractCollection<E>
    implements Deque<E>, Cloneable, Serializable {

    transient Object[] elements;       // 백킹 배열
    transient int head;                // head 인덱스
    transient int tail;                // tail 인덱스 (next slot)
}

초기 (size 8):  [_ _ _ _ _ _ _ _]
                 ↑head=tail=0

addLast: a, b, c
        [a b c _ _ _ _ _]
         ↑head    ↑tail=3

addFirst: x
        [a b c _ _ _ _ x]
                        ↑head=7  tail=3

수정된 인덱스 = (i + length) % length

가득 차면 배열 크기를 2 배로 grow 하고 원소를 새 배열로 복사.

복잡도

작업	시간
`addFirst`, `addLast`	amortized O(1)
`removeFirst`, `removeLast`	O(1)
`peek*`, `getFirst`, `getLast`	O(1)
`contains`, `remove(Object)`	O(n)
임의 인덱스 접근	불가 (List 가 아니므로)

amortized 인 이유는 가득 찼을 때 2 배 grow + copy 비용 때문. 평균은 O(1).

LinkedList vs ArrayDeque

항목	LinkedList	ArrayDeque
백킹	linked nodes	원형 배열
메모리 / 원소	노드 헤더 + 두 포인터 (~32B)	슬롯 1 개 (4-8B)
캐시 친화	✗	✓
addFirst / addLast	O(1)	amortized O(1)
null 허용	✓	✗
List 가능	✓ (인덱스 O(n))	✗
Deque 가능	✓	✓
실측 속도	느림	빠름

null 거부와 List 미구현이 단점이지만, 그 외에는 모든 면에서 [[LinkedList]] 보다 우월.

Stack 사용 예

Deque<Integer> stack = new ArrayDeque<>();
stack.push(1);              // head 쪽에 push
stack.push(2);
stack.push(3);
stack.peek();               // 3
stack.pop();                // 3

// DFS: 재귀 대신 반복으로
Deque<Integer> dfs = new ArrayDeque<>();
dfs.push(startNode);
while (!dfs.isEmpty()) {
    int node = dfs.pop();
    for (int next : graph[node]) {
        if (!visited[next]) {
            visited[next] = true;
            dfs.push(next);
        }
    }
}

Deque<E> stack = new ArrayDeque<>() 패턴이 [[Vector]] 기반 Stack<E> 보다 두세 배 빠르다.

Queue 사용 예 (BFS)

Queue<Integer> bfs = new ArrayDeque<>();
bfs.offer(startNode);
visited[startNode] = true;

while (!bfs.isEmpty()) {
    int node = bfs.poll();
    for (int next : graph[node]) {
        if (!visited[next]) {
            visited[next] = true;
            bfs.offer(next);
        }
    }
}

Deque 사용 예: 슬라이딩 윈도우 최댓값

// 크기 k 의 슬라이딩 윈도우에서 최댓값 배열 구하기 (단조 감소 덱)
int[] nums = {1, 3, -1, -3, 5, 3, 6, 7};
int k = 3;
int[] result = new int[nums.length - k + 1];

Deque<Integer> dq = new ArrayDeque<>();  // 인덱스 저장 (단조 감소)
for (int i = 0; i < nums.length; i++) {
    // 윈도우 범위 벗어난 front 제거
    if (!dq.isEmpty() && dq.peekFirst() < i - k + 1) {
        dq.pollFirst();
    }
    // 현재 원소보다 작은 rear 제거 (단조 유지)
    while (!dq.isEmpty() && nums[dq.peekLast()] <= nums[i]) {
        dq.pollLast();
    }
    dq.offerLast(i);
    if (i >= k - 1) {
        result[i - k + 1] = nums[dq.peekFirst()];
    }
}
// result: [3, 3, 5, 5, 6, 7]  O(n) 시간

Deque 인터페이스 주요 API

조작	head (앞)	tail (뒤)
추가	`addFirst(e)` / `offerFirst(e)`	`addLast(e)` / `offerLast(e)`
제거 (예외)	`removeFirst()`	`removeLast()`
제거 (null)	`pollFirst()`	`pollLast()`
조회 (예외)	`getFirst()`	`getLast()`
조회 (null)	`peekFirst()`	`peekLast()`

스택 메서드 push / pop / peek 은 각각 addFirst / removeFirst / peekFirst 의 alias. 큐 메서드 offer / poll / peek 은 addLast / removeFirst / peekFirst 의 alias.

괄호 검사 (스택 활용 예)

boolean isBalanced(String s) {
    Deque<Character> stack = new ArrayDeque<>();
    for (char c : s.toCharArray()) {
        if (c == '(' || c == '[' || c == '{') {
            stack.push(c);
        } else if (c == ')' || c == ']' || c == '}') {
            if (stack.isEmpty()) return false;
            char top = stack.pop();
            if ((c == ')' && top != '(') ||
                (c == ']' && top != '[') ||
                (c == '}' && top != '{')) return false;
        }
    }
    return stack.isEmpty();
}

함정

1. null 비허용

Deque<String> dq = new ArrayDeque<>();
dq.add(null);    // NullPointerException

이유: poll / peek 이 null 을 “비어 있음” 신호로 쓰는 의미와 충돌.

2. thread-safe 가 아님

[[ConcurrentLinkedDeque]] 또는 LinkedBlockingDeque 사용.

3. iterator 는 [[fail-fast iterator]]

순회 중 수정 시 CME.

4. push/pop vs offer/poll 혼용 주의

Deque<Integer> dq = new ArrayDeque<>();
dq.push(1); dq.push(2); dq.push(3);  // 스택: [3, 2, 1] (head 쪽)
dq.poll();    // 3 (스택 top)
dq.offer(4);  // tail 쪽에 추가: [2, 1, 4]

[!WARNING] push 는 head 쪽에 넣고 (addFirst), offer 는 tail 쪽에 넣는다 (addLast). 스택과 큐를 혼용하면 원소 순서가 뒤섞인다. 한 Deque 를 스택 또는 큐 하나의 역할 로만 쓴다.

참고

[[Queue]]
[[Deque]]
[[LinkedList]]
[[ConcurrentLinkedDeque]]
[[fail-fast iterator]]
[[ArrayList]]
[[Vector]]

[Java] AtomicInteger

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.atomic.AtomicInteger 는 lock-free 로 원자성을 보장 하는 int 래퍼. 내부적으로 CAS (Compare-And-Swap) 를 사용해 락 없이 atomic 한 read-modify-write 를 수행.

volatile int i; i++; 가 thread-safe 가 아닌 이유 (read + increment + write 세 단계) 를 해결한다. JDK 1.5 (Java SE 5.0) 에 java.util.concurrent.atomic 패키지와 함께 도입.

사용 상황

상황	예시
공유 카운터	요청 수, 오류 수 등 멀티스레드 집계
시퀀스 생성	unique ID, 트랜잭션 번호
상태 전이	단일 int 로 표현 가능한 상태 머신
락 없는 flag	초기화 완료 여부 (0/1)

단, 여러 변수 간의 복합 불변식 (예: 잔액 + 거래 이력의 일관성) 은 AtomicInteger 하나로 보장 불가. 이때는 [[ReentrantLock]] 또는 synchronized.

시각화

{}

핵심 메서드

AtomicInteger a = new AtomicInteger(0);

// 기본 읽기/쓰기
a.get();                           // 현재 값 (volatile read)
a.set(10);                         // 값 설정 (volatile write)
a.lazySet(10);                     // 비동기 설정 (정렬 보장 없음, GC용)

// 원자 증감
a.incrementAndGet();               // ++a, atomic
a.getAndIncrement();               // a++, 증가 전 값 반환
a.decrementAndGet();               // --a
a.getAndDecrement();               // a--, 감소 전 값 반환
a.addAndGet(5);                    // a += 5, 새 값 반환
a.getAndAdd(5);                    // a += 5, 이전 값 반환

// CAS
a.compareAndSet(10, 99);           // 현재 10 이면 99 로, 성공 여부 반환
// Java 9+
a.compareAndExchange(10, 99);      // 현재 값 반환 (성공하면 old, 실패하면 current)

// Java 8+: 람다 기반
a.updateAndGet(x -> x * 2);       // f(현재값) 으로 갱신, 새 값 반환
a.getAndUpdate(x -> x * 2);       // f(현재값) 으로 갱신, 이전 값 반환
a.accumulateAndGet(3, Integer::sum);   // 누산기 함수 적용
a.getAndAccumulate(3, Integer::sum);

CAS 원리

public final int incrementAndGet() {
    while (true) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))   // current 와 일치하면 next 로
            return next;
        // 일치하지 않으면 다른 스레드가 바꾼 것, 재시도
    }
}

CPU 명령어 (LOCK CMPXCHG on x86) 한 번으로 “비교 후 일치하면 교체” 를 atomic 하게 수행. 락 acquire/release 비용보다 훨씬 작다.

CAS 루프 흐름

flowchart TD
    Start["incrementAndGet() 호출"] --> Read["current = get()"]
    Read --> Calc["next = current + 1"]
    Calc --> CAS{"CAS(current, next) 성공?"}
    CAS -->|"예, current 와 일치"| Done["next 반환"]
    CAS -->|"아니오, 다른 스레드가 변경"| Read
    Other["다른 스레드가\nCAS 먼저 성공"] -.->|"메모리 값 변경"| CAS

경합이 적을 때는 한 번에 성공. 경합이 많을수록 재시도 루프가 길어진다.

volatile vs synchronized vs AtomicInteger

옵션	가시성	atomic read-modify-write	락 비용
`int i;`	✗	✗	없음
`volatile int i;`	✓	✗ (`i++` 안 됨)	없음
`synchronized`	✓	✓	중간
`AtomicInteger`	✓	✓ (CAS)	매우 작음 (저경합)

[!IMPORTANT] 단일 변수의 atomic 갱신만 필요하면 AtomicInteger 가 거의 항상 최선. 여러 변수 간 invariant 보호가 필요하면 [[ReentrantLock]] 또는 synchronized.

고경합에서의 문제: LongAdder

CAS 는 저경합에서 빠르다. 하지만 수십 스레드가 같은 AtomicInteger 에 동시 증가 하면 CAS 실패가 폭주, 성능이 락보다 떨어질 수 있다.

이때 [[LongAdder]] 가 해법. 내부적으로 여러 Cell 에 분산 누적 후 sum() 으로 합산. 최종 값이 필요한 시점에만 집계하는 카운터에 최적이다.

// 고경합 카운터: LongAdder 권장
LongAdder counter = new LongAdder();
counter.increment();         // 분산 Cell 에 누적
long total = counter.sum();  // 필요할 때 합산

// vs AtomicLong: 고경합 시 CAS 폭주
AtomicLong atomicCounter = new AtomicLong();
atomicCounter.incrementAndGet();

사용 예

카운터

class RequestCounter {
    private final AtomicInteger total = new AtomicInteger();
    private final AtomicInteger errors = new AtomicInteger();

    public void onRequest()  { total.incrementAndGet(); }
    public void onError()    { errors.incrementAndGet(); }
    public int count()       { return total.get(); }
    public int errorCount()  { return errors.get(); }
    public double errorRate() {
        int t = total.get();
        return t == 0 ? 0.0 : (double) errors.get() / t;
    }
}

시퀀스 생성

// Java 17+
class IdGenerator {
    private final AtomicInteger seq = new AtomicInteger(0);

    public int nextId() {
        return seq.incrementAndGet();
    }
}

상태 전이 (CAS)

// Java 17+ 상태 머신 예
sealed interface State permits State.Ready, State.Running, State.Done {}

class Task {
    private static final int READY   = 0;
    private static final int RUNNING = 1;
    private static final int DONE    = 2;

    private final AtomicInteger state = new AtomicInteger(READY);

    public boolean tryStart() {
        return state.compareAndSet(READY, RUNNING);
    }

    public boolean tryFinish() {
        return state.compareAndSet(RUNNING, DONE);
    }

    public boolean isDone() {
        return state.get() == DONE;
    }
}

compareAndSet 으로 상태 전이를 atomic 하게 수행. 두 스레드가 동시에 tryStart() 를 호출해도 하나만 성공.

Java 9+ compareAndExchange

// compareAndSet: boolean 반환
boolean updated = a.compareAndSet(expected, newVal);

// compareAndExchange: 현재 실제 값 반환 (loop-free CAS 에 편리)
int witness = a.compareAndExchange(expected, newVal);
if (witness == expected) {
    // 성공
} else {
    // 실패, witness 가 실제 현재 값
}

ABA 문제

CAS 의 알려진 한계. A → B → A 로 변한 값을 “안 바뀜” 으로 잘못 판단할 수 있다.

// 1. T1 이 값 A 를 읽음
int v = a.get();   // v = A
// 2. T2 가 A -> B -> A 로 변경
// 3. T1 의 CAS(A, x) 성공, 하지만 이 사이에 두 번 바뀐 사실 모름

정수 단순 증감 에서는 ABA 가 문제 되지 않는다. ABA 는 포인터 기반 자료구조 (Lock-free linked list 등) 에서 위험. 해법: AtomicStampedReference 가 stamp (버전) 도 같이 비교.

AtomicStampedReference<String> ref =
    new AtomicStampedReference<>("A", 0);

int[] stampHolder = new int[1];
String val = ref.get(stampHolder);
int stamp = stampHolder[0];

// stamp 도 함께 비교
ref.compareAndSet(val, "B", stamp, stamp + 1);

다른 Atomic 타입

타입	용도
AtomicInteger	int 원자 갱신
AtomicLong	long
AtomicBoolean	boolean
[[AtomicReference]]	임의 객체 참조
AtomicIntegerArray	int 배열 원소 원자 갱신
AtomicLongArray	long 배열
AtomicReferenceArray	객체 배열
[[LongAdder]]	고경합 누적 카운터
DoubleAdder	double 누적
LongAccumulator	람다 기반 누산기

함정

1. compound 연산은 atomic 하지 않다

AtomicInteger a = new AtomicInteger(0);

// 두 연산 사이에 다른 스레드 개입 가능
if (a.get() < 10) {
    a.incrementAndGet();   // get 과 increment 사이에 다른 스레드가 변경 가능
}

// 올바름: updateAndGet 으로 원자적으로
a.updateAndGet(v -> v < 10 ? v + 1 : v);

2. int 오버플로 시 조용히 음수로 전환

AtomicInteger max = new AtomicInteger(Integer.MAX_VALUE);
max.incrementAndGet();   // Integer.MIN_VALUE 로 wrap-around

long 이 필요하면 AtomicLong, 또는 오버플로 불가라면 guard 조건 추가.

3. lazySet 은 가시성 보장 없음

a.lazySet(1);   // volatile write 가 아님, 다른 스레드가 보지 못할 수 있음

보통 GC 용도 (null 로 레퍼런스 해제) 나 단일 Writer 특수 케이스에만 사용.

[Java] AtomicReference

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.atomic.AtomicReference<V> 는 객체 참조를 atomic 하게 갱신 하는 래퍼. volatile 참조 + CAS (Compare-And-Swap) 의 결합.

[[AtomicInteger]] 의 객체 버전. 불변 객체 패턴, 상태 머신, lock-free 자료구조의 빌딩 블록.

JDK 1.5 도입. java.util.concurrent.atomic 패키지.

언제 쓰나

불변 객체 원자적 교체: 설정 객체, 스냅샷 등을 락 없이 교체
상태 머신: 상태 전이를 CAS 로 원자적으로 처리
lock-free 자료구조: 노드 포인터를 CAS 로 갱신
단일 객체 캐시: 최신 값을 여러 스레드가 읽고 하나의 스레드가 갱신
초기화 경쟁 방지: compareAndSet 으로 한 번만 초기화 보장

시각화: CAS 동작

flowchart TD
    CAS["compareAndSet(expected, newVal)"] --> Read["현재 값 읽기"]
    Read --> Match{"현재 == expected?"}
    Match -->|"예"| Swap["원자적으로 newVal 로 교체, true 반환"]
    Match -->|"아니오"| Fail["교체 안 함, false 반환"]
    Swap --> Done["완료"]
    Fail --> Retry["재시도 (루프)"]
    Retry --> Read

시각화: 불변 객체 교체 패턴

sequenceDiagram
    participant T1 as "스레드 A (읽기)"
    participant T2 as "스레드 B (갱신)"
    participant Ref as "AtomicReference"

    T1->>Ref: get() = Config{v=1}
    T2->>Ref: set(Config{v=2}) - volatile write
    T1->>Ref: get() = Config{v=2} (즉시 반영)
    Note over T1: Config 객체 자체는 불변
    Note over T2: 참조만 교체, 기존 객체 불변

핵심 메서드

AtomicReference<Config> ref = new AtomicReference<>(initialConfig);

// 현재 참조 읽기 (volatile read)
Config current = ref.get();

// 단순 설정 (volatile write)
ref.set(newConfig);

// CAS: expected 와 같으면 newVal 로 교체, 성공 시 true
boolean success = ref.compareAndSet(expected, newVal);

// 이전 값 반환 + 새 값으로 설정
Config old = ref.getAndSet(newConfig);

// 람다로 갱신 (CAS 루프 내장, 실패 시 자동 재시도)
Config updated = ref.updateAndGet(c -> c.withVersion(c.version() + 1));

// 인자와 현재 값을 결합해 갱신
ref.accumulateAndGet(delta, (cur, d) -> cur.merge(d));

가장 흔한 패턴: 불변 객체 교체



// Config 는 불변 record
record Config(String host, int port, int timeout) {
    Config withTimeout(int newTimeout) {
        return new Config(host, port, newTimeout);
    }
}

class ConfigHolder {
    private final AtomicReference<Config> ref =
        new AtomicReference<>(new Config("localhost", 8080, 30));

    // lock-free 읽기
    public Config get() {
        return ref.get();
    }

    // 단순 교체 (volatile write)
    public void reload(Config newConfig) {
        ref.set(newConfig);
    }

    // CAS 루프로 안전한 갱신
    public void updateTimeout(int newTimeout) {
        ref.updateAndGet(c -> c.withTimeout(newTimeout));
    }
}

Config 가 불변 이면 한 번 참조한 객체는 변하지 않는다. 새 설정으로 교체할 때 참조만 atomic 하게 바꾸면 안전.

내부 구현: VarHandle 기반

public class AtomicReference<V> implements Serializable {
    private static final VarHandle VALUE;

    static {
        try {
            VALUE = MethodHandles.lookup()
                .findVarHandle(AtomicReference.class, "value", Object.class);
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    private volatile V value;   // volatile: 가시성 보장

    public final boolean compareAndSet(V expectedValue, V newValue) {
        return VALUE.compareAndSet(this, expectedValue, newValue);
        // 내부적으로 CPU 의 CAS 명령어 (x86: CMPXCHG) 사용
    }

    public final V updateAndGet(UnaryOperator<V> updateFunction) {
        V prev = get(), next = null;
        for (boolean haveNext = false;;) {
            if (!haveNext)
                next = updateFunction.apply(prev);
            if (weakCompareAndSetVolatile(prev, next))
                return next;
            haveNext = (prev == (prev = get()));
        }
    }
}

volatile V value: JMM 가시성 보장. 한 스레드의 쓰기가 다른 스레드에 즉시 보임.
compareAndSet: CPU 의 CAS 명령어로 원자적 비교-교체. 락 없음.
updateAndGet: CAS 루프. 실패하면 최신 값으로 재시도.

사용 사례

1. lock-free 단일 객체 swap

private final AtomicReference<Snapshot> snapshot = new AtomicReference<>();

// Writer (단일 스레드 또는 드물게)
snapshot.set(takeSnapshot());

// Reader (여러 스레드, lock-free)
Snapshot s = snapshot.get();
process(s);

2. 상태 머신


enum State { READY, RUNNING, STOPPED }

class Service {
    private final AtomicReference<State> state =
        new AtomicReference<>(State.READY);

    // READY -> RUNNING 전이 (한 스레드만 성공)
    public boolean start() {
        return state.compareAndSet(State.READY, State.RUNNING);
    }

    // RUNNING -> STOPPED 전이
    public boolean stop() {
        return state.compareAndSet(State.RUNNING, State.STOPPED);
    }

    public State getState() {
        return state.get();
    }
}

3. lock-free 자료구조의 노드 포인터

class Node<E> {
    final E value;
    final AtomicReference<Node<E>> next;

    Node(E value) {
        this.value = value;
        this.next = new AtomicReference<>(null);
    }
}

// ConcurrentLinkedQueue 의 내부 패턴

[[ConcurrentLinkedQueue]] 의 internal pattern.

Java 17+ 실전: 초기화 경쟁 방지


// 비용이 큰 객체를 한 번만 초기화 (lazy init)
class ExpensiveResource {
    private final AtomicReference<Resource> ref = new AtomicReference<>();

    Resource get() {
        Resource existing = ref.get();
        if (existing != null) return existing;

        // 여러 스레드가 동시에 도달할 수 있음
        Resource created = new Resource();   // 비용이 큰 생성
        if (ref.compareAndSet(null, created)) {
            return created;   // 이 스레드가 초기화 성공
        } else {
            created.close();  // 다른 스레드가 먼저 초기화 → 버림
            return ref.get();
        }
    }
}

Java 17+ 실전: 설정 핫 리로드



record AppConfig(
    String dbUrl,
    int maxConnections,
    Duration timeout
) {}

class ConfigManager {
    private final AtomicReference<AppConfig> config;
    private final ScheduledExecutorService scheduler =
        Executors.newSingleThreadScheduledExecutor();

    ConfigManager(AppConfig initial) {
        this.config = new AtomicReference<>(initial);
        // 30초마다 설정 리로드
        scheduler.scheduleAtFixedRate(this::reload, 30, 30, TimeUnit.SECONDS);
    }

    // 여러 스레드에서 lock-free 읽기
    public AppConfig current() {
        return config.get();
    }

    private void reload() {
        try {
            AppConfig newConfig = loadFromFile();
            AppConfig old = config.getAndSet(newConfig);
            System.out.println("Config reloaded: " + old + " -> " + newConfig);
        } catch (Exception e) {
            System.err.println("Config reload failed: " + e.getMessage());
        }
    }
}

ABA 문제와 해법

CAS 의 고전적 문제: A -> B -> A 로 변경됐을 때 CAS 가 변경을 감지 못함.

// ABA 시나리오
// 1. 스레드 A: ref.get() = "A"
// 2. 스레드 B: ref.set("B"), ref.set("A")  (A -> B -> A)
// 3. 스레드 A: ref.compareAndSet("A", "C") 성공 (변경 감지 못함)

해법:

AtomicStampedReference<V>: stamp (int 버전) 추가


AtomicStampedReference<String> ref =
    new AtomicStampedReference<>("A", 0);

int[] stampHolder = new int[1];
String current = ref.get(stampHolder);   // current="A", stamp=0

// stamp 도 함께 비교 → ABA 감지
boolean success = ref.compareAndSet(
    current, "C",
    stampHolder[0], stampHolder[0] + 1   // stamp 증가
);

AtomicMarkableReference<V>: boolean mark 추가 (삭제 표시 등)


AtomicMarkableReference<Node> ref =
    new AtomicMarkableReference<>(node, false);

// 논리적 삭제 표시
ref.compareAndSet(node, node, false, true);   // mark = true (삭제됨)

AtomicReference vs volatile vs synchronized

항목	`volatile`	`AtomicReference`	`synchronized`
가시성	✓	✓	✓
원자적 복합 연산	✗	✓ (CAS)	✓
락	없음	없음 (CAS)	있음
성능	가장 빠름	빠름	느림 (경합 시)
용도	단순 읽기/쓰기	CAS 필요	복잡한 임계 구역

함정

1. updateAndGet 의 람다는 순수 함수여야 함

// 위험: 람다에 부작용 (side effect) 있으면 재시도 시 중복 실행
ref.updateAndGet(c -> {
    log.info("updating");   // CAS 실패 시 여러 번 실행될 수 있음
    return c.withVersion(c.version() + 1);
});

// 올바름: 순수 함수만 사용
ref.updateAndGet(c -> c.withVersion(c.version() + 1));

2. 가변 객체를 AtomicReference 에 넣으면 의미 없음

// 위험: 참조는 atomic 하게 교체되지만 객체 내부는 보호 안 됨
AtomicReference<List<String>> ref = new AtomicReference<>(new ArrayList<>());
ref.get().add("item");   // 비원자적! 다른 스레드와 경쟁

불변 객체 를 AtomicReference 에 넣어야 의미가 있다.

3. compareAndSet 실패 루프 없이 사용

// 위험: 실패 시 처리 없음
ref.compareAndSet(old, newVal);   // 실패해도 모름

// 올바름: 성공 여부 확인 또는 updateAndGet 사용
if (!ref.compareAndSet(old, newVal)) {
    // 실패 처리
}
// 또는
ref.updateAndGet(v -> computeNew(v));   // 자동 재시도

[Java] ConcurrentSkipListMap

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.ConcurrentSkipListMap<K,V> 는 Skip List 기반의 thread-safe 정렬 [[Map]]. [[TreeMap]] 의 동시성 버전.

[[ConcurrentHashMap]] 과의 결정적 차이: 정렬 순서를 유지 + ConcurrentNavigableMap 인터페이스 구현 (floor, ceiling, subMap 등).

Skip List 는 평균 O(log n) 의 균형 트리 대체 자료구조. 락 없이 동시 수정이 가능한 알고리즘이 잘 알려져 있어 동시성 구현에 적합.

JDK 1.6 도입.

언제 쓰나

정렬 + 동시성: 여러 스레드가 동시에 읽고 쓰면서 정렬 순서가 필요할 때
Range 쿼리 + 동시성: subMap, headMap, tailMap 으로 범위 조회가 필요할 때
시간순 이벤트 로그: 타임스탬프 기준 정렬, 최근 N 초 이벤트 조회
계단식 요금/등급 룩업: floorEntry 로 구간 매핑
리더보드: 점수 기준 정렬, 상위 N 명 조회

시각화: Skip List 구조

flowchart TD
    subgraph "Level 3 (sparse)"
        H3["head"] --> N25_3["25"] --> T3["null"]
    end
    subgraph "Level 2"
        H2["head"] --> N10_2["10"] --> N25_2["25"] --> N40_2["40"] --> T2["null"]
    end
    subgraph "Level 1"
        H1["head"] --> N5_1["5"] --> N10_1["10"] --> N17_1["17"] --> N25_1["25"] --> N40_1["40"] --> T1["null"]
    end
    subgraph "Level 0 (base)"
        H0["head"] --> N5_0["5"] --> N10_0["10"] --> N17_0["17"] --> N25_0["25"] --> N33_0["33"] --> N40_0["40"] --> T0["null"]
    end

각 노드가 확률적으로 여러 레벨에 포함 (1/2 확률로 한 레벨씩 위로)
상위 레벨은 “스킵 인덱스” 처럼 작용해 O(log n) 검색
새 노드 삽입 시 동전 던지듯 레벨 결정

시각화: floor/ceiling/subMap 동작

flowchart LR
    subgraph "ConcurrentSkipListMap keys: 5, 10, 17, 25, 33, 40"
        direction LR
        K5["5"] --- K10["10"] --- K17["17"] --- K25["25"] --- K33["33"] --- K40["40"]
    end

    F["floorKey(22)\n22 이하 최대 = 17"] --> K17
    C["ceilingKey(22)\n22 이상 최소 = 25"] --> K25
    Sub["subMap(10, 30)\n= {10, 17, 25}"] --> K10

핵심 NavigableMap 메서드



ConcurrentSkipListMap<Integer, String> map = new ConcurrentSkipListMap<>();
map.put(10, "ten");
map.put(25, "twenty-five");
map.put(40, "forty");
map.put(5, "five");

// 경계값 조회
map.firstKey();              // 5 (최솟값)
map.lastKey();               // 40 (최댓값)

// 인접 키 탐색
map.floorKey(22);            // 10 (22 이하 최대)
map.ceilingKey(22);          // 25 (22 이상 최소)
map.lowerKey(25);            // 10 (25 미만 최대)
map.higherKey(25);           // 40 (25 초과 최소)

// 범위 view (live view, 동시 수정 반영)
ConcurrentNavigableMap<Integer, String> sub = map.subMap(10, true, 30, false);
ConcurrentNavigableMap<Integer, String> head = map.headMap(25, false);
ConcurrentNavigableMap<Integer, String> tail = map.tailMap(25, true);

// 역순 view
ConcurrentNavigableMap<Integer, String> desc = map.descendingMap();

내부 구현: lock-free CAS

// 단순화된 내부 구조
class ConcurrentSkipListMap<K,V> {
    // 각 노드는 여러 레벨의 next 포인터를 가짐
    static final class Node<K,V> {
        final K key;
        volatile Object value;   // volatile: 가시성 보장
        volatile Node<K,V> next; // CAS 대상
    }

    static final class Index<K,V> {
        final Node<K,V> node;
        final Index<K,V> down;   // 아래 레벨
        volatile Index<K,V> right; // CAS 대상
    }
}

삽입: CAS 로 노드를 base level 에 추가 후, 확률적으로 상위 레벨 인덱스 추가
삭제: 논리적 삭제 (value 를 null 로 CAS) 후 물리적 제거
검색: 상위 레벨부터 내려오며 스킵, 락 없음

복잡도

작업	평균	최악
`get`, `put`, `remove`	O(log n)	O(n) (매우 드뭄)
`firstKey`, `lastKey`	O(1)	O(1)
`floorKey`, `ceilingKey`	O(log n)	O(n)
`subMap` (view 생성)	O(log n)	O(n)
순회	O(n)	O(n)
`size()`	O(n)	O(n)

[!WARNING] size() 는 O(n) 이다. 크기를 자주 확인해야 한다면 별도 AtomicInteger 카운터를 유지하는 것이 낫다.

스레드 안전성

완전 lock-free: 읽기/쓰기 모두 CAS 기반. 락 없음.
weakly consistent iterator: 순회 중 다른 스레드가 수정해도 [[ConcurrentModificationException]] 없음. 단, 수정 내용이 반영될 수도 있고 안 될 수도 있음.
원자적 복합 연산: putIfAbsent, replace, remove(key, value) 모두 원자적.

ConcurrentSkipListMap<String, Integer> scores = new ConcurrentSkipListMap<>();

// 원자적 복합 연산
scores.putIfAbsent("alice", 100);
scores.replace("alice", 100, 150);   // CAS: 100 이면 150 으로
scores.merge("alice", 10, Integer::sum);   // 없으면 10, 있으면 합산

Java 17+ 실전: 시간순 이벤트 로그



record Event(String type, String payload) {}

class EventLog {
    private final ConcurrentSkipListMap<Instant, Event> log =
        new ConcurrentSkipListMap<>();

    // 여러 스레드에서 동시에 이벤트 추가
    void record(Event event) {
        log.put(Instant.now(), event);
    }

    // 최근 N 초 이벤트 조회 (live view)
    ConcurrentNavigableMap<Instant, Event> recent(int seconds) {
        return log.tailMap(Instant.now().minusSeconds(seconds));
    }

    // 특정 시간 범위 이벤트
    ConcurrentNavigableMap<Instant, Event> between(Instant from, Instant to) {
        return log.subMap(from, true, to, true);
    }

    // 오래된 이벤트 정리
    void evictBefore(Instant cutoff) {
        log.headMap(cutoff).clear();
    }
}

Java 17+ 실전: 계단식 요금 룩업


// 동시성 환경에서 계단식 요금 조회
// 0원 이상: 0%, 1000원 이상: 5%, 5000원 이상: 10%, 10000원 이상: 15%
class PricingTable {
    private final ConcurrentSkipListMap<Integer, Integer> table =
        new ConcurrentSkipListMap<>();

    PricingTable() {
        table.put(0,     0);
        table.put(1000,  5);
        table.put(5000,  10);
        table.put(10000, 15);
    }

    int getDiscountRate(int amount) {
        var entry = table.floorEntry(amount);
        return entry != null ? entry.getValue() : 0;
    }

    // 동적으로 요금 구간 추가/수정 (thread-safe)
    void updateRate(int threshold, int rate) {
        table.put(threshold, rate);
    }
}

Java 17+ 실전: 동시성 리더보드


// 점수 기준 정렬 리더보드 (여러 스레드에서 동시 업데이트)
class Leaderboard {
    // key: 점수 (내림차순), value: 플레이어 이름
    private final ConcurrentSkipListMap<Integer, String> board =
        new ConcurrentSkipListMap<>(java.util.Comparator.reverseOrder());

    void updateScore(String player, int score) {
        // 기존 점수 제거 후 새 점수 추가 (단순화)
        board.put(score, player);
    }

    // 상위 N 명 조회
    List<Map.Entry<Integer, String>> topN(int n) {
        return board.entrySet().stream()
            .limit(n)
            .toList();
    }

    // 특정 점수 이상 플레이어
    ConcurrentNavigableMap<Integer, String> aboveScore(int minScore) {
        return board.headMap(minScore, true);   // 내림차순이므로 headMap
    }
}

ConcurrentHashMap vs ConcurrentSkipListMap

항목	[[ConcurrentHashMap]]	ConcurrentSkipListMap
`get`/`put` 시간	O(1) 평균	O(log n)
순서	없음	정렬
Range 쿼리	✗	✓ (`subMap` 등)
`floor`/`ceiling`	✗	✓
`size()`	O(1)	O(n)
동시성 메커니즘	CAS + 버킷 sync	lock-free skip list
null key/value	✗	✗

순서가 중요하지 않으면 [[ConcurrentHashMap]], 정렬/범위 쿼리가 필요하면 ConcurrentSkipListMap.

함정

1. size() 는 O(n)

// 위험: 루프 안에서 size() 반복 호출
while (map.size() > 0) {   // 매번 O(n) 순회
    map.pollFirstEntry();
}

// 올바름: isEmpty() 사용 (O(1))
while (!map.isEmpty()) {
    map.pollFirstEntry();
}

2. null key/value 불허

ConcurrentSkipListMap<String, Integer> map = new ConcurrentSkipListMap<>();
map.put(null, 1);    // NullPointerException
map.put("a", null);  // NullPointerException

3. subMap view 는 live view

ConcurrentNavigableMap<Integer, String> sub = map.subMap(10, 30);
// sub 를 통한 수정은 원본 map 에 반영됨
sub.put(20, "twenty");   // map 에도 추가됨
sub.put(50, "fifty");    // IllegalArgumentException (범위 밖)

4. weakly consistent iterator

// 순회 중 다른 스레드가 추가한 원소가 보일 수도, 안 보일 수도 있음
for (Map.Entry<Integer, String> e : map.entrySet()) {
    // 다른 스레드가 map.put(99, "x") 해도 CME 없음
    // 단, 99 가 이 순회에서 보일지는 보장 안 됨
}

[Java] CopyOnWriteArrayList

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.CopyOnWriteArrayList 는 쓰기 시 배열 전체를 복사 하는 thread-safe [[List]] 구현. 읽기에는 lock 이 전혀 없고, 쓰기에는 ReentrantLock 으로 직렬화한다.

java.util.concurrent (JSR-166) 의 컬렉션. 읽기 압도적 다, 쓰기 거의 없음 인 시나리오 (예: 이벤트 리스너 목록, 옵저버 패턴, 설정 캐시) 에 가장 적합.

사용 상황

패턴	이유
이벤트 리스너 목록	리스너 등록/해제 드묾, 이벤트 발화 빈번
옵저버 패턴 구독자 목록	subscribe/unsubscribe 드묾, notify 빈번
설정 캐시	변경 드묾, 읽기 매우 빈번
순회 중 수정이 필요한 경우	CME 없이 안전한 순회 보장

쓰기가 잦거나 컬렉션이 크면 절대 사용 금지. 쓰기마다 O(n) 배열 복사가 발생한다.

시각화

{}

내부 구조

public class CopyOnWriteArrayList<E>
    implements List<E>, RandomAccess, Cloneable, java.io.Serializable {

    final transient ReentrantLock lock = new ReentrantLock();
    private transient volatile Object[] array;

    final Object[] getArray() { return array; }
    final void setArray(Object[] a) { array = a; }
}

핵심 두 가지.

array 는 volatile: 한 스레드의 setArray() 가 다른 스레드의 getArray() 에 즉시 보인다. 별도 락 없이 새 배열 참조가 publish 된다.
lock 은 쓰기 직렬화용: 동시에 두 쓰기가 진행되지 않도록만 보장. 읽기에는 관여하지 않는다.

읽기: lock 없이

public E get(int index) {
    return elementAt(getArray(), index);
}

getArray() 로 현재 배열 참조를 한 번 읽고, 그 배열의 인덱스 자리를 반환한다. lock 도, 동기화 블록도 없다.

스레드가 100 개라도 모두 자기 CPU 의 캐시로 volatile 읽기 1 번을 수행할 뿐. 사실상 [[ArrayList]] 만큼 빠르다.

쓰기: 전체 복사

public boolean add(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        int len = elements.length;
        Object[] newElements = Arrays.copyOf(elements, len + 1);  // O(n) 복사
        newElements[len] = e;
        setArray(newElements);   // volatile 쓰기로 publish
        return true;
    } finally {
        lock.unlock();
    }
}

락 획득: 다른 쓰기를 막는다 (읽기는 그대로 진행 가능)
Arrays.copyOf: 전체 배열을 통째로 복사. O(n) 비용.
수정: 새 배열에 원소 추가
setArray: 새 배열 참조로 교체. 이 한 순간에 모든 후속 읽기가 새 배열을 보게 된다.

remove, set 도 같은 패턴. 모든 쓰기가 O(n) 복사 를 동반한다.

Copy-On-Write 쓰기 흐름

flowchart TD
    W["add() / remove() / set() 호출"] --> Lock["ReentrantLock 획득"]
    Lock --> Copy["기존 배열 전체 복사\nArrays.copyOf = O(n)"]
    Copy --> Modify["새 배열 수정"]
    Modify --> Publish["array = 새 배열\n(volatile 쓰기)"]
    Publish --> Unlock["락 해제"]
    Unlock --> Done["완료"]
    R1["읽기 스레드 1\nget() / iterator()"] -.->|"락 없음"| OldArr["기존 배열 참조 유지"]
    R2["읽기 스레드 2"] -.->|"Publish 이후"| NewArr["새 배열 참조"]

읽기 스레드는 쓰기와 완전히 분리되어 실행된다. Publish 시점 이전에 배열을 읽은 스레드는 기존 배열을, 이후는 새 배열을 본다.

주요 연산 비용

메서드	시간	락	비고
`get(int i)`	O(1)	없음	volatile read 1 번
`size()`	O(1)	없음
`iterator()`	O(1)	없음	snapshot 반환
`add(E)`	O(n)	쓰기 락	배열 전체 복사
`add(int i, E)`	O(n)	쓰기 락	복사 + shift
`remove(int i)`	O(n)	쓰기 락	복사 + shift
`set(int i, E)`	O(n)	쓰기 락	한 자리만 바뀌어도 복사
`addAll(Collection)`	O(n + m)	쓰기 락 한 번	묶어서 처리

[!TIP] 여러 원소를 한 번에 추가할 때는 addAll(...) 을 쓰자. 각각 add 하면 n 회의 전체 복사가 발생하지만, addAll 은 한 번의 복사로 끝난다.

Snapshot Iterator

CopyOnWriteArrayList 의 iterator 는 생성 시점의 배열 참조를 그대로 들고 다닌다.

List<String> list = new CopyOnWriteArrayList<>(List.of("A", "B", "C"));

Iterator<String> it = list.iterator();
list.add("D");                      // 새 배열로 교체됨
while (it.hasNext()) {
    System.out.println(it.next());  // A, B, C 만 출력 (D 는 보이지 않음)
}

장점:

ConcurrentModificationException 없음: 순회 중 다른 스레드가 수정해도 안전
순회 중 수정 자유: 수정 내용은 다음 iterator() 부터 반영

단점:

it.remove(), it.set(E), it.add(E) 모두 UnsupportedOperationException: iterator 는 read-only

실전 패턴: 이벤트 리스너

// Java 17+
public class EventBus<T> {
    private final CopyOnWriteArrayList<Consumer<T>> listeners =
        new CopyOnWriteArrayList<>();

    public void subscribe(Consumer<T> listener) {
        listeners.add(listener);       // 드물게 호출, O(n) 복사 OK
    }

    public void unsubscribe(Consumer<T> listener) {
        listeners.remove(listener);    // 드물게 호출
    }

    public void publish(T event) {
        // 발화는 빈번, lock 없이 빠르게 순회
        for (Consumer<T> listener : listeners) {
            listener.accept(event);
        }
    }
}

publish 호출 도중 unsubscribe 가 와도 CME 없이 안전하게 처리된다. unsubscribe 는 새 배열을 만들어 교체하고, 현재 진행 중인 publish 는 기존 배열 스냅샷을 계속 사용.

실전 패턴: 옵저버

public class Config {
    private volatile String value = "default";
    private final CopyOnWriteArrayList<Runnable> changeListeners =
        new CopyOnWriteArrayList<>();

    public void addChangeListener(Runnable listener) {
        changeListeners.add(listener);
    }

    public void update(String newValue) {
        this.value = newValue;
        // 변경 이벤트 발화 (순회 중 리스너 추가/제거 안전)
        changeListeners.forEach(Runnable::run);
    }

    public String get() { return value; }
}

읽기/쓰기 분리 모델

flowchart LR
    subgraph Readers["읽기 (무한 동시)"]
        R1["스레드 1\nget()"] 
        R2["스레드 2\niterator()"]
        R3["스레드 3\nsize()"]
    end
    subgraph Array["volatile array 참조"]
        Arr["현재 배열"]
    end
    subgraph Writers["쓰기 (직렬화)"]
        W1["스레드 A\nadd()"] --> WLock["ReentrantLock"]
        W2["스레드 B\nremove()"] --> WLock
    end
    R1 & R2 & R3 -->|"lock 없음"| Arr
    WLock --> NewArr["새 배열 생성 후\narray 교체"]
    NewArr -.->|"다음 읽기부터"| Arr

메모리 관점

쓰기가 일어날 때마다 두 배열이 동시에 존재 한다 (기존 + 새것). GC 가 기존 배열을 회수할 때까지는 메모리 2 배 사용.

또한 진행 중인 iterator 가 기존 배열을 참조하고 있다면 그것도 살아 있어야 한다. 긴 iterator 가 많은 환경에서는 메모리 사용량이 더 늘어날 수 있다.

// 1000 개 원소 리스트에 매초 100 번 add:
// 매초 100 회 복사 = 100_000 개 원소 복사/초 = 잠재적 GC 부담
// 이런 워크로드에서는 CopyOnWriteArrayList 금지

[!IMPORTANT] 1000 개 원소 리스트에 매초 100 번 add 한다면 CoW 는 매초 100,000 회 배열 복사 = 10MB+ 메모리 트래픽. 이런 워크로드에서는 사용 금지.

언제 CopyOnWriteArrayList 가 답인가

읽기 >> 쓰기 시나리오에서 최적이다.

패턴	적합도
이벤트 리스너 목록 (등록 드물고 발화 잦음)	최적
옵저버 패턴 구독자 목록	최적
설정 / 메타데이터 캐시 (변경 드묾)	최적
읽기 위주의 작은 리스트	적합
쓰기 빈도 적당, 컬렉션이 작음	주의
쓰기 빈도 높음 / 컬렉션 큼	부적합

다른 동시성 List 와의 비교

옵션	읽기	쓰기	메모리	iterator
CopyOnWriteArrayList	lock-free	O(n) 복사	쓰기 시 2x	snapshot, CME 없음
`Collections.synchronizedList(arraylist)`	락	락	동일	외부 동기화 필요, fail-fast
[[Vector]]	락	락	동일	외부 동기화 필요, fail-fast
`ConcurrentLinkedDeque`	lock-free	lock-free	노드 오버헤드	weakly consistent

함정

1. iterator 로 수정 시도

Iterator<String> it = list.iterator();
it.remove();   // UnsupportedOperationException

CoW iterator 는 read-only. 수정하려면 list.remove(...) 를 직접 호출.

2. 쓰기 루프에서의 비용

// 매우 느림: n 회 전체 복사
for (String item : newItems) {
    list.add(item);   // 매번 O(n) 복사
}

// 올바름: 한 번만 복사
list.addAll(newItems);

3. 배열이 교체되는 타이밍 오해

Iterator<String> it = list.iterator();  // 스냅샷 생성
list.add("X");                           // 새 배열로 교체
// it 는 여전히 이전 배열을 본다
// "X" 는 이 iterator 로 볼 수 없음

현재 상태가 필요하면 list.iterator() 를 다시 호출해야 한다.

4. 크기 기반 최신성

int size = list.size();   // snapshot 시점의 크기
for (int i = 0; i < size; i++) {
    list.get(i);          // 다른 스레드가 remove 했으면 AIOOBE 가능
}

// 올바름: for-each (내부 배열을 고정해 순회)
for (String s : list) { ... }

[Java] CountDownLatch

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.CountDownLatch 는 한 스레드 또는 여러 스레드가 다른 스레드들의 작업 완료를 기다리는 일회용 synchronizer.

N 으로 초기화하고, 각 worker 가 작업 후 countDown() 호출. waiter 는 await() 로 count 가 0 이 될 때까지 [[Blocking]]. 0 이 되면 다시 1 로 돌릴 수 없음, 일회용.

JDK 1.5 도입. AbstractQueuedSynchronizer (AQS) 를 기반으로 구현된다.

언제 쓰나

N 개 작업 완료 대기: main 스레드가 병렬 작업 전체가 끝날 때까지 기다릴 때
시작 신호 (start gate): 여러 스레드를 동시에 출발시킬 때 (부하 테스트 등)
초기화 완료 대기: 서비스 시작 전 의존 컴포넌트가 모두 준비될 때까지 대기
일회성 이벤트: 재사용이 필요 없는 단순 동기화 지점

[!IMPORTANT] 재사용이 필요하면 [[CyclicBarrier]] 또는 [[Phaser]] 를 사용. CountDownLatch 는 count 가 0 이 된 후 재설정 불가.

시각화: N 개 작업 완료 대기

sequenceDiagram
    participant M as "Main 스레드"
    participant L as "CountDownLatch(3)"
    participant W1 as "Worker 1"
    participant W2 as "Worker 2"
    participant W3 as "Worker 3"

    M->>L: await() - count=3, 블록
    W1->>L: countDown() - count=2
    W2->>L: countDown() - count=1
    W3->>L: countDown() - count=0
    L-->>M: count=0, 깨어남
    Note over M: 모든 작업 완료 후 진행

시각화: 시작 신호 (start gate)

sequenceDiagram
    participant M as "Main 스레드"
    participant G as "CountDownLatch(1)"
    participant T1 as "Thread 1"
    participant T2 as "Thread 2"
    participant T3 as "Thread 3"

    T1->>G: await() - 대기
    T2->>G: await() - 대기
    T3->>G: await() - 대기
    Note over M: 모든 스레드 준비 확인
    M->>G: countDown() - count=0
    G-->>T1: 동시 출발
    G-->>T2: 동시 출발
    G-->>T3: 동시 출발

핵심 메서드

CountDownLatch latch = new CountDownLatch(N);

latch.countDown();                      // count - 1 (0 이하로 내려가지 않음)
latch.await();                          // count == 0 될 때까지 block
boolean done = latch.await(5, TimeUnit.SECONDS);  // timeout 있는 대기
latch.getCount();                       // 현재 count (참고용, 동기화 목적 사용 금지)

가장 흔한 두 패턴

1. main 스레드가 N 개 작업 완료 대기


int N = 5;
ExecutorService pool = Executors.newFixedThreadPool(N);
CountDownLatch done = new CountDownLatch(N);

for (int i = 0; i < N; i++) {
    final int taskId = i;
    pool.submit(() -> {
        try {
            doWork(taskId);
        } finally {
            done.countDown();   // 반드시 finally: 예외 발생해도 countDown 보장
        }
    });
}

done.await();   // 모든 작업 끝날 때까지 block
pool.shutdown();
System.out.println("all done");

2. 시작 신호 (start gate)


int N = 10;
CountDownLatch startGate = new CountDownLatch(1);
CountDownLatch endGate = new CountDownLatch(N);

for (int i = 0; i < N; i++) {
    Thread.ofVirtual().start(() -> {
        try {
            startGate.await();   // start 신호 대기
            run();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            endGate.countDown();
        }
    });
}

// 모든 스레드가 준비됐을 때 동시 출발
startGate.countDown();
endGate.await();   // 모든 스레드 완료 대기

부하 테스트 도구 (JMeter, Gatling 의 ramp-up) 와 비슷한 패턴.

내부 구현: AQS 기반

CountDownLatch 는 AbstractQueuedSynchronizer (AQS) 의 공유 모드를 사용한다.

public class CountDownLatch {
    private static final class Sync extends AbstractQueuedSynchronizer {
        Sync(int count) {
            setState(count);   // AQS state = count
        }

        // tryAcquireShared: state == 0 이면 통과 (1), 아니면 대기 (-1)
        protected int tryAcquireShared(int acquires) {
            return (getState() == 0) ? 1 : -1;
        }

        // tryReleaseShared: CAS 로 state - 1, 0 이 되면 true (대기자 깨움)
        protected boolean tryReleaseShared(int releases) {
            for (;;) {
                int c = getState();
                if (c == 0) return false;
                int nextc = c - 1;
                if (compareAndSetState(c, nextc))
                    return nextc == 0;
            }
        }
    }

    private final Sync sync;

    public CountDownLatch(int count) {
        this.sync = new Sync(count);
    }

    public void await() throws InterruptedException {
        sync.acquireSharedInterruptibly(1);
    }

    public void countDown() {
        sync.releaseShared(1);
    }
}

countDown(): CAS 로 state 를 1 감소. 0 이 되면 AQS 대기 큐의 모든 스레드를 깨운다.
await(): state 가 0 이 아니면 AQS 대기 큐에 진입해 park.
count 가 0 이 된 후 추가 countDown() 은 무시 (state 가 이미 0).

성능과 스레드 안전성

countDown(): CAS 연산 하나. 락 없음. 매우 빠름.
await(): state 가 0 이면 즉시 반환 (락 없음). 0 이 아니면 LockSupport.park() 로 블록.
여러 스레드가 동시에 countDown() 해도 안전: CAS 루프로 직렬화.
여러 스레드가 동시에 await() 해도 안전: count 가 0 이 되면 모두 동시에 깨어남.

Java 17+ 실전: 서비스 초기화 대기


// 여러 서비스가 모두 준비될 때까지 대기
class ServiceOrchestrator {
    private final CountDownLatch ready;
    private final List<String> errors = new CopyOnWriteArrayList<>();

    ServiceOrchestrator(int serviceCount) {
        this.ready = new CountDownLatch(serviceCount);
    }

    void registerService(String name, Callable<Void> initializer) {
        Thread.ofVirtual().start(() -> {
            try {
                initializer.call();
                System.out.println(name + " ready");
            } catch (Exception e) {
                errors.add(name + ": " + e.getMessage());
            } finally {
                ready.countDown();   // 성공/실패 모두 countDown
            }
        });
    }

    boolean awaitReady(long timeout, TimeUnit unit) throws InterruptedException {
        boolean allDone = ready.await(timeout, unit);
        if (!errors.isEmpty()) {
            throw new IllegalStateException("Init errors: " + errors);
        }
        return allDone;
    }
}

Java 17+ 실전: 병렬 데이터 수집



// 여러 소스에서 병렬로 데이터 수집 후 집계
record FetchResult(String source, List<String> data) {}

List<FetchResult> parallelFetch(List<String> sources) throws InterruptedException {
    CountDownLatch latch = new CountDownLatch(sources.size());
    List<FetchResult> results = new CopyOnWriteArrayList<>();

    for (String source : sources) {
        Thread.ofVirtual().start(() -> {
            try {
                List<String> data = fetchFrom(source);
                results.add(new FetchResult(source, data));
            } catch (Exception e) {
                results.add(new FetchResult(source, List.of()));
            } finally {
                latch.countDown();
            }
        });
    }

    latch.await(30, TimeUnit.SECONDS);
    return List.copyOf(results);
}

CountDownLatch vs CyclicBarrier vs Phaser

항목	CountDownLatch	[[CyclicBarrier]]	[[Phaser]]
사용 횟수	일회용	재사용 가능	재사용 가능
누가 기다리는가	한 명 또는 여러 명	모두가 서로 기다림	동적 참여자
도착 콜백	없음	barrier action	onAdvance()
참여자 수	고정	고정	동적 변경 가능
reset	불가	`reset()` 가능	자동
복잡도	단순	중간	복잡

CountDownLatch 는 비대칭 (1 -> N 또는 N -> 1), CyclicBarrier 는 대칭 (N -> N 만남).

함정

1. 0 이후 다시 못 쓴다

CountDownLatch latch = new CountDownLatch(1);
latch.countDown();   // count = 0
// latch 재사용 불가. 새 CountDownLatch 생성 필요
// 재사용이 필요하면 CyclicBarrier 또는 Phaser 사용

2. countDown 빠뜨리면 영원히 block

// 위험: 예외 발생 시 countDown 미호출
pool.submit(() -> {
    doWork();           // 예외 발생 가능
    done.countDown();   // 예외 발생 시 실행 안 됨 → main 영원히 대기
});

// 올바름: finally 에서 countDown
pool.submit(() -> {
    try {
        doWork();
    } finally {
        done.countDown();   // 항상 실행
    }
});

3. timeout 없는 await 는 위험

// 위험: worker 가 영원히 끝나지 않으면 main 도 영원히 대기
latch.await();

// 올바름: timeout 지정
boolean completed = latch.await(30, TimeUnit.SECONDS);
if (!completed) {
    // 타임아웃 처리
    throw new TimeoutException("작업이 30초 내에 완료되지 않음");
}

4. getCount() 로 동기화 판단 금지

// 위험: getCount() 는 스냅샷, 확인 후 상태가 바뀔 수 있음
if (latch.getCount() == 0) {
    // 이 시점에 count 가 다시 0 이 아닐 수 있음 (실제로는 불가하지만 패턴 자체가 위험)
    proceed();
}

// 올바름: await() 사용
latch.await();
proceed();

[Java] DelayQueue

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.DelayQueue<E extends Delayed> 는 각 원소가 지정된 delay 가 만료된 후에만 꺼낼 수 있는 [[java-blocking-queue|BlockingQueue]]. 우선순위는 만료 시각이 빠른 것부터.

내부는 [[java-priorityqueue|PriorityQueue]] (min-heap). 단일 [[java-reentrant-lock|ReentrantLock]] 으로 thread-safe.

사용 상황

TTL 캐시: 만료된 항목을 별도 스레드가 주기적으로 정리
재시도 큐 (retry queue): 실패한 요청을 일정 시간 뒤 재시도
작업 스케줄러: ScheduledThreadPoolExecutor 와 유사한 단순 구현
세션 만료: 로그인 세션, 인증 토큰 만료 처리

시각화: 시간 기반 꺼내기

flowchart LR
    subgraph queue["DelayQueue (min-heap by expiresAt)"]
        A["Task A\nexpiresAt: T+1s"]
        B["Task B\nexpiresAt: T+3s"]
        C["Task C\nexpiresAt: T+5s"]
        A --> B --> C
    end
    TAKE["take()"] -->|"T+1s 도달 시 반환"| A
    TAKE -->|"T+3s 도달 시 반환"| B
    TAKE -->|"T+5s 도달 시 반환"| C

Delayed 인터페이스

원소는 Delayed 인터페이스를 구현해야 한다.

public interface Delayed extends Comparable<Delayed> {
    long getDelay(TimeUnit unit);
}

getDelay 는 남은 시간 을 반환. 0 이하가 되면 take 가능. compareTo 는 힙 정렬에 사용.

// Java 17+: record 기반 구현
record DelayedTask(String name, long readyAt, Runnable job)
        implements Delayed {

    DelayedTask(String name, long delayMs, Runnable job) {
        this(name, System.currentTimeMillis() + delayMs, job);
    }

    @Override
    public long getDelay(TimeUnit unit) {
        return unit.convert(readyAt - System.currentTimeMillis(), TimeUnit.MILLISECONDS);
    }

    @Override
    public int compareTo(Delayed o) {
        return Long.compare(this.readyAt, ((DelayedTask) o).readyAt());
    }
}

동작

DelayQueue<DelayedTask> q = new DelayQueue<>();
q.put(new DelayedTask("slow", 5000, () -> System.out.println("5초 뒤")));
q.put(new DelayedTask("fast", 1000, () -> System.out.println("1초 뒤")));

// take() 는 만료 순으로 반환: 1s -> 5s
DelayedTask t = q.take();   // 1초 대기 후 "fast" 반환
t.job().run();
t = q.take();               // 추가 4초 대기 후 "slow" 반환
t.job().run();

take() 는 큐의 head 원소의 getDelay 가 0 이하가 될 때까지 block.

복잡도

내부는 [[java-priorityqueue|PriorityQueue]] (heap).

작업	시간
`put`, `offer`	O(log n)
`take`, `poll`	O(log n)
`peek`	O(1)
`size`	O(1)

실전 코드: TTL 캐시

public class TtlCache<K, V> {
    private final Map<K, V> store = new ConcurrentHashMap<>();
    private final DelayQueue<ExpiryKey<K>> expirations = new DelayQueue<>();

    // 만료 키 추적
    record ExpiryKey<K>(K key, long expiresAt) implements Delayed {
        ExpiryKey(K key, long ttlMs) {
            this(key, System.currentTimeMillis() + ttlMs);
        }

        @Override
        public long getDelay(TimeUnit unit) {
            return unit.convert(expiresAt - System.currentTimeMillis(), MILLISECONDS);
        }

        @Override
        public int compareTo(Delayed o) {
            return Long.compare(expiresAt, ((ExpiryKey<?>) o).expiresAt());
        }
    }

    public TtlCache() {
        // 만료 스캔 스레드 (데몬)
        Thread sweeper = Thread.ofVirtual().start(() -> {
            while (!Thread.currentThread().isInterrupted()) {
                try {
                    ExpiryKey<K> expired = expirations.take();
                    store.remove(expired.key());
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
    }

    public void put(K key, V value, long ttlMs) {
        store.put(key, value);
        expirations.offer(new ExpiryKey<>(key, ttlMs));
    }

    public V get(K key) {
        return store.get(key);
    }
}

실전 코드: 지수 백오프 Retry 큐

// 실패한 요청을 점점 늘어나는 간격으로 재시도
record RetryTask(String id, int attempt, Runnable job, long readyAt)
        implements Delayed {

    static RetryTask of(String id, int attempt, Runnable job) {
        long delay = (long) Math.pow(2, attempt) * 500;  // 500ms, 1s, 2s, 4s...
        return new RetryTask(id, attempt, job, System.currentTimeMillis() + delay);
    }

    @Override
    public long getDelay(TimeUnit unit) {
        return unit.convert(readyAt - System.currentTimeMillis(), MILLISECONDS);
    }

    @Override
    public int compareTo(Delayed o) {
        return Long.compare(readyAt, ((RetryTask) o).readyAt());
    }
}

DelayQueue<RetryTask> retryQueue = new DelayQueue<>();

// 소비자
Thread worker = Thread.ofVirtual().start(() -> {
    while (true) {
        RetryTask task = retryQueue.take();
        try {
            task.job().run();
        } catch (Exception e) {
            if (task.attempt() < 5) {
                retryQueue.offer(RetryTask.of(task.id(), task.attempt() + 1, task.job()));
            }
        }
    }
});

ScheduledExecutorService 와의 비교

ScheduledThreadPoolExecutor 는 내부에 DelayedWorkQueue (DelayQueue 유사 구조) 를 사용하며, 스레드 관리까지 포함.

항목	DelayQueue	ScheduledExecutorService
스레드 관리	직접	자동 (thread pool)
커스텀 만료 로직	✓ (Delayed 구현)	제한적
반복 실행	별도 구현 필요	`scheduleAtFixedRate` 내장
취소	`remove(task)`	`Future.cancel()`
복잡도	낮음	높음

단순 delay 큐나 TTL 캐시 수준은 DelayQueue 가 더 가볍다. 주기적 작업 스케줄링은 ScheduledExecutorService 가 적합.

함정

1. Clock 비교 기준

getDelay 에서 System.currentTimeMillis() 와 System.nanoTime() 을 혼용하면 안 된다. 일관된 시계를 사용할 것.

[!WARNING] System.nanoTime() 은 경과 시간 측정용, System.currentTimeMillis() 는 절대 시각용. 섞으면 overflow 나 음수 delay 가 발생할 수 있다.

2. `compareTo` 를 단순 빼기로 구현

// ❌ overflow 가능
public int compareTo(Delayed o) {
    return (int) (this.readyAt - o.readyAt);  // long -> int 캐스트, overflow
}

// ✓ Long.compare 사용
public int compareTo(Delayed o) {
    return Long.compare(this.readyAt, o.readyAt);
}

3. peek() 는 만료 전에도 반환

peek() 는 head 를 확인만 하고 만료 여부를 무시한다. poll() 은 만료된 경우만 꺼내고 아니면 null 반환.

DelayedTask head = q.peek();   // 만료 전이어도 반환 (null 아님)
DelayedTask ready = q.poll();  // 만료된 경우만 반환, 아니면 null
DelayedTask wait  = q.take();  // 만료될 때까지 block

[!CAUTION] 멀티스레드 환경에서 여러 consumer 가 take() 를 동시에 기다리면 모두 정확히 만료 시각에 한 번씩 깨어난다. 하나의 원소를 여러 스레드가 가져가지 않는다. consumer 스레드 수는 처리 속도에 맞게 조정할 것.

크기 제한 없음 주의

DelayQueue 는 크기 제한이 없는 unbounded 큐. offer() 는 항상 true 를 반환하고 메모리가 허용하는 한 계속 쌓인다.

// ❌ 소비자 속도보다 생산자가 빠르면 OOM
while (running) {
    q.offer(new DelayedTask(...));  // 무한 증가 가능
}

// ✓ 외부에서 크기 모니터링
if (q.size() > MAX_PENDING) {
    log.warn("지연 큐 포화: {}", q.size());
    // 생산자 속도 조절 또는 오래된 항목 드롭
}

[!WARNING] DelayQueue 는 backpressure 가 없다. 대용량 스케줄링에는 ScheduledExecutorService 처럼 처리량 제어가 내장된 솔루션이 더 안전하다.

[Java] Fail-Fast Iterator

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

Fail-Fast Iterator 는 순회 도중 컬렉션의 구조가 변경되면 즉시 ConcurrentModificationException 을 던지는 iterator. [[List]], Set, Map 등 대부분의 java.util 컬렉션의 iterator 가 이 방식.

목적은 단순하다. 나중에 발견되면 디버깅이 끔찍하게 어려울 정합성 위배를, 가능한 가장 이른 시점에 노출 시키는 것이다. 실패 자체를 빠르게 만든다는 뜻에서 fail-fast.

java.util.concurrent 의 컬렉션 ([[CopyOnWriteArrayList]], ConcurrentHashMap, ConcurrentLinkedQueue 등) 은 일부러 fail-fast 가 아닌 weakly consistent / snapshot iterator 를 쓴다.

사용 상황

Fail-Fast Iterator 는 직접 선택하는 것이 아니라, java.util 컬렉션을 사용할 때 이미 내장 되어 있다.

상황	영향
for-each 루프 안에서 컬렉션 수정	CME 발생
iterator 도중 다른 스레드가 수정	CME 발생 (best-effort)
`Iterator.remove()` 사용	안전 (modCount 동기화됨)
`Collection.removeIf()` 사용	안전
`set()` 으로 값만 교체	안전 (구조 변경 아님)

알아야 하는 이유: 실수로 순회 중 수정하면 CME 가 발생한다. 패턴을 알면 예방 가능.

메커니즘: modCount

AbstractList, [[ArrayList]], [[LinkedList]], [[Vector]], HashMap 등은 내부에 modCount 라는 정수 필드를 가진다.

public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E> {
    protected transient int modCount = 0;
    // 구조 변경 메서드마다 modCount++
}

구조 변경 (structural modification) 이 일어날 때마다 modCount++
iterator 생성 시 expectedModCount = modCount 로 스냅샷
next(), remove() 등 호출마다 expectedModCount == modCount 검사
다르면 throw new ConcurrentModificationException()

// ArrayList.Itr (단순화)
private class Itr implements Iterator<E> {
    int cursor;
    int lastRet = -1;
    int expectedModCount = modCount;   // 스냅샷

    public E next() {
        checkForComodification();      // 매번 검사
        // ... return element ...
    }

    final void checkForComodification() {
        if (modCount != expectedModCount)
            throw new ConcurrentModificationException();
    }
}

modCount 사용 컬렉션

flowchart TD
    Coll["java.util 컬렉션"] --> HasMod{"modCount 사용?"}
    HasMod -->|"예 (fail-fast)"| FF["ArrayList\nLinkedList\nVector\nHashMap / LinkedHashMap\nHashSet\nTreeMap / TreeSet"]
    HasMod -->|"아니오 (weakly-consistent)"| WC["ConcurrentHashMap\nConcurrentLinkedQueue\nCopyOnWriteArrayList\nCopyOnWriteArraySet"]

java.util 컬렉션은 모두 fail-fast, java.util.concurrent 컬렉션은 weakly-consistent 또는 snapshot.

구조 변경이란

modCount 가 증가하는 작업은 컬렉션의 크기를 바꾸거나 내부 배열을 새로 할당하는 작업.

add(E), add(int, E), addAll(...)
remove(int), remove(Object), removeAll(...), clear()
ArrayList.trimToSize(), ensureCapacity(int)
LinkedHashMap 의 put() 으로 새 키 추가

set(int, E) 처럼 기존 원소를 교체만 하는 작업은 구조 변경이 아니다. 따라서 fail-fast 가 발생하지 않는다.

List<Integer> list = new ArrayList<>(List.of(1, 2, 3));
for (Integer x : list) {
    list.set(0, 99);   // OK, 구조 변경 아님
}

modCount 검사 흐름

flowchart TD
    Iter["iterator() 생성"] --> Snap["expectedModCount = modCount"]
    Snap --> Next["next() 호출"]
    Next --> Check{"modCount ==\nexpectedModCount?"}
    Check -->|"같음"| Return["원소 반환"]
    Return --> HasNext{"hasNext()?"}
    HasNext -->|"예"| Next
    HasNext -->|"아니오"| End["순회 종료"]
    Check -->|"다름"| CME["ConcurrentModificationException"]
    CME --> Crash["스택 트레이스 출력"]
    Mod["다른 스레드 or\n자기 자신이 add/remove"] --> Inc["modCount++"]
    Inc -.->|"검사 시 불일치"| Check

트리거 예시

단일 스레드의 자기 수정

List<Integer> list = new ArrayList<>(List.of(1, 2, 3, 4));
for (Integer x : list) {
    if (x == 2) list.remove(x);   // CME
}

순회 중 자기 자신을 수정해도 발생. 멀티스레드만의 문제가 아니다.

안전한 패턴

// 1. Iterator.remove() - modCount 와 expectedModCount 를 함께 갱신
Iterator<Integer> it = list.iterator();
while (it.hasNext()) {
    if (it.next() == 2) it.remove();   // 안전
}

// 2. Java 8+: Collection.removeIf - 내부에서 modCount 정합 유지
list.removeIf(x -> x == 2);

// 3. 복사본 순회 후 원본 수정
for (Integer x : new ArrayList<>(list)) {
    if (x == 2) list.remove(x);
}

// 4. Java 16+ Stream.toList() 로 필터링
List<Integer> filtered = list.stream()
    .filter(x -> x != 2)
    .toList();

// 5. Java 17+ record + stream (불변 처리)
record Item(int id, String name) {}
List<Item> items = new ArrayList<>(...);
List<Item> kept = items.stream()
    .filter(item -> item.id() != targetId)
    .toList();
items = new ArrayList<>(kept);

멀티스레드에서

다른 스레드가 add/remove 하면 modCount 가 증가, 내 iterator 가 다음 next() 에서 CME. 단, fail-fast 는 best-effort 검사, 절대 보장이 아니다.

[!CAUTION] fail-fast 가 CME 를 던지지 않는다고 해서 안전한 것은 아니다. modCount 검사는 동기화 없이 수행되므로, 두 스레드가 동시에 수정/순회하면 modCount 조차 비정상 상태로 보일 수 있다. CME 가 발생하지 않은 채 잘못된 결과 (배열 인덱스 ArrayIndexOutOfBoundsException, NullPointerException, 무한 루프) 가 나올 수 있다.

진짜 동시성 안전이 필요하면 [[CopyOnWriteArrayList]] / ConcurrentHashMap 또는 외부 동기화.

fail-fast vs weakly consistent vs snapshot

종류	컬렉션	동시 수정 시 동작	보는 데이터
fail-fast	ArrayList, LinkedList, Vector, HashMap	CME 즉시 던짐 (best-effort)	수정 전 상태
weakly consistent	ConcurrentHashMap, ConcurrentLinkedQueue	예외 없음, 순회 계속	일부 수정 반영 가능
snapshot	CopyOnWriteArrayList, CopyOnWriteArraySet	예외 없음, 순회 계속	iterator 생성 시점 (이후 수정 안 보임)

왜 fail-fast 인가

처음 보면 “왜 일부러 예외를 던지는 것이지?” 싶다. 대안 (silent corruption) 이 훨씬 무서운 디버깅 경험을 만들기 때문이다.

CME 가 없다면: 순회가 무한 루프, 같은 원소 두 번 방문, 잘못된 인덱스 접근 등 진단 불가능한 증상으로 나타난다. 며칠을 디버깅하다 결국 다른 스레드가 컬렉션을 건드린 것을 발견.
CME 가 있으면: 즉시 스택 트레이스로 위치 파악, 수정을 누가 했는지 추적 가능.

[!IMPORTANT] CME 는 적이 아니다, 친구다. CME 가 발생하면 코드의 동시성 가정이 틀렸다는 신호. 무시하거나 catch 해서 삼키지 말고, 동시성 컬렉션을 쓰거나 동기화를 추가하라.

함정

1. Stream 에서 컬렉션 수정

List<String> list = new ArrayList<>(List.of("a", "b", "c"));

// CME: Stream 내부가 iterator 를 사용
list.stream().forEach(s -> {
    if (s.equals("a")) list.remove(s);   // CME
});

// 올바름: removeIf 또는 stream + collect
list.removeIf("a"::equals);

2. for-each 는 iterator 의 syntactic sugar

// 이것은
for (String s : list) { ... }

// 이것과 같다
Iterator<String> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();   // checkForComodification()
    ...
}

for-each 안에서 list.add() / list.remove() 를 호출하면 내부 iterator 가 CME 를 던진다.

3. Lambda 로 외부 컬렉션 캡처 후 수정

List<String> result = new ArrayList<>();
List<String> input = new ArrayList<>(List.of("a", "b", "c"));

// CME: forEach 도중 input 을 수정
input.forEach(s -> {
    result.add(s.toUpperCase());
    input.remove(s);   // CME
});

순회 중에는 읽기만 해야 한다. 별도 컬렉션에 결과를 모으고, 순회 완료 후 처리.

4. subList / entrySet 수정

list.subList(1, 3) 은 원본 리스트의 뷰. subList 수정 시 원본 modCount 가 증가해 원본 iterator 가 CME.

AbstractList.modCount 상속 체계

modCount 는 AbstractList 에 정의되어 있고, 이를 상속하는 모든 컬렉션이 함께 사용한다.

// AbstractList
protected transient int modCount = 0;

// ArrayList 의 add 구현 (단순화)
public boolean add(E e) {
    modCount++;           // 구조 변경 기록
    add(e, elementData, size);
    return true;
}

// LinkedList, Vector, HashMap 의 iterator 도 동일한 패턴
// TreeMap 은 AbstractMap 경유지만 비슷한 modCount 로직 보유

HashMap.entrySet().iterator(), HashSet.iterator() 도 내부적으로 HashMap.modCount 를 관찰한다. HashMap 에 put/remove 하는 동안 entrySet 을 순회하면 CME.

Java 21 Sequenced Collections

Java 21 에서 도입된 SequencedCollection 인터페이스는 순서가 있는 컬렉션에 reversed() 뷰를 제공한다.

// Java 21+
SequencedCollection<String> seq = new ArrayList<>(List.of("a", "b", "c"));
SequencedCollection<String> rev = seq.reversed();

// reversed() 는 원본의 live view, 원본 수정 시 반영됨
// 단, reversed() 를 순회하는 도중 원본 수정 -> CME
for (String s : rev) {
    seq.add("x");   // CME
}

reversed() 뷰의 iterator 도 fail-fast 다.

[Java] LinkedBlockingQueue

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.LinkedBlockingQueue<E> 는 linked list 기반의 [[BlockingQueue]]. 기본 unbounded (Integer.MAX_VALUE) 이지만 생성 시 capacity 지정 가능.

Two-Lock Queue 알고리즘 으로 producer 와 consumer 가 서로 다른 락 을 사용 → [[ArrayBlockingQueue]] 보다 높은 throughput.

JDK 1.5 도입. Executors.newFixedThreadPool() 과 newSingleThreadExecutor() 의 기본 큐.

언제 쓰나

생산자-소비자 패턴: 생산 속도와 소비 속도가 다를 때 버퍼 역할
스레드 풀 작업 큐: ThreadPoolExecutor 의 작업 큐
파이프라인 단계 간 버퍼: 처리 단계 사이에 데이터를 임시 저장
이벤트 큐: 이벤트를 순서대로 처리할 때
고처리량 생산자-소비자: ArrayBlockingQueue 보다 처리량이 중요할 때

[!IMPORTANT] 기본 생성자 new LinkedBlockingQueue<>() 는 용량이 Integer.MAX_VALUE. producer 가 빠르면 OOM 위험. 반드시 bounded capacity 지정 권장.

시각화: Two-Lock 구조

flowchart LR
    subgraph "Producer 스레드들"
        P1["Producer 1"]
        P2["Producer 2"]
    end

    subgraph "LinkedBlockingQueue"
        PL["putLock\n(tail 쪽)"]
        TL["takeLock\n(head 쪽)"]
        H["head (dummy)"] --> N1["Node 1"] --> N2["Node 2"] --> N3["Node 3 (tail)"]
    end

    subgraph "Consumer 스레드들"
        C1["Consumer 1"]
        C2["Consumer 2"]
    end

    P1 --> PL
    P2 --> PL
    TL --> C1
    TL --> C2

put 과 take 가 서로 다른 끝 (tail/head) 을 다루므로 동시에 진행 가능.

시각화: put/take 흐름

flowchart TD
    Put["put(e)"] --> PL["putLock 획득"]
    PL --> Full{"count == capacity?"}
    Full -->|"예"| Await1["notFull.await() 블록"]
    Await1 --> Full
    Full -->|"아니오"| Enq["tail 에 Node 추가"]
    Enq --> Inc["count.getAndIncrement()"]
    Inc --> Sig1["count+1 < capacity 이면\nnotFull.signal()"]
    Sig1 --> Unlock1["putLock 해제"]
    Unlock1 --> Wake1["count==1 이면\nsignalNotEmpty()"]

    Take["take()"] --> TL["takeLock 획득"]
    TL --> Empty{"count == 0?"}
    Empty -->|"예"| Await2["notEmpty.await() 블록"]
    Await2 --> Empty
    Empty -->|"아니오"| Deq["head 에서 Node 제거"]
    Deq --> Dec["count.getAndDecrement()"]
    Dec --> Sig2["count-1 > 0 이면\nnotEmpty.signal()"]
    Sig2 --> Unlock2["takeLock 해제"]
    Unlock2 --> Wake2["count==capacity-1 이면\nsignalNotFull()"]

내부 구조

public class LinkedBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, Serializable {

    private final int capacity;
    private final AtomicInteger count = new AtomicInteger();

    transient Node<E> head;          // dummy head (head.item == null)
    private transient Node<E> last;  // tail

    // 두 개의 독립적인 락
    private final ReentrantLock takeLock = new ReentrantLock();
    private final Condition notEmpty = takeLock.newCondition();

    private final ReentrantLock putLock = new ReentrantLock();
    private final Condition notFull = putLock.newCondition();

    static class Node<E> {
        E item;
        Node<E> next;
        Node(E x) { item = x; }
    }
}

핵심: takeLock 과 putLock 이 분리. take 와 put 이 동시에 진행 가능 (다른 끝을 다루므로).

count 는 AtomicInteger, 두 락 모두에서 안전하게 갱신.

두 락의 협력

public void put(E e) throws InterruptedException {
    int c = -1;
    Node<E> node = new Node<>(e);
    final ReentrantLock putLock = this.putLock;
    final AtomicInteger count = this.count;
    putLock.lockInterruptibly();
    try {
        while (count.get() == capacity)
            notFull.await();
        enqueue(node);
        c = count.getAndIncrement();
        if (c + 1 < capacity)
            notFull.signal();   // 다음 put 대기자 깨움
    } finally {
        putLock.unlock();
    }
    if (c == 0)
        signalNotEmpty();   // take 대기자 깨움 (putLock 밖에서)
}

public E take() throws InterruptedException {
    E x;
    int c = -1;
    final AtomicInteger count = this.count;
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lockInterruptibly();
    try {
        while (count.get() == 0)
            notEmpty.await();
        x = dequeue();
        c = count.getAndDecrement();
        if (c > 1)
            notEmpty.signal();   // 다음 take 대기자 깨움
    } finally {
        takeLock.unlock();
    }
    if (c == capacity)
        signalNotFull();   // put 대기자 깨움 (takeLock 밖에서)
    return x;
}

복잡도 및 동시성

작업	시간	동시성
`put`/`offer`	O(1)	putLock 직렬
`take`/`poll`	O(1)	takeLock 직렬
`put` + `take` 동시	O(1)	병렬 (다른 락)
`size()`	O(1)	AtomicInteger
`remove(Object)`	O(n)	두 락 모두 획득
`contains(Object)`	O(n)	두 락 모두 획득

Java 17+ 실전: 생산자-소비자 파이프라인


// bounded 큐로 backpressure 구현
class DataPipeline {
    private final BlockingQueue<String> queue = new LinkedBlockingQueue<>(100);
    private volatile boolean done = false;

    void startProducer(List<String> data) {
        Thread.ofVirtual().start(() -> {
            try {
                for (String item : data) {
                    queue.put(item);   // 큐가 가득 차면 블록 (backpressure)
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                done = true;
            }
        });
    }

    void startConsumer() {
        Thread.ofVirtual().start(() -> {
            try {
                while (!done || !queue.isEmpty()) {
                    String item = queue.poll(100, TimeUnit.MILLISECONDS);
                    if (item != null) process(item);
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
    }
}

Java 17+ 실전: ThreadPoolExecutor 커스텀 큐


// 작업 큐 크기를 제한한 스레드 풀
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,                                    // corePoolSize
    8,                                    // maximumPoolSize
    60L, TimeUnit.SECONDS,               // keepAliveTime
    new LinkedBlockingQueue<>(200),       // bounded 큐
    new ThreadPoolExecutor.CallerRunsPolicy()  // 큐 가득 차면 호출자 스레드에서 실행
);

// 작업 제출
executor.submit(() -> processTask());
executor.shutdown();
executor.awaitTermination(30, TimeUnit.SECONDS);

Java 17+ 실전: 이벤트 처리 시스템


sealed interface AppEvent permits LoginEvent, LogoutEvent, ErrorEvent {}
record LoginEvent(String userId, long timestamp) implements AppEvent {}
record LogoutEvent(String userId, long timestamp) implements AppEvent {}
record ErrorEvent(String message, Throwable cause) implements AppEvent {}

class EventProcessor {
    private final BlockingQueue<AppEvent> eventQueue =
        new LinkedBlockingQueue<>(1000);

    EventProcessor() {
        // 이벤트 처리 스레드
        Thread.ofVirtual().start(() -> {
            try {
                while (!Thread.currentThread().isInterrupted()) {
                    AppEvent event = eventQueue.take();
                    switch (event) {
                        case LoginEvent e -> handleLogin(e);
                        case LogoutEvent e -> handleLogout(e);
                        case ErrorEvent e -> handleError(e);
                    }
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
    }

    // 여러 스레드에서 안전하게 이벤트 발행
    boolean publish(AppEvent event) {
        return eventQueue.offer(event);   // 큐 가득 차면 false 반환
    }
}

LinkedBlockingQueue vs ArrayBlockingQueue

항목	LinkedBlockingQueue	[[ArrayBlockingQueue]]
내부 구조	linked list	배열
기본 용량	`Integer.MAX_VALUE`	필수 지정
락 구조	두 개 (put/take 분리)	하나
처리량	높음	낮음
메모리	노드 객체 오버헤드	예측 가능
GC 압력	높음 (노드 생성/소멸)	낮음
공정성 옵션	✗	✓

high throughput 이 필요하면 LinkedBlockingQueue, 메모리 예측이 중요하면 ArrayBlockingQueue.

함정

1. unbounded 가 기본

// 위험: 기본 용량 Integer.MAX_VALUE → OOM 가능
BlockingQueue<Task> q = new LinkedBlockingQueue<>();

// 올바름: bounded capacity 지정
BlockingQueue<Task> q = new LinkedBlockingQueue<>(1000);

2. 노드 객체 GC 압력

각 원소가 Node 객체로 감싸진다. 짧은 시간에 수만 개가 들어왔다 나가는 워크로드에서는 GC 영향이 보일 수 있다. 이 경우 ArrayBlockingQueue 가 더 적합.

3. remove(Object) 는 두 락 모두 획득

// 위험: remove(Object) 는 putLock + takeLock 모두 획득 → 처리량 저하
queue.remove(specificItem);   // O(n) + 두 락

// 취소가 빈번하면 취소 플래그 패턴 사용
record Task(String id, volatile boolean cancelled) {}

4. 인터럽트 처리

try {
    queue.put(item);
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // 인터럽트 상태 복원 필수
    // 적절한 정리 작업
}

put/take 는 InterruptedException 을 던진다. 반드시 처리해야 한다.

[Java] LinkedHashMap

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.LinkedHashMap<K,V> 는 [[HashMap]] 을 상속해 삽입 순서 (또는 접근 순서) 를 유지 하는 Map. 모든 [[HashMap]] 의 평균 O(1) 성능을 유지하면서 추가로 순회 순서가 일관된다.

핵심: 이중 연결 리스트 (doubly-linked list) 가 모든 entry 를 삽입 순서대로 엮어 둔다.

사용 상황

상황	이유
삽입 순서가 중요한 캐시	API 응답 JSON 키 순서 보존
LRU 캐시 구현	`accessOrder=true` + `removeEldestEntry`
최근 N 개 항목 유지	eldest 제거 조건 설정
설정값 순서 보존	사람이 읽는 출력의 일관성

단순 O(1) map 이 필요하고 순서가 필요 없다면 [[HashMap]] 을 쓴다.

시각화

{}

내부 구조: 두 가지 자료구조가 공존

flowchart LR
    HEAD["head (oldest)"]
    EA["Entry: key=a"]
    EB["Entry: key=b"]
    EC["Entry: key=c"]
    TAIL["tail (newest)"]

    HEAD --> EA --> EB --> EC --> TAIL

    BA["hash bucket for a"] --> EA
    BB["hash bucket for b"] --> EB
    BC["hash bucket for c"] --> EC

각 entry 는 해시 버킷 chain 과 이중 연결 리스트 두 군데에 동시에 속한다.

static class Entry<K,V> extends HashMap.Node<K,V> {
    Entry<K,V> before, after;     // ← 추가된 두 포인터
}

// LinkedHashMap 의 추가 필드
transient LinkedHashMap.Entry<K,V> head;    // 가장 오래된 entry
transient LinkedHashMap.Entry<K,V> tail;    // 가장 최근 entry
final boolean accessOrder;                   // false = 삽입 순서, true = 접근 순서

두 가지 순회 순서

삽입 순서 (기본)

LinkedHashMap<String, Integer> map = new LinkedHashMap<>();
map.put("a", 1); map.put("b", 2); map.put("c", 3);
map.put("a", 99);                // 기존 key 갱신, 순서 유지

map.forEach((k, v) -> System.out.println(k + "=" + v));
// a=99, b=2, c=3

접근 순서 (LRU 캐시용)

Map<String, Integer> lru = new LinkedHashMap<>(16, 0.75f, true);
//                                                    ^^^^ accessOrder

lru.put("a", 1); lru.put("b", 2); lru.put("c", 3);
lru.get("a");                    // "a" 가 가장 최근 접근
lru.forEach((k, v) -> System.out.print(k + " "));
// b c a  (가장 오래된 것부터 출력)

accessOrder = true 면 get, put 마다 entry 가 linked list 의 끝으로 이동.

LRU 캐시 구현

removeEldestEntry 를 override 하면 손쉽게 LRU 캐시를 만들 수 있다.

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int capacity;

    public LRUCache(int capacity) {
        super(capacity, 0.75f, true);       // accessOrder = true
        this.capacity = capacity;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > capacity;            // 초과 시 가장 오래된 항목 제거
    }
}

// 사용
Map<String, String> cache = new LRUCache<>(3);
cache.put("a", "1"); cache.put("b", "2"); cache.put("c", "3");
cache.get("a");          // "a" 를 가장 최근으로 이동
cache.put("d", "4");     // capacity 초과 → "b" (eldest) 제거
// cache: {c=3, a=1, d=4}

[!IMPORTANT] 단일 스레드 LRU 라면 LinkedHashMap 이 매우 깔끔하다. 동시성이 필요하면 [Spring] ConcurrentLruCache 또는 Caffeine 같은 외부 라이브러리.

Thread-safe LRU

단순히 Collections.synchronizedMap 으로 감싸면 메서드 단위 동기화가 된다.

Map<String, String> syncLru = Collections.synchronizedMap(
    new LRUCache<>(100)
);

// 순회할 때는 맵 자체를 동기화해야 함
synchronized (syncLru) {
    syncLru.forEach((k, v) -> process(k, v));
}

고성능 동시성 LRU 캐시가 필요하면 Caffeine 의 Window TinyLFU 알고리즘이 훨씬 효율적이다.

API 응답 필드 순서 보존 (실전 예시)

// JSON 직렬화 라이브러리가 Map 순서를 보존한다고 가정할 때
Map<String, Object> response = new LinkedHashMap<>();
response.put("id", 123);
response.put("name", "Alice");
response.put("email", "alice@example.com");
response.put("createdAt", "2026-01-01");

// ObjectMapper (Jackson) 는 LinkedHashMap 의 삽입 순서를 그대로 직렬화
// {"id":123,"name":"Alice","email":"alice@example.com","createdAt":"2026-01-01"}

HashMap 을 쓰면 키 순서가 JVM 마다, 실행마다 달라질 수 있다.

HashMap vs LinkedHashMap vs TreeMap 비교

항목	HashMap	LinkedHashMap	TreeMap
내부 구조	해시 테이블	해시 + 이중 연결 리스트	Red-Black Tree
순회 순서	불정	삽입 순서 (or 접근 순서)	키 오름차순
`get` / `put`	O(1) avg	O(1) avg	O(log n)
`firstKey` / `lastKey`	없음	없음	O(log n)
메모리	기준	+ 2 포인터/entry	+ tree node
null key	✓ (1개)	✓ (1개)	✗

순서 보장이 필요하면 LinkedHashMap, 정렬된 키 순서가 필요하면 [[TreeMap]], 그 외에는 [[HashMap]].

실전: FIFO 캐시 (삽입 순서 oldest 제거)

accessOrder 없이 삽입 순서로 eldest 제거하는 FIFO 캐시:

class FIFOCache<K, V> extends LinkedHashMap<K, V> {
    private final int maxSize;

    public FIFOCache(int maxSize) {
        super(maxSize, 0.75f, false);   // accessOrder = false (삽입 순서)
        this.maxSize = maxSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > maxSize;
    }
}

FIFOCache<String, Integer> cache = new FIFOCache<>(3);
cache.put("a", 1); cache.put("b", 2); cache.put("c", 3);
cache.get("a");         // FIFO 이므로 "a" 순서 변동 없음
cache.put("d", 4);      // "a" (첫 번째 삽입) 제거
// cache: {b=2, c=3, d=4}

복잡도

[[HashMap]] 과 동일.

작업	평균	최악
`get`, `put`, `remove`	O(1)	O(log n)
순회	O(n) (linked list 따라가므로 빠름)	같음

순회는 HashMap 보다 빠르다. HashMap 은 빈 버킷도 모두 거쳐야 하지만, LinkedHashMap 은 linked list 만 따라간다.

메모리

각 entry 가 before/after 두 포인터를 추가로 가지므로 [[HashMap]] 대비 per-entry 메모리가 ~16-32 바이트 더 든다. 큰 map 에서는 무시 못 한다.

함정

1. accessOrder 가 동시성 문제 증폭

accessOrder = true 일 때 get() 도 구조 변경 (linked list 재정렬). 이는 modCount 를 증가시키지는 않지만, 동시 환경에서 iterator 와 충돌 할 수 있다. 동기화 필요.

2. removeEldestEntry 가 매 put 후 호출

대용량 데이터를 부어 넣는 경우 매 put 마다 호출되는 비용이 누적된다.

3. thread-safe 가 아니다

[[HashMap]] 처럼 단일 스레드 전용.

[!WARNING] accessOrder = true 인 LinkedHashMap 을 멀티스레드 환경에서 공유하면 get() 자체가 내부 구조를 변경하므로, Collections.synchronizedMap 으로 감싸도 순회 중 별도 동기화 블록이 필수.

entrySet 순회로 최근 N 개 추출

// LinkedHashMap 에서 최근 삽입된 N 개만 가져오기
LinkedHashMap<String, Integer> map = new LinkedHashMap<>();
// ... 100 개 삽입 ...

int n = 5;
List<Map.Entry<String, Integer>> recent = new ArrayList<>(map.entrySet())
    .subList(Math.max(0, map.size() - n), map.size());
// 마지막 5 개 entry 반환 (삽입 순서 기준)

entrySet() 의 iterator 는 linked list 를 따라 삽입 순서대로 방문하므로, subList 로 tail 을 잘라내면 최근 항목을 O(n) 에 추출할 수 있다.

[Java] List

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.List 는 순서가 있고 중복이 허용 되는 컬렉션을 표현하는 인터페이스. 각 원소는 0 부터 시작하는 정수 인덱스로 접근 가능.

Collection 인터페이스를 확장하며, Iterable 의 모든 성질을 물려받는다. 대표 구현체로 [[ArrayList]], [[LinkedList]], [[Vector]], [[CopyOnWriteArrayList]] 가 있다.

사용 상황

상황	이유
순서가 있는 데이터 보관	인덱스 기반 접근
중복이 허용되는 컬렉션	[[Set]] 이 아닌 List
순차 순회	Iterator / for-each
정렬 및 이진 검색	`Collections.sort`, `binarySearch`
Stream 파이프라인 시작점	`list.stream()`
배치 처리, 임시 버퍼	동적 크기 조정

시각화

{}

상속 계층

flowchart TD
    IT["Iterable"]
    COL["Collection"]
    LS["List (interface)"]
    AL["AbstractList"]
    ARR["ArrayList"]
    LL["LinkedList"]
    VEC["Vector"]
    COW["CopyOnWriteArrayList"]

    IT --> COL --> LS
    LS --> AL
    AL --> ARR
    AL --> VEC
    LS --> LL
    LS --> COW

핵심 메서드

메서드	의미	일반적 비용
`get(int i)`	i 번째 원소 반환	구현체 의존
`set(int i, E e)`	i 번째 원소를 e 로 교체, 이전 값 반환	구현체 의존
`add(E e)`	끝에 추가, true 반환	보통 O(1)
`add(int i, E e)`	i 위치에 삽입	구현체 의존
`remove(int i)`	i 번째 원소 삭제, 그 값 반환	구현체 의존
`remove(Object o)`	첫 번째로 발견된 o 삭제	O(n)
`indexOf(Object o)`	첫 등장 인덱스, 없으면 -1	O(n)
`size()`	원소 개수	O(1)
`iterator()`, `listIterator()`	순회	O(1) 생성
`subList(int from, int to)`	부분 뷰 (백킹 리스트 공유)	O(1)

구현체별 특징 한눈에

구현체	내부 구조	random access	끝에 add	앞/중간 삽입	thread-safe
[[ArrayList]]	동적 배열	O(1)	amortized O(1)	O(n)	✗
[[LinkedList]]	양방향 연결 리스트	O(n)	O(1)	O(1) (노드 있을 때) / O(n) (인덱스)	✗
[[Vector]]	동적 배열 + 메서드 동기화	O(1)	amortized O(1)	O(n)	✓ (메서드 단위)
[[CopyOnWriteArrayList]]	불변 배열 + 쓰기 시 복사	O(1)	O(n) (전체 복사)	O(n)	✓

[!IMPORTANT] 거의 모든 실무 코드에서 ArrayList 가 기본 선택. LinkedList 가 더 빠를 것 같은 상황 (앞 삽입) 도 실측하면 ArrayList 가 빠를 때가 많다. 캐시 친화성 차이 때문.

기본 사용

List<String> users = new ArrayList<>();
users.add("Alice");                    // [Alice]
users.add("Bob");                      // [Alice, Bob]
users.add(0, "Charlie");               // [Charlie, Alice, Bob]
users.set(1, "Dave");                  // [Charlie, Dave, Bob]
String first = users.get(0);           // "Charlie"
boolean has = users.contains("Bob");   // true
users.remove("Charlie");               // [Dave, Bob]

for (String u : users) {               // for-each (iterator)
    System.out.println(u);
}

정렬

List.sort() 와 Collections.sort() 모두 내부적으로 TimSort (O(n log n)) 를 사용한다.

List<Integer> nums = new ArrayList<>(List.of(5, 2, 8, 1, 9));

// 자연 순서 오름차순
nums.sort(Comparator.naturalOrder());         // [1, 2, 5, 8, 9]

// 역순
nums.sort(Comparator.reverseOrder());         // [9, 8, 5, 2, 1]

// 커스텀: 길이 오름차순, 동점이면 사전 순
List<String> words = new ArrayList<>(List.of("banana", "fig", "apple"));
words.sort(Comparator.comparingInt(String::length)
                     .thenComparing(Comparator.naturalOrder()));
// [fig, apple, banana]

// 이진 검색 (정렬 선행 필수)
Collections.sort(nums);
int idx = Collections.binarySearch(nums, 5);  // 인덱스 반환

Stream API 와 함께

List<String> names = List.of("Alice", "Bob", "Charlie", "Dave");

// 필터 + 변환 + 수집
List<String> result = names.stream()
    .filter(n -> n.length() > 3)
    .map(String::toUpperCase)
    .sorted()
    .collect(Collectors.toList());
// [ALICE, CHARLIE, DAVE]

// 합계
int totalLen = names.stream()
    .mapToInt(String::length)
    .sum();   // 18

// 그룹화: Map<길이, 이름 리스트>
Map<Integer, List<String>> byLen = names.stream()
    .collect(Collectors.groupingBy(String::length));
// {3=[Bob], 4=[Dave], 5=[Alice], 7=[Charlie]}

// 플랫맵: 중첩 List 펼치기
List<List<Integer>> nested = List.of(List.of(1, 2), List.of(3, 4));
List<Integer> flat = nested.stream()
    .flatMap(Collection::stream)
    .collect(Collectors.toList());   // [1, 2, 3, 4]

Collections 유틸리티

List<Integer> nums = new ArrayList<>(List.of(3, 1, 4, 1, 5));

Collections.reverse(nums);          // [5, 1, 4, 1, 3]
Collections.shuffle(nums);          // 무작위 섞기
int min = Collections.min(nums);    // 최솟값
int max = Collections.max(nums);    // 최댓값
Collections.fill(nums, 0);          // [0, 0, 0, 0, 0]

// nCopies: 같은 원소 n 개로 채운 불변 리스트
List<String> zeros = Collections.nCopies(5, "x");  // [x, x, x, x, x]

불변 (Immutable) List

Java 9 부터 List.of(...) 정적 메서드가 추가됐다.

List<Integer> primes = List.of(2, 3, 5, 7, 11);
primes.add(13);  // UnsupportedOperationException

// 기존 리스트의 불변 복사본
List<String> copy = List.copyOf(original);

List.of 는 null 원소도 허용하지 않는다. Arrays.asList 와 달리 크기 변경도 불가.

fail-fast 와 동시 수정

ArrayList, LinkedList, Vector 의 iterator 는 순회 중 구조가 변경되면 [[ConcurrentModificationException]] 을 던진다 ([[fail-fast iterator]]). 단일 스레드 안에서도 발생한다.

List<Integer> list = new ArrayList<>(List.of(1, 2, 3, 4));
for (Integer x : list) {
    if (x % 2 == 0) list.remove(x);  // ConcurrentModificationException
}

// Iterator.remove() 만 안전
Iterator<Integer> it = list.iterator();
while (it.hasNext()) {
    if (it.next() % 2 == 0) it.remove();
}

// Java 8+: removeIf (가장 간결)
list.removeIf(x -> x % 2 == 0);

[[CopyOnWriteArrayList]] 만 예외, snapshot iterator 라 CME 가 발생하지 않는다.

함정

1. `remove(int)` vs `remove(Object)` 오버로드 혼동

List<Integer> list = new ArrayList<>(List.of(1, 2, 3));
list.remove(1);                      // int 오버로드: 인덱스 1 삭제 → [1, 3]
list.remove(Integer.valueOf(1));     // Object 오버로드: 값 1 삭제 → [2, 3]

[!WARNING] List<Integer> 에서 remove(1) 은 값 1이 아닌 인덱스 1 을 삭제한다. 값을 제거하려면 remove(Integer.valueOf(x)) 또는 removeIf(v -> v == x).

2. `subList` 는 원본을 공유

List<String> full = new ArrayList<>(List.of("a", "b", "c", "d"));
List<String> sub = full.subList(1, 3);   // [b, c] (뷰)
sub.clear();                              // full = [a, d]

subList() 반환값을 수정하면 원본도 바뀐다. 독립 복사본이 필요하면 new ArrayList<>(sub).

3. `Arrays.asList` 는 크기 고정

List<String> fixed = Arrays.asList("x", "y", "z");
fixed.set(0, "X");   // OK: 원소 교체 가능
fixed.add("w");      // UnsupportedOperationException: 크기 변경 불가

List.of 와 달리 원소 교체는 가능하지만 add / remove 는 불가.

4. `Collections.sort` 는 in-place, Stream.sorted 는 새 리스트

List<Integer> a = new ArrayList<>(List.of(3, 1, 2));
List<Integer> b = a.stream().sorted().collect(Collectors.toList());
// a 는 그대로 [3, 1, 2], b 는 [1, 2, 3]

Collections.sort(a);
// a 는 [1, 2, 3] (in-place 정렬)

어떤 구현체를 골라야 하나

상황	권장
기본, 의심스러우면	[[ArrayList]]
앞/뒤 빈번 삽입/삭제, Deque 로도 쓰고 싶다	[[LinkedList]] (인덱스 접근 거의 없을 때)
레거시 코드 호환	[[Vector]] (새 코드에서는 피한다)
읽기 多 / 쓰기 거의 없음, 동시성	[[CopyOnWriteArrayList]]
불변 데이터	`List.of(...)`, `List.copyOf(...)`
일반적 동시성	`Collections.synchronizedList(new ArrayList<>())`

[Java] LongAdder

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.atomic.LongAdder 는 고경합 카운터 를 위한 자료구조. JDK 1.8 도입. AtomicLong 보다 동시 증가 throughput 이 압도적으로 높다.

원리는 striped counter (분산 누적). 여러 cell 에 나누어 누적하고, 합산할 때 모두 더한다. CAS 충돌이 발생하면 다른 cell 을 시도 → 거의 모든 increment 가 무경합.

사용 상황

상황	이유
HTTP 요청 수 카운터	수십 스레드가 동시에 increment
에러율 / 처리량 메트릭	eventual consistency 허용
키별 빈도 집계	`ConcurrentHashMap + LongAdder` 조합
이벤트 누적 (로그, 알림)	높은 throughput 필요

AtomicLong 을 쓰면 되는 상황 (단일/저경합, 현재값이 즉시 필요) 에는 오히려 오버헤드.

시각화

{}

increment 흐름

flowchart TD
    INC["increment()"]
    BASE["CAS on base 시도"]
    OK["성공: base 값 갱신"]
    FAIL["실패, 경합 감지"]
    CHECK{"cells 배열 존재?"}
    INIT["cells 초기화 or 확장"]
    CELL["CAS on cells[threadHash mod len]"]
    DONE["완료"]

    INC --> BASE
    BASE -->|"성공"| OK --> DONE
    BASE -->|"실패"| FAIL --> CHECK
    CHECK -->|"없음"| INIT --> CELL --> DONE
    CHECK -->|"있음"| CELL --> DONE

처음에는 단일 base 필드에 CAS 를 시도한다. 경합이 생기는 순간 Striped64 가 cells 배열을 초기화하고, 이후 각 스레드는 자신의 threadLocalRandom 해시로 고유 cell 을 골라 누적한다.

내부 구조 (Striped64)

LongAdder 는 Striped64 를 상속한다.

abstract class Striped64 extends Number {
    transient volatile Cell[] cells;   // null 이면 base 만 사용
    transient volatile long base;      // 경합 없을 때 직접 CAS
    transient volatile int cellsBusy; // cells 배열 resize 락
}

@sun.misc.Contended              // false sharing 방지 (캐시 라인 패딩)
static final class Cell {
    volatile long value;
    // CAS 메서드 포함
}

@Contended 어노테이션이 각 Cell 을 별도 캐시 라인에 배치해 false sharing 을 방지. 이것이 성능 향상의 핵심 중 하나.

동작

LongAdder count = new LongAdder();

count.increment();         // ++count
count.add(5);
count.sum();               // 모든 cell 합산, 추정값
count.longValue();         // == sum()
count.reset();

AtomicLong.incrementAndGet() 처럼 새 값을 반환하지는 않는다. 누적 결과만 보장.

왜 AtomicLong 보다 빠른가

[[AtomicInteger]] / AtomicLong 의 CAS 루프는 다음과 같다.

스레드 N 개가 동시에 increment:
  T1: CAS(0, 1) 성공
  T2: CAS(0, 1) 실패 → 재시도 → CAS(1, 2) 성공
  T3: CAS(0, 1) 실패 → 재시도 → CAS(1, 2) 실패 → 재시도 → CAS(2, 3) 성공
  ...

경합이 심하면 거의 모든 스레드가 여러 번 CAS 실패. 성능이 락보다 떨어질 수 있다.

LongAdder 는.

스레드 N 개가 동시에 increment:
  T1 → cell[hash(T1) % cells.length].add(1)
  T2 → cell[hash(T2) % cells.length].add(1)
  T3 → cell[hash(T3) % cells.length].add(1)
  ... (각자 다른 cell 에 누적, 충돌 거의 없음)

cells 배열의 크기가 동적으로 늘어나면서 경합이 분산된다.

sum 의 약점

long total = adder.sum();   // 모든 cell 의 합

합산 시점에 다른 스레드가 add 중이면 그 값은 반영 안 될 수 있다. “순간 정확한 카운트” 는 보장 안 됨.

워크로드 통계, request count 같이 eventual consistency 가 허용되는 카운터에 적합.

사용 예

request 카운터

class Metrics {
    private final LongAdder requests = new LongAdder();
    private final LongAdder errors = new LongAdder();

    public void onRequest() { requests.increment(); }
    public void onError() { errors.increment(); }

    public long requestCount() { return requests.sum(); }
    public long errorCount() { return errors.sum(); }
}

Map 의 값으로

ConcurrentMap<String, LongAdder> counts = new ConcurrentHashMap<>();
counts.computeIfAbsent(key, k -> new LongAdder()).increment();

이 패턴이 흔한 idiom. [[ConcurrentHashMap]] + LongAdder 조합으로 키별 카운트.

rate limiter 에서 슬라이딩 윈도우 카운터

class RateLimiter {
    private final LongAdder counter = new LongAdder();
    private final long maxPerSecond;
    private volatile long windowStart = System.currentTimeMillis();

    public boolean tryAcquire() {
        long now = System.currentTimeMillis();
        if (now - windowStart >= 1000) {
            counter.reset();
            windowStart = now;
        }
        counter.increment();
        return counter.sum() <= maxPerSecond;
    }
}

정밀한 rate limiting 은 외부 라이브러리 (Bucket4j, Resilience4j) 를 쓰는 게 낫지만, 로컬 카운터에 LongAdder 가 적합하다.

DoubleAdder, LongAccumulator, DoubleAccumulator

DoubleAdder: 같은 패턴의 double 버전
LongAccumulator: 일반화, 임의의 람다 (prev, x) -> next 로 누적
DoubleAccumulator: double 버전

LongAccumulator max = new LongAccumulator(Long::max, Long.MIN_VALUE);
max.accumulate(42);
max.accumulate(100);
max.get();   // 100

// 실전: 처리된 최대 배치 크기 추적
LongAccumulator maxBatch = new LongAccumulator(Long::max, 0);
// 각 스레드에서:
maxBatch.accumulate(batchSize);
// 나중에:
long peak = maxBatch.get();

함정

1. sum() 은 일관성 보장 없음

LongAdder adder = new LongAdder();
// 스레드 A: adder.add(100)
// 스레드 B: long v = adder.sum()  // 0 또는 100 중 어느 쪽이든 가능

[!WARNING] sum() 은 스냅샷이 아니다. 합산 도중에도 다른 스레드가 add 할 수 있어 결과가 과거값이 될 수 있다. 트랜잭션 합계 같이 정확한 일관성이 필요한 곳에는 쓰지 않는다.

2. reset() 은 원자적이지 않다

adder.reset();
// reset() 직후 다른 스레드가 increment() 하면 그 값은 날아감

카운터를 읽고 초기화하는 패턴은 sumThenReset() 을 쓴다. 단, 이것도 완전 원자적이지 않으므로 주의.

3. 현재값 반환이 없다

AtomicLong.incrementAndGet() 처럼 증가 후 즉시 현재값을 받을 방법이 없다. “지금 몇 번째 요청인지” 가 필요하다면 AtomicLong 을 써야 한다.

성능 참고

아래는 대략적인 경향이다 (실제 수치는 JVM / CPU 코어 수에 따라 다름).

조건	AtomicLong ops/s	LongAdder ops/s
1 스레드	~500M	~300M (오버헤드 있음)
8 스레드	~150M	~1,200M
32 스레드	~80M	~3,000M

스레드가 많아질수록 LongAdder 의 이점이 지수적으로 커진다. 단일 스레드에서는 오히려 AtomicLong 이 빠르다.

AtomicLong vs LongAdder 의 선택

시나리오	권장
단일 스레드 / 저경합	[[AtomicInteger]] / `AtomicLong`
고경합 + sum 만 필요	LongAdder
고경합 + 매 갱신마다 결과 필요	`AtomicLong` (CAS 비용 감수)
custom accumulation	`LongAccumulator`

초기화 시점 주의

LongAdder 는 생성 직후부터 사용 가능하고 초기값은 0. reset() 이나 sumThenReset() 도 별도 동기화 없이 호출할 수 있다. 다만 reset 과 읽기 사이에 race 가 있을 수 있으므로, 정확한 snapshot 이 필요하다면 외부에서 별도 동기화를 추가해야 한다.

// 1초마다 카운터를 읽고 초기화
long delta = counter.sumThenReset();   // 읽고 즉시 reset
metrics.record(delta);

[Java] Map

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.Map<K,V> 는 key 와 value 의 쌍으로 데이터를 저장 하는 자료구조의 인터페이스. 하나의 key 에는 하나의 value 만 매핑, 중복 key 는 허용하지 않는다.

Map 은 [[Collection]] 을 extends 하지 않는다 (key-value 쌍 의미가 단일 원소와 다르므로). 그래도 keySet(), values(), entrySet() 을 통해 Collection 인터페이스의 view 를 제공.

언제 쓰나

key-value 매핑: 이름 -> 나이, ID -> 객체 등 연관 관계 저장
빠른 조회: key 로 O(1) 또는 O(log n) 에 value 를 찾을 때
그룹핑: 카테고리별 항목 목록 (Map<String, List<T>>)
카운팅: 단어 빈도, 이벤트 횟수 (Map<String, Integer>)
캐시: 계산 결과를 key 로 저장해 재사용

시각화: Map 구현체 계층

flowchart TD
    Map["Map"] --> HashMap["HashMap"]
    Map --> SortedMap["SortedMap"]
    Map --> ConcurrentMap["ConcurrentMap"]
    HashMap --> LinkedHashMap["LinkedHashMap"]
    SortedMap --> NavigableMap["NavigableMap"]
    NavigableMap --> TreeMap["TreeMap"]
    ConcurrentMap --> ConcurrentHashMap["ConcurrentHashMap"]
    ConcurrentMap --> ConcurrentNavigableMap["ConcurrentNavigableMap"]
    ConcurrentNavigableMap --> ConcurrentSkipListMap["ConcurrentSkipListMap"]

핵심 메서드

메서드	의미
`put(K, V)`	매핑 추가 또는 갱신, 이전 값 반환
`get(Object)`	key 로 value 조회, 없으면 null
`getOrDefault(Object, V)`	없으면 기본값 반환
`containsKey(Object)`	key 존재 여부
`containsValue(Object)`	value 존재 여부 (보통 O(n))
`remove(Object)`	key 제거, 이전 값 반환
`size()`, `isEmpty()`	크기
`keySet()`	key 집합 (Set view)
`values()`	value 컬렉션 (Collection view)
`entrySet()`	key-value 쌍 집합 (Set view)

Java 8+ 기본 메서드

// 없으면 삽입, 있으면 무시
map.putIfAbsent(key, value);

// 없으면 람다 실행 후 삽입 (비용 절약)
map.computeIfAbsent(key, k -> new ArrayList<>());

// 있으면 람다로 갱신
map.computeIfPresent(key, (k, v) -> v + 1);

// 없으면 초기값, 있으면 함수 적용
map.compute(key, (k, v) -> v == null ? 1 : v + 1);

// 없으면 value 삽입, 있으면 remappingFunction 적용
map.merge(key, 1, Integer::sum);

// 조건부 교체
map.replace(key, oldVal, newVal);

// 모든 값에 함수 적용
map.replaceAll((k, v) -> v.toUpperCase());

// 람다로 순회
map.forEach((k, v) -> System.out.println(k + "=" + v));

구현체 비교

구현	순서	thread-safe	null key	null value	백킹
[[HashMap]]	없음	✗	✓ (1개)	✓	해시 테이블
[[LinkedHashMap]]	삽입/접근 순서	✗	✓ (1개)	✓	해시 + linked list
[[TreeMap]]	정렬	✗	✗	✓	Red-Black Tree
`Hashtable` (legacy)	없음	✓ (메서드)	✗	✗	해시
[[ConcurrentHashMap]]	없음	✓ (bin-level)	✗	✗	해시 + CAS
`EnumMap`	enum 선언 순서	✗	✗	✓	배열
`WeakHashMap`	없음	✗	✓	✓	key 약참조

불변 Map (Java 9+)

// Map.of: 불변, null 비허용, 중복 key 시 IllegalArgumentException
Map<String, Integer> ages = Map.of("Alice", 30, "Bob", 25);

// 10개 이상이거나 일관성 있게 표현하려면 ofEntries
Map<String, Integer> more = Map.ofEntries(
    Map.entry("a", 1),
    Map.entry("b", 2),
    Map.entry("c", 3)
);

// Map.copyOf: 기존 Map 을 불변으로 복사
Map<String, Integer> copy = Map.copyOf(mutableMap);

// Collections.unmodifiableMap: 불변 뷰 (원본 변경 반영)
Map<String, Integer> view = Collections.unmodifiableMap(mutableMap);

[!IMPORTANT] Map.of 는 순서를 보장하지 않는다. 반복 순서가 실행마다 다를 수 있다. 순서가 필요하면 LinkedHashMap 또는 TreeMap 사용.

entrySet 순회가 가장 효율적

// 비효율: key 로 다시 get (해시 lookup 2번)
for (String k : map.keySet()) {
    System.out.println(k + "=" + map.get(k));
}

// 효율: entrySet 직접 순회 (해시 lookup 1번)
for (Map.Entry<String, Integer> e : map.entrySet()) {
    System.out.println(e.getKey() + "=" + e.getValue());
}

// Java 8+ forEach (가장 간결)
map.forEach((k, v) -> System.out.println(k + "=" + v));

Java 17+ 실전: 단어 빈도 카운터



// merge 로 단어 카운팅
String text = "apple banana apple cherry banana apple";
Map<String, Integer> freq = new HashMap<>();
for (String word : text.split("\\s+")) {
    freq.merge(word, 1, Integer::sum);
}
// {apple=3, banana=2, cherry=1}

// Stream 으로 동일 결과
Map<String, Long> freqStream = Arrays.stream(text.split("\\s+"))
    .collect(Collectors.groupingBy(w -> w, Collectors.counting()));

Java 17+ 실전: 그룹핑 (multimap)


record Person(String name, String dept) {}

List<Person> people = List.of(
    new Person("Alice", "Engineering"),
    new Person("Bob", "Marketing"),
    new Person("Carol", "Engineering")
);

// computeIfAbsent 로 그룹핑
Map<String, List<Person>> byDept = new HashMap<>();
people.forEach(p ->
    byDept.computeIfAbsent(p.dept(), k -> new ArrayList<>()).add(p)
);

// Stream groupingBy (더 간결)
Map<String, List<Person>> byDeptStream = people.stream()
    .collect(Collectors.groupingBy(Person::dept));

Java 17+ 실전: LRU 캐시 (LinkedHashMap)


// LinkedHashMap 의 accessOrder=true + removeEldestEntry 로 LRU 캐시
class LruCache<K, V> extends LinkedHashMap<K, V> {
    private final int maxSize;

    LruCache(int maxSize) {
        super(maxSize, 0.75f, true);   // accessOrder=true
        this.maxSize = maxSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > maxSize;
    }
}

LruCache<String, String> cache = new LruCache<>(3);
cache.put("a", "1");
cache.put("b", "2");
cache.put("c", "3");
cache.get("a");        // a 를 최근 사용으로 이동
cache.put("d", "4");   // b 가 제거됨 (가장 오래된 미사용)

Java 17+ 실전: 계단식 요금 룩업 (TreeMap)


// 1000원 미만: 0%, 1000원 이상: 5%, 5000원 이상: 10%, 10000원 이상: 15%
TreeMap<Integer, Integer> discountTable = new TreeMap<>();
discountTable.put(0,     0);
discountTable.put(1000,  5);
discountTable.put(5000,  10);
discountTable.put(10000, 15);

int getDiscount(int amount) {
    return discountTable.floorEntry(amount).getValue();
}

getDiscount(3000);   // 5%
getDiscount(9999);   // 10%
getDiscount(10000);  // 15%

동기화 옵션

// 옵션 1: Collections.synchronizedMap (복합 연산은 외부 동기화 필요)
Map<K, V> sync = Collections.synchronizedMap(new HashMap<>());
synchronized (sync) {
    if (!sync.containsKey(key)) sync.put(key, value);   // check-then-act
}

// 옵션 2: ConcurrentHashMap (권장, 복합 연산도 원자적)
Map<K, V> concurrent = new ConcurrentHashMap<>();
concurrent.putIfAbsent(key, value);   // 원자적

// 옵션 3: 정렬 + 동시성
Map<K, V> sortedConcurrent = new java.util.concurrent.ConcurrentSkipListMap<>();

[[ConcurrentHashMap]] 이 거의 항상 synchronizedMap 보다 빠르다.

함정

1. null key/value 구현체별 차이

HashMap<String, String> hm = new HashMap<>();
hm.put(null, "v");    // OK
hm.put("k", null);    // OK

TreeMap<String, String> tm = new TreeMap<>();
tm.put(null, "v");    // NullPointerException (compareTo(null))

ConcurrentHashMap<String, String> chm = new ConcurrentHashMap<>();
chm.put(null, "v");   // NullPointerException
chm.put("k", null);   // NullPointerException

2. entrySet/keySet/values 는 live view

Map<String, Integer> map = new HashMap<>(Map.of("a", 1, "b", 2));
Set<String> keys = map.keySet();
map.put("c", 3);
keys.contains("c");   // true (live view)

// 순회 중 map 수정 → ConcurrentModificationException
for (String k : map.keySet()) {
    map.remove(k);   // ConcurrentModificationException
}

// 안전한 제거
map.entrySet().removeIf(e -> e.getValue() < 2);

3. getOrDefault vs computeIfAbsent 혼동

// getOrDefault: 기본값 반환만, map 에 추가 안 함
map.getOrDefault("missing", new ArrayList<>());   // map 에 추가 안 됨

// computeIfAbsent: 없으면 람다 실행 후 map 에 추가
map.computeIfAbsent("missing", k -> new ArrayList<>());   // map 에 추가됨

4. Map.of 중복 key 예외

// 컴파일은 되지만 런타임 예외
Map<String, Integer> bad = Map.of("a", 1, "a", 2);   // IllegalArgumentException

[Java] PriorityQueue

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.PriorityQueue<E> 는 이진 힙 (binary heap) 기반의 [[Queue]] 구현. FIFO 가 아닌 우선순위 순서 로 원소를 꺼낸다.

기본은 min-heap, Comparable 의 자연 순서나 Comparator 로 우선순위 결정. 가장 작은 (또는 highest-priority) 원소가 head.

사용 상황

상황	이유
Top-K 원소 추출	O(n log k), 전체 정렬보다 효율적
작업 스케줄러	우선순위별 실행 순서 보장
Dijkstra / A* 최단경로	최소 비용 노드를 O(log n) 에 꺼냄
Merge K sorted lists	각 리스트 head 를 힙에 유지
이벤트 드리븐 시뮬레이션	타임스탬프 기반 정렬

시각화

{}

내부 구조

public class PriorityQueue<E> extends AbstractQueue<E> ... {
    transient Object[] queue;      // 힙을 표현하는 배열
    private int size;
    private final Comparator<? super E> comparator;
}

배열로 이진 힙을 표현. 인덱스 i 일 때:

부모: (i - 1) / 2
왼쪽 자식: 2i + 1
오른쪽 자식: 2i + 2

배열: [1, 3, 2, 6, 5, 8, 7]
힙:        1
         /   \
        3     2
       / \   / \
      6   5 8   7

peek (= queue[0]) 가 항상 최솟값.

offer / poll 흐름

flowchart LR
    subgraph OFFER["offer(e): 삽입"]
        O1["배열 끝에 추가"]
        O2["sift up: 부모와 비교"]
        O3{"부모 > e?"}
        O4["부모와 swap"]
        O5["완료"]

        O1 --> O2 --> O3
        O3 -->|"예"| O4 --> O2
        O3 -->|"아니오"| O5
    end

    subgraph POLL["poll(): 최솟값 제거"]
        P1["root 저장"]
        P2["마지막 원소를 root로"]
        P3["sift down: 더 작은 자식과 비교"]
        P4{"더 작은 자식 < 현재?"}
        P5["자식과 swap"]
        P6["완료"]

        P1 --> P2 --> P3 --> P4
        P4 -->|"예"| P5 --> P3
        P4 -->|"아니오"| P6
    end

복잡도

작업	시간
`offer(e)` (add)	O(log n) (sift up)
`poll()` (remove min)	O(log n) (sift down)
`peek()`	O(1)
`contains`	O(n)
`remove(Object)`	O(n) (선형 검색 + sift)

사용 예

최솟값 N 개 (Top-K)

PriorityQueue<Integer> minHeap = new PriorityQueue<>();
for (int x : data) {
    minHeap.offer(x);
    if (minHeap.size() > k) minHeap.poll();   // k 보다 크면 제거
}
// minHeap 에는 최대 k 개의 가장 큰 값들이 들어있음

O(n log k) 로 Top-K 해결. 전체 정렬 O(n log n) 보다 효율적.

max-heap 만들기

// Comparator.reverseOrder() 로 max-heap 구현
PriorityQueue<Integer> maxHeap = new PriorityQueue<>(Comparator.reverseOrder());
maxHeap.offer(3);
maxHeap.offer(1);
maxHeap.offer(5);
maxHeap.poll();   // 5 (가장 큰 값)

작업 스케줄러

PriorityQueue<Task> scheduler = new PriorityQueue<>(
    Comparator.comparingInt(Task::priority).reversed()   // 우선순위 높은 게 먼저
);
scheduler.offer(new Task(...));
Task next = scheduler.poll();

Dijkstra 알고리즘

PriorityQueue<int[]> pq = new PriorityQueue<>(
    (a, b) -> Integer.compare(a[1], b[1])   // [node, distance]
);
pq.offer(new int[]{start, 0});
int[] dist = new int[n];
Arrays.fill(dist, Integer.MAX_VALUE);
dist[start] = 0;

while (!pq.isEmpty()) {
    int[] cur = pq.poll();
    int node = cur[0], d = cur[1];
    if (d > dist[node]) continue;          // 이미 더 짧은 경로 처리됨
    for (int[] edge : graph[node]) {
        int next = edge[0], cost = edge[1];
        if (dist[node] + cost < dist[next]) {
            dist[next] = dist[node] + cost;
            pq.offer(new int[]{next, dist[next]});
        }
    }
}

K 개의 정렬된 배열 병합

// int[][] arrays = 정렬된 k 개의 배열
PriorityQueue<int[]> pq = new PriorityQueue<>((a, b) -> a[0] - b[0]);
// [값, 배열인덱스, 원소인덱스]
for (int i = 0; i < arrays.length; i++) {
    if (arrays[i].length > 0) {
        pq.offer(new int[]{arrays[i][0], i, 0});
    }
}

List<Integer> result = new ArrayList<>();
while (!pq.isEmpty()) {
    int[] cur = pq.poll();
    result.add(cur[0]);
    int ai = cur[1], ei = cur[2];
    if (ei + 1 < arrays[ai].length) {
        pq.offer(new int[]{arrays[ai][ei + 1], ai, ei + 1});
    }
}
// O(n log k), n = 전체 원소 수

힙 정렬 (Heap Sort)

PriorityQueue 를 이용한 O(n log n) 정렬. 실용적이진 않지만 동작 원리를 이해하는 데 좋다.

static int[] heapSort(int[] arr) {
    PriorityQueue<Integer> minHeap = new PriorityQueue<>();
    for (int x : arr) minHeap.offer(x);

    int[] result = new int[arr.length];
    for (int i = 0; i < arr.length; i++) {
        result[i] = minHeap.poll();
    }
    return result;   // 오름차순 정렬
}

실무에서는 Arrays.sort() 가 dual-pivot quicksort 를 써서 캐시 효율이 훨씬 좋다. 이 패턴은 알고리즘 이해용.

함정

1. 순회 순서가 정렬 순서가 아니다

PriorityQueue<Integer> pq = new PriorityQueue<>(List.of(5, 3, 8, 1));
for (Integer x : pq) System.out.print(x + " ");   // 1 3 8 5 (힙 배열 순서)

원소를 정렬된 순서로 보려면 poll() 을 반복하거나 별도 정렬 필요.

2. null 비허용

pq.offer(null);   // NullPointerException

3. thread-safe 가 아님

[[PriorityBlockingQueue]] 가 동시성 버전.

4. remove(Object) 는 O(n)

힙에서 임의 원소를 빠르게 찾는 방법이 없다. 빠른 remove 가 필요하면 TreeSet 또는 외부 인덱싱 자료구조.

[!CAUTION] Comparator 가 equals 와 일치하지 않으면 remove(Object) 가 동작하지 않을 수 있다. Comparator 가 두 원소를 “같다” 고 보더라도 equals 가 false 면 다른 객체로 취급.

5. 초기 용량과 정렬 모드

// 힙 생성 시 초기 용량 + Comparator 지정
PriorityQueue<String> pq = new PriorityQueue<>(100, Comparator.reverseOrder());

초기 용량은 힌트. 자동 grow 되지만, 대량 삽입이 예상되면 미리 지정해 reallocation 방지.

초기 데이터 일괄 삽입

// Collection 을 넘기면 O(n) heapify 로 힙 구성 (개별 offer 의 O(n log n) 보다 빠름)
List<Integer> data = List.of(5, 3, 8, 1, 9, 2);
PriorityQueue<Integer> pq = new PriorityQueue<>(data);
// pq.poll() = 1 (최솟값)

// size 힌트 없이 만들어도 내부에서 배열 grow 처리
PriorityQueue<Integer> pq2 = new PriorityQueue<>(data.size(), Comparator.reverseOrder());
pq2.addAll(data);
// pq2.poll() = 9 (최댓값)

[Java] ReentrantReadWriteLock

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.locks.ReentrantReadWriteLock 는 읽기 락과 쓰기 락을 분리 한 [[java-reentrant-lock|ReentrantLock]] 의 확장.

핵심 규칙:

여러 reader 가 동시에 read lock 획득 가능 (병렬 읽기)
writer 는 배타적: write lock 잡혀 있으면 reader 도 새 writer 도 대기
재진입 가능 (같은 스레드)

사용 상황

읽기 비율이 압도적으로 높고 쓰기가 드문 자료구조에 적합.

설정 캐시: 수천 번 읽고 드물게 reload
인메모리 인덱스: 검색은 병렬, 갱신은 배타
참조 데이터 테이블: 국가 코드, 환율 등 거의 변하지 않는 테이블

쓰기 비율이 높으면 오히려 [[java-reentrant-lock|ReentrantLock]] 단일 락보다 느리다.

시각화: 락 상태 전이

flowchart TD
    FREE["락 없음\n(readers=0, writer=0)"]
    READING["읽기 중\n(readers=N, writer=0)"]
    WRITING["쓰기 중\n(readers=0, writer=1)"]

    FREE -->|"readLock.lock()"| READING
    READING -->|"readLock.lock() 추가"| READING
    READING -->|"모든 readLock.unlock()"| FREE
    FREE -->|"writeLock.lock()"| WRITING
    WRITING -->|"writeLock.unlock()"| FREE
    READING -->|"writeLock.lock() 시도"| BLOCK_W["write 대기\n(readers 종료까지)"]
    BLOCK_W -->|"모든 reader 완료"| WRITING

사용

ReentrantReadWriteLock rrw = new ReentrantReadWriteLock();
Lock readLock = rrw.readLock();
Lock writeLock = rrw.writeLock();

// Reader: 여러 스레드가 동시에 실행 가능
readLock.lock();
try {
    return data.get();
} finally {
    readLock.unlock();
}

// Writer: 배타적 실행
writeLock.lock();
try {
    data.update();
} finally {
    writeLock.unlock();
}

내부 구조: AQS 기반

ReentrantReadWriteLock 은 AbstractQueuedSynchronizer (AQS) 의 단일 int state 를 두 영역으로 분리해 사용한다.

state (32bit)
┌─────────────────┬──────────────────┐
│  상위 16bit     │  하위 16bit      │
│  read lock 수   │  write lock 수   │
└─────────────────┴──────────────────┘

// JDK 소스 발췌 (단순화)
static final int SHARED_SHIFT   = 16;
static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;  // 65535
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

read lock 하나 획득 = state += SHARED_UNIT, write lock 하나 획득 = state += 1.

언제 유리한가

읽기 >> 쓰기 인 시나리오. 여러 reader 가 동시에 읽을 수 있으니 throughput 이 향상.

쓰기가 잦으면 오히려 손해. ReentrantLock 보다 오버헤드가 크고, write lock 대기로 reader 도 같이 멈춘다.

Read 80%, Write 20% 이상 -> ReentrantLock 이 더 빠를 가능성
Read 99%, Write 1% -> ReentrantReadWriteLock 유리

공정성

ReentrantReadWriteLock fair = new ReentrantReadWriteLock(true);

non-fair (기본): writer starvation 가능 (계속 reader 가 들어와 writer 가 기다림)
fair: FIFO, writer 기아 방지하지만 throughput 저하

downgrading 과 upgrading

락 다운그레이드 (write → read): 가능

writeLock.lock();
try {
    data.update();
    readLock.lock();      // write 락 유지한 채 read 락도 획득
} finally {
    writeLock.unlock();   // write 만 풀어 reader 로 강등
}
try {
    return data.get();    // 이제 read 락만 잡고 있음
} finally {
    readLock.unlock();
}

다운그레이드 패턴의 이점: 갱신 후 결과를 읽는 동안 다른 writer 가 끼어들지 못하게 한다.

락 업그레이드 (read → write): 직접 불가

readLock.lock();
writeLock.lock();    // ❌ deadlock 발생 가능

두 reader 가 동시에 업그레이드를 시도하면 서로가 상대방의 read lock 을 기다려 deadlock. 해결책은 read lock 을 풀고 write lock 을 새로 잡는 것 (그 사이 상태 변경 가능성 고려 필요).

실전 코드: 캐시 패턴

// Java 17+ 패턴
public class ConfigCache {
    private final Map<String, String> cache = new HashMap<>();
    private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
    private final Lock readLock = rwLock.readLock();
    private final Lock writeLock = rwLock.writeLock();

    public String get(String key) {
        readLock.lock();
        try {
            return cache.get(key);
        } finally {
            readLock.unlock();
        }
    }

    public void reload(Map<String, String> newConfig) {
        writeLock.lock();
        try {
            cache.clear();
            cache.putAll(newConfig);
        } finally {
            writeLock.unlock();
        }
    }

    // 쓰기 후 바로 읽기: 다운그레이드 패턴
    public String putAndGet(String key, String value) {
        writeLock.lock();
        try {
            cache.put(key, value);
            readLock.lock();          // 다운그레이드 준비
        } finally {
            writeLock.unlock();       // write 락 해제 (read 락은 유지)
        }
        try {
            return cache.get(key);
        } finally {
            readLock.unlock();
        }
    }
}

StampedLock 과의 비교

[[java-stamped-lock|StampedLock]] (JDK 1.8) 은 추가로 optimistic read 를 지원. read lock 없이 시도 후 검증. 변경 가능성이 낮을 때 더 빠르다.

| 항목 | ReentrantReadWriteLock | [[java-stamped-lock|StampedLock]] | |:---|:---|:---| | 재진입 | ✓ | ✗ | | 조건 변수 | ✓ | ✗ | | optimistic read | ✗ | ✓ | | 인터럽트 응답 | ✓ | 메서드별 다름 | | 도입 | JDK 1.5 | JDK 1.8 | | 코드 복잡도 | 단순 | 복잡 |

함정

1. writer starvation (non-fair 기본)

// non-fair 모드: reader 가 계속 들어오면 writer 가 영원히 못 잡음
// 해결: new ReentrantReadWriteLock(true) 또는 쓰기 빈도 재검토

[!WARNING] non-fair 기본 설정에서 읽기 비율이 매우 높으면 writer 가 starve 될 수 있다. 실제 서비스 환경에서 관찰된 경우에만 fair 모드로 전환.

2. 읽기 Condition 미지원

read lock 에는 Condition 을 만들 수 없다. write lock 에만 가능.

Condition cond = rwLock.writeLock().newCondition();  // ✓
Condition cond = rwLock.readLock().newCondition();   // ❌ UnsupportedOperationException

3. 재진입 횟수 상한

read lock 의 재진입 횟수는 65535 회. 이를 초과하면 Error 발생. 실무에서 도달하기 어렵지만 재귀 깊이 관리 필요.

[!CAUTION] 읽기/쓰기 비율 80/20 이하 시나리오에서는 단일 ReentrantLock 이나 synchronized 가 더 빠른 경우가 많다. 반드시 프로파일링 후 도입.

성능 가이드라인

읽기 비율   쓰기 비율   추천
≥ 99%      ≤ 1%       StampedLock optimistic read
≥ 90%      ≤ 10%      ReentrantReadWriteLock
≥ 70%      ≤ 30%      ReentrantLock or synchronized
< 70%                  synchronized (단순, JVM 최적화)

프로파일링 없이 최적화 도구를 선택하지 말 것. synchronized 는 JVM 이 biased-locking, adaptive spinning 등으로 최적화하므로 실측 우선.

[!TIP] JDK 15+ 에서 biased-locking 이 deprecated 되었고 JDK 21 에서 제거됐다. 저경합 시나리오에서 synchronized 성능이 이전보다 약간 달라졌으므로 측정 환경의 JDK 버전도 확인할 것.

[Java] Semaphore

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.Semaphore 는 N 개의 permit (허가) 을 발급/회수 하는 synchronizer. permit 이 있으면 진행, 없으면 [[Blocking]] 또는 즉시 실패.

자원 풀, rate limiting, 동시 접근 수 제한 같은 패턴의 표준 도구. 내부적으로 AbstractQueuedSynchronizer (AQS) 를 기반으로 구현되어 있다.

사용 상황

상황	예시
외부 API 동시 요청 제한	동시 5 요청만 허용하는 외부 결제 API
자원 풀 접근 제어	DB connection pool, thread pool
Rate limiting	처리량 상한 설정
섹션 간 흐름 제어	생산자-소비자 버퍼 크기 제한
단방향 신호	permit 1개를 다른 스레드에서 release

Semaphore 는 “동시에 N 개 진행” 이라는 제약이 필요한 모든 곳에 사용. 재사용 가능한 synchronizer 라는 점에서 [[CountDownLatch]] (단방향, 재사용 불가) 와 구분된다.

시각화

{}

핵심 메서드

Semaphore s = new Semaphore(10);          // 10 permit 발급

// 획득
s.acquire();                               // 1 permit 획득, 없으면 block
s.acquire(3);                              // 3 permit 동시 획득
s.tryAcquire();                            // 즉시 시도, 실패 시 false
s.tryAcquire(500, TimeUnit.MILLISECONDS);  // 최대 500ms 대기 후 false

// 반환
s.release();                               // 1 permit 반환
s.release(3);                              // 3 permit 동시 반환

// 조회/제어
s.availablePermits();                      // 현재 남은 permit 수
s.hasQueuedThreads();                      // 대기 중인 스레드 존재 여부
s.getQueueLength();                        // 대기 중인 스레드 수 (추정)
s.drainPermits();                          // 남은 permit 전부 획득 후 개수 반환

permit 획득 흐름

flowchart TD
    T["acquire() 호출"] --> Check{"permits > 0?"}
    Check -->|"예"| Dec["permits 감소"]
    Dec --> Enter["임계 구역 진입"]
    Enter --> Work["작업 수행"]
    Work --> Rel["release() 호출"]
    Rel --> Inc["permits 증가"]
    Inc --> Wake["대기 스레드 깨우기"]
    Check -->|"아니오"| Fair{"공정 모드?"}
    Fair -->|"예"| Queue["AQS CLH 큐 끝에 삽입"]
    Fair -->|"아니오"| Spin["CAS 재시도 or 파킹"]
    Queue --> Park["스레드 파킹"]
    Spin --> Park
    Park --> Check

가장 흔한 세 가지 패턴

1. 동시 접근 제한 (concurrency limiter)

Semaphore limiter = new Semaphore(5);   // 동시 5 요청만 허용

public void callExpensiveApi() throws InterruptedException {
    limiter.acquire();
    try {
        externalApi.call();
    } finally {
        limiter.release();   // 반드시 finally
    }
}

외부 API 가 동시 5 요청까지만 허용한다면 이렇게 제한. finally 에 release() 가 없으면 permit 이 영구 소실된다.

2. 자원 풀

// Java 17+ record 활용
record ConnectionPool(Semaphore semaphore, Queue<Connection> pool) {

    static ConnectionPool create(int size) {
        return new ConnectionPool(
            new Semaphore(size),
            createConnections(size)
        );
    }

    public Connection acquire() throws InterruptedException {
        semaphore.acquire();
        return pool.poll();   // semaphore 가 보장하므로 null 불가
    }

    public void release(Connection c) {
        pool.offer(c);
        semaphore.release();
    }
}

pool.poll() 이 항상 non-null 인 이유: semaphore permit 수 = pool 크기. permit 을 획득했다는 것은 pool 에 반드시 자원이 하나 있다는 뜻.

3. tryAcquire 로 비차단 패턴

public Optional<Result> tryProcess(Request req) {
    if (!semaphore.tryAcquire()) {
        return Optional.empty();   // 즉시 거부, 큐잉하거나 fallback
    }
    try {
        return Optional.of(process(req));
    } finally {
        semaphore.release();
    }
}

대기 없이 즉시 성공/실패를 결정해야 하는 경우 (예: API rate limiting 에서 초과 시 429 반환).

binary semaphore (= mutex 와 비슷)

Semaphore mutex = new Semaphore(1);
mutex.acquire();
try {
    // 상호 배제 구역
} finally {
    mutex.release();
}

ReentrantLock / synchronized 와 비슷하지만 핵심 차이.

특성	binary Semaphore	ReentrantLock
소유권 추적	없음 (누구든 release 가능)	있음 (획득 스레드만 release)
재진입	불가 (self-deadlock)	가능
일반적 용도	크로스 스레드 신호	일반 mutual exclusion

mutex 용도라면 [[ReentrantLock]] 또는 synchronized 를 사용하고, Semaphore 는 permit 수 제어 가 필요한 경우에만 사용.

공정성 옵션

Semaphore fair = new Semaphore(5, true);   // FIFO 순서 보장

true 이면 FIFO: 대기 큐에 가장 오래된 스레드부터 permit 할당. false (기본) 이면 경쟁: 새로 도착한 스레드가 대기 중인 스레드보다 먼저 획득 가능.

[!NOTE] tryAcquire() (timeout 없는 버전) 는 공정 모드에서도 큐를 무시하고 즉시 barging. 공정성이 필요하면 tryAcquire(0, NANOSECONDS) 를 사용.

Semaphore vs CountDownLatch vs CyclicBarrier

flowchart LR
    Goal["동시성 제어 필요"] --> Q1{"동시 실행 수\n제한이 목적?"}
    Q1 -->|"예"| Sem["Semaphore\n재사용 가능"]
    Q1 -->|"아니오"| Q2{"스레드들이\n한 지점에서 모임?"}
    Q2 -->|"예, 재사용 필요"| CB["CyclicBarrier\n재사용 가능"]
    Q2 -->|"예, 일회성"| CDL["CountDownLatch\n일회성"]
    Q2 -->|"단방향 이벤트 신호"| CDL

특성	Semaphore	CountDownLatch	CyclicBarrier
목적	자원 수 제한	이벤트 대기	집결 후 출발
재사용	✓	✗	✓
방향	양방향 (acquire/release)	단방향 (count down)	양방향 (await/trip)
일반 패턴	접근 제어	초기화 완료 대기	페이즈 동기화

AQS 내부 구조

Semaphore 는 AbstractQueuedSynchronizer (AQS) 를 위임 받아 구현. permit 수는 AQS 의 state 정수에 저장된다.

// Semaphore 내부 (단순화)
abstract static class Sync extends AbstractQueuedSynchronizer {

    Sync(int permits) {
        setState(permits);   // AQS state = permit 수
    }

    final int nonfairTryAcquireShared(int acquires) {
        for (;;) {
            int available = getState();
            int remaining = available - acquires;
            if (remaining < 0 || compareAndSetState(available, remaining))
                return remaining;   // 음수면 큐에 파킹
        }
    }

    protected final boolean tryReleaseShared(int releases) {
        for (;;) {
            int current = getState();
            int next = current + releases;
            if (compareAndSetState(current, next))
                return true;   // 파킹된 스레드 깨우기 트리거
        }
    }
}

permit 이 0 이 되면 AQS 의 CLH 큐에 스레드가 LockSupport.park() 로 파킹된다. release() 시 CLH 큐에서 꺼내 LockSupport.unpark().

Java 17+ 활용 예

// Java 17+ record + Semaphore 로 간단한 rate limiter 빌더
record RateLimitedExecutor(Semaphore semaphore) {

    static RateLimitedExecutor of(int concurrency) {
        return new RateLimitedExecutor(new Semaphore(concurrency));
    }

    <T> T execute(Callable<T> task) throws Exception {
        semaphore.acquire();
        try {
            return task.call();
        } finally {
            semaphore.release();
        }
    }

    <T> Optional<T> tryExecute(Callable<T> task) throws Exception {
        if (!semaphore.tryAcquire()) return Optional.empty();
        try {
            return Optional.of(task.call());
        } finally {
            semaphore.release();
        }
    }
}

함정

1. release 빠뜨리면 permit 영구 소실

limiter.acquire();
doWork();             // 예외 시 release 안 됨
limiter.release();    // 도달하지 않을 수 있음

반드시 try/finally 패턴.

2. acquire 없이 release 하면 permit 수가 늘어남

release() 가 acquire() 보다 많이 호출되면 permit 이 초기값보다 늘어난다. Semaphore 는 이를 막지 않는다. acquire/release 쌍이 항상 균형을 이뤄야 한다.

3. tryAcquire() 와 tryAcquire(0, NANOSECONDS) 의 차이

tryAcquire() 는 공정 모드에서도 큐를 무시하고 barging (새치기). 공정한 비차단 시도가 필요하면 tryAcquire(0, TimeUnit.NANOSECONDS) 사용.

4. InterruptedException 처리

acquire() 는 InterruptedException 을 던진다. 인터럽트를 캐치만 하고 무시하면 신호가 소실된다.

try {
    semaphore.acquire();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // 신호 복원
    return;   // 혹은 상위로 전파
}

5. 복합 연산의 원자성

// 잘못: availablePermits() 확인과 acquire() 사이에 다른 스레드가 끼어들 수 있음
if (semaphore.availablePermits() > 0) {
    semaphore.acquire();   // CME 아닌 논리 오류
}

// 올바름: tryAcquire() 가 원자적으로 확인 + 획득
if (semaphore.tryAcquire()) { ... }

[Java] StampedLock

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.locks.StampedLock 는 JDK 1.8 도입의 새 락. 세 가지 모드 제공.

Write lock (배타)
Read lock (공유)
Optimistic read (락 없이 시도, 변경 감지 시 retry)

stamp 라는 long 토큰으로 락 상태를 추적. acquire 시 stamp 반환, release 시 stamp 전달.

사용 상황

읽기가 압도적으로 많고 쓰기는 거의 없는 자료구조
짧은 읽기 연산: 두세 필드 읽는 수준, 긴 연산은 optimistic retry 비용이 누적
[[java-reentrant-readwrite-lock|ReentrantReadWriteLock]] 으로도 부족할 때의 차선책
재진입이 필요 없는 단순 락 시나리오

시각화: 세 가지 모드 전이

flowchart TD
    FREE["락 없음"]
    WRITING["쓰기 모드\n(배타)"]
    READING["읽기 모드\n(공유, N개 동시)"]
    OPT["옵티미스틱 읽기\n(락 없음)"]

    FREE -->|"writeLock()"| WRITING
    WRITING -->|"unlockWrite(stamp)"| FREE
    FREE -->|"readLock()"| READING
    READING -->|"unlockRead(stamp)"| FREE
    FREE -->|"tryOptimisticRead()"| OPT
    OPT -->|"validate(stamp) true"| FREE
    OPT -->|"validate(stamp) false"| READING
    WRITING -->|"tryConvertToReadLock(stamp)"| READING
    READING -->|"tryConvertToWriteLock(stamp)"| WRITING

핵심 메서드

StampedLock lock = new StampedLock();

// Write lock
long stamp = lock.writeLock();
try { ... } finally { lock.unlockWrite(stamp); }

// Read lock
long stamp = lock.readLock();
try { ... } finally { lock.unlockRead(stamp); }

// Optimistic read
long stamp = lock.tryOptimisticRead();
int value = data.get();                       // 락 없이 읽기
if (!lock.validate(stamp)) {                  // 변경 발생?
    stamp = lock.readLock();                  // 폴백: read lock
    try {
        value = data.get();
    } finally {
        lock.unlockRead(stamp);
    }
}

Optimistic Read 의 사상

writer 가 거의 없을 것이라 가정하고 락 없이 일단 읽는다. 끝나고 “내가 읽는 동안 write 가 있었나?” 를 validate(stamp) 로 검사. 없었다면 데이터 일관, 있었다면 read lock 으로 폴백.

[[java-volatile|volatile]] read 한 번 정도의 비용으로 끝나는 best case.

stamp 내부 구조

stamp 는 단순 long 이 아니라 버전 카운터 + 모드 비트 가 인코딩된 값.

stamp (64bit long)
┌──────────────────────────────────────────────────────────┐
│  상위 57bit: 버전 카운터 (write 발생마다 증가)             │
│  하위 7bit: 락 모드 (RUNIT=0000001, WBIT=10000000 등)     │
└──────────────────────────────────────────────────────────┘

validate(stamp) 는 현재 stamp 와 저장된 stamp 의 버전 비트가 같은지 비교. write 가 발생하면 버전이 증가하므로 mismatch 가 된다.

실전 패턴: Point 클래스

// Java 17+: StampedLock Point 패턴
class Point {
    private double x, y;
    private final StampedLock lock = new StampedLock();

    // 쓰기: 배타 락
    public void move(double dx, double dy) {
        long stamp = lock.writeLock();
        try {
            x += dx;
            y += dy;
        } finally {
            lock.unlockWrite(stamp);
        }
    }

    // 읽기: optimistic first, read lock fallback
    public double distanceFromOrigin() {
        long stamp = lock.tryOptimisticRead();
        double cx = x, cy = y;                // 락 없이 스냅샷
        if (!lock.validate(stamp)) {           // write 발생?
            stamp = lock.readLock();
            try {
                cx = x; cy = y;
            } finally {
                lock.unlockRead(stamp);
            }
        }
        return Math.sqrt(cx * cx + cy * cy);
    }
}

Point 의 두 필드를 atomic 하게 읽기 위해 락 없이 시도, 변경 발생 시 폴백.

tryConvertToWriteLock: 조건부 업그레이드

readLock 에서 조건에 따라 write lock 으로 전환할 수 있다.

// 읽고, 조건 충족 시 쓰기 (업그레이드 시도)
public void updateIfAbsent(int newValue) {
    long stamp = lock.readLock();
    try {
        if (data != 0) return;     // 이미 있음

        // read -> write 업그레이드 시도
        long ws = lock.tryConvertToWriteLock(stamp);
        if (ws != 0) {             // 성공
            stamp = ws;
            data = newValue;
        } else {
            // 업그레이드 실패 (다른 reader 있음), write lock 명시 획득
            lock.unlockRead(stamp);
            stamp = lock.writeLock();
            data = newValue;
        }
    } finally {
        lock.unlock(stamp);
    }
}

lock.unlock(stamp) 은 stamp 모드에 따라 읽기/쓰기 unlock 을 자동 선택.

제약사항

재진입 불가: 같은 스레드가 write lock 을 두 번 잡으면 deadlock
Condition 미지원: wait/notify 같은 조건 변수 사용 불가
인터럽트 처리 메서드별 다름: 모두 인터럽트에 응답하지는 않음
upgrading / downgrading: tryConvertToWriteLock, tryConvertToReadLock 으로 가능 (다른 stamp 발급)

언제 적절한가

읽기 압도적으로 많고, 쓰기는 거의 없으며, 짧은 읽기 인 경우.

긴 read 작업이라면 optimistic read 도중 변경 발생 가능성이 높아 폴백 비용이 누적된다.

읽기 짧음 + 쓰기 극히 드묾 -> StampedLock optimistic read
읽기 길거나 쓰기 가끔 있음 -> ReentrantReadWriteLock
재진입 / Condition 필요   -> ReentrantReadWriteLock
단순 mutex               -> synchronized 또는 ReentrantLock

ReentrantReadWriteLock vs StampedLock

| 항목 | [[java-reentrant-readwrite-lock|ReentrantReadWriteLock]] | StampedLock | |:---|:---|:---| | 재진입 | ✓ | ✗ | | 조건 변수 | ✓ | ✗ | | optimistic read | ✗ | ✓ | | 코드 복잡도 | 단순 | 복잡 | | 성능 (read 99%) | 좋음 | 더 좋음 | | 성능 (read 50%) | 비슷 | 비슷 또는 더 나쁨 |

함정

1. 재진입 deadlock

// ❌ 같은 스레드가 두 번 write lock
long s1 = lock.writeLock();
long s2 = lock.writeLock();  // deadlock: 자기 자신이 먼저 release 해야 하는데 block 됨

[!WARNING] StampedLock 은 재진입을 허용하지 않는다. 재귀 함수나 콜백 체인에서 같은 lock 을 두 번 잡으면 즉시 deadlock. 재진입이 필요하면 ReentrantReadWriteLock 을 사용.

2. stamp 0 반환

tryOptimisticRead() 가 0 을 반환하는 경우: write lock 이 잡혀 있을 때. 이때 validate 는 항상 false.

long stamp = lock.tryOptimisticRead();
if (stamp == 0) {
    // write lock 잡혀 있음, optimistic 불가
    stamp = lock.readLock();
    try { ... } finally { lock.unlockRead(stamp); }
    return;
}

3. optimistic read 범위 밖에서 validate

// ❌ validate 를 읽기 완료 전에 호출
long stamp = lock.tryOptimisticRead();
if (!lock.validate(stamp)) { ... }
// validate 후에 읽으면 의미 없음: validate 사이에 write 가 또 올 수 있음
int value = data.get();

[!CAUTION] validate 는 읽기 완료 후 호출해야 한다. 읽기 범위 전체를 stamp 발급과 validate 사이에 두는 것이 올바른 패턴.

인터럽트 응답 메서드 정리

일부 메서드만 인터럽트에 응답한다.

메서드	인터럽트 응답
`writeLock()`	✗ (block)
`writeLockInterruptibly()`	✓
`readLock()`	✗ (block)
`readLockInterruptibly()`	✓
`tryOptimisticRead()`	N/A (락 없음)
`tryWriteLock()`	N/A (즉시 반환)
`tryReadLock()`	N/A (즉시 반환)

인터럽트가 필요한 시나리오에서는 *Interruptibly() 버전을 사용할 것.

[!CAUTION] writeLock() 은 인터럽트를 무시하고 락이 해제될 때까지 대기한다. 스레드를 종료해야 하는 shutdownNow 등의 상황에서는 반드시 writeLockInterruptibly() 를 사용.

[Java] TreeMap

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.TreeMap<K,V> 는 Red-Black Tree 기반의 정렬된 [[java-map|Map]]. NavigableMap (확장 인터페이스) 을 구현해 범위 쿼리, floor/ceiling, sub-map 같은 정렬 기반 연산을 제공한다.

key 는 자연 순서 (Comparable) 또는 생성 시 지정한 Comparator 로 정렬된다.

사용 상황

정렬된 순회 가 필요한 경우: 알파벳 순, 날짜 순 나열
범위 쿼리: “X 이상 Y 미만” 항목 검색
floor / ceiling 조회: 특정 값 이상/이하에서 가장 가까운 key 찾기
우선순위 큐 대안: 다음 이벤트 시각 찾기, 스케줄 범위 조회

단순 key-value 저장이라면 [[java-hashmap|HashMap]] 평균 O(1) 이 훨씬 빠르다.

시각화: Red-Black Tree

flowchart TD
    R["20 (검정)"]
    L["10 (빨강)"]
    RR["30 (빨강)"]
    LL["5 (검정)"]
    LR["15 (검정)"]
    RRL["25 (검정)"]
    RRR["40 (검정)"]

    R --> L
    R --> RR
    L --> LL
    L --> LR
    RR --> RRL
    RR --> RRR

Red-Black Tree 속성:

노드는 빨강 또는 검정
루트는 검정
빨강 노드의 자식은 검정 (연속 빨강 없음)
모든 경로의 검정 노드 수 동일 (Black-height)

이 속성 덕에 트리 높이가 2 log(n+1) 이하로 보장, O(log n) 확정.

핵심 메서드 (NavigableMap)

TreeMap<Integer, String> tm = new TreeMap<>();
tm.put(10, "a"); tm.put(20, "b"); tm.put(30, "c");

tm.firstKey();           // 10
tm.lastKey();            // 30
tm.floorKey(15);         // 10  (15 이하 중 가장 큰 key)
tm.ceilingKey(15);       // 20  (15 이상 중 가장 작은 key)
tm.higherKey(20);        // 30  (20 초과 중 가장 작은 key)
tm.lowerKey(20);         // 10  (20 미만 중 가장 큰 key)

tm.subMap(10, 30);       // [10, 30) 의 뷰
tm.headMap(20);          // 20 미만의 뷰
tm.tailMap(20);          // 20 이상의 뷰
tm.descendingMap();      // 역순 뷰

이런 정렬 기반 연산이 필요할 때 TreeMap. 그 외에는 [[java-hashmap|HashMap]] 이 빠르다.

복잡도

Red-Black Tree 의 성질.

작업	시간
`get`, `put`, `remove`	O(log n)
`containsKey`	O(log n)
`firstKey`, `lastKey`	O(log n)
`floorKey`, `ceilingKey`	O(log n)
순회	O(n), 정렬 순서

[[java-hashmap|HashMap]] 의 평균 O(1) 보다 느리지만 최악도 O(log n) 으로 보장된다는 점이 강점.

Comparator 사용

// 역순 정렬
TreeMap<String, Integer> reverse = new TreeMap<>(Comparator.reverseOrder());

// 사람 나이 기준 정렬
record Person(String name, int age) {}
TreeMap<Person, String> byAge = new TreeMap<>(
    Comparator.comparingInt(Person::age)
              .thenComparing(Person::name)
);

Comparator 가 일관되지 않으면 (transitive 위반 등) tree 가 깨진다.

null key 비허용

HashMap 과 달리 key 에 null 을 넣으면 NullPointerException (자연 순서 비교를 할 수 없음). Comparator 가 null 을 처리하도록 만들면 가능하지만 보통 안 한다.

실전 코드: 범위 쿼리

시간 범위 이벤트 조회

// Java 17+: 이벤트 스케줄러
record Event(String name) {}

TreeMap<Instant, Event> schedule = new TreeMap<>();
schedule.put(Instant.parse("2026-07-16T09:00:00Z"), new Event("일일 스탠드업"));
schedule.put(Instant.parse("2026-07-16T14:00:00Z"), new Event("기술 리뷰"));
schedule.put(Instant.parse("2026-07-16T17:00:00Z"), new Event("코드 리뷰"));

Instant from = Instant.parse("2026-07-16T10:00:00Z");
Instant to   = Instant.parse("2026-07-16T16:00:00Z");

// 10시~16시 사이 이벤트만
NavigableMap<Instant, Event> afternoon = schedule.subMap(from, true, to, false);
afternoon.forEach((t, e) -> System.out.println(t + " - " + e.name()));
// 2026-07-16T14:00:00Z - 기술 리뷰

가격 구간 할인율 찾기

// floor lookup: 기준 이하에서 가장 가까운 구간 찾기
TreeMap<Integer, Double> discounts = new TreeMap<>();
discounts.put(0,    0.00);   // 0원 이상: 할인 없음
discounts.put(10000, 0.05);  // 1만 이상: 5%
discounts.put(50000, 0.10);  // 5만 이상: 10%
discounts.put(100000, 0.15); // 10만 이상: 15%

int price = 75000;
Map.Entry<Integer, Double> tier = discounts.floorEntry(price);
// tier.getKey() = 50000, tier.getValue() = 0.10
double discount = tier != null ? tier.getValue() : 0.0;

자동완성 prefix 검색

TreeMap<String, Object> trie = new TreeMap<>();
trie.put("apple", 1); trie.put("app", 2); trie.put("application", 3);
trie.put("banana", 4);

String prefix = "app";
// "app" 이상 ~ "app" + 최대 Unicode 코드포인트 미만
NavigableMap<String, Object> matches = trie.subMap(prefix, prefix + "\uffff");
matches.forEach((k, v) -> System.out.println(k));
// app, apple, application

ConcurrentSkipListMap 과의 비교

| 항목 | TreeMap | [[java-concurrentskiplistmap|ConcurrentSkipListMap]] | |:---|:---|:---| | 백킹 | Red-Black Tree | Skip List | | Thread-safe | ✗ | ✓ | | 단일 스레드 성능 | 빠름 | 약간 느림 | | 동시성 | 외부 동기화 필요 | lock-free 읽기 | | 메모리 | 작음 | 더 큼 |

멀티스레드 환경의 정렬 Map 이 필요하면 [[java-concurrentskiplistmap|ConcurrentSkipListMap]] 을 사용. Collections.synchronizedSortedMap(new TreeMap<>()) 은 전 메서드에 lock 걸어서 처리량이 낮다.

함정

1. Comparator 와 equals 의 불일치

TreeMap 은 equals 가 아니라 compareTo/Comparator.compare 로 동등성 을 판단한다. 두 key 가 equals 는 false 인데 compare 가 0 을 반환하면 같은 key 로 취급.

TreeMap<BigDecimal, String> tm = new TreeMap<>();
tm.put(new BigDecimal("1.0"), "a");
tm.put(new BigDecimal("1.00"), "b");
// tm.size() == 1, "b" 가 "a" 를 덮어씀
// BigDecimal.compareTo 는 scale 을 무시하기 때문

[!WARNING] TreeMap 에 사용하는 key 의 compareTo 와 equals 는 반드시 일관되게 구현해야 한다. SortedMap 계약(contract)에 의해 equals 가 아니라 compareTo == 0 을 기준으로 동등성을 판단한다.

2. 동시 수정

TreeMap 은 thread-safe 하지 않다. 동시 수정 시 ConcurrentModificationException 또는 내부 트리 구조 오염이 발생할 수 있다.

// ❌ 멀티스레드에서 공유
Map<String, String> unsafe = new TreeMap<>();

// ✓ 외부 동기화 (단순, 처리량 낮음)
Map<String, String> safe = Collections.synchronizedSortedMap(new TreeMap<>());

// ✓ 동시성 전용 (처리량 높음)
ConcurrentNavigableMap<String, String> concurrent = new ConcurrentSkipListMap<>();

3. subMap 뷰는 live view

subMap, headMap, tailMap 은 새 복사본이 아니라 원본 맵의 뷰다. 뷰를 통한 수정은 원본에 즉시 반영되고, 범위를 벗어난 key 를 넣으면 예외.

NavigableMap<Integer, String> sub = tm.subMap(10, 20);
sub.put(15, "ok");   // ✓ 원본에도 반영
sub.put(25, "err");  // ❌ IllegalArgumentException: key out of range

실전 코드: 슬라이딩 윈도우 통계

// 최근 N개의 측정값에서 범위 통계 계산
// TreeMap<Long timestamp, Double value>
TreeMap<Long, Double> window = new TreeMap<>();
long windowMs = 60_000L;  // 1분 윈도우

public void add(long ts, double value) {
    window.put(ts, value);
    // 오래된 항목 제거
    Long cutoff = ts - windowMs;
    window.headMap(cutoff).clear();  // headMap 은 live view, clear() 가 원본 수정
}

public DoubleSummaryStatistics stats() {
    return window.values().stream().mapToDouble(Double::doubleValue).summaryStatistics();
}

public Map.Entry<Long, Double> latestBefore(long ts) {
    return window.floorEntry(ts);  // ts 이하에서 가장 가까운 항목
}

직렬화와 NavigableMap

TreeMap 은 Serializable 을 구현. 단, Comparator 도 직렬화 가능해야 한다.

// ❌ 람다 Comparator 는 직렬화 불가
TreeMap<String, Integer> broken = new TreeMap<>((a, b) -> b.compareTo(a));

// ✓ Serializable 구현 또는 Comparator.reverseOrder() 사용
TreeMap<String, Integer> ok = new TreeMap<>(Comparator.reverseOrder());
// Comparator.reverseOrder() 는 enum 기반으로 Serializable

[Java] Vector

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

java.util.Vector 는 [[ArrayList]] 와 거의 동일한 동적 배열 기반 [[List]] 이지만, 모든 public 메서드가 synchronized 로 묶여 있다. Java 1.0 (1996) 부터 존재하는 레거시 컬렉션.

JDK 1.2 의 Collections Framework 도입 시 List 인터페이스에 retrofit 됐으며, 같은 인터페이스를 구현하는 [[ArrayList]] 가 등장했다. 새 코드에서는 거의 쓰지 않는다.

사용 상황

Vector 는 새 코드에서 쓰지 않는다. 하지만 다음 상황에서 마주치게 된다.

상황	비고
레거시 코드 유지보수	JDK 1.0-1.1 시절 코드, 90년대 후반 ~ 2000년대 초
`Stack<E>` 사용 코드	`Stack` 이 `Vector` 를 상속
AWT/Swing API 내부	`JTable`, `JList` 모델 일부가 Vector 사용
API 반환값	서드파티 라이브러리가 반환하는 경우

이 파일은 Vector 를 왜 쓰지 않는지, 그리고 마주쳤을 때 어떻게 처리하는지를 이해하기 위한 것이다.

시각화

{}

내부 구조

public class Vector<E> extends AbstractList<E>
    implements List<E>, RandomAccess, Cloneable, java.io.Serializable {

    protected Object[] elementData;
    protected int elementCount;
    protected int capacityIncrement;   // 0 이면 두 배씩 증가

    public synchronized boolean add(E e) { ... }
    public synchronized E get(int index) { ... }
    public synchronized E remove(int index) { ... }
    public synchronized int size() { ... }
    // 거의 모든 메서드에 synchronized
}

[[ArrayList]] 와의 두 가지 구조적 차이.

capacityIncrement: 0 일 때 두 배씩 확장 (ArrayList 는 1.5 배). 양수로 지정하면 그 값만큼 고정 증가.
모든 메서드가 synchronized: 메서드 호출마다 this 의 모니터 락을 획득. size() 조차 락을 건다.

주요 연산 비용

복잡도 자체는 [[ArrayList]] 와 동일. 매 호출마다 락 acquire/release 가 더해진다.

메서드	시간	추가 비용
`get(int i)`	O(1)	락 acquire/release
`add(E e)`	amortized O(1)	락 acquire/release
`add(int i, E e)`	O(n)	락 acquire/release
`remove(int i)`	O(n)	락 acquire/release
`size()`	O(1)	락 acquire/release

단일 스레드 환경이라면 락은 무경합 (uncontended) 이라 비용이 매우 작지만, ArrayList 대비 측정 가능한 오버헤드가 있다. 멀티스레드 경합 시 모니터 진입 비용이 크다.

synchronized 메서드 락 흐름

flowchart TD
    T1["스레드 1: v.add(x)"] --> L1{"this 락 획득"}
    T2["스레드 2: v.get(0)"] --> L2{"this 락 획득"}
    L1 -->|"성공"| Op1["add 실행"]
    L2 -->|"락 보유 중"| Wait["대기 (BLOCKED)"]
    Op1 --> Rel1["락 해제"]
    Rel1 --> L2Retry["스레드 2 재시도"]
    L2Retry -->|"성공"| Op2["get 실행"]
    Op2 --> Rel2["락 해제"]
    Wait -.-> L2Retry

각 메서드가 this 모니터를 잠근다. add 와 get 도 동시에 실행 불가.

메서드별 동기화의 한계

각 메서드 호출은 atomic 하지만, 복합 연산 은 race condition 의 여지가 그대로 남는다.

Vector<Integer> v = new Vector<>();

// 각 메서드는 atomic 이지만 두 호출 사이에 다른 스레드가 끼어들 수 있음
if (!v.contains(42)) {
    v.add(42);   // 다른 스레드가 그 사이에 42 를 넣었을 수 있음
}

// 외부에서 명시적 락으로 묶어야 안전
synchronized (v) {
    if (!v.contains(42)) {
        v.add(42);
    }
}

[!CAUTION] “Vector 가 thread-safe 하다” 는 오해다. 단일 메서드는 thread-safe 지만, 두 개 이상의 메서드를 묶는 일관성은 호출자가 따로 보장해야 한다. 진정한 동시성 컬렉션은 [[CopyOnWriteArrayList]] 또는 ConcurrentHashMap 같은 java.util.concurrent 의 컬렉션.

iterator 의 fail-fast

Vector 의 iterator 도 [[fail-fast iterator]]. 순회 도중 다른 스레드가 add/remove 하면 [[ConcurrentModificationException]]. 락으로 외부 동기화를 해야 안전한 순회가 가능하다.

synchronized (v) {
    for (Integer x : v) {
        process(x);   // 이 블록 안에서는 다른 스레드 진입 불가
    }
}

락 없이 순회하면 CME 가 발생할 수 있다. v.get(i) 인덱스 순회도 size 가 변하면 AIOOBE.

Stack 과의 관계

java.util.Stack<E> 는 Vector<E> 를 상속 한다. 레거시 코드에서 Stack 을 발견하면 Vector 의 모든 동작이 함께 온다는 뜻이다.

// 레거시: Stack은 Vector를 상속, 모든 List 메서드 노출됨
Stack<Integer> stack = new Stack<>();
stack.push(1);
stack.pop();
stack.get(0);    // 인덱스 접근도 가능 (스택의 의도와 다름)
stack.add(0, 99);  // 스택 중간에 삽입도 가능!

// Java 현대 권장: Deque 인터페이스 + ArrayDeque 구현
Deque<Integer> stack2 = new ArrayDeque<>();
stack2.push(1);
stack2.pop();
// stack2.get(0);  컴파일 에러, Deque 는 인덱스 접근 없음

ArrayDeque 기반 Deque 가 Stack 역할을 더 명확하게 표현하고 성능도 우수하다.

ArrayList vs Vector

항목	ArrayList	Vector
동기화	없음	모든 메서드에 synchronized
도입 시점	JDK 1.2 (1998)	JDK 1.0 (1996)
용량 증가	1.5 배	2 배 (또는 `capacityIncrement`)
메서드 호출 비용	작음	+ 락 비용
복합 연산 안전성	외부 동기화 필요	여전히 외부 동기화 필요
새 코드 권장	✓	✗

왜 새 코드에서 쓰지 않는가

단일 스레드 라면 락이 불필요한데도 비용을 낸다.
다중 스레드 라도 메서드별 락만으로는 복합 연산이 안전하지 않다. 결국 외부 동기화가 필요하다.
진짜 동시성 컬렉션 ([[CopyOnWriteArrayList]], ConcurrentLinkedQueue 등) 이 훨씬 우수하다.
레거시 설계 잔재: JDK 가 retrofit 했으나 이상적인 컬렉션 설계가 아니다.

대안: 상황별 선택

flowchart TD
    Goal["List 가 필요"] --> MT{"멀티스레드?"}
    MT -->|"아니오"| AL["ArrayList"]
    MT -->|"예"| RW{"읽기/쓰기 비율?"}
    RW -->|"읽기 압도적"| CoW["CopyOnWriteArrayList"]
    RW -->|"균형 or 쓰기 多"| SL["Collections.synchronizedList\nor ConcurrentLinkedDeque"]
    MT -->|"스택 용도"| Deq["Deque + ArrayDeque"]

의도	대안
단일 스레드 List	[[ArrayList]]
외부 동기화 List	`Collections.synchronizedList(new ArrayList<>())`
읽기 多, 쓰기 거의 없음	[[CopyOnWriteArrayList]]
동시 큐/덱	`ConcurrentLinkedDeque`, `LinkedBlockingDeque`
스택	`Deque<E> stack = new ArrayDeque<>()`

레거시 Vector 마이그레이션

레거시 코드에서 Vector 를 마주쳤을 때 점진 교체 전략.

// 기존 레거시
Vector<String> v = new Vector<>();
v.add("a");
String s = v.get(0);

// 1단계: 변수 타입을 List 로 추상화 (컴파일 체크)
List<String> list = new Vector<>();   // 구현체는 그대로

// 2단계: 실제 구현체 교체 (단일 스레드라면)
List<String> list2 = new ArrayList<>();

// 3단계: 멀티스레드라면 상황에 맞는 concurrent 컬렉션으로
// 읽기 多: CopyOnWriteArrayList
// 쓰기 多: Collections.synchronizedList(new ArrayList<>()) + 복합연산 외부 락

capacityIncrement 의 미묘한 차이

[[ArrayList]] 는 grow 할 때 현재 크기의 1.5 배 로 늘리지만, Vector 는 capacityIncrement 가 0 이면 두 배 로 늘린다.

// capacityIncrement = 0 (기본)
Vector<Integer> v1 = new Vector<>();          // 초기 capacity 10, 초과 시 20으로
Vector<Integer> v2 = new Vector<>(10, 5);     // 초기 10, 초과 시 5씩 증가

// ArrayList: 초기 10, 초과 시 15 -> 22 -> 33 ... (1.5배)
ArrayList<Integer> a = new ArrayList<>();

두 배 성장은 메모리 낭비가 클 수 있고, 고정 증가(capacityIncrement > 0)는 잦은 재할당이 발생할 수 있다. [[ArrayList]] 의 1.5 배 전략이 일반적으로 더 균형 잡혀 있다.

Enumeration: Vector 전용 레거시 API

Vector 는 iterator() 외에 레거시 Enumeration<E> 도 지원한다.

Vector<String> v = new Vector<>(List.of("a", "b", "c"));

// 레거시 API (JDK 1.0)
Enumeration<String> e = v.elements();
while (e.hasMoreElements()) {
    System.out.println(e.nextElement());
}

// 현대 방식
for (String s : v) { ... }
v.forEach(System.out::println);

Enumeration 은 fail-fast 가 아니다. 순회 중 수정해도 CME 가 발생하지 않고, 대신 정의되지 않은 동작이 일어날 수 있다. 레거시 Enumeration 코드를 유지보수할 때 주의.

[Java] ConcurrentLinkedDeque

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.ConcurrentLinkedDeque<E> 는 lock-free [[Deque]]. [[ConcurrentLinkedQueue]] 의 양방향 버전. JDK 1.7 추가.

양 끝 모두에서 add/remove 가 가능하며, 모든 연산이 CAS (Compare-And-Swap) 기반이라 락 없이 동시성을 보장한다. 내부적으로 이중 연결 리스트를 사용한다.

언제 쓰나

양 끝에서 동시 작업 이 일어나는 큐 (예: work-stealing 스레드 풀에서 tail 에 push, head 에서 steal)
stack + queue 혼용 이 필요한 동시성 시나리오
블로킹 없이 non-blocking 처리를 우선해야 하는 경우
LinkedBlockingDeque 의 전역 락이 병목이 될 때

시각화: 이중 연결 리스트 구조

flowchart LR
    H["head (sentinel)"] <-->|"prev/next"| A["Node A\nprev=head\nnext=B"]
    A <-->|"prev/next"| B["Node B\nprev=A\nnext=C"]
    B <-->|"prev/next"| C["Node C\nprev=B\nnext=tail"]
    C <-->|"prev/next"| T["tail (sentinel)"]

각 노드는 prev, next 포인터를 volatile로 보유. CAS 로 포인터를 원자적으로 교체한다.

시각화: CAS 기반 offerLast 흐름

flowchart TD
    Start["offerLast(e)"] --> NewNode["새 Node 생성\nitem=e"]
    NewNode --> ReadTail["tail 포인터 읽기 (volatile)"]
    ReadTail --> TryLink["CAS: tail.next = null → newNode"]
    TryLink -->|"성공"| UpdateTail["CAS: tail = newNode"]
    TryLink -->|"실패 (다른 스레드 선점)"| Retry["재시도 (tail 재탐색)"]
    Retry --> ReadTail
    UpdateTail --> Done["삽입 완료"]

CAS 실패 시 루프를 돌며 재시도. 대기(waiting) 없이 non-blocking 진행.

내부 구조

public class ConcurrentLinkedDeque<E> extends AbstractCollection<E>
        implements Deque<E>, Serializable {

    // 이중 연결 리스트 노드
    static final class Node<E> {
        volatile Node<E> prev;
        volatile E item;          // null = 삭제된(dead) 노드
        volatile Node<E> next;
    }

    // sentinel 노드 (head/tail 는 실제 데이터 아님)
    private transient volatile Node<E> head;
    private transient volatile Node<E> tail;
}

item = null 노드: 논리적 삭제 표시. GC 가 회수하기 전 물리 제거를 미루는 lazy deletion.
head/tail 는 sentinel: 경쟁 조건 단순화를 위해 실제 데이터를 담지 않는 dummy 노드.

복잡도

작업	시간	동시성
`addFirst`, `addLast`, `offerFirst`, `offerLast`	amortized O(1)	lock-free
`pollFirst`, `pollLast`, `removeFirst`, `removeLast`	amortized O(1)	lock-free
`peekFirst`, `peekLast`	O(1)	volatile read
`size`	O(n), 부정확	약함
`contains`, `remove(Object)`	O(n)	lock-free 순회
iterator	O(n)	weakly consistent

[!IMPORTANT] size() 는 O(n) 이며 값이 정확하지 않을 수 있다. 동시 수정 중에는 일관된 스냅샷 없이 순회하기 때문. 크기 확인보다 isEmpty() 를 선호할 것.

사용법


ConcurrentLinkedDeque<String> deque = new ConcurrentLinkedDeque<>();

// 양 끝 삽입
deque.offerFirst("A");     // 앞에 추가
deque.offerLast("B");      // 뒤에 추가
deque.offerFirst("C");     // 앞에 추가 → [C, A, B]

// 양 끝 제거
String head = deque.pollFirst();   // "C"
String tail = deque.pollLast();    // "B"

// 들여다보기 (제거 안 함)
String peek = deque.peekFirst();   // "A"

Java 17+ 실전: Work-Stealing 패턴


// 각 스레드가 자신의 작업 deque 를 보유
// tail 에서 자신의 작업 push/pop, head 에서 다른 스레드가 steal
class WorkStealingExample {
    // 워커당 deque
    private final ConcurrentLinkedDeque<Runnable>[] queues;
    private final int nWorkers;

    @SuppressWarnings("unchecked")
    WorkStealingExample(int n) {
        this.nWorkers = n;
        this.queues = new ConcurrentLinkedDeque[n];
        for (int i = 0; i < n; i++) queues[i] = new ConcurrentLinkedDeque<>();
    }

    void submitTask(int workerId, Runnable task) {
        queues[workerId].offerLast(task);   // 자신의 deque tail 에 push
    }

    Runnable nextTask(int workerId) {
        // 자신의 deque tail 에서 먼저 pop
        Runnable task = queues[workerId].pollLast();
        if (task != null) return task;

        // 없으면 다른 스레드 deque head 에서 steal
        for (int i = 0; i < nWorkers; i++) {
            if (i == workerId) continue;
            task = queues[i].pollFirst();   // steal
            if (task != null) return task;
        }
        return null;
    }
}

[!TIP] Java 의 ForkJoinPool 은 이와 유사한 work-stealing 알고리즘을 내부에서 사용한다. 직접 구현보다 ForkJoinPool 을 쓰는 것이 대부분의 경우 더 적합하다.

Java 17+ 실전: 멀티스레드 로그 버퍼




// 링 버퍼 패턴: 최근 N 개 로그만 유지
class RecentLogBuffer {
    private final ConcurrentLinkedDeque<String> logs = new ConcurrentLinkedDeque<>();
    private final int maxSize;

    RecentLogBuffer(int maxSize) { this.maxSize = maxSize; }

    void append(String entry) {
        logs.offerLast(entry);
        // 초과 시 앞에서 제거
        while (logs.size() > maxSize) {
            logs.pollFirst();
        }
    }

    List<String> snapshot() {
        return new ArrayList<>(logs);   // weakly consistent
    }
}

LinkedBlockingDeque 와 비교

항목	ConcurrentLinkedDeque	LinkedBlockingDeque
동시성 방식	lock-free (CAS)	ReentrantLock
Blocking 지원	✗ (non-blocking)	✓ (`putFirst`, `takeFirst`)
용량 제한	없음 (unbounded)	선택적 (bounded/unbounded)
`size()` 정확도	부정확	정확 (락 안에서 카운트)
GC 부담	lazy deletion 으로 다소 높음	즉각 연결 해제
적합 상황	non-blocking 우선	producer-consumer blocking

ConcurrentLinkedQueue 와의 선택

단방향 FIFO 로 충분하다면 ConcurrentLinkedQueue 가 더 단순하고 오버헤드가 낮다. 양쪽 끝 연산이 모두 필요할 때만 Deque 를 선택.

시나리오	권장
FIFO 만 필요	[[ConcurrentLinkedQueue]]
양 끝 add/remove	ConcurrentLinkedDeque
Producer-Consumer (blocking 허용)	[[BlockingQueue]] 구현체
Work-stealing 패턴 직접 구현	ConcurrentLinkedDeque
ForkJoin 계열 병렬 처리	`ForkJoinPool` 내장 사용

함정

1. size() 는 선형 시간

if (deque.size() > 0) {          // O(n), 다른 스레드가 수정 중이면 오차 발생
    deque.pollFirst();
}

// 올바른 패턴
String item = deque.pollFirst();   // null 반환 여부로 비어 있는지 판단
if (item != null) { ... }

2. iterator 는 약한 일관성 (weakly consistent)

순회 중 다른 스레드가 추가/삭제해도 ConcurrentModificationException 을 던지지 않는다. 대신 순회 시작 당시의 상태를 일부 반영 하거나 안 할 수도 있다.

3. null 삽입 불가

deque.offerLast(null);   // NullPointerException

내부적으로 item == null 이 삭제된 노드의 표시이므로 null 은 허용하지 않는다.

4. 무한 루프 위험 (remove 중 retry)

매우 높은 경합 환경에서 CAS 재시도가 오래 걸릴 수 있다. 극단적 경합에서는 LinkedBlockingDeque 의 락 기반 방식이 오히려 공정성(fairness) 을 보장할 수 있다.

[Java] ConcurrentSkipListSet

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.ConcurrentSkipListSet<E> 는 [[ConcurrentSkipListMap]] 을 백킹으로 사용하는 정렬된 thread-safe [[Set]]. NavigableSet 인터페이스를 구현하며 [[TreeSet]] 의 동시성 버전에 해당한다.

JDK 1.6 추가
내부는 skip list (확률적 자료구조) 기반, lock-free 동시성 보장
floor, ceiling, subSet, headSet, tailSet 등 범위 쿼리 제공

언제 쓰나

정렬 순서를 유지하면서 여러 스레드가 동시에 add/remove 해야 할 때
range 쿼리 (e.g., “특정 타임스탬프 범위의 이벤트”) 가 동시성 환경에서 필요할 때
TreeSet + 외부 동기화 (Collections.synchronizedSortedSet) 의 전역 락이 병목일 때
정렬 순서가 필요 없다면 [[ConcurrentHashMap]] 의 keySet() 이 더 빠름

시각화: Skip List 구조

flowchart TD
    subgraph "Level 3 (최상위)"
        H3["HEAD"] -->|"next"| N30["10"] -->|"next"| N31["40"] -->|"next"| T3["TAIL"]
    end
    subgraph "Level 2"
        H2["HEAD"] -->|"next"| N20["10"] -->|"next"| N21["20"] -->|"next"| N22["40"] -->|"next"| T2["TAIL"]
    end
    subgraph "Level 1 (기본)"
        H1["HEAD"] -->|"next"| N10["10"] -->|"next"| N11["20"] -->|"next"| N12["30"] -->|"next"| N13["40"] -->|"next"| T1["TAIL"]
    end

    N30 -.->|"down"| N20
    N31 -.->|"down"| N22
    N20 -.->|"down"| N10
    N21 -.->|"down"| N11
    N22 -.->|"down"| N13

상위 레벨: 큰 폭으로 건너뛰며 탐색 가속
삽입 시: 확률적으로 레벨을 결정 (p = 0.5 면 레벨 k 까지 올라갈 확률 ≈ 0.5^k)
탐색: O(log n) 기대 시간, 레벨을 타고 내려가며 이진 탐색과 유사하게 동작

시각화: 동시성 add 흐름 (CAS)

flowchart TD
    Start["add(e)"] --> Find["각 레벨에서 삽입 위치 탐색"]
    Find --> GenLevel["확률적 레벨 결정 (randomLevel)"]
    GenLevel --> CAS1["Level 1: CAS pred.next null to newNode"]
    CAS1 -->|"성공"| CAS2["Level 2: CAS pred.next null to newNode"]
    CAS1 -->|"실패 (경쟁)"| Retry["탐색 재시도"]
    Retry --> Find
    CAS2 --> MoreLevels["상위 레벨 반복 CAS"]
    MoreLevels --> Done["삽입 완료"]

각 레벨의 연결을 CAS 로 원자적으로 교체. 전역 락 없이 세밀한 단위로 경합을 처리한다.

복잡도

[[ConcurrentSkipListMap]] 의 성질을 그대로 상속.

작업	기대 시간	최악
`add`, `remove`, `contains`	O(log n)	O(n) (이론적 최악)
`first`, `last`, `floor`, `ceiling`	O(log n)	O(log n)
`subSet`, `headSet`, `tailSet`	O(log n) view	-
`size`	O(n), 부정확	-
iterator 순회	O(n), 정렬 순서	-

[!IMPORTANT] size() 는 O(n) 이며 동시 수정 중에는 부정확할 수 있다. 크기 기반 판단보다 isEmpty() 또는 pollFirst() 반환값으로 판단할 것.

핵심 NavigableSet 메서드



NavigableSet<Integer> set = new ConcurrentSkipListSet<>();
set.add(10); set.add(20); set.add(30); set.add(40);

set.first();             // 10 (최솟값)
set.last();              // 40 (최댓값)

set.floor(25);           // 20 (25 이하 최댓값)
set.ceiling(25);         // 30 (25 이상 최솟값)
set.lower(20);           // 10 (20 미만 최댓값)
set.higher(20);          // 30 (20 초과 최솟값)

set.subSet(10, 30);      // [10, 30) = {10, 20}
set.headSet(30);         // < 30 = {10, 20}
set.tailSet(20);         // >= 20 = {20, 30, 40}

set.pollFirst();         // 10 제거 후 반환 (원자적)
set.pollLast();          // 40 제거 후 반환 (원자적)

NavigableSet<Integer> desc = set.descendingSet();  // 역순 view

Java 17+ 실전: 타임스탬프 기반 이벤트 버퍼




// 이벤트: 타임스탬프 기준 정렬
record Event(Instant ts, String payload) implements Comparable<Event> {
    @Override
    public int compareTo(Event other) {
        int cmp = ts.compareTo(other.ts);
        return cmp != 0 ? cmp : payload.compareTo(other.payload);
    }
}

class EventBuffer {
    private final ConcurrentSkipListSet<Event> buffer = new ConcurrentSkipListSet<>();

    void publish(Event e) {
        buffer.add(e);
    }

    // 특정 시간 이전 이벤트 처리 후 제거
    void drainBefore(Instant cutoff) {
        Event sentinel = new Event(cutoff, "");
        NavigableSet<Event> expired = buffer.headSet(sentinel, false);
        // weakly consistent iterator - 동시 수정 안전
        expired.forEach(e -> {
            if (buffer.remove(e)) {
                process(e);
            }
        });
    }

    private void process(Event e) { /* 처리 로직 */ }
}

Java 17+ 실전: 동시성 순위표 (Leaderboard)



record Score(String player, int value) {}

class Leaderboard {
    // 내림차순 (높은 점수 먼저), 동점이면 이름순
    private final ConcurrentSkipListSet<Score> board = new ConcurrentSkipListSet<>(
        Comparator.comparingInt(Score::value).reversed()
                  .thenComparing(Score::player)
    );

    void update(Score score) {
        // 동일 플레이어 기존 점수 제거 후 새 점수 삽입
        board.removeIf(s -> s.player().equals(score.player()));
        board.add(score);
    }

    // 상위 N 명
    java.util.List<Score> topN(int n) {
        java.util.List<Score> result = new java.util.ArrayList<>();
        var it = board.iterator();
        for (int i = 0; i < n && it.hasNext(); i++) result.add(it.next());
        return result;
    }
}

TreeSet vs ConcurrentSkipListSet

항목	TreeSet	ConcurrentSkipListSet
내부 구조	Red-Black Tree	Skip List
Thread-safe	✗	✓ (lock-free)
동시성 방식	없음 (외부 동기화 필요)	CAS per node
`add/remove/contains`	O(log n)	O(log n)
`size()` 비용	O(1)	O(n)
정렬	✓ (자연 순서 또는 Comparator)	✓
Range view	✓ (`subSet` 등)	✓
null 허용	✗	✗
적합 상황	단일 스레드	멀티스레드 동시 정렬 필요

HashSet / TreeSet / ConcurrentSkipListSet 한눈에

항목	HashSet	TreeSet	ConcurrentSkipListSet
시간	O(1) 평균	O(log n)	O(log n)
정렬	✗	✓	✓
Thread-safe	✗	✗	✓
Range 쿼리	✗	✓	✓
Comparator 지원	✗	✓	✓
null 허용	✓	✗	✗

함정

1. size() 비용과 부정확성

// 잘못: 빈 여부 확인에 size() 사용
if (set.size() == 0) { ... }   // O(n) + 부정확

// 올바름
if (set.isEmpty()) { ... }        // O(1) 에 가까움

2. null 삽입 불가

set.add(null);   // NullPointerException

skip list 내부에서 null 이 특별한 sentinel 의미를 가지기 때문.

3. Comparator 는 일관성 있어야 함

Comparator 가 equals 와 일치하지 않으면 Set 계약 위반. 동일한 원소를 두 번 추가하거나 contains 가 잘못 동작할 수 있다.

// 위험: value 만으로 비교하면 player 가 다른 동점 Score 가 하나로 취급됨
Comparator.comparingInt(Score::value)   // 잘못된 예

4. view 의 일관성

subSet, headSet, tailSet 반환값은 live view. 원본 set 변경이 즉시 반영된다. Weakly consistent 이지만 range 범위 밖 삽입은 예외를 던진다.

NavigableSet<Integer> sub = set.subSet(10, 30);
sub.add(5);   // IllegalArgumentException (범위 밖)

[Java] CopyOnWriteArraySet

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.CopyOnWriteArraySet<E> 는 [[CopyOnWriteArrayList]] 를 백킹으로 사용하는 thread-safe [[Set]]. 중복 검사를 위해 매 add 마다 선형 검색 (O(n)) 을 수행한다.

[[CopyOnWriteArrayList]] 의 모든 특성을 물려받는다.

읽기 lock-free: contains, iterator 는 락 없이 동작
쓰기 시 전체 복사: add, remove 는 내부 배열 전체를 복사한 뒤 교체
snapshot iterator: iterator 생성 시점의 배열 스냅샷을 순회, 이후 변경 반영 안 됨

언제 쓰나

이벤트 리스너 집합: 리스너 등록/해제는 드물고, 이벤트 발생 시 전체 순회가 잦을 때
옵저버 패턴 구독자 목록: 구독자 변경보다 알림 발송이 훨씬 많을 때
설정/메타데이터 집합: 애플리케이션 시작 시 한 번 구성, 이후 읽기만
원소 수가 수십 이하: O(n) add 비용이 허용되는 소규모 집합

[!CAUTION] 원소 수가 많거나 쓰기가 빈번하면 절대 사용하지 말 것. add 가 O(n) + 전체 배열 복사이므로 n 이 커질수록 GC 압박과 지연이 급증한다.

시각화: 쓰기 시 복사 흐름

flowchart TD
    Add["add(e) 호출"] --> Lock["ReentrantLock 획득"]
    Lock --> Contains{"배열에 e 존재?"}
    Contains -->|"예"| Unlock1["락 해제, false 반환"]
    Contains -->|"아니오"| Copy["배열 전체 복사 (n+1 크기)"]
    Copy --> Append["새 배열 끝에 e 추가"]
    Append --> Swap["array 참조 교체 (volatile write)"]
    Swap --> Unlock2["락 해제, true 반환"]

읽기 스레드는 array 참조를 volatile 로 읽으므로 락 없이 항상 일관된 스냅샷을 본다.

시각화: snapshot iterator 동작

sequenceDiagram
    participant T1 as "스레드 A (순회)"
    participant T2 as "스레드 B (쓰기)"
    participant Arr as "내부 배열"

    T1->>Arr: iterator() - 스냅샷 [a, b, c] 획득
    T2->>Arr: add(d) - 새 배열 [a, b, c, d] 로 교체
    T1->>T1: next() = a (스냅샷 기준)
    T1->>T1: next() = b
    T1->>T1: next() = c
    Note over T1: d 는 보이지 않음 (snapshot)

내부 구조

public class CopyOnWriteArraySet<E> extends AbstractSet<E>
        implements Serializable {

    private final CopyOnWriteArrayList<E> al;

    public CopyOnWriteArraySet() {
        al = new CopyOnWriteArrayList<>();
    }

    public boolean add(E e) {
        return al.addIfAbsent(e);   // 선형 검색 후 없으면 추가
    }

    public boolean contains(Object o) {
        return al.contains(o);      // lock-free 선형 검색
    }

    public boolean remove(Object o) {
        return al.remove(o);        // 락 + 복사
    }

    public Iterator<E> iterator() {
        return al.iterator();       // snapshot iterator
    }
}

CopyOnWriteArrayList.addIfAbsent(e) 핵심 로직:

// CopyOnWriteArrayList (단순화)
public boolean addIfAbsent(E e) {
    Object[] snapshot = getArray();
    // 스냅샷에 이미 있으면 락 없이 false 반환 (fast path)
    return indexOf(e, snapshot, 0, snapshot.length) < 0
        && addIfAbsent(e, snapshot);
}

private boolean addIfAbsent(E e, Object[] snapshot) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] current = getArray();
        int len = current.length;
        if (snapshot != current) {
            // 락 획득 사이에 다른 스레드가 변경 → 재검사
            int common = Math.min(snapshot.length, len);
            for (int i = 0; i < common; i++)
                if (current[i] != snapshot[i] && eq(e, current[i]))
                    return false;
            if (indexOf(e, current, common, len) >= 0)
                return false;
        }
        Object[] newElements = Arrays.copyOf(current, len + 1);
        newElements[len] = e;
        setArray(newElements);   // volatile write
        return true;
    } finally {
        lock.unlock();
    }
}

복잡도

작업	시간	비고
`add(e)`	O(n)	선형 검색 + 전체 배열 복사
`contains(o)`	O(n)	선형 검색 (락 없음)
`remove(o)`	O(n)	선형 검색 + 전체 배열 복사
`size()`	O(1)	배열 길이
순회 (`iterator`)	O(n)	snapshot 순회

스레드 안전성

읽기 (contains, iterator, size): 완전 lock-free. volatile 배열 참조를 읽기만 하므로 여러 스레드가 동시에 읽어도 안전.
쓰기 (add, remove): ReentrantLock 으로 직렬화. 동시에 두 스레드가 add 를 호출하면 하나씩 순서대로 처리.
iterator 는 [[fail-fast iterator]] 가 아님: 생성 시점 스냅샷을 순회하므로 순회 중 다른 스레드가 add/remove 해도 [[ConcurrentModificationException]] 이 발생하지 않는다.

CopyOnWriteArraySet<String> listeners = new CopyOnWriteArraySet<>();

// 순회 중 안전하게 수정 가능 (다른 스레드에서)
for (String listener : listeners) {
    notify(listener);
    // 다른 스레드가 listeners.add("new") 해도 이 순회에는 영향 없음
}

Java 17+ 실전: 이벤트 리스너 관리



sealed interface AppEvent permits UserLoginEvent, DataChangedEvent {}
record UserLoginEvent(String userId) implements AppEvent {}
record DataChangedEvent(String entity, long id) implements AppEvent {}

class EventBus {
    private final CopyOnWriteArraySet<Consumer<AppEvent>> listeners =
        new CopyOnWriteArraySet<>();

    // 리스너 등록/해제는 드물게 발생
    public void subscribe(Consumer<AppEvent> listener) {
        listeners.add(listener);
    }

    public void unsubscribe(Consumer<AppEvent> listener) {
        listeners.remove(listener);
    }

    // 이벤트 발행은 자주 발생, 순회 중 리스너 변경 안전
    public void publish(AppEvent event) {
        for (Consumer<AppEvent> listener : listeners) {
            try {
                listener.accept(event);
            } catch (Exception e) {
                // 한 리스너 실패가 다른 리스너에 영향 없도록
                System.err.println("Listener error: " + e.getMessage());
            }
        }
    }
}

Java 17+ 실전: 옵저버 패턴


interface StockObserver {
    void onPriceChange(String ticker, double price);
}

class StockTicker {
    private final String ticker;
    private final CopyOnWriteArraySet<StockObserver> observers =
        new CopyOnWriteArraySet<>();
    private volatile double price;

    StockTicker(String ticker) { this.ticker = ticker; }

    public void addObserver(StockObserver o) { observers.add(o); }
    public void removeObserver(StockObserver o) { observers.remove(o); }

    public void updatePrice(double newPrice) {
        this.price = newPrice;
        // 순회 중 observer 추가/제거 가능 (snapshot 순회)
        observers.forEach(o -> o.onPriceChange(ticker, newPrice));
    }
}

동시성 Set 비교

옵션	`add`	`contains`	`iterator`	정렬
CopyOnWriteArraySet	O(n) + 복사	O(n) lock-free	snapshot	삽입 순서
`ConcurrentHashMap.newKeySet()`	O(1) avg	O(1) avg	weakly consistent	✗
`Collections.synchronizedSet(HashSet)`	O(1) + 락	O(1) + 락	fail-fast (외부 동기화 필요)	✗
[[ConcurrentSkipListSet]]	O(log n)	O(log n)	weakly consistent	정렬

함정

1. 대용량 집합에 사용

// 위험: 원소가 수천 개면 add 마다 수천 개 배열 복사
CopyOnWriteArraySet<String> bigSet = new CopyOnWriteArraySet<>();
for (int i = 0; i < 10_000; i++) {
    bigSet.add("item" + i);   // 매번 O(n) 검색 + O(n) 복사 → 총 O(n^2)
}

// 올바름: 대용량은 ConcurrentHashMap.newKeySet()
Set<String> bigConcurrent = ConcurrentHashMap.newKeySet();

2. iterator 결과가 최신이 아닐 수 있음

CopyOnWriteArraySet<String> set = new CopyOnWriteArraySet<>();
set.add("a");
Iterator<String> it = set.iterator();   // 스냅샷: ["a"]
set.add("b");                           // 다른 스레드에서 추가
it.next();   // "a" (스냅샷 기준, "b" 는 보이지 않음)

snapshot iterator 는 약한 일관성 (weakly consistent) 을 제공한다. 최신 상태가 필요하면 contains() 를 직접 호출.

3. iterator.remove() 미지원

Iterator<String> it = set.iterator();
it.next();
it.remove();   // UnsupportedOperationException

순회 중 제거는 set.remove(element) 를 직접 호출해야 한다.

4. equals 기반 중복 검사

add 시 equals 로 중복 판단. equals/hashCode 를 올바르게 구현하지 않은 객체는 중복이 허용될 수 있다.

// 위험: equals/hashCode 미구현 클래스
class Tag {
    String name;
    Tag(String name) { this.name = name; }
    // equals, hashCode 없음 → 참조 동등성으로 비교
}

CopyOnWriteArraySet<Tag> tags = new CopyOnWriteArraySet<>();
tags.add(new Tag("java"));
tags.add(new Tag("java"));   // 다른 객체 참조 → 중복 허용됨
tags.size();   // 2 (기대: 1)

[Java] Deque

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.Deque<E> (Double-Ended Queue) 는 [[Queue]] 의 확장 인터페이스. 양쪽 끝 (head, tail) 모두에서 add/remove/examine 이 가능한 자료구조.

JDK 1.6 도입. Queue, Stack, 일반 양 끝 연산을 모두 한 인터페이스로 통합한다.

시각화: Deque 구조

flowchart LR
    direction LR
    PF["addFirst / pollFirst\n(head)"] <-->|"head"| A["A"] --- B["B"] --- C["C"] <-->|"tail"| PL["addLast / pollLast\n(tail)"]

head: Stack 의 top, Queue 의 front
tail: Queue 의 back
양 방향 모두 O(1) 삽입/삭제 (구현체에 따라 다름)

메서드 매트릭스

위치	insert (예외)	insert (특수값)	remove (예외)	remove (특수값)	examine
head	`addFirst(e)`	`offerFirst(e)`	`removeFirst()`	`pollFirst()`	`peekFirst()`
tail	`addLast(e)`	`offerLast(e)`	`removeLast()`	`pollLast()`	`peekLast()`
Queue alias	`add(e)`	`offer(e)`	`remove()`	`poll()`	`peek()`
Stack alias	`push(e)`	(= addFirst)	`pop()`	(= removeFirst)	`peek()`

push / pop 은 head (앞) 에 동작 → Stack 으로 쓸 때 head 가 top
offer / poll 은 tail 추가, head 제거 → FIFO Queue 동작

구현체 선택

구현	내부 구조	특징
[[ArrayDeque]]	원형 배열	권장 기본, null 불가, GC 친화
[[LinkedList]]	양방향 연결리스트	null 허용, 메모리 많이 씀, 중간 삽입 O(1)
[[ConcurrentLinkedDeque]]	이중 연결리스트 (lock-free)	thread-safe, non-blocking
`LinkedBlockingDeque`	이중 연결리스트	thread-safe + blocking, bounded 지원

[!IMPORTANT] 새 코드의 Stack 은 Deque<E> stack = new ArrayDeque<>() 가 권장. 레거시 java.util.Stack 은 Vector 상속이라 모든 메서드가 동기화돼 비효율적. 새 코드에서 Stack 클래스는 쓰지 말 것.

시각화: ArrayDeque 내부 (원형 배열)

flowchart LR
    subgraph "원형 배열 (capacity=8)"
        direction LR
        I0["[0]"] --- I1["[1] head=1\nA"] --- I2["[2]\nB"] --- I3["[3]\nC"] --- I4["[4] tail=4"] --- I5["[5]"] --- I6["[6]"] --- I7["[7]"]
    end
    H["head 포인터\n(index 1)"] --> I1
    T["tail 포인터\n(index 4)"] --> I4

head: 다음에 꺼낼 인덱스
tail: 다음에 넣을 인덱스
addFirst 는 head 를 감소 (mod capacity), addLast 는 tail 를 증가
꽉 차면 2배 배열로 복사 (grow)

Stack 패턴



Deque<Integer> stack = new ArrayDeque<>();

stack.push(1);     // addFirst(1)
stack.push(2);     // addFirst(2)
stack.push(3);     // addFirst(3)

stack.peek();      // 3 (top, 제거 안 함)
stack.pop();       // 3 (removeFirst)
stack.pop();       // 2
stack.pop();       // 1
stack.pop();       // EmptyStackException 대신 NoSuchElementException

// 비어 있음 확인
boolean empty = stack.isEmpty();

Queue 패턴 (FIFO)




// Queue 인터페이스로 잡으면 FIFO 만 사용 가능
Queue<Integer> queue = new ArrayDeque<>();
queue.offer(1);
queue.offer(2);
queue.offer(3);

queue.peek();     // 1 (head, 제거 안 함)
queue.poll();     // 1
queue.poll();     // 2

// 또는 Deque 그대로 사용
Deque<Integer> deque = new ArrayDeque<>();
deque.offerLast(1);    // tail 에 추가
deque.offerLast(2);
deque.pollFirst();     // 1 (head 에서 제거)

Palindrome 검사 (양쪽 끝 동시 비교)



boolean isPalindrome(String s) {
    Deque<Character> deque = new ArrayDeque<>();
    for (char c : s.toCharArray()) deque.addLast(c);

    while (deque.size() > 1) {
        if (!deque.pollFirst().equals(deque.pollLast())) return false;
    }
    return true;
}

// 테스트
isPalindrome("racecar");   // true
isPalindrome("hello");     // false

Java 17+ 실전: 슬라이딩 윈도우 최댓값



// 크기 k 의 슬라이딩 윈도우에서 각 위치의 최댓값 (Monotonic Deque)
int[] maxSlidingWindow(int[] nums, int k) {
    int n = nums.length;
    int[] result = new int[n - k + 1];
    // deque 는 인덱스를 저장, 항상 감소 순서 유지
    Deque<Integer> deque = new ArrayDeque<>();

    for (int i = 0; i < n; i++) {
        // 윈도우 범위 밖 인덱스 제거
        while (!deque.isEmpty() && deque.peekFirst() < i - k + 1) {
            deque.pollFirst();
        }
        // 현재 원소보다 작은 후보 제거
        while (!deque.isEmpty() && nums[deque.peekLast()] < nums[i]) {
            deque.pollLast();
        }
        deque.offerLast(i);

        if (i >= k - 1) {
            result[i - k + 1] = nums[deque.peekFirst()];
        }
    }
    return result;
}

// maxSlidingWindow([3,1,4,1,5,9,2,6], 3) = [4,4,5,9,9,9]

Java 17+ 실전: 수식 괄호 검사




boolean isBalanced(String expr) {
    Deque<Character> stack = new ArrayDeque<>();
    Map<Character, Character> pairs = Map.of(')', '(', ']', '[', '}', '{');

    for (char c : expr.toCharArray()) {
        if ("([{".indexOf(c) >= 0) {
            stack.push(c);
        } else if (pairs.containsKey(c)) {
            if (stack.isEmpty() || stack.pop() != pairs.get(c)) return false;
        }
    }
    return stack.isEmpty();
}

ArrayDeque vs LinkedList 성능

// ArrayDeque: 원형 배열 → 캐시 라인 친화, 객체 생성 최소화
Deque<Integer> arrayDeque = new ArrayDeque<>();

// LinkedList: 노드마다 힙 할당 → GC 부담, 캐시 미스
Deque<Integer> linkedList = new java.util.LinkedList<>();

항목	ArrayDeque	LinkedList
`addFirst` / `addLast`	amortized O(1)	O(1)
`pollFirst` / `pollLast`	O(1)	O(1)
중간 삽입/삭제	O(n)	O(1) (노드 보유 시)
메모리 per 원소	낮음 (배열 슬롯)	높음 (Node 객체)
null 허용	✗	✓
캐시 효율	높음	낮음
권장 상황	대부분	중간 삽입 多, null 필요

LinkedBlockingDeque (blocking 패턴)


LinkedBlockingDeque<String> bq = new LinkedBlockingDeque<>(100);

// Producer
new Thread(() -> {
    try {
        bq.putLast("work item");    // 꽉 차면 block
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}).start();

// Consumer
new Thread(() -> {
    try {
        String item = bq.takeFirst();   // 비어 있으면 block
        System.out.println("Got: " + item);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}).start();

함정

1. null 삽입 금지 (ArrayDeque)

Deque<String> deque = new ArrayDeque<>();
deque.push(null);   // NullPointerException

// null 이 필요하면 LinkedList (비권장) 또는 Optional 래핑

2. Stack 클래스 사용 금지

// 잘못: Stack 은 Vector 상속 (synchronized + 비효율)
java.util.Stack<Integer> stack = new java.util.Stack<>();

// 올바름: Deque 로 Stack 패턴
Deque<Integer> stack = new ArrayDeque<>();

3. poll vs pop 혼동

Deque<Integer> d = new ArrayDeque<>();
d.push(1);

d.pop();    // 비어 있으면 NoSuchElementException
d.poll();   // 비어 있으면 null (예외 없음)

pop() 은 Queue/Deque 에서 예외 던지는 버전, poll() 은 특수값 반환 버전.

4. 동시성 주의

ArrayDeque 와 LinkedList 는 thread-safe 하지 않다. 동시성이 필요하면 [[ConcurrentLinkedDeque]] 또는 LinkedBlockingDeque.

5. Deque 를 Queue 로 쓸 때 메서드 혼용

Deque<Integer> deque = new ArrayDeque<>();
deque.offer(1);       // tail 에 추가 (Queue 관행)
deque.addFirst(0);    // head 에 추가 (Deque)
deque.poll();         // head 에서 제거 (Queue = pollFirst)

코드 의도를 명확히 하려면 Queue<E> 인터페이스 타입으로 선언하거나, Stack/Queue 전용 메서드만 사용.

[Java] HashSet

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.HashSet<E> 는 [[HashMap]] 을 백킹으로 사용하는 [[Set]] 구현. 내부적으로 모든 원소를 HashMap 의 key 로 저장하고, value 는 dummy 상수 PRESENT 로 채운다.

평균 O(1) 의 add/remove/contains
순서 보장 없음 (삽입 순서, 정렬 순서 모두 아님)
null 원소 하나 허용
thread-safe 하지 않음

JDK 1.2 도입. Java 컬렉션 프레임워크에서 가장 흔히 쓰이는 Set 구현.

언제 쓰나

중복 제거: 리스트에서 중복 원소를 빠르게 제거할 때
멤버십 검사: “이 값이 집합에 있는가?” 를 O(1) 로 확인
집합 연산: 교집합, 합집합, 차집합 (단일 스레드)
방문 여부 추적: BFS/DFS 에서 방문한 노드 기록
순서가 필요 없고 빠른 조회가 우선일 때

시각화: HashMap 기반 구조

flowchart TD
    subgraph "HashSet"
        Add["add(e)"] --> HM["HashMap.put(e, PRESENT)"]
        Contains["contains(o)"] --> HMC["HashMap.containsKey(o)"]
        Remove["remove(o)"] --> HMR["HashMap.remove(o)"]
    end

    subgraph "내부 HashMap"
        HM --> Bucket["버킷 배열"]
        HMC --> Bucket
        HMR --> Bucket
        Bucket --> Node1["Node: key=e1, value=PRESENT"]
        Bucket --> Node2["Node: key=e2, value=PRESENT"]
        Bucket --> Node3["Node: key=e3, value=PRESENT"]
    end

내부 구조

public class HashSet<E> extends AbstractSet<E>
        implements Set<E>, Cloneable, Serializable {

    private transient HashMap<E, Object> map;

    // 모든 원소의 value 로 사용되는 dummy 객체
    private static final Object PRESENT = new Object();

    public HashSet() {
        map = new HashMap<>();
    }

    // 초기 capacity 와 loadFactor 지정 가능
    public HashSet(int initialCapacity, float loadFactor) {
        map = new HashMap<>(initialCapacity, loadFactor);
    }

    public boolean add(E e) {
        return map.put(e, PRESENT) == null;
        // map.put 이 null 반환 = 새로 삽입됨 = true
        // map.put 이 PRESENT 반환 = 이미 있었음 = false
    }

    public boolean contains(Object o) {
        return map.containsKey(o);
    }

    public boolean remove(Object o) {
        return map.remove(o) == PRESENT;
    }

    public Iterator<E> iterator() {
        return map.keySet().iterator();
    }

    public int size() {
        return map.size();
    }
}

HashMap 의 모든 동작과 성능 특성을 그대로 물려받는다. capacity/loadFactor, treeify 같은 내용은 [[HashMap]] 참고.

복잡도

작업	평균	최악 (Java 8+)
`add(e)`	O(1)	O(log n)
`contains(o)`	O(1)	O(log n)
`remove(o)`	O(1)	O(log n)
순회	O(n + capacity)	같음
`size()`	O(1)	O(1)

최악 O(log n) 은 Java 8 에서 도입된 treeify (버킷 내 노드 8개 이상 시 red-black tree 변환) 덕분. Java 7 이전은 최악 O(n).

equals / hashCode 규약

HashSet 의 정확한 동작은 원소의 equals 와 hashCode 구현에 달려 있다.

규약: a.equals(b) 이면 반드시 a.hashCode() == b.hashCode().

// Java 17+ record: equals/hashCode 자동 생성
record Point(int x, int y) {}

Set<Point> points = new HashSet<>();
points.add(new Point(1, 2));
points.add(new Point(1, 2));   // 중복 → 추가 안 됨
points.size();                  // 1

// 일반 클래스: 직접 구현 필요
class BadPoint {
    int x, y;
    BadPoint(int x, int y) { this.x = x; this.y = y; }
    // equals/hashCode 없음 → 참조 동등성 사용
}

Set<BadPoint> bad = new HashSet<>();
bad.add(new BadPoint(1, 2));
bad.add(new BadPoint(1, 2));   // 다른 참조 → 중복 허용됨
bad.size();                     // 2 (기대: 1)

[!IMPORTANT] equals 만 override 하고 hashCode 를 override 하지 않으면 HashSet 이 잘못 동작한다. 두 객체가 equals 로 같아도 hashCode 가 다르면 다른 버킷에 들어가 중복 허용.

null 허용

원소 하나는 null 가능 (HashMap 의 null key 처럼).

Set<String> s = new HashSet<>();
s.add(null);                     // OK
s.add(null);                     // false (이미 있음)
s.contains(null);                // true
s.remove(null);                  // true

// Set.of() 는 null 비허용
Set<String> immutable = Set.of("a", null);   // NullPointerException

Java 17+ 실전: 중복 제거




// 리스트에서 중복 제거 (순서 무관)
List<String> words = List.of("apple", "banana", "apple", "cherry", "banana");
Set<String> unique = new HashSet<>(words);
// unique = {apple, banana, cherry} (순서 불정)

// Stream 으로 중복 제거 후 리스트 반환
List<String> deduped = words.stream()
    .distinct()
    .toList();   // Java 16+

Java 17+ 실전: 집합 연산



Set<Integer> a = new HashSet<>(List.of(1, 2, 3, 4));
Set<Integer> b = new HashSet<>(List.of(3, 4, 5, 6));

// 합집합 (union)
Set<Integer> union = new HashSet<>(a);
union.addAll(b);           // {1, 2, 3, 4, 5, 6}

// 교집합 (intersection)
Set<Integer> inter = new HashSet<>(a);
inter.retainAll(b);        // {3, 4}

// 차집합 (difference)
Set<Integer> diff = new HashSet<>(a);
diff.removeAll(b);         // {1, 2}

// 대칭 차집합 (symmetric difference)
Set<Integer> symDiff = new HashSet<>(union);
symDiff.removeAll(inter);  // {1, 2, 5, 6}

Java 17+ 실전: BFS 방문 추적


// 그래프 BFS (방문 여부 O(1) 확인)
List<Integer> bfs(Map<Integer, List<Integer>> graph, int start) {
    Set<Integer> visited = new HashSet<>();
    Queue<Integer> queue = new ArrayDeque<>();
    List<Integer> order = new ArrayList<>();

    queue.add(start);
    visited.add(start);

    while (!queue.isEmpty()) {
        int node = queue.poll();
        order.add(node);
        for (int neighbor : graph.getOrDefault(node, List.of())) {
            if (visited.add(neighbor)) {   // add 가 true = 처음 방문
                queue.add(neighbor);
            }
        }
    }
    return order;
}

LinkedHashSet: 삽입 순서 유지

LinkedHashSet 은 HashSet 의 서브클래스로, 내부적으로 [[LinkedHashMap]] 을 사용해 삽입 순서를 유지한다.



Set<String> linked = new LinkedHashSet<>();
linked.add("banana");
linked.add("apple");
linked.add("cherry");
linked.add("apple");   // 중복, 무시

System.out.println(linked);   // [banana, apple, cherry] (삽입 순서)

// HashSet 은 순서 불정
Set<String> hash = new HashSet<>(linked);
System.out.println(hash);     // [apple, banana, cherry] 또는 다른 순서

LinkedHashSet 의 성능은 HashSet 과 거의 동일하지만, 이중 연결 리스트 유지 비용으로 약간의 메모리/시간 오버헤드가 있다.

HashSet vs LinkedHashSet vs TreeSet

항목	HashSet	LinkedHashSet	TreeSet
백킹 구조	HashMap	LinkedHashMap	TreeMap
순서	없음	삽입 순서	정렬 순서
`add`/`contains`	O(1) avg	O(1) avg	O(log n)
null 허용	✓	✓	✗
Range 쿼리	✗	✗	✓
Thread-safe	✗	✗	✗
메모리	기준	약간 더	더 많음

초기 capacity 최적화

// 1000 개 원소 예상 → capacity 가 1000 / 0.75 ≈ 1334 보다 커야 resize 안 함
Set<String> set = new HashSet<>(2048);

// Guava 스타일 (Java 표준 없음)
// int capacity = (int)(expectedSize / 0.75f) + 1;
Set<String> optimized = new HashSet<>((int)(1000 / 0.75f) + 1);

함정

1. 가변 객체를 원소로

Set<List<Integer>> set = new HashSet<>();
List<Integer> key = new ArrayList<>(List.of(1, 2));
set.add(key);
key.add(3);                  // hashCode 변경
set.contains(key);           // false! (다른 버킷으로 이동)
set.size();                  // 1 이지만 찾을 수 없음

불변 객체 (String, Integer, record) 를 원소로 사용 권장.

2. equals 만 override, hashCode 미구현

[[Object]] 의 규약 위반. HashSet 이 조용히 잘못 동작.

3. thread-safe 가 아님

동시 수정 시 데이터 손상. 동시성 필요 시:

// 옵션 1: Collections.synchronizedSet (복합 연산은 외부 동기화 필요)
Set<String> sync = Collections.synchronizedSet(new HashSet<>());

// 옵션 2: ConcurrentHashMap.newKeySet (권장)
Set<String> concurrent = ConcurrentHashMap.newKeySet();

4. iterator 는 [[fail-fast iterator]]

Set<Integer> set = new HashSet<>(Set.of(1, 2, 3));
for (Integer x : set) {
    set.add(4);   // ConcurrentModificationException
}

순회 중 수정은 removeIf 또는 별도 컬렉션에 모아 처리.

5. 순회 비용: O(n + capacity)

// 초기 capacity 가 크면 순회 비용 증가
Set<String> set = new HashSet<>(1_000_000);
set.add("only-one");
// iterator 는 1,000,000 개 버킷을 모두 스캔

원소가 적고 capacity 가 크면 순회가 느리다. trimToSize() 에 해당하는 메서드는 없으므로 처음부터 적절한 capacity 를 지정.

[Java] PriorityBlockingQueue

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.PriorityBlockingQueue<E> 는 [[PriorityQueue]] 의 동시성 + blocking 버전. unbounded 힙 기반 [[BlockingQueue]].

원소는 Comparable (자연 순서) 또는 생성자에 전달한 Comparator 로 정렬
put 은 절대 블록하지 않음 (unbounded 이므로 항상 공간 있음)
take 는 큐가 비어 있을 때만 블록
단일 [[ReentrantLock]] 으로 보호
null 원소 불허

JDK 1.5 도입.

언제 쓰나

우선순위 기반 작업 스케줄러: 긴급 작업을 일반 작업보다 먼저 처리
이벤트 처리 시스템: 중요도에 따라 이벤트 순서 결정
멀티스레드 다익스트라/A*: 우선순위 큐를 여러 스레드가 공유
타임아웃 관리: 만료 시간 기준으로 정렬, 가장 빨리 만료되는 것부터 처리

시각화: 힙 구조

flowchart TD
    Root["1 (최솟값, 루트)"] --> L1["3"]
    Root --> R1["2"]
    L1 --> LL["7"]
    L1 --> LR["5"]
    R1 --> RL["4"]
    R1 --> RR["6"]

최소 힙 (min-heap) 기반. poll/take 는 항상 루트 (최솟값) 를 반환하고 힙을 재구성한다.

시각화: put/take 흐름

flowchart TD
    Put["put(e) / offer(e)"] --> Lock1["ReentrantLock 획득"]
    Lock1 --> Grow{"용량 부족?"}
    Grow -->|"예"| Resize["배열 확장 (1.5x)"]
    Grow -->|"아니오"| Sift["siftUp: 힙 재구성"]
    Resize --> Sift
    Sift --> Signal["notEmpty.signal()"]
    Signal --> Unlock1["락 해제"]

    Take["take()"] --> Lock2["lockInterruptibly()"]
    Lock2 --> Empty{"큐 비어 있음?"}
    Empty -->|"예"| Await["notEmpty.await() 블록"]
    Await --> Empty
    Empty -->|"아니오"| Dequeue["dequeue: 루트 제거 + siftDown"]
    Dequeue --> Unlock2["락 해제, 원소 반환"]

내부 구조

public class PriorityBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, Serializable {

    private transient Object[] queue;       // 힙 배열
    private transient int size;
    private transient Comparator<? super E> comparator;
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notEmpty = lock.newCondition();

    // put 은 절대 블록 안 함 (unbounded)
    public void put(E e) {
        offer(e);
    }

    public boolean offer(E e) {
        if (e == null) throw new NullPointerException();
        final ReentrantLock lock = this.lock;
        lock.lock();
        try {
            int i = size;
            if (i >= queue.length)
                tryGrow(queue, i);   // 배열 확장
            siftUp(i, e, queue, comparator);
            size = i + 1;
            notEmpty.signal();
            return true;
        } finally {
            lock.unlock();
        }
    }

    public E take() throws InterruptedException {
        final ReentrantLock lock = this.lock;
        lock.lockInterruptibly();
        try {
            E result;
            while ((result = dequeue()) == null)
                notEmpty.await();   // 큐가 빌 때만 블록
            return result;
        } finally {
            lock.unlock();
        }
    }

    public E poll() {
        final ReentrantLock lock = this.lock;
        lock.lock();
        try {
            return dequeue();   // 비어 있으면 null 반환 (블록 없음)
        } finally {
            lock.unlock();
        }
    }
}

복잡도

작업	시간	비고
`offer`/`put`	O(log n)	siftUp
`take`/`poll`	O(log n)	siftDown
`peek`	O(1)	루트 반환
`remove(o)`	O(n)	선형 검색 + siftDown
`contains(o)`	O(n)	선형 검색
순회	O(n)	정렬 순서 보장 안 됨

Comparator 사용



// 자연 순서 (Comparable 구현 필요)
record Task(int priority, String name) implements Comparable<Task> {
    @Override
    public int compareTo(Task other) {
        return Integer.compare(this.priority, other.priority);
    }
}

PriorityBlockingQueue<Task> naturalOrder = new PriorityBlockingQueue<>();
naturalOrder.put(new Task(3, "low"));
naturalOrder.put(new Task(1, "high"));
naturalOrder.put(new Task(2, "medium"));
naturalOrder.take();   // Task(1, "high") - 우선순위 낮은 숫자가 먼저

// Comparator 로 역순 (높은 숫자 = 높은 우선순위)
PriorityBlockingQueue<Task> reversed = new PriorityBlockingQueue<>(
    11,
    Comparator.comparingInt(Task::priority).reversed()
);
reversed.put(new Task(3, "low"));
reversed.put(new Task(1, "high"));
reversed.take();   // Task(3, "low") - 숫자 큰 것이 먼저

Java 17+ 실전: 우선순위 작업 스케줄러


sealed interface Priority {
    record Urgent() implements Priority {}
    record Normal() implements Priority {}
    record Low() implements Priority {}
}

record WorkItem(Priority priority, String payload, long createdAt)
        implements Comparable<WorkItem> {

    private static int priorityRank(Priority p) {
        return switch (p) {
            case Priority.Urgent u -> 0;
            case Priority.Normal n -> 1;
            case Priority.Low l -> 2;
        };
    }

    @Override
    public int compareTo(WorkItem other) {
        int cmp = Integer.compare(priorityRank(this.priority), priorityRank(other.priority));
        // 같은 우선순위면 먼저 들어온 것 우선 (FIFO)
        return cmp != 0 ? cmp : Long.compare(this.createdAt, other.createdAt);
    }
}

class PriorityWorkerPool {
    private final PriorityBlockingQueue<WorkItem> queue =
        new PriorityBlockingQueue<>();
    private final ExecutorService workers;

    PriorityWorkerPool(int threadCount) {
        workers = Executors.newFixedThreadPool(threadCount);
        for (int i = 0; i < threadCount; i++) {
            workers.submit(this::workerLoop);
        }
    }

    private void workerLoop() {
        try {
            while (!Thread.currentThread().isInterrupted()) {
                WorkItem item = queue.take();   // 우선순위 높은 것부터
                process(item);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    public void submit(Priority priority, String payload) {
        queue.put(new WorkItem(priority, payload, System.nanoTime()));
    }

    private void process(WorkItem item) {
        System.out.printf("[%s] %s%n", item.priority().getClass().getSimpleName(), item.payload());
    }

    public void shutdown() {
        workers.shutdownNow();
    }
}

Java 17+ 실전: 타임아웃 관리 (DelayQueue 대안)



// 만료 시간 기준 정렬
record TimedTask(Instant deadline, Runnable action)
        implements Comparable<TimedTask> {
    @Override
    public int compareTo(TimedTask other) {
        return this.deadline.compareTo(other.deadline);
    }
}

class TimeoutManager {
    private final PriorityBlockingQueue<TimedTask> tasks =
        new PriorityBlockingQueue<>();

    TimeoutManager() {
        Thread.ofVirtual().start(this::checkLoop);
    }

    public void schedule(Instant deadline, Runnable action) {
        tasks.put(new TimedTask(deadline, action));
    }

    private void checkLoop() {
        try {
            while (!Thread.currentThread().isInterrupted()) {
                TimedTask task = tasks.peek();
                if (task == null) {
                    Thread.sleep(10);
                    continue;
                }
                long delay = Instant.now().until(task.deadline(),
                    java.time.temporal.ChronoUnit.MILLIS);
                if (delay <= 0) {
                    tasks.poll();
                    task.action().run();
                } else {
                    Thread.sleep(Math.min(delay, 100));
                }
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

PriorityQueue vs PriorityBlockingQueue

항목	PriorityQueue	PriorityBlockingQueue
Thread-safe	✗	✓
`put` 블록	N/A	절대 블록 안 함
`take` 블록	N/A	비어 있을 때 블록
null 허용	✗	✗
unbounded	✓	✓
도입	JDK 1.5	JDK 1.5
용도	단일 스레드	멀티스레드

함정

1. unbounded → OOM

// 위험: producer 가 빠르고 consumer 가 느리면 메모리 무한 증가
PriorityBlockingQueue<Task> queue = new PriorityBlockingQueue<>();
// producer 가 초당 1000개 추가, consumer 가 초당 100개 처리
// → 큐가 계속 증가 → OOM

// 해결: 외부 backpressure 또는 bounded 큐 사용
// bounded 가 필요하면 ArrayBlockingQueue 사용

2. 순회 순서는 정렬 순서가 아님

PriorityBlockingQueue<Integer> q = new PriorityBlockingQueue<>();
q.addAll(List.of(5, 1, 3, 2, 4));

// iterator 는 힙 배열 순서 (정렬 아님)
for (int x : q) {
    System.out.print(x + " ");   // 1 2 3 5 4 (힙 내부 순서)
}

// 정렬된 결과가 필요하면 모두 poll
List<Integer> sorted = new ArrayList<>();
while (!q.isEmpty()) sorted.add(q.poll());
// sorted = [1, 2, 3, 4, 5]

3. remove(Object) 는 O(n)

PriorityBlockingQueue<Task> q = new PriorityBlockingQueue<>();
// 특정 작업 취소
q.remove(specificTask);   // O(n) 선형 검색 + 힙 재구성

취소가 빈번하면 DelayQueue 또는 취소 플래그 패턴 고려.

4. Comparator 와 equals 불일치

PriorityBlockingQueue 는 Comparator 가 0 을 반환해도 중복을 허용한다 ([[TreeSet]] 과 다름). 하지만 remove(Object) 는 equals 로 검색하므로 불일치 시 예상치 못한 동작.

5. 인터럽트 처리

try {
    E item = queue.take();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // 인터럽트 상태 복원 필수
    return;
}

[Java] Queue

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.Queue<E> 는 FIFO (First-In, First-Out) 처리 순서를 가진 [[Collection]] 인터페이스. 한쪽 끝 (tail) 에 추가하고 반대쪽 (head) 에서 제거하는 자료구조.

PriorityQueue 처럼 다른 순서 (heap) 인 구현체도 있지만, 인터페이스 자체는 “원소를 꺼내는 순서를 정의” 정도의 추상화다.

시각화: FIFO 큐 동작

flowchart LR
    direction LR
    P1["offer(A)"] --> Q1["[A]"]
    P2["offer(B)"] --> Q2["[A, B]"]
    P3["offer(C)"] --> Q3["[A, B, C]"]
    Q3 --> PL1["poll()"]
    PL1 --> R1["A 반환\n[B, C]"]
    R1 --> PL2["poll()"]
    PL2 --> R2["B 반환\n[C]"]

head 에서 꺼내고 tail 에 넣는 단방향 흐름.

두 그룹의 메서드

각 동작마다 예외를 던지는 버전 과 특수값을 반환하는 버전 이 존재한다.

동작	예외 throw	특수값 반환
insert	`add(e)`	`offer(e)`
remove	`remove()`	`poll()`
examine	`element()`	`peek()`

add(e): 용량 초과 시 IllegalStateException
offer(e): 용량 초과 시 false 반환 (bounded 큐에서 실용적)
remove(): 비어 있으면 NoSuchElementException
poll(): 비어 있으면 null 반환
element(): 비어 있으면 NoSuchElementException
peek(): 비어 있으면 null 반환

[!IMPORTANT] 대부분의 코드에서는 offer / poll / peek (특수값 버전) 이 안전하다. add 가 던지는 예외는 bounded 큐를 쓸 때가 아니면 처리하기 어렵다.

시각화: 구현체 계층

flowchart TD
    Iterable --> Collection
    Collection --> Queue
    Queue -->|"extends"| Deque["Deque (양방향)"]
    Queue --> PQ["PriorityQueue\n힙 기반, 정렬 순서"]
    Deque --> AD["ArrayDeque\n원형 배열, 권장"]
    Deque --> LL["LinkedList\n양방향 연결 리스트"]
    Queue --> CLQ["ConcurrentLinkedQueue\nlock-free, thread-safe"]
    Queue --> BQ["BlockingQueue\n(인터페이스)"]
    BQ --> ABQ["ArrayBlockingQueue\nbounded + lock"]
    BQ --> LBQ["LinkedBlockingQueue\noptionally bounded"]
    BQ --> PBQ["PriorityBlockingQueue\n정렬 + blocking"]

구현체 선택 가이드

구현	백킹	특징	언제
[[ArrayDeque]]	원형 배열	빠름, null 불가, 권장 FIFO	기본 선택
[[LinkedList]]	양방향 연결리스트	가장 단순, null 허용, 메모리 多	단순 코드
[[PriorityQueue]]	이진 힙	우선순위 순 꺼냄, 정렬 아님	우선순위 처리
[[ConcurrentLinkedQueue]]	연결리스트 (lock-free)	thread-safe, unbounded	비동기 파이프라인
[[BlockingQueue]] 구현체	다양	가득/비어 있으면 block	producer-consumer

기본 사용법



Queue<String> queue = new ArrayDeque<>();

// 삽입
queue.offer("first");
queue.offer("second");
queue.offer("third");

// 들여다보기 (제거 안 함)
String head = queue.peek();       // "first", 큐 변화 없음

// 제거
String polled = queue.poll();     // "first"

// 비어 있는지 확인
boolean empty = queue.isEmpty();  // false

// FIFO 순회
while (!queue.isEmpty()) {
    System.out.println(queue.poll());
}
// 출력: second, third

PriorityQueue: 우선순위 큐




// 자연 순서 (숫자 오름차순)
Queue<Integer> pq = new PriorityQueue<>();
pq.offer(30); pq.offer(10); pq.offer(20);
pq.poll();  // 10 (가장 작은 값 먼저)

// Comparator 로 내림차순 (큰 값 우선)
Queue<Integer> maxHeap = new PriorityQueue<>(Comparator.reverseOrder());
maxHeap.offer(10); maxHeap.offer(30); maxHeap.offer(20);
maxHeap.poll();  // 30

// 커스텀 객체
record Task(String name, int priority) {}

Queue<Task> tasks = new PriorityQueue<>(
    Comparator.comparingInt(Task::priority)
);
tasks.offer(new Task("low", 5));
tasks.offer(new Task("high", 1));
tasks.poll();  // Task("high", 1) 먼저

Java 17+ 실전: BFS (너비 우선 탐색)


// 그래프 BFS
Map<Integer, List<Integer>> graph = Map.of(
    1, List.of(2, 3),
    2, List.of(4),
    3, List.of(4, 5),
    4, List.of(),
    5, List.of()
);

List<Integer> bfs(int start) {
    Queue<Integer> queue = new ArrayDeque<>();
    Set<Integer> visited = new HashSet<>();
    List<Integer> order = new ArrayList<>();

    queue.offer(start);
    visited.add(start);

    while (!queue.isEmpty()) {
        int node = queue.poll();
        order.add(node);
        for (int neighbor : graph.getOrDefault(node, List.of())) {
            if (!visited.contains(neighbor)) {
                visited.add(neighbor);
                queue.offer(neighbor);
            }
        }
    }
    return order;   // [1, 2, 3, 4, 5]
}

Java 17+ 실전: 작업 스케줄링 (PriorityQueue)



record Job(int id, int priority, Runnable task)
        implements Comparable<Job> {
    @Override
    public int compareTo(Job other) {
        return Integer.compare(this.priority, other.priority);
    }
}

class Scheduler {
    private final Queue<Job> queue = new PriorityQueue<>();

    void submit(Job job) {
        queue.offer(job);
    }

    void runAll() {
        while (!queue.isEmpty()) {
            Job job = queue.poll();
            System.out.printf("Running job %d (priority %d)%n",
                job.id(), job.priority());
            job.task().run();
        }
    }
}

Java 17+ 실전: LinkedList vs ArrayDeque 성능

// LinkedList: 각 원소마다 Node 객체 할당 → GC 부담, 캐시 미스
Queue<Integer> linked = new LinkedList<>();
for (int i = 0; i < 100_000; i++) linked.offer(i);

// ArrayDeque: 배열 기반 원형 버퍼 → 캐시 친화적, 메모리 효율
Queue<Integer> array = new ArrayDeque<>(100_000);
for (int i = 0; i < 100_000; i++) array.offer(i);

벤치마크상 ArrayDeque 가 LinkedList 보다 약 2-4배 빠름 (특히 GC 압력이 높을 때).

offer vs add

// add: 용량 초과 시 IllegalStateException
// ArrayDeque 처럼 unbounded 에서는 사실상 같지만, 아래 경우 차이남
Queue<Integer> bounded = new java.util.concurrent.ArrayBlockingQueue<>(3);
bounded.add(1); bounded.add(2); bounded.add(3);
bounded.add(4);    // IllegalStateException: Queue full

Queue<Integer> bounded2 = new java.util.concurrent.ArrayBlockingQueue<>(3);
bounded2.offer(1); bounded2.offer(2); bounded2.offer(3);
boolean ok = bounded2.offer(4);   // false, 예외 없음

Deque 와의 관계

[[Deque]] 는 Queue 의 확장 인터페이스로 양 끝 모두 연산이 가능하다. Queue<E> q = new ArrayDeque<>() 처럼 인터페이스 타입을 Queue 로 잡으면 FIFO 의 약속만 사용할 수 있다.

// 타입을 Queue 로 제한 → FIFO 의미만 사용
Queue<Integer> fifo = new ArrayDeque<>();
fifo.offer(1);
fifo.poll();   // 1

// 타입을 Deque 로 사용 → 양방향 가능
Deque<Integer> deque = new ArrayDeque<>();
deque.offerFirst(0);   // head 에 삽입
deque.offerLast(1);    // tail 에 삽입

함정

1. null 반환과 비어 있음 혼동

Queue<String> q = new ArrayDeque<>();
String item = q.poll();    // null
if (item == null) {        // 비어 있는 것이지, null 원소가 아님
    // 비어 있음
}

LinkedList 는 null 원소를 허용하므로 poll() 이 null 을 반환해도 비어 있는 건지 null 원소인지 구분할 수 없다. ArrayDeque 는 null 불허 로 이 혼란을 피한다.

2. PriorityQueue 는 FIFO 가 아님

Queue<Integer> pq = new PriorityQueue<>();
pq.offer(3); pq.offer(1); pq.offer(2);
pq.poll();  // 1 (힙 최솟값), NOT 3 (삽입 순서 첫 원소)

for-each 로 순회해도 정렬 순서를 보장하지 않는다. 순서 보장이 필요하면 poll() 로 꺼내야 한다.

3. Thread-safe 가 아닌 구현체

ArrayDeque, LinkedList, PriorityQueue 는 thread-safe 하지 않다. 동시성이 필요하면 ConcurrentLinkedQueue 또는 BlockingQueue 구현체를 사용.

4. iterator 는 fail-fast (일부 구현체)

ArrayDeque 의 iterator 는 순회 중 구조적 수정 시 ConcurrentModificationException.

[Java] Set

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.Set<E> 는 중복을 허용하지 않는 [[Collection]]. 수학의 집합 (set) 에 대응. 같은 원소를 두 번 추가하면 두 번째는 무시된다.

Collection 인터페이스의 모든 메서드를 그대로 사용하면서, equals 와 hashCode (또는 compareTo) 로 중복 판단.

Set<String> s = new HashSet<>();
s.add("apple");
s.add("banana");
s.add("apple");   // 중복, 무시
s.size();         // 2

언제 쓰나

중복 제거: 컬렉션에서 유일한 원소만 남길 때
멤버십 검사: “이 값이 집합에 있는가?” 를 빠르게 확인
집합 연산: 교집합, 합집합, 차집합
방문 여부 추적: 그래프 탐색에서 방문한 노드 기록
고유 ID 관리: 중복 없는 식별자 집합 유지

시각화: Set 구현체 계층

flowchart TD
    Iterable["Iterable"] --> Collection["Collection"]
    Collection --> Set["Set"]
    Set --> HashSet["HashSet"]
    Set --> SortedSet["SortedSet"]
    HashSet --> LinkedHashSet["LinkedHashSet"]
    SortedSet --> NavigableSet["NavigableSet"]
    NavigableSet --> TreeSet["TreeSet"]
    Set --> CopyOnWriteArraySet["CopyOnWriteArraySet"]
    Set --> EnumSet["EnumSet"]

핵심 메서드

메서드	반환	의미
`add(E e)`	boolean	추가, 이미 있으면 false
`remove(Object o)`	boolean	제거, 없으면 false
`contains(Object o)`	boolean	포함 여부
`size()`	int	원소 개수
`isEmpty()`	boolean	비어 있는지
`iterator()`	Iterator	순회
`addAll(Collection)`	boolean	합집합 (in-place)
`retainAll(Collection)`	boolean	교집합 (in-place)
`removeAll(Collection)`	boolean	차집합 (in-place)
`containsAll(Collection)`	boolean	부분집합 여부

추가/조회/삭제의 시간 복잡도는 구현체에 따라 다르다.

구현체 비교

구현	백킹 구조	`add`/`contains`	순서	null	Thread-safe
[[HashSet]]	HashMap	O(1) avg	없음	✓ (1개)	✗
`LinkedHashSet`	LinkedHashMap	O(1) avg	삽입 순서	✓ (1개)	✗
[[TreeSet]]	TreeMap	O(log n)	정렬	✗	✗
`CopyOnWriteArraySet`	CopyOnWriteArrayList	O(n)	삽입 순서	✓	✓
`ConcurrentSkipListSet`	ConcurrentSkipListMap	O(log n)	정렬	✗	✓
`EnumSet`	bit vector	O(1)	enum 선언 순서	✗	✗

대부분의 Set 구현은 내부적으로 Map 을 사용, key 만 노출하고 value 는 dummy 상수.

불변 Set (Set.of)

Java 9+ 에서 도입된 팩토리 메서드.

// Set.of: 불변, null 비허용, 중복 인자 시 IllegalArgumentException
Set<Integer> primes = Set.of(2, 3, 5, 7, 11);
primes.add(13);      // UnsupportedOperationException
primes.add(null);    // NullPointerException

// 중복 인자 → 예외
Set<String> bad = Set.of("a", "a");   // IllegalArgumentException

// Set.copyOf: 기존 컬렉션을 불변 Set 으로 복사
List<String> list = List.of("x", "y", "z");
Set<String> copy = Set.copyOf(list);   // 불변

// Collections.unmodifiableSet: 기존 Set 의 불변 뷰 (원본 변경 반영)
Set<String> mutable = new HashSet<>(Set.of("a", "b"));
Set<String> view = Collections.unmodifiableSet(mutable);
mutable.add("c");
view.contains("c");   // true (원본 변경 반영)

[!IMPORTANT] Set.of 는 순서를 보장하지 않는다. 반복 순서가 실행마다 다를 수 있다. 순서가 필요하면 LinkedHashSet 또는 TreeSet 사용.

집합 연산

Set<Integer> a = new HashSet<>(List.of(1, 2, 3, 4));
Set<Integer> b = new HashSet<>(List.of(3, 4, 5, 6));

// 합집합 (union): a ∪ b
Set<Integer> union = new HashSet<>(a);
union.addAll(b);           // {1, 2, 3, 4, 5, 6}

// 교집합 (intersection): a ∩ b
Set<Integer> inter = new HashSet<>(a);
inter.retainAll(b);        // {3, 4}

// 차집합 (difference): a \ b
Set<Integer> diff = new HashSet<>(a);
diff.removeAll(b);         // {1, 2}

// 대칭 차집합 (symmetric difference): (a ∪ b) \ (a ∩ b)
Set<Integer> symDiff = new HashSet<>(union);
symDiff.removeAll(inter);  // {1, 2, 5, 6}

// 부분집합 여부
a.containsAll(inter);      // true (inter ⊆ a)

addAll, retainAll, removeAll 의 비용은 인자의 contains 가 빠를수록 좋다. 인자로 HashSet 을 전달하면 O(n), ArrayList 를 전달하면 O(n*m).

Java 17+ 실전: 중복 제거



// 리스트에서 중복 제거 (순서 무관)
List<String> words = List.of("apple", "banana", "apple", "cherry", "banana");
Set<String> unique = new HashSet<>(words);

// 삽입 순서 유지
Set<String> ordered = new LinkedHashSet<>(words);
// [apple, banana, cherry]

// Stream.distinct() (내부적으로 LinkedHashSet 유사 동작)
List<String> deduped = words.stream().distinct().toList();

// 정렬된 고유 원소
Set<String> sorted = new TreeSet<>(words);
// [apple, banana, cherry] (알파벳 순)

Java 17+ 실전: EnumSet 활용


enum Permission { READ, WRITE, EXECUTE, DELETE }

// EnumSet: bit vector 기반, 가장 빠른 Set 구현
EnumSet<Permission> adminPerms = EnumSet.allOf(Permission.class);
EnumSet<Permission> readOnly = EnumSet.of(Permission.READ);
EnumSet<Permission> readWrite = EnumSet.of(Permission.READ, Permission.WRITE);

// 집합 연산
EnumSet<Permission> extra = EnumSet.copyOf(readWrite);
extra.add(Permission.EXECUTE);   // {READ, WRITE, EXECUTE}

// 여집합
EnumSet<Permission> complement = EnumSet.complementOf(readOnly);
// {WRITE, EXECUTE, DELETE}

boolean canWrite = adminPerms.contains(Permission.WRITE);   // true

Java 17+ 실전: 권한 검사 시스템


record User(String name, Set<String> roles) {}

class AccessControl {
    private final Map<String, Set<String>> rolePermissions = new HashMap<>();

    void grantPermission(String role, String permission) {
        rolePermissions.computeIfAbsent(role, k -> new HashSet<>()).add(permission);
    }

    // 사용자가 특정 권한을 가지는지 확인
    boolean hasPermission(User user, String permission) {
        return user.roles().stream()
            .anyMatch(role -> {
                Set<String> perms = rolePermissions.getOrDefault(role, Set.of());
                return perms.contains(permission);
            });
    }

    // 사용자의 모든 권한 (합집합)
    Set<String> allPermissions(User user) {
        Set<String> result = new HashSet<>();
        user.roles().forEach(role ->
            result.addAll(rolePermissions.getOrDefault(role, Set.of()))
        );
        return Collections.unmodifiableSet(result);
    }
}

동기화

// 옵션 1: Collections.synchronizedSet (복합 연산은 외부 동기화 필요)
Set<Integer> sync = Collections.synchronizedSet(new HashSet<>());
synchronized (sync) {
    if (!sync.contains(x)) sync.add(x);   // check-then-act 원자적으로
}

// 옵션 2: ConcurrentHashMap.newKeySet (권장, 복합 연산도 원자적)
Set<Integer> concurrent = ConcurrentHashMap.newKeySet();
concurrent.add(x);   // 내부적으로 putIfAbsent

// 옵션 3: CopyOnWriteArraySet (읽기 多, 쓰기 少)
Set<String> cow = new CopyOnWriteArraySet<>();

// 옵션 4: ConcurrentSkipListSet (정렬 + 동시성)
Set<Integer> skipList = new ConcurrentSkipListSet<>();

equals / hashCode 규약

Set 의 equals 는 두 집합이 같은 원소를 가지면 true.

Set<Integer> s1 = new HashSet<>(List.of(1, 2, 3));
Set<Integer> s2 = new TreeSet<>(List.of(1, 2, 3));
s1.equals(s2);   // true (구현체 달라도 원소 같으면 같음)

// Set 의 hashCode = 원소 hashCode 의 합
s1.hashCode() == s2.hashCode();   // true

원소의 equals/hashCode 가 잘못 구현되면 HashSet/LinkedHashSet 이 잘못 동작한다.

함정

1. 가변 객체를 원소로

Set<List<Integer>> set = new HashSet<>();
List<Integer> elem = new ArrayList<>(List.of(1, 2));
set.add(elem);
elem.add(3);                 // hashCode 변경
set.contains(elem);          // false! (다른 버킷)
set.size();                  // 1 이지만 찾을 수 없음

불변 객체 (String, Integer, record) 를 원소로 사용 권장.

2. equals 만 override, hashCode 미구현

[[Object]] 의 규약 위반. HashSet, LinkedHashSet 이 잘못 동작.

class Point {
    int x, y;
    @Override public boolean equals(Object o) {
        if (!(o instanceof Point p)) return false;
        return x == p.x && y == p.y;
    }
    // hashCode 없음 → Object.hashCode() 사용 (참조 기반)
}

Set<Point> set = new HashSet<>();
set.add(new Point(1, 2));
set.contains(new Point(1, 2));   // false! (hashCode 다름)

3. Set.of 의 순서 불정

Set<String> s = Set.of("a", "b", "c");
// 반복 순서가 실행마다 다를 수 있음
// 순서가 필요하면 LinkedHashSet 또는 TreeSet 사용

4. iterator 는 [[fail-fast iterator]] (HashSet, TreeSet)

Set<Integer> set = new HashSet<>(Set.of(1, 2, 3));
for (Integer x : set) {
    set.add(4);   // ConcurrentModificationException
}

// 안전한 제거
set.removeIf(x -> x % 2 == 0);

5. TreeSet 에 null 추가

TreeSet<String> ts = new TreeSet<>();
ts.add(null);   // NullPointerException (compareTo(null) 호출)

null 이 필요하면 HashSet 또는 null-friendly Comparator 를 명시.

[Java] SynchronousQueue

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

java.util.concurrent.SynchronousQueue<E> 는 용량 0 의 [[BlockingQueue]]. 저장 공간이 없다. put 은 매칭되는 take 가 있어야 진행하고, 반대도 마찬가지.

직접 핸드오프 (direct handoff) 또는 랑데부 (rendezvous) 패턴: producer 와 consumer 가 서로를 정확히 한 명씩 기다린다. 데이터가 큐에 저장되지 않고 producer 에서 consumer 로 직접 전달된다.

JDK 1.5 도입. java.util.concurrent.Executors.newCachedThreadPool() 의 내부 큐로 사용된다.

언제 쓰나

직접 핸드오프: producer 가 consumer 의 수신을 확인하고 진행해야 할 때
Executors.newCachedThreadPool(): idle thread 가 있으면 즉시 전달, 없으면 새 thread 생성
파이프라인 단계 간 동기화: 앞 단계가 뒷 단계의 처리 완료를 기다려야 할 때
스레드 풀 작업 분배: 작업이 큐에 쌓이지 않고 즉시 처리되어야 할 때

시각화: rendezvous 흐름

sequenceDiagram
    participant P as "Producer 스레드"
    participant SQ as "SynchronousQueue"
    participant C as "Consumer 스레드"

    P->>SQ: put(item) - Consumer 없으면 대기
    Note over P,SQ: Producer 블록
    C->>SQ: take() - Producer 있으면 즉시 수신
    SQ-->>C: item 전달
    SQ-->>P: put 완료 (핸드오프 확인)
    Note over P: Producer 진행 재개

시각화: offer/poll 비블로킹 동작

flowchart LR
    Offer["offer(item)"] --> Check{"즉시 매칭\n가능?"}
    Check -->|"Consumer 대기 중"| Transfer["직접 전달, true 반환"]
    Check -->|"Consumer 없음"| Fail["false 반환 (저장 안 함)"]

    Poll["poll()"] --> Check2{"즉시 매칭\n가능?"}
    Check2 -->|"Producer 대기 중"| Receive["item 수신, 반환"]
    Check2 -->|"Producer 없음"| Null["null 반환"]

특수한 동작

SynchronousQueue<String> q = new SynchronousQueue<>();

// 크기 관련 메서드는 항상 0/true/null
q.size();                   // 항상 0
q.isEmpty();                // 항상 true
q.peek();                   // 항상 null
q.iterator().hasNext();     // 항상 false
q.remainingCapacity();      // 항상 0

// 블로킹 메서드
q.put("x");    // Consumer 가 없으면 블록
q.take();      // Producer 가 없으면 블록

// 비블로킹 메서드
q.offer("x");                          // Consumer 없으면 false 반환
q.poll();                              // Producer 없으면 null 반환
q.offer("x", 1, TimeUnit.SECONDS);    // 1초 대기 후 실패 시 false
q.poll(1, TimeUnit.SECONDS);          // 1초 대기 후 실패 시 null

내부 구현: transfer 메커니즘

SynchronousQueue 는 내부적으로 두 가지 구현을 가진다.

비공정 (unfair, 기본): TransferStack (LIFO 스택 기반)
공정 (fair): TransferQueue (FIFO 큐 기반)

// 핵심 추상 메서드
abstract static class Transferer<E> {
    // put 이면 e != null, take 이면 e == null
    abstract E transfer(E e, boolean timed, long nanos);
}

transfer 메서드 하나로 put 과 take 를 모두 처리한다.

put(e) → transfer(e, false, 0) (무한 대기)
take() → transfer(null, false, 0) (무한 대기)
offer(e) → transfer(e, true, 0) (즉시 반환)
poll() → transfer(null, true, 0) (즉시 반환)

// TransferStack (비공정) 단순화
E transfer(E e, boolean timed, long nanos) {
    SNode s = null;
    int mode = (e == null) ? REQUEST : DATA;

    for (;;) {
        SNode h = head;
        if (h == null || h.mode == mode) {
            // 같은 모드 → 스택에 push 하고 대기
            if (timed && nanos <= 0) return null;
            s = new SNode(e);
            casHead(h, s);
            s.awaitFulfill(timed, nanos);
            return s.match;
        } else {
            // 반대 모드 → 매칭, 핸드오프
            SNode m = h;
            if (casHead(m, m.next)) {
                m.match = e;
                LockSupport.unpark(m.waiter);
                return (E) m.item;
            }
        }
    }
}

공정성 옵션

// 비공정 (기본): LIFO, 마지막에 온 스레드가 먼저 매칭될 수 있음
SynchronousQueue<String> unfair = new SynchronousQueue<>();

// 공정: FIFO, 가장 오래 기다린 스레드부터 매칭
SynchronousQueue<String> fair = new SynchronousQueue<>(true);

공정 모드는 기아 (starvation) 를 방지하지만 처리량이 약간 낮다.

Executors.newCachedThreadPool() 연계

// newCachedThreadPool 내부 (단순화)
public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(
        0,                          // corePoolSize: 항상 0
        Integer.MAX_VALUE,          // maximumPoolSize: 무제한
        60L, TimeUnit.SECONDS,      // keepAliveTime
        new SynchronousQueue<>()    // 큐: 용량 0
    );
}

동작 원리:

새 작업 도착 → SynchronousQueue.offer(task) 시도
idle thread 가 take() 대기 중이면 즉시 전달 (핸드오프)
idle thread 없으면 offer 실패 → 새 thread 생성
thread 가 60초 동안 idle 이면 종료

ExecutorService pool = Executors.newCachedThreadPool();

// 작업이 큐에 쌓이지 않고 즉시 thread 에 전달
for (int i = 0; i < 10; i++) {
    final int taskId = i;
    pool.submit(() -> {
        System.out.println("Task " + taskId + " on " + Thread.currentThread().getName());
    });
}
pool.shutdown();

Java 17+ 실전: 직접 핸드오프 파이프라인


// 두 단계 파이프라인: 파싱 → 처리
// SynchronousQueue 로 단계 간 동기화
class Pipeline {
    private final SynchronousQueue<String> channel = new SynchronousQueue<>();

    void run() throws InterruptedException {
        // 파싱 스레드 (Producer)
        Thread parser = Thread.ofVirtual().start(() -> {
            try {
                String[] lines = {"line1", "line2", "line3"};
                for (String line : lines) {
                    channel.put(line);   // 처리 스레드가 받을 때까지 대기
                    System.out.println("Parsed and handed off: " + line);
                }
                channel.put("DONE");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        // 처리 스레드 (Consumer)
        Thread processor = Thread.ofVirtual().start(() -> {
            try {
                String item;
                while (!(item = channel.take()).equals("DONE")) {
                    System.out.println("Processing: " + item);
                    Thread.sleep(100);   // 처리 시뮬레이션
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        parser.join();
        processor.join();
    }
}

Java 17+ 실전: 작업 분배기


// 단일 Producer, 다중 Consumer
// SynchronousQueue 로 작업을 idle Consumer 에게 직접 전달
class WorkDispatcher {
    private final SynchronousQueue<Runnable> queue = new SynchronousQueue<>(true);
    private final int workerCount;

    WorkDispatcher(int workerCount) {
        this.workerCount = workerCount;
        for (int i = 0; i < workerCount; i++) {
            Thread.ofVirtual().start(() -> {
                try {
                    while (!Thread.currentThread().isInterrupted()) {
                        Runnable task = queue.take();
                        task.run();
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }
    }

    // 작업 제출: idle worker 가 없으면 블록
    void dispatch(Runnable task) throws InterruptedException {
        queue.put(task);
    }

    // 타임아웃 있는 제출
    boolean tryDispatch(Runnable task, long timeout, TimeUnit unit)
            throws InterruptedException {
        return queue.offer(task, timeout, unit);
    }
}

SynchronousQueue vs 다른 BlockingQueue

항목	SynchronousQueue	[[LinkedBlockingQueue]]	[[ArrayBlockingQueue]]
용량	0 (저장 없음)	무제한 또는 bounded	bounded
`put` 블록 조건	Consumer 없을 때	용량 초과 시	용량 초과 시
`take` 블록 조건	Producer 없을 때	비어 있을 때	비어 있을 때
처리량	낮음 (1:1 동기화)	높음	높음
용도	직접 핸드오프	일반 생산자-소비자	고정 버퍼

함정

1. drainTo 는 항상 0 반환

SynchronousQueue<String> q = new SynchronousQueue<>();
List<String> list = new ArrayList<>();
q.drainTo(list);   // 항상 0 (저장된 원소 없음)

2. 처리량 병목

producer 와 consumer 속도가 다르면 빠른 쪽이 계속 블록된다. 버퍼링이 필요하면 [[LinkedBlockingQueue]] 사용.

3. newCachedThreadPool 의 OOM 위험

ExecutorService pool = Executors.newCachedThreadPool();
// 작업이 폭발적으로 증가하면 thread 수가 Integer.MAX_VALUE 까지 증가 가능
// → OOM 또는 시스템 과부하
// 프로덕션에서는 maximumPoolSize 를 제한한 ThreadPoolExecutor 직접 사용 권장

4. 인터럽트 처리

try {
    q.put(item);
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // 인터럽트 상태 복원
    // 적절한 정리 작업
}

put/take 는 InterruptedException 을 던진다. 반드시 처리해야 한다.

김신건의 로그 - 위키 / java

[Java] Object

정의

사용 상황

상속 계층 시각화

핵심 메서드 11개

equals / hashCode 의 5가지 규약

toString, 디버깅의 기본

Objects 유틸리티 클래스

wait / notify, monitor 패턴

모든 컬렉션의 root 가 Object 인 이유

getClass, Reflection 의 입구

clone, 거의 안 쓰는 것이 답

finalize, deprecated

Object 만 받는 메서드와 제네릭

함정

1. equals 만 override 하고 hashCode 빠뜨리기

2. instanceof 와 getClass() 의 혼용

3. synchronized 없이 wait 호출

관련 위키

[Java] ArrayBlockingQueue

정의

사용 상황

내부 구조

시각화: 원형 배열 순환

동작 흐름

핵심 메서드 정리

복잡도

실전 코드: bounded 생산자-소비자

공정성 옵션

ArrayBlockingQueue vs LinkedBlockingQueue

함정

1. capacity 를 너무 크게 잡기

2. offer() 결과 무시

3. contains() / remove(Object) 는 O(n)

Thread Pool 연동: 작업 큐로 활용

멀티 Producer-Consumer 패턴

관련 위키

[Java] ArrayDeque

정의

사용 상황

시각화

원형 배열 동작

내부 구조

복잡도

LinkedList vs ArrayDeque

Stack 사용 예

Queue 사용 예 (BFS)

Deque 사용 예: 슬라이딩 윈도우 최댓값

Deque 인터페이스 주요 API

괄호 검사 (스택 활용 예)

함정

1. null 비허용

2. thread-safe 가 아님

3. iterator 는 [[fail-fast iterator]]

4. push/pop vs offer/poll 혼용 주의

참고

[Java] AtomicInteger

정의

사용 상황

시각화

핵심 메서드

CAS 원리

CAS 루프 흐름

volatile vs synchronized vs AtomicInteger

고경합에서의 문제: LongAdder

사용 예

카운터

시퀀스 생성

상태 전이 (CAS)

Java 9+ compareAndExchange

ABA 문제

다른 Atomic 타입

함정

1. compound 연산은 atomic 하지 않다

2. int 오버플로 시 조용히 음수로 전환

3. lazySet 은 가시성 보장 없음

관련 위키

[Java] AtomicReference

정의

2. `offer()` 결과 무시

3. `contains()` / `remove(Object)` 는 O(n)