My Note

https://park0691.github.io/My NoteA minimal, responsive and feature-rich Jekyll theme for technical writing. 2026-04-01T20:10:15+09:00 depark https://park0691.github.io/ Jekyll © 2026 depark /assets/img/favicons/favicon.ico /assets/img/favicons/favicon-96x96.png 왜 스레드 풀 사이즈가 동시성 테스트의 신뢰도를 결정하나?2026-03-01T23:55:00+09:00 2026-04-01T20:09:55+09:00 https://park0691.github.io/posts/thread-pool-sizing-for-concurrency-testing/ depark

내 테스트는 정말 동시성을 검증하고 있는가? 동시성 제어 로직을 작성하고 나면, 반드시 테스트 코드를 통해 이를 검증해야 한다. 그런데 이때 스레드 풀(Thread Pool)의 크기를 대충 설정하면, 로직에 버그가 있음에도 불구하고 테스트가 통과되는 문제가 발생할 수 있다. 왜 이런 일이 발생하는지, 그리고 적절한 스레드 숫자는 어떻게 정해야 하는지에 대해 이번 포스트에서 다루려고 한다. 1. 스레드 10개면 충분한가? 작업하던 프로젝트에서 ‘사용자가 10명이니까 스레드도 10개면 되겠지?’ 단순히 생각했다. 배경 코드 (테스트 시나리오) 10명의 유저가 각각 충전/사용 요청을 25회씩(총 50회), 전체 500번의 요청을 동시에 보내는 상황을 가정했다. // 수정 전: 막연하게 설정한 스레드 ...

Future는 왜 Completable해 졌을까?2026-02-11T12:00:00+09:00 2026-03-16T21:40:30+09:00 https://park0691.github.io/posts/why-future-completable/ depark

이 글은 비동기 처리를 공부하던 중, ‘왜 하필 Completable이라고 명명했을까?’라는 순수한 호기심에서 시작되었습니다. 이해를 돕기 위한 상황 예시와 코드는 정리 과정에서 Claude, Gemini의 도움을 받아 작성했습니다. 비동기 처리, 이렇게까지 복잡해야 할까? 비동기 처리는 @Async 어노테이션 하나면 다 되는 줄 알았는데, 실무에서는 여러 API를 동시에 호출하고 그 결과를 조합해야 하는 상황이 많았다. 다음은 실무에서 비동기를 적용하며 고민했던 내용을 각색한 코드다. import java.util.List; import java.util.concurrent.*; public class MyPageService { private final ExecutorService...

ConcurrentHashMap 분석 - 데이터 조회, 저장 시 동시성 제어2025-10-20T23:30:00+09:00 2025-10-20T23:30:00+09:00 https://park0691.github.io/posts/java-concurrent-hash-map/ depark

ConcurrentHashMap은 Java에서 스레드 안전한 맵(Map)을 구현할 때 가장 먼저 고려되는 표준 컬렉션이다. Java 8에서 ConcurrentHashMap은 기존의 세그먼트(Segment) 락 방식에서 벗어나, CAS(Compare-And-Swap) 연산과 버킷 레벨 락(Bucket-level Lock)을 결합한 정교한 방식으로 재설계되어 극대화된 동시성을 제공한다. 이 포스트에서는 Java 8을 기준으로 ConcurrentHashMap이 어떻게 데이터를 조회하고 저장하는지, 그 내부 동작 원리를 소스 코드와 함께 심층 분석하고자 한다. 먼저, ConcurrentHashMap의 다양한 생성자를 살펴보며 initialCapacity와 concurrencyLevel 같은 파라미터가 어떤...

Java 동시성 제어 기법 (5) - Synchronized Collection, Concurrent Collection2025-09-22T16:00:00+09:00 2025-09-22T16:00:00+09:00 https://park0691.github.io/posts/java-synchronized-concurrent-collections/ depark

Synchronized Collection 특징 [동기화 방식: 컬렉션 전체에 단일 락] Synchronized 컬렉션은 add, get, remove 등 데이터에 접근하는 모든 메서드에 synchronized키워드를 사용한다. 이는 컬렉션 객체 전체를 단 하나의 락(Lock)으로 제어하는 ‘전체 잠금(Single Global Lock)’ 방식으로, 열쇠가 하나뿐인 방과 같다. 결과적으로 한 번에 오직 하나의 스레드만 접근할 수 있으므로, 한 스레드가 값을 읽는 동안 다른 스레드는 값을 추가/삭제하는 것은 물론, 다른 데이터를 읽는 작업조차 할 수 없다. [Fail-Fast: 빠른 실패] Iterator를 이용한 컬렉션 순회 도중 다른 스레드가 컬렉션을 수정하면 ConcurrentModificati...

CAS 연산의 숨겨진 함정 - ABA 문제2025-09-15T12:00:00+09:00 2025-09-15T12:00:00+09:00 https://park0691.github.io/posts/aba-problem/ depark

스레드를 멈추지 않고 하드웨어 수준의 원자적 연산을 통해 동시성을 제어하는 Lock-Free 알고리즘은 병렬 프로그래밍의 핵심 기술이다. Lock-Free 알고리즘은 다음 포스트에서 다루었다. https://park0691.github.io/posts/java-cas-atomic/ 하지만 이 기법의 이면에는 ABA 문제라는 치명적인 함정이 숨어있다. 변수의 값이 A에서 B로, 다시 A로 돌아왔을 때 CAS(Compare-And-Swap) 연산이 ‘아무 것도 변하지 않았다’ 고 착각하여 데이터의 일관성을 깨뜨리는 문제가 발생한다. 값은 같지만 그 사이에 다른 변경이 있었던 상황은 찾기 힘든 버그를 유발하여 Lock-Free 자료구조를 망가뜨릴 수 있다. 이 포스트에서는 C++로 구현된 Lock-...