김신건의 로그 - 위키 / java

[Java] Reflection: Class, Method, Field, MethodHandle

koa (김신건) — Tue, 23 Jun 2026 00:00:00 GMT

정의

Reflection 은 런타임에 클래스 메타데이터 (필드, 메서드, 어노테이션, 생성자) 를 조회하고, 컴파일 타임에 알 수 없는 객체를 생성/조작할 수 있게 해 주는 Java API. java.lang.reflect.* 패키지.

Spring 의 DI, Jackson 의 직렬화, JPA 의 entity 매핑, JUnit 의 테스트 메서드 호출 모두 reflection 위에서 동작. 단, 성능 비용 + 캡슐화 위반 + JVM 최적화 방해 같은 단점이 있어 일반 코드에서는 피하고 framework 가 대신 써 준다.

Class 객체 얻기

Class<String> c1 = String.class;                           // 컴파일 타임 알 때
Class<?> c2 = "hello".getClass();                          // 인스턴스에서
Class<?> c3 = Class.forName("com.example.User");           // 런타임 이름으로
Class<?> c4 = ClassLoader.getSystemClassLoader().loadClass("com.example.User");

Class.forName 은 클래스를 로드하고 static initializer 실행. JDBC driver 등록 같은 부수효과가 있는 코드에 사용 (Class.forName("org.postgresql.Driver")).

메타데이터 조회

<CodeWithOutput language=“java” outputLanguage=“text” outputLabel=“stdout” code={`import java.lang.reflect.*;

public class MetaDemo { static class User { private String name; public int age; public User() {} public String greet(String prefix) { return prefix + ” ” + name; } private void secret() {} }

public static void main(String[] args) {
    Class<?> c = User.class;
    System.out.println("declared fields:");
    for (Field f : c.getDeclaredFields()) {
        System.out.printf("  %s %s%n", Modifier.toString(f.getModifiers()), f.getName());
    }
    System.out.println("declared methods:");
    for (Method m : c.getDeclaredMethods()) {
        System.out.printf("  %s %s(%d)%n",
            Modifier.toString(m.getModifiers()), m.getName(), m.getParameterCount());
    }
}

}} output={declared fields: private name public age declared methods: public greet(1) private secret(0)`} />

getDeclaredX() 는 private 포함 직접 선언만. getX() 는 public + 상속받은 것. 이름이 헷갈리니 주의.

동적 호출

Class<?> c = Class.forName("com.example.User");
Object instance = c.getDeclaredConstructor().newInstance();      // no-args ctor

Method greet = c.getMethod("greet", String.class);
String result = (String) greet.invoke(instance, "Hello,");        // greet("Hello,")

Field name = c.getDeclaredField("name");
name.setAccessible(true);                                         // private 우회
name.set(instance, "Alice");

setAccessible(true) 는 캡슐화 우회. JDK 9 모듈 시스템 도입 후 --add-opens JVM 옵션이 없으면 외부 모듈에는 적용 안 됨.

어노테이션 처리

@Retention(RUNTIME) 가 필수. SOURCE / CLASS 로 선언된 어노테이션은 reflection 으로 조회 불가.

동적 프록시

interface 기반 프록시 생성 (AOP 의 기본):

interface Greeter {
    String greet(String name);
}

Greeter proxy = (Greeter) Proxy.newProxyInstance(
    Greeter.class.getClassLoader(),
    new Class<?>[] { Greeter.class },
    (p, method, args) -> {
        System.out.println("→ " + method.getName());
        return "Hello, " + args[0];
    }
);

System.out.println(proxy.greet("World"));
// → greet
// Hello, World

interface 가 아닌 클래스를 프록시하려면 CGLIB / ByteBuddy 같은 바이트코드 라이브러리 필요. Spring 의 @Configuration proxy 가 그 예.

MethodHandle (JDK 7+, 현대적 대안)

java.lang.invoke.MethodHandle 은 reflection 보다 빠르고 JIT 친화적:

MethodHandles.Lookup lookup = MethodHandles.lookup();

MethodHandle greet = lookup.findVirtual(
    User.class,
    "greet",
    MethodType.methodType(String.class, String.class)
);

String result = (String) greet.invoke(user, "Hi,");

특징:

JIT 최적화 가능: 반복 호출이 reflection 보다 훨씬 빠름 (거의 native call 수준)
MethodType 으로 정확한 시그니처 명시
VarHandle: 필드 접근의 MethodHandle 대응 (atomic, volatile semantics)
Lookup 의 권한: 호출한 클래스의 접근 권한이 그대로 적용 (캡슐화 보존)

라이브러리 (Jackson 신버전, ByteBuddy) 가 reflection 대신 MethodHandle 로 전환 중.

성능 비용

직접 호출:        1x  (baseline)
MethodHandle:    2-3x
Reflection:      30-100x  (cache 안 했을 때)
Reflection (cached): 5-10x

framework 들이 Method 객체를 캐싱해 두는 이유. 매번 getMethod() 호출은 절대 금물.

JDK 17 이후 JIT 가 많이 개선돼 cached reflection 의 차이는 줄었지만 여전히 hot path 에서는 피하는 게 좋다.

함정과 베스트 프랙티스

JDK 9+ 모듈 시스템: setAccessible(true) 가 외부 모듈에 막힘. --add-opens java.base/java.lang=ALL-UNNAMED 같은 JVM 옵션 필요
getName() vs getCanonicalName() vs getSimpleName(): inner class / array 에서 결과 다름
isAssignableFrom 방향 주의: Animal.class.isAssignableFrom(Dog.class) 는 true (반대로 안 됨)
Generic type erasure: 런타임에 List<String> 의 String 정보 없음. ParameterizedType 으로 super class / field declaration 에서만 추출 가능 (Spring 의 ResolvableType 활용)
Class.forName 의 static 초기화 부수효과 주의
GraalVM Native Image: reflection 사용 클래스는 미리 reflect-config.json 에 등록 필요
JIT 친화적이려면 MethodHandle 사용

[Java] JavaBean 프로퍼티 규약

koa (김신건) — Sun, 21 Jun 2026 00:00:00 GMT

정의

JavaBean 은 다음 세 가지 규약을 만족하는 클래스:

public no-args constructor (인자 없는 public 생성자)
프로퍼티 접근자: getX()/setX() 명명 규칙
Serializable 구현 (선택, 일부 컨텍스트에서 필수)

원래는 1996 년 데스크톱 컴포넌트 모델용이었지만, 지금은 reflection 기반 framework 가 객체 상태에 접근하는 표준 인터페이스 로 살아남았다. Jackson, JPA/Hibernate, Spring Data Binding, Bean Validation 등이 이 규약에 의존.

POJO (Plain Old Java Object) 는 더 느슨한 개념. 특정 framework 인터페이스를 상속하지 않은 평범한 객체. JavaBean 은 POJO 의 한 종류.

명명 규칙

public class User implements Serializable {
    private String name;
    private int age;
    private boolean active;

    public User() {}                              // no-args ctor

    public String getName() { return name; }      // getter
    public void setName(String name) { this.name = name; }  // setter

    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }

    public boolean isActive() { return active; }  // boolean 은 is- prefix
    public void setActive(boolean active) { this.active = active; }
}

getX() / setX(T): 일반 프로퍼티
isX() / setX(boolean): boolean 프로퍼티 (getX() 도 허용되나 isX() 가 관례)
property 이름은 메서드명에서 prefix 제거 후 첫 글자만 소문자 : getURL() → URL, getFirstName() → firstName
getXxx() 만 있고 setXxx() 없으면 read-only property

Introspector

java.beans.Introspector 가 reflection 으로 메서드를 스캔해 BeanInfo 를 만든다:

BeanInfo info = Introspector.getBeanInfo(User.class);
for (PropertyDescriptor pd : info.getPropertyDescriptors()) {
    System.out.println(pd.getName() + " : " + pd.getPropertyType());
}
// active : boolean
// age : int
// name : String
// class : Class  ← Object.getClass() 도 잡힘

Spring 의 BeanWrapper, Jackson 의 ObjectMapper, JPA 의 EntityManager 모두 내부적으로 이 메커니즘을 변형해 사용.

Introspector 가 getXxx/setXxx/isXxx 메서드를 스캔해 property 로 인식.

no-args constructor 의 이유

framework 는 객체를 두 단계 로 생성:

Class.newInstance() 로 빈 객체 생성 (no-args ctor 필요)
setter 로 필드 채우기

DB row → entity, JSON → DTO, form → command object 같은 변환 패턴. JPA 는 @Entity 에 no-args ctor 를 명시적으로 요구한다.

이게 불변 객체와 충돌. 필드를 final 로 만들고 ctor 에서만 set 하려면 no-args ctor 가 불가능. 해결책 두 가지:

@ConstructorProperties

public class User {
    private final String name;
    private final int age;

    @ConstructorProperties({"name", "age"})
    public User(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() { return name; }
    public int getAge() { return age; }
}

Jackson 이 @ConstructorProperties 를 보고 ctor 인자명 → JSON 키 매핑. JPA 는 인식 안 함 (proxy 생성을 위해 no-args 가 여전히 필요).

record (JDK 14+)

public record User(String name, int age) {}

자동 생성:

private final 필드
모든 필드를 받는 canonical constructor
name(), age() accessor (getName() 아님 주의)
equals/hashCode/toString

대부분 modern framework 가 record 를 직접 지원 (Jackson 2.12+, Spring Boot 2.6+). JPA 는 아직 entity 로는 부적합 (mutable 필요).

record 와 JavaBean 의 차이: accessor 이름이 name() 이지 getName() 이 아님. JavaBean 규약을 따르지 않으므로 일부 레거시 framework 는 record 인식 못 함.

Lombok 과의 관계

@Data  // = @Getter + @Setter + @ToString + @EqualsAndHashCode + @RequiredArgsConstructor
@NoArgsConstructor
public class User {
    private String name;
    private int age;
}

Lombok 은 컴파일 타임에 JavaBean 보일러플레이트를 자동 생성. JavaBean 규약을 매뉴얼하게 지키는 것과 동등.

다만 @Data 는 mutable + equals/hashCode 자동 구현 둘 다 들어가서 JPA entity 에 쓰면 양방향 연관관계에서 무한 루프 / 영속성 컨텍스트 문제 발생. JPA entity 에는 @Getter + @Setter 정도만 권장.

framework 별 의존

Framework	요구사항	비고
JPA / Hibernate	no-args ctor (public 또는 protected), getter/setter	proxy 생성을 위해
Jackson	no-args ctor 또는 `@JsonCreator` / `@ConstructorProperties`	record 도 지원
Spring `@ConfigurationProperties`	setter (또는 record)	환경 변수 → 객체 binding
Bean Validation	getter	필드/메서드 어디든 어노테이션 가능
Spring MVC (`@ModelAttribute`)	no-args ctor + setter	form binding
Spring `JdbcTemplate` + `BeanPropertyRowMapper`	no-args ctor + setter (또는 record)	RowMapper 가 reflection 사용

베스트 프랙티스

API 응답 / 요청 DTO: record 우선
JPA entity: 클래스 + @Getter + protected no-args ctor (Lombok @NoArgsConstructor(access = PROTECTED))
@ConfigurationProperties: JDK 16+ 에선 record 권장 (spring.application.name 같은 단순 binding)
불변 DTO 가 필요한데 record 가 안 맞을 때: @ConstructorProperties 또는 builder pattern

[Java] Servlet API: HttpServletRequest, HttpServletResponse

koa (김신건) — Sun, 21 Jun 2026 00:00:00 GMT

정의

Servlet 은 Java 진영의 표준 HTTP 처리 API. 컨테이너 (Tomcat / Jetty / Undertow) 가 HTTP 요청을 객체 (HttpServletRequest) 로 만들어 servlet 의 service() 에 넘기고, 응답 (HttpServletResponse) 을 받아 클라이언트에 송신한다.

Spring MVC, JSF, Struts 같은 web framework 가 모두 이 위에서 동작. Spring Boot 의 DispatcherServlet 도 본질적으로 하나의 Servlet 이다.

javax → jakarta 네임스페이스

시기	네임스페이스	컨테이너
Java EE 8 이하	`javax.servlet.*`	Tomcat 9 이하, Jetty 9 이하
Jakarta EE 9+	`jakarta.servlet.*`	Tomcat 10+, Jetty 11+

2019 년 Oracle 이 Java EE 를 Eclipse Foundation 에 이관하면서 javax 상표를 못 쓰게 됨. 모든 import 가 강제 변경됐다. Spring Boot 3.x / Spring Framework 6 부터 jakarta.* 만 지원.

오래된 라이브러리가 javax.servlet 을 import 하면 Spring Boot 3 에서 동작 안 함. 마이그레이션 도구 org.eclipse.transformer 가 바이트코드 레벨에서 패키지 치환을 해 준다.

가장 간단한 Servlet




@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain;charset=UTF-8");
        resp.getWriter().write("Hello, " + req.getParameter("name"));
    }
}

@WebServlet("/hello") 가 URL 매핑. web.xml 으로도 가능하지만 annotation 방식이 일반적.

요청과 응답 예:

HttpServletRequest 핵심 API

// URL 구성요소
String method = req.getMethod();                 // "GET"
String uri = req.getRequestURI();                // "/api/users/42"
String url = req.getRequestURL().toString();     // "http://host/api/users/42"
String query = req.getQueryString();             // "page=1&size=10"
String contextPath = req.getContextPath();       // "/myapp" or ""
String servletPath = req.getServletPath();       // "/api/users/42"

// 파라미터 (query string + form body)
String name = req.getParameter("name");
String[] tags = req.getParameterValues("tag");
Map<String, String[]> all = req.getParameterMap();

// 헤더
String ua = req.getHeader("User-Agent");
Enumeration<String> names = req.getHeaderNames();
long contentLength = req.getContentLengthLong();
String contentType = req.getContentType();

// 본문 (한 번만 읽을 수 있음!)
InputStream body = req.getInputStream();          // 바이너리
BufferedReader reader = req.getReader();          // 텍스트
// getReader() 또는 getInputStream() 중 하나만 호출 가능

// 쿠키, 세션
Cookie[] cookies = req.getCookies();
HttpSession session = req.getSession();           // 없으면 생성
HttpSession existing = req.getSession(false);     // 없으면 null

// 클라이언트 정보
String ip = req.getRemoteAddr();
String userAgent = req.getRemoteUser();

// attribute (request scope 임시 데이터)
req.setAttribute("user", currentUser);
User u = (User) req.getAttribute("user");

본문 한 번만 읽기 가 함정. logging filter 가 본문을 미리 읽으면 controller 가 못 읽는다. Spring 의 ContentCachingRequestWrapper 가 이 문제를 해결.

HttpServletResponse 핵심 API

// 상태 코드
resp.setStatus(200);
resp.sendError(404, "Not Found");

// 헤더
resp.setHeader("X-Custom", "value");
resp.addHeader("Set-Cookie", "session=abc");
resp.setContentType("application/json;charset=UTF-8");
resp.setCharacterEncoding("UTF-8");

// 본문 쓰기
PrintWriter writer = resp.getWriter();
writer.write("{\"ok\":true}");
// 또는 바이너리
OutputStream out = resp.getOutputStream();
out.write(bytes);

// 리다이렉트 (302)
resp.sendRedirect("/login");

// 쿠키
Cookie c = new Cookie("session", "abc");
c.setHttpOnly(true);
c.setSecure(true);
c.setPath("/");
c.setMaxAge(3600);
resp.addCookie(c);

// flush / commit
resp.flushBuffer();    // 헤더 + 버퍼 즉시 전송
// 이후엔 헤더 변경 불가

getWriter() 와 getOutputStream() 도 둘 중 하나만. 함께 쓰면 IllegalStateException.

ServletContext

애플리케이션 전체에 1 개. 모든 servlet 이 공유:

ServletContext ctx = req.getServletContext();
ctx.setAttribute("startupTime", Instant.now());

// 초기화 파라미터 (web.xml 의 <context-param>)
String env = ctx.getInitParameter("env");

// 실제 파일 시스템 경로
String realPath = ctx.getRealPath("/WEB-INF/data.json");

// 동적 servlet 등록 (Servlet 3.0+)
ctx.addServlet("myServlet", MyServlet.class).addMapping("/api/*");

Spring 의 application scope Bean 이 이 ServletContext attribute 에 저장된다 (@Scope("application")).

ServletConfig

개별 servlet 의 초기화 정보:

@Override
public void init() {
    ServletConfig cfg = getServletConfig();
    String mode = cfg.getInitParameter("mode");   // web.xml 의 <init-param>
}

@WebServlet(initParams = @WebInitParam(name = "mode", value = "prod")) 로도 설정 가능.

Servlet 3.0+ Async 처리

@WebServlet(urlPatterns = "/slow", asyncSupported = true)
public class SlowServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
        AsyncContext async = req.startAsync();
        async.setTimeout(10_000);

        // 워커 풀에 작업 위임, servlet thread 즉시 반환
        executor.submit(() -> {
            try {
                String result = computeSlowly();
                async.getResponse().getWriter().write(result);
            } finally {
                async.complete();
            }
        });
    }
}

asyncSupported = true 설정 + startAsync() 호출. 응답 완료까지 servlet thread 를 잡고 있지 않아 컨테이너 throughput 향상. Spring MVC 의 Callable / DeferredResult 가 내부적으로 이걸 사용.

함정과 베스트 프랙티스

본문, writer, stream 모두 1회용: filter 가 미리 읽으면 컨트롤러에서 못 읽음. wrapper 패턴 사용.
servlet 은 멀티스레드: 컨테이너는 같은 인스턴스에 동시 요청을 보낸다. 인스턴스 필드 (mutable state) 두지 말 것. [[java-servlet-lifecycle]] 참고.
HttpSession.setAttribute 는 분산 환경에서 문제. session 객체에 직접 저장하지 말고 Redis 등 외부 store 사용 (Spring Session).
getParameter() 는 query string + form body 둘 다 본다. POST 본문이 application/x-www-form-urlencoded 가 아니면 body 파라미터 못 읽음 (JSON body 는 직접 stream 파싱).
응답 commit 후 헤더 변경 불가: flushBuffer() 또는 본문이 buffer 크기를 넘기면 자동 commit.

[Java] Servlet Filter

koa (김신건) — Sun, 21 Jun 2026 00:00:00 GMT

정의

Filter 는 servlet 호출 전/후 에 끼어들어 요청과 응답을 가로채는 컴포넌트. 인증, 로깅, 압축, CORS, 인코딩 변환 같은 횡단 관심사 (cross-cutting concern) 를 servlet 코드 밖에서 처리할 때 쓴다.

여러 filter 가 체인 (chain) 으로 연결돼 순차 실행된다. 마지막 filter 가 chain.doFilter(req, resp) 를 호출하면 비로소 매핑된 servlet 의 service() 가 실행된다.

HandlerInterceptor 와 다른 점: 컨테이너 레벨 (servlet 보다 바깥) 에서 동작. Spring 의 DispatcherServlet 진입 전후 모두를 감쌀 수 있다.

Filter 인터페이스





@WebFilter("/api/*")
public class RequestLoggingFilter implements Filter {

    @Override
    public void init(FilterConfig config) {
        // 컨테이너 시작 시 1회
    }

    @Override
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain)
            throws IOException, ServletException {
        long start = System.nanoTime();
        HttpServletRequest http = (HttpServletRequest) req;

        try {
            chain.doFilter(req, resp);   // ← 다음 filter / servlet 으로 진행
        } finally {
            long ms = (System.nanoTime() - start) / 1_000_000;
            log.info("{} {} {}ms", http.getMethod(), http.getRequestURI(), ms);
        }
    }

    @Override
    public void destroy() { /* 정리 */ }
}

JDK 8+ 에서 init / destroy 는 default 구현이 있어 생략 가능. 핵심은 doFilter 하나.

체인 진입/종료가 어떤 순서로 일어나는지:

chain.doFilter 호출 전후가 명확하게 양파처럼 감싸진다.

시각화

{}

양파 (onion) 구조. Filter A 의 chain.doFilter 호출이 Filter B 진입, Servlet 처리 후 역순으로 복귀.

chain.doFilter 의 의미

Request 흐름:
  ↓
[Filter1.doFilter pre]
  ↓ chain.doFilter
  [Filter2.doFilter pre]
    ↓ chain.doFilter
    [Servlet.service]
    ↑
  [Filter2.doFilter post]
  ↑
[Filter1.doFilter post]
  ↓
Response

chain.doFilter 호출 전 = 요청 전처리, 호출 후 = 응답 후처리. 호출 안 하면 체인 중단 = servlet 까지 도달하지 않음. 인증 실패 처리에 사용:

if (!isAuthenticated(http)) {
    ((HttpServletResponse) resp).sendError(401);
    return;   // chain.doFilter 호출 안 함
}
chain.doFilter(req, resp);

등록 방법

1. @WebFilter annotation

@WebFilter(urlPatterns = "/api/*", initParams = @WebInitParam(name = "level", value = "DEBUG"))
public class LogFilter implements Filter { ... }

2. web.xml

<filter>
    <filter-name>logFilter</filter-name>
    <filter-class>com.example.LogFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>logFilter</filter-name>
    <url-pattern>/api/*</url-pattern>
</filter-mapping>

3. Spring Boot FilterRegistrationBean

@Configuration
public class FilterConfig {
    @Bean
    public FilterRegistrationBean<LogFilter> logFilter() {
        FilterRegistrationBean<LogFilter> reg = new FilterRegistrationBean<>();
        reg.setFilter(new LogFilter());
        reg.addUrlPatterns("/api/*");
        reg.setOrder(1);    // 낮을수록 먼저
        return reg;
    }
}

순서 제어가 필요하면 FilterRegistrationBean 권장. @Component 로 등록하면 Spring Boot 가 자동 매핑하지만 순서를 제어하기 어렵다.

흔한 패턴

인증

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) {
    HttpServletRequest http = (HttpServletRequest) req;
    String token = http.getHeader("Authorization");
    if (token == null || !jwtVerifier.verify(token)) {
        ((HttpServletResponse) resp).sendError(401);
        return;
    }
    chain.doFilter(req, resp);
}

CORS

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) {
    HttpServletResponse http = (HttpServletResponse) resp;
    http.setHeader("Access-Control-Allow-Origin", "https://app.example.com");
    http.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
    http.setHeader("Access-Control-Allow-Headers", "Authorization, Content-Type");

    if ("OPTIONS".equalsIgnoreCase(((HttpServletRequest) req).getMethod())) {
        http.setStatus(204);
        return;
    }
    chain.doFilter(req, resp);
}

문자 인코딩

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) {
    req.setCharacterEncoding("UTF-8");
    chain.doFilter(req, resp);
}

Spring Boot 는 CharacterEncodingFilter 가 기본 등록돼 있음.

응답 압축 / 캐싱 (wrapper)

응답을 가로채려면 HttpServletResponseWrapper 로 감싸기:

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) {
    ContentCachingResponseWrapper wrapper = new ContentCachingResponseWrapper((HttpServletResponse) resp);
    chain.doFilter(req, wrapper);
    byte[] body = wrapper.getContentAsByteArray();
    // 로깅, 압축, 변환 ...
    wrapper.copyBodyToResponse();    // 실제 응답으로 복사
}

요청도 마찬가지: ContentCachingRequestWrapper 로 본문을 캐싱해야 logging filter + controller 가 모두 읽을 수 있다.

OncePerRequestFilter (Spring)

Servlet spec 에선 forward / include / async dispatch 시 filter chain 이 다시 실행 될 수 있다. 인증 filter 가 2 번 돌면 안 되는데.

Spring 의 OncePerRequestFilter 가 이 문제를 해결:

public class JwtFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse resp, FilterChain chain)
            throws ServletException, IOException {
        // 요청당 정확히 1회만 실행 보장
        ...
        chain.doFilter(req, resp);
    }
}

내부적으로 request attribute 에 alreadyFilteredAttributeName 플래그를 두고 중복 실행을 차단. Spring 환경에선 거의 항상 이걸 상속하는 게 안전.

Filter vs HandlerInterceptor vs AOP

항목	Filter	HandlerInterceptor	AOP @Around
실행 위치	servlet 컨테이너	DispatcherServlet 내부	Bean 메서드 호출
Spring context 접근	등록 시 의존성 주입 가능	Spring Bean 으로 자연 통합	Spring Bean 만 적용
handler 정보 접근	불가	가능 (`Object handler`)	proxy target 메서드
응답 변환 가능	가능 (wrapper 로)	postHandle 에서 ModelAndView	메서드 반환값 변형
예외 처리	직접 try/catch	afterCompletion 의 `ex`	throwing advice
적용 범위	URL 패턴	URL 패턴 + handler	pointcut (메서드/클래스)

규칙: HTTP 레이어 (인증, CORS, 압축, 로깅) = Filter, MVC handler 정보 필요 = Interceptor, 서비스 메서드 횡단 관심사 = AOP.

함정과 베스트 프랙티스

항상 OncePerRequestFilter (Spring 환경): forward/include 중복 방지
순서 제어 명시적으로: FilterRegistrationBean.setOrder() 또는 @Order
chain.doFilter 누락 방지: 중단 의도가 아니면 반드시 호출
try/finally 패턴: ThreadLocal set/remove, 시간 측정 등은 finally 에서
응답 commit 후 헤더 변경 불가: filter 후처리에서 헤더 추가하려면 응답이 아직 commit 전이어야
본문 wrapper 는 메모리 비용: 큰 body 전체 캐싱은 OOM 위험

[Java] Servlet 생명주기

koa (김신건) — Sun, 21 Jun 2026 00:00:00 GMT

정의

Servlet 은 컨테이너 (Tomcat / Jetty / Undertow) 가 생성, 호출, 소멸시키는 객체. 개발자는 인터페이스 메서드만 구현하고 인스턴스 관리는 일체 안 한다.

핵심 메서드 3 가지:

메서드	호출 시점	호출 횟수
`init(ServletConfig)`	첫 요청 도착 시 (lazy) 또는 컨테이너 시작 시 (eager)	인스턴스당 1회
`service(req, resp)`	매 HTTP 요청	요청마다 1회, 멀티스레드로 동시 호출
`destroy()`	컨테이너 종료 또는 hot reload 시	인스턴스당 1회

HttpServlet 은 service() 를 오버라이드해 HTTP 메서드별로 doGet / doPost / doPut 등에 분기.

인스턴스 수: 1

기본적으로 servlet 클래스당 인스턴스 1개. 모든 요청이 같은 인스턴스의 service() 를 동시 호출. 그래서:

public class BrokenServlet extends HttpServlet {
    private String currentUser;  // ❌ 멀티스레드 공유 = race condition

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
        currentUser = req.getRemoteUser();
        respondWithGreeting(currentUser);  // 다른 요청이 덮어쓸 수 있음
    }
}

규칙: 인스턴스 필드 = 불변 의존성만 (logger, config). 요청별 데이터는 메서드 로컬 변수에.

SingleThreadModel 마커 인터페이스는 Servlet 2.4 부터 deprecated. 대신 thread-safe 하게 작성하거나 ThreadLocal 사용 ([[java-threadlocal]]).

실제 라이프사이클 로그 출력:

AtomicLong 같은 thread-safe 필드만 안전하다. worker thread 가 같은 인스턴스를 공유한다는 사실에 주목.

init: lazy vs eager

기본은 lazy: 첫 요청이 와야 인스턴스 생성 + init() 호출. 첫 요청이 느려진다.

load-on-startup 으로 eager:

@WebServlet(urlPatterns = "/api/*", loadOnStartup = 1)
public class ApiServlet extends HttpServlet { ... }

<!-- web.xml -->
<servlet>
    <servlet-name>api</servlet-name>
    <servlet-class>com.example.ApiServlet</servlet-class>
    <load-on-startup>1</load-on-startup>   <!-- 숫자 작을수록 먼저 -->
</servlet>

DB 풀 초기화, 캐시 워밍업 등 무거운 작업을 init() 에서 한다. init() 실패 시 ServletException 던지면 컨테이너는 servlet 을 사용 불가 처리.

@Override
public void init() throws ServletException {
    try {
        this.dataSource = createDataSource();
    } catch (SQLException e) {
        throw new ServletException("DB 초기화 실패", e);
    }
}

service 의 dispatch

HttpServlet.service() 의 기본 구현:

// HttpServlet (간략화)
protected void service(HttpServletRequest req, HttpServletResponse resp) {
    String method = req.getMethod();
    switch (method) {
        case "GET":    doGet(req, resp); break;
        case "POST":   doPost(req, resp); break;
        case "PUT":    doPut(req, resp); break;
        case "DELETE": doDelete(req, resp); break;
        case "HEAD":   doHead(req, resp); break;
        case "OPTIONS": doOptions(req, resp); break;
        case "TRACE":  doTrace(req, resp); break;
        default: resp.sendError(SC_NOT_IMPLEMENTED);
    }
}

직접 service() 를 오버라이드하면 메서드 분기를 직접 해야 함. 일반적으로는 doX() 만 오버라이드.

destroy

컨테이너가 servlet 을 제거하기 직전 호출. 진행 중인 요청이 끝날 때까지 기다림 (graceful shutdown).

@Override
public void destroy() {
    if (dataSource != null) dataSource.close();
    executor.shutdown();
}

중요한 한계: JVM 이 비정상 종료 (kill -9, OOM crash) 되면 destroy() 호출 안 됨. 영속적 cleanup 은 외부 메커니즘 (DB transaction commit, file flush) 에 의존하지 말 것.

컨테이너의 인스턴스 관리

컨테이너 시작
  └─ load-on-startup servlet 인스턴스화
       └─ init() 호출

요청 도착
  ├─ 첫 요청이면 lazy servlet 인스턴스화 + init()
  └─ thread pool 에서 worker thread 가져옴
       └─ servlet.service(req, resp)
            └─ doGet/doPost/...

요청 처리 중
  └─ 같은 servlet 인스턴스에 동시 호출 가능 (다른 worker thread 에서)

컨테이너 종료 / 재배포
  ├─ 신규 요청 거부
  ├─ 진행 중 요청 완료 대기 (timeout)
  └─ servlet.destroy() → GC

Tomcat 의 Connector + Executor 가 worker thread pool 을 관리. 기본 200 개. server.tomcat.threads.max 로 조정.

hot deploy 와 ClassLoader

Spring Boot DevTools 가 코드 변경 감지 시:

기존 WebApplicationContext + servlet destroy()
새 ClassLoader 로 클래스 재로딩
새 인스턴스 + init()

이때 init() / destroy() 가 빠르고 idempotent 여야 함. 외부 리소스 (DB connection) 누수 주의.

비동기 lifecycle

startAsync() 호출 시 service() 반환과 응답 commit 이 분리:

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
    AsyncContext ac = req.startAsync();
    ac.start(() -> {
        // 별도 thread 에서 응답 작성
        respondLater(ac);
    });
}
// service() 는 즉시 반환, but 응답은 아직 미완료

worker thread 는 풀로 복귀. 응답 완료는 ac.complete() 호출 시. timeout 도 컨테이너가 관리.

함정과 베스트 프랙티스

인스턴스 필드 = 불변 의존성만
init() 에서 OOM 위험 작업 (큰 캐시 로드) 주의: 컨테이너 시작이 멈춤
destroy() 는 빠르게: 응답 안 하면 컨테이너가 강제 종료
graceful shutdown 은 Tomcat.setAwaitTimeout() 또는 Spring Boot server.shutdown=graceful 설정
load-on-startup 은 정수만 의미 있음. 음수면 lazy 와 동일.
컨테이너 별 차이: Tomcat 은 worker thread pool, Jetty 도 유사, Undertow 는 XNIO 기반 다름.

[Java] ThreadLocal

koa (김신건) — Sun, 21 Jun 2026 00:00:00 GMT

정의

ThreadLocal<T> 는 각 스레드마다 독립된 변수 사본을 가지게 해 주는 컨테이너. set/get/remove 로 접근하며, 한 스레드의 값은 다른 스레드에서 볼 수 없다.

쓰임은 두 가지: (1) 같은 인스턴스를 여러 스레드가 공유하지만 상태는 격리해야 할 때 (e.g., SimpleDateFormat 캐싱), (2) 메서드 인자로 전달하기 번거로운 “요청 컨텍스트” 를 호출 스택 전체에 보이게 하고 싶을 때 (e.g., 트랜잭션, 인증 정보).

시각화

{}

각 스레드가 자신의 ThreadLocalMap 에만 값을 저장. 다른 스레드는 접근 자체 불가.

기본 사용

public class RequestId {
    private static final ThreadLocal<String> CURRENT = new ThreadLocal<>();

    public static void set(String id) { CURRENT.set(id); }
    public static String get() { return CURRENT.get(); }
    public static void clear() { CURRENT.remove(); }
}

// 진입점에서 설정
RequestId.set("req-123");
try {
    service.doWork();   // 깊은 호출 스택 어디서든 RequestId.get() 으로 접근
} finally {
    RequestId.clear();  // 반드시 정리
}

실행해 보면 각 스레드가 독립 값을 보유한다:

<CodeWithOutput language=“java” outputLanguage=“text” code={`public class ThreadLocalDemo { static final ThreadLocal COUNT = ThreadLocal.withInitial(() -> 0);

public static void main(String[] args) throws InterruptedException {
    Runnable task = () -> {
        for (int i = 0; i < 3; i++) {
            COUNT.set(COUNT.get() + 1);
        }
        System.out.println(Thread.currentThread().getName() + " count=" + COUNT.get());
    };
    Thread t1 = new Thread(task, "A");
    Thread t2 = new Thread(task, "B");
    t1.start(); t2.start();
    t1.join(); t2.join();
}

}} output={A count=3 B count=3`} />

각 스레드는 자신의 카운터만 증가. 스레드 간 누수 없음.

withInitial 로 lazy 초기값 지정 가능:

private static final ThreadLocal<SimpleDateFormat> FORMAT =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

String today = FORMAT.get().format(new Date());

SimpleDateFormat 은 thread-safe 하지 않으므로 흔한 패턴.

내부 구조

ThreadLocal 값은 ThreadLocal 인스턴스 자체에 저장되지 않는다. 각 Thread 객체 안의 ThreadLocalMap 에 저장된다.

Thread A.threadLocals = { ThreadLocal_X: "A 값", ThreadLocal_Y: 1 }
Thread B.threadLocals = { ThreadLocal_X: "B 값" }

ThreadLocal 인스턴스는 map 의 key 역할. 그래서 같은 ThreadLocal 변수에 대해 스레드별로 다른 값이 보이는 것.

map 의 키는 WeakReference<ThreadLocal>. ThreadLocal 변수 자체가 GC 되면 entry 의 key 가 null 이 되지만, value 는 strong reference 라 GC 안 됨. 이게 누수의 원인.

메모리 누수 함정

스레드 풀 환경에서 흔히 발생:

// 잘못된 패턴
ExecutorService pool = Executors.newFixedThreadPool(10);
pool.submit(() -> {
    BIG_OBJECT.set(new byte[100_000_000]);  // 100 MB 할당
    doWork();
    // remove() 안 함
});

스레드가 풀에 반환돼도 ThreadLocalMap 은 그대로. 다음 작업이 와도 그 100 MB 가 계속 살아있다. 10 개 스레드 풀이면 최악의 경우 1 GB 가 유지됨.

규칙: 진입점에서 try { set(...); ... } finally { remove(); } 패턴 강제. Web 프레임워크들이 servlet filter / interceptor 로 처리해 주는 이유.

InheritableThreadLocal

자식 스레드가 부모의 값을 상속:

InheritableThreadLocal<String> trace = new InheritableThreadLocal<>();
trace.set("trace-1");

new Thread(() -> {
    System.out.println(trace.get());  // "trace-1"
}).start();

중요한 한계: Thread 생성 시점에 값이 복사된다. 스레드 풀처럼 스레드를 재사용하면 풀에 들어갈 때 한 번만 복사되고, 이후 작업에서는 stale 한 부모 값이 그대로. 풀 환경에선 거의 무용지물.

Spring 의 TaskDecorator 로 매 작업마다 복사하는 패턴이 일반적.

ScopedValue (JDK 21+)

ThreadLocal 의 함정을 해결한 불변, 스코프 한정 대안:

private static final ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();

ScopedValue.where(CURRENT_USER, alice)
    .run(() -> {
        // 이 블록 안에서만 CURRENT_USER.get() == alice
        service.process();
    });
// 블록 종료 = 자동 해제, 누수 불가능

특징:

불변: set 으로 덮어쓸 수 없음 (rebinding 만 가능, 새 스코프 안에서)
자동 정리: try/finally 불필요
virtual thread 친화적: 가벼움 (ThreadLocal 은 virtual thread 마다 map 생성 비용)

JDK 25 에서도 preview 단계 (2026 기준). 정식 stable 화 진행 중.

Spring 활용

Spring 은 ThreadLocal 을 광범위하게 사용. 주요 위치:

컴포넌트	저장 대상	설정/해제 시점
`RequestContextHolder`	HTTP 요청/응답 attributes	`RequestContextFilter`, `DispatcherServlet`
`LocaleContextHolder`	현재 요청의 locale	`LocaleResolver` 가 갱신
`TransactionSynchronizationManager`	현재 트랜잭션 자원 (Connection 등)	`@Transactional` 진입/종료
`SecurityContextHolder` (Spring Security)	인증된 `Authentication` 객체	`SecurityContextPersistenceFilter`

@Async 메서드는 별도 스레드에서 실행되므로 위 ThreadLocal 이 자동 전파되지 않음. 해결책은 TaskDecorator 로 컨텍스트를 복사하거나 setRequestAttributes(attrs, inheritable=true) 옵션 사용. [[spring-request-context]] 참고.

베스트 프랙티스

private static final 로 선언 (인스턴스마다 만들면 누수 가속)
반드시 try { set; ... } finally { remove; } 패턴
프레임워크가 관리해 주는 ThreadLocal 은 직접 건드리지 말 것
스레드 풀에서 쓸 때 더 조심
JDK 21+ 신규 코드에선 ScopedValue 우선 검토
virtual thread 사용 시 ThreadLocal 남용 피하기 (수백만 개 가능 = 누수 폭발)

[Java] ArrayBlockingQueue

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

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

내부에 단일 [[ReentrantLock]] 을 사용 (head/tail 공유). 동시 throughput 은 [[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 두 [[ReentrantLock]] Condition 을 사용. take 가 비어 있으면 notEmpty 에서 대기, put 이 가득 차면 notFull 에서 대기.

동작

public void put(E e) throws InterruptedException {
    lock.lockInterruptibly();
    try {
        while (count == items.length) notFull.await();      // 가득 차면 대기
        enqueue(e);
        notEmpty.signal();                                    // take 대기자 깨움
    } finally { lock.unlock(); }
}

public E take() throws InterruptedException {
    lock.lockInterruptibly();
    try {
        while (count == 0) notEmpty.await();                // 비어 있으면 대기
        E e = dequeue();
        notFull.signal();                                     // put 대기자 깨움
        return e;
    } finally { lock.unlock(); }
}

복잡도

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

ArrayBlockingQueue vs LinkedBlockingQueue

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

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

사용 예

bounded 생산자-소비자

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

// Producer
new Thread(() -> {
    while (running) queue.put(create());
}).start();

// Consumer
new Thread(() -> {
    while (running) process(queue.take());
}).start();

참고

[[BlockingQueue]]
[[LinkedBlockingQueue]]
[[ReentrantLock]]
[[Blocking]]

[Java] ArrayDeque

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

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

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

시각화

{}

내부 구조

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)
}

원형 배열 (circular array) 방식.

head 와 tail 인덱스를 따로 관리
배열의 끝에 도달하면 다시 0 으로 (modular arithmetic)
가득 차면 2 배로 grow

초기 (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

복잡도

작업	시간
`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

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

Queue 사용 예

Queue<Task> queue = new ArrayDeque<>();
queue.offer(task1);
queue.offer(task2);
Task t = queue.poll();      // task1 (FIFO)

함정

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.

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Queue]]
[[Deque]]
[[LinkedList]]
[[ConcurrentLinkedDeque]]
[[fail-fast iterator]]

[Java] ArrayList

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.ArrayList 는 동적 배열 (dynamic array) 로 구현된 [[List]]. 내부적으로 Object[] 를 들고 다니며, 용량이 부족해지면 새 배열로 옮긴다.

Java 의 가장 흔한 컬렉션 구현체. 인덱스 기반 접근이 압도적으로 빠르고, 캐시 친화적이라 LinkedList 보다 실측이 빠른 경우가 대부분이다.

시각화

{}

내부 구조

public class ArrayList<E> extends AbstractList<E> implements List<E>, ... {
    transient Object[] elementData;   // 백킹 배열
    private int size;                 // 실제 원소 수
    private static final int DEFAULT_CAPACITY = 10;
}

세 개의 핵심 변수.

elementData: 실제 데이터가 들어있는 배열. 길이가 곧 capacity.
size: 사용 중인 슬롯 수. size <= elementData.length 가 항상 성립.
DEFAULT_CAPACITY: 첫 add 시 할당되는 초기 크기 (10).

빈 ArrayList 의 lazy 초기화

List<Integer> list = new ArrayList<>();  // elementData = {}, 빈 배열
list.add(1);                              // 이 순간 처음으로 길이 10 배열 할당

new ArrayList<>() 만 호출했을 때는 실제 배열을 만들지 않는다. 첫 add 에서 비로소 길이 10 의 배열이 잡힌다. 메모리 절약을 위한 lazy 전략.

용량 확장 (`grow()`)

size == elementData.length 인 상태에서 add 가 호출되면 새 배열을 만들고 옮긴다.

private Object[] grow(int minCapacity) {
    int oldCapacity = elementData.length;
    int newCapacity = ArraysSupport.newLength(
        oldCapacity,
        minCapacity - oldCapacity,    // 최소 증가량
        oldCapacity >> 1              // 선호 증가량 = 50%
    );
    return elementData = Arrays.copyOf(elementData, newCapacity);
}

기본 정책: 1.5 배 (oldCapacity + oldCapacity >> 1). 즉 10 → 15 → 22 → 33 → 49 → 73 → …

[!IMPORTANT] 미리 크기를 알면 new ArrayList<>(initialCapacity) 로 생성. 매 grow() 마다 Arrays.copyOf (= O(n) 복사) 가 발생하므로, 큰 데이터를 채울 때 차이가 크다.

주요 연산 비용

메서드	시간 복잡도	설명
`get(int i)`	O(1)	`elementData[i]` 직접 접근
`set(int i, E e)`	O(1)	인덱스 자리만 교체
`add(E e)`	amortized O(1)	size 슬롯에 대입, capacity 부족하면 1.5x 확장
`add(int i, E e)`	O(n)	i 이후 원소를 모두 한 칸씩 오른쪽으로 shift
`remove(int i)`	O(n)	i 이후 원소를 모두 왼쪽으로 shift
`remove(Object o)`	O(n)	indexOf 검색 + shift
`contains(Object o)`	O(n)	선형 검색
`indexOf(Object o)`	O(n)	선형 검색
`size()`, `isEmpty()`	O(1)	size 필드

amortized O(1) 의 의미

매 add 가 O(1) 이 아니라 평균적으로 O(1) 이라는 뜻. n 개 원소를 추가하는 비용을 따져보면:

용량 확장 비용 합 = 1 + 1.5 + 2.25 + ... ≈ 3n (등비급수 합 ≤ n / (1-1.5/2.25) ≈ 3n)
총 비용 = n (단순 대입) + 3n (확장) ≈ 4n
평균 = O(1)

함정

1. `remove(int)` vs `remove(Object)` 모호성

List<Integer> 에 대해서는 둘이 다른 의미.

List<Integer> list = new ArrayList<>(List.of(10, 20, 30));
list.remove(1);                  // 인덱스 1 의 원소 제거 → [10, 30]
list.remove(Integer.valueOf(1)); // 값 1 을 찾아서 제거 → 변화 없음 (1 이 없음)

오토박싱이 위 둘을 헷갈리게 만든다. 명시적으로 Integer.valueOf(x) 를 권장.

2. [[fail-fast iterator]]

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

iterator 의 expectedModCount 가 ArrayList.modCount 와 다르면 즉시 예외. 단일 스레드여도 발생.

3. `subList()` 는 뷰일 뿐

List<Integer> list = new ArrayList<>(List.of(1, 2, 3, 4, 5));
List<Integer> sub = list.subList(1, 4);  // [2, 3, 4]
sub.set(0, 99);                          // sub = [99, 3, 4]
// list 는?
System.out.println(list);                // [1, 99, 3, 4, 5] ← 원본도 바뀐다

독립 사본이 필요하면 new ArrayList<>(sub).

4. thread-safe 가 아니다

여러 스레드가 동시에 수정하면 데이터 손상, 무한 루프, ArrayIndexOutOfBoundsException 가 발생할 수 있다. 동시성이 필요하면 [[CopyOnWriteArrayList]] 또는 Collections.synchronizedList.

메모리 사용량

객체 헤더 (~16B) + Object[] 참조 (4-8B) + size (4B) + modCount (4B) → 약 32-40B
elementData: capacity 만큼의 참조 슬롯 (4-8B × capacity)
비어있는 슬롯 (capacity - size) 도 메모리 차지. trimToSize() 로 회수 가능.

ArrayList<Integer> list = new ArrayList<>(1000);
list.add(1); list.add(2);  // 998 슬롯이 null 로 낭비됨
list.trimToSize();          // elementData = new Object[2]

언제 ArrayList 가 답인가

인덱스 접근이 자주 일어남 (랜덤 read)
끝에 추가가 대부분 (스택, 누적 버퍼)
이미 정렬돼서 보관, 이진 탐색 (Collections.binarySearch)
단일 스레드 또는 외부 동기화

언제 다른 구현이 더 나은가

앞/중간 삽입·삭제가 빈번 + 인덱스 접근 거의 없음 → [[LinkedList]] (드물게)
수정이 거의 없는 공유 데이터 → [[CopyOnWriteArrayList]]
불변 → List.of(...) / List.copyOf(...)

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[List]]
[[LinkedList]]
[[Vector]]
[[CopyOnWriteArrayList]]
[[fail-fast iterator]]
[[ConcurrentModificationException]]
Joshua Bloch, Effective Java (3rd ed.), Item 28

[Java] AtomicInteger

koa (김신건) — Thu, 18 Jun 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 세 단계) 를 해결한다.

시각화

{}

핵심 메서드

AtomicInteger a = new AtomicInteger(0);

a.get();                          // 현재 값
a.set(10);                        // 설정
a.incrementAndGet();              // ++a, atomic
a.getAndIncrement();              // a++, atomic
a.decrementAndGet();              // --a
a.addAndGet(5);                   // a += 5
a.getAndAdd(5);                   // 더하기 전 값 반환

a.compareAndSet(10, 99);          // 현재 값이 10 이면 99 로, 성공하면 true
a.updateAndGet(x -> x * 2);       // Java 8+, 람다로 갱신
a.accumulateAndGet(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 비용보다 훨씬 작다.

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 에 분산 누적 후 합산.

사용 예

카운터

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

    public void onRequest() { total.incrementAndGet(); }
    public int count() { return total.get(); }
}

시퀀스 생성

private final AtomicInteger seq = new AtomicInteger();
public int nextId() { return seq.incrementAndGet(); }

상태 전이 (CAS)

private final AtomicInteger state = new AtomicInteger(STATE_READY);

public boolean tryStart() {
    return state.compareAndSet(STATE_READY, STATE_RUNNING);
}

상태 머신을 락 없이 안전하게 전이.

ABA 문제

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

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

해법: AtomicStampedReference 가 stamp (버전) 도 같이 비교.

다른 Atomic 타입

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

참고

[[volatile]]
[[ReentrantLock]]
[[AtomicReference]]
[[LongAdder]]
[[Non-Blocking]]
Brian Goetz, Java Concurrency in Practice, §15 Atomic Variables and Nonblocking Synchronization

[Java] AtomicReference

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

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

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

핵심 메서드

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

ref.get();                            // 현재 참조
ref.set(newConfig);                   // 단순 설정 (volatile write)
ref.compareAndSet(expected, newVal);  // CAS, 성공 시 true
ref.getAndSet(newVal);                // 이전 값 반환 + 새 값으로
ref.updateAndGet(c -> c.withFoo("x")); // 람다로 갱신 (CAS 루프 내장)
ref.accumulateAndGet(arg, (cur, a) -> ...);

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

class ConfigHolder {
    private final AtomicReference<Config> ref = new AtomicReference<>(defaultConfig);

    public Config get() { return ref.get(); }

    public void reload(Config newConfig) {
        ref.set(newConfig);              // volatile write, 다른 스레드 즉시 봄
    }

    public void update(Function<Config, Config> updater) {
        ref.updateAndGet(updater);       // CAS 루프, 동시 update 안전
    }
}

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

사용 사례

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 }
private final AtomicReference<State> state = new AtomicReference<>(State.READY);

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

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

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

[[ConcurrentLinkedQueue]] 의 internal pattern.

ABA 문제와 해법

[[AtomicInteger]] 와 같은 ABA 문제. 해법.

AtomicStampedReference<V>: stamp (int 버전) 추가
AtomicMarkableReference<V>: boolean mark 추가 (삭제 표시 등)

AtomicStampedReference<Node> ref = new AtomicStampedReference<>(node, 0);
int[] stampHolder = new int[1];
Node current = ref.get(stampHolder);
ref.compareAndSet(current, newNode, stampHolder[0], stampHolder[0] + 1);

참고

[[AtomicInteger]]
[[volatile]]
[[CopyOnWriteArrayList]]
[[ConcurrentLinkedQueue]]
[[Non-Blocking]]

[Java] BlockingQueue

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.concurrent.BlockingQueue<E> 는 요소를 가져올 때 비어 있으면 대기, 넣을 때 가득 차 있으면 대기 하는 thread-safe 큐 인터페이스. 생산자-소비자 (producer-consumer) 패턴의 표준 구현체.

take() 는 큐가 빌 때까지 [[Blocking]], put() 은 큐가 가득 찰 때까지 blocking. 이름 그대로 block 의 성질을 활용 한다.

핵심 구현체 6 개.

구현	특징
ArrayBlockingQueue	고정 크기, 단일 락 (head/tail 공유)
LinkedBlockingQueue	옵션 크기, 두 락 (head/tail 분리, 더 높은 throughput)
PriorityBlockingQueue	우선순위 (heap), unbounded
SynchronousQueue	용량 0, 직접 핸드오프
DelayQueue	원소가 지정된 delay 이후에만 꺼낼 수 있음
LinkedTransferQueue	producer 가 consumer 도착을 기다릴 수 있음

시각화

{}

핵심 메서드 매트릭스

BlockingQueue 의 메서드는 꽉 참 / 비어 있음 상황에 어떻게 반응하느냐로 4 가지 그룹으로 나뉜다.

동작	예외 throw	특수값 반환	block	timeout
insert	`add(e)`	`offer(e)`	`put(e)`	`offer(e, t, u)`
remove	`remove()`	`poll()`	`take()`	`poll(t, u)`
peek	`element()`	`peek()`	(없음)	(없음)

예외 throw

queue.add(elem);        // 큐 가득 → IllegalStateException
queue.remove();         // 큐 비어 있음 → NoSuchElementException

특수값 반환

boolean ok = queue.offer(elem);   // 가득 → false
Task t = queue.poll();             // 비어 있음 → null

Block (BlockingQueue 의 핵심)

queue.put(elem);        // 가득 → 자리 날 때까지 block
Task t = queue.take();   // 비어 있음 → 원소 들어올 때까지 block

Timeout

boolean ok = queue.offer(elem, 100, TimeUnit.MILLISECONDS);
Task t = queue.poll(500, TimeUnit.MILLISECONDS);

[!TIP] 어떤 그룹을 쓸지가 설계 결정이다. 반드시 처리해야 함 → put/take, 포기 가능 → offer/poll, 포기 + 타임아웃 → timed offer/poll.

가장 흔한 패턴, Producer-Consumer

final BlockingQueue<Task> queue = new LinkedBlockingQueue<>(1000);

// Producer
new Thread(() -> {
    while (true) {
        Task t = generate();
        queue.put(t);              // 큐가 가득 차면 자연스럽게 backpressure
    }
}).start();

// Consumer
new Thread(() -> {
    while (true) {
        Task t = queue.take();     // 원소 올 때까지 block
        process(t);
    }
}).start();

이 코드의 강점.

명시적 동기화 코드가 없다, BlockingQueue 가 모두 처리
자연스러운 backpressure, producer 가 너무 빠르면 큐가 가득 차서 자동으로 throttle
확장 가능, producer 또는 consumer 를 N 개로 늘려도 코드 변경 없음

구현체별 비교

ArrayBlockingQueue

내부: 원형 배열 (circular buffer)
락: 단일 ReentrantLock, head 와 tail 모두 같은 락 보호
크기: 고정 (생성 시 지정)
공정성: 옵션 (FIFO 보장)

BlockingQueue<Task> q = new ArrayBlockingQueue<>(100);
BlockingQueue<Task> fair = new ArrayBlockingQueue<>(100, true);

장점: 메모리 미리 할당, GC 압력 작음. 단점: 락 경합 (read/write 가 같은 락).

LinkedBlockingQueue

내부: linked list (head, tail 포인터)
락: 두 개의 ReentrantLock (takeLock, putLock)
크기: optionally bounded (Integer.MAX_VALUE 기본)

BlockingQueue<Task> q = new LinkedBlockingQueue<>();       // unbounded
BlockingQueue<Task> q2 = new LinkedBlockingQueue<>(1000);  // bounded

장점: producer 와 consumer 가 다른 락 → 동시에 가능. 단점: 각 원소가 노드 객체 → GC 압력.

[!IMPORTANT] 거의 모든 실무 case 의 첫 선택은 LinkedBlockingQueue 또는 ArrayBlockingQueue. 두 락 분리 덕에 LinkedBlockingQueue 가 throughput 우위인 경우가 많다. 크기를 반드시 bounded 로 지정 하라, unbounded 는 OOM 의 원인.

PriorityBlockingQueue

내부: 힙 (heap)
락: 단일 ReentrantLock
크기: unbounded (capacity 부족 시 grow)
순서: Comparator 또는 Comparable 기준 우선순위

BlockingQueue<Task> q = new PriorityBlockingQueue<>(
    100,
    Comparator.comparingInt(Task::priority).reversed()
);

긴급 작업 우선 처리, 스케줄러 패턴에 적합.

SynchronousQueue

용량 0, 저장 공간 없음
put 은 매칭되는 take 가 있어야 진행, 반대도 마찬가지
직접 핸드오프 (direct handoff)

BlockingQueue<Task> q = new SynchronousQueue<>();
// Producer: put 하면 consumer 가 take 할 때까지 block
// Consumer: take 하면 producer 가 put 할 때까지 block

쓰임: Executors.newCachedThreadPool() 의 내부 큐. 새 작업이 오면 즉시 스레드에 전달, 없으면 새 스레드 생성.

DelayQueue

원소는 Delayed 인터페이스 구현 필요
delay 가 만료된 원소만 poll/take 로 꺼낼 수 있음

class DelayedTask implements Delayed {
    private final long readyAt;
    public long getDelay(TimeUnit u) {
        return u.convert(readyAt - System.currentTimeMillis(), TimeUnit.MILLISECONDS);
    }
    public int compareTo(Delayed o) { ... }
}

BlockingQueue<DelayedTask> q = new DelayQueue<>();
q.put(new DelayedTask(System.currentTimeMillis() + 5000));  // 5초 뒤 ready
q.take();   // 5초간 block 후 반환

스케줄러, retry 큐, TTL 캐시 만료 처리 등.

LinkedTransferQueue

LinkedBlockingQueue 의 확장
추가 메서드: transfer(e) (consumer 가 받을 때까지 block), tryTransfer(e)
producer 가 consumer 의 도착을 알 수 있음

대량 동시성에 최적화. 일반 BlockingQueue 보다 throughput 우위지만 구현 복잡.

ExecutorService 와의 연동

Java 의 ThreadPoolExecutor 가 내부적으로 BlockingQueue 를 사용한다.

ExecutorService pool = new ThreadPoolExecutor(
    4, 16, 60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(1000)   // 작업 대기열
);

Executors factory 별 기본 큐.

Factory	내부 큐
`newFixedThreadPool(n)`	`LinkedBlockingQueue` (unbounded ⚠️)
`newSingleThreadExecutor()`	`LinkedBlockingQueue` (unbounded ⚠️)
`newCachedThreadPool()`	`SynchronousQueue` (핸드오프)
`newScheduledThreadPool(n)`	`DelayedWorkQueue` (DelayQueue 변형)

[!CAUTION] newFixedThreadPool 의 unbounded 큐가 OOM 의 단골 원인. 명시적으로 new ThreadPoolExecutor(..., new LinkedBlockingQueue<>(N)) 로 제한해야 한다.

함정

1. `take()` 의 인터럽트

try {
    Task t = queue.take();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // 인터럽트 상태 복원
    return;
}

take() 는 block 중 인터럽트되면 InterruptedException. 처리 안 하면 컴파일 오류. 무시하지 말고 인터럽트 상태를 복원, 그러지 않으면 상위 코드가 인터럽트를 못 본다.

2. unbounded 큐의 OOM 위험

new LinkedBlockingQueue<>() (인자 없이) 는 Integer.MAX_VALUE 크기. producer 가 빠르면 OOM. 항상 bounded.

3. drainTo 사용

List<Task> batch = new ArrayList<>();
queue.drainTo(batch, 100);   // 한 번에 최대 100 개를 batch 로

take() 를 반복 호출하는 것보다 훨씬 빠르다 (락 한 번에 여러 원소 이동). 배치 처리에 유용.

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Blocking]]
[[Non-Blocking]]
[[Synchronous]]
[[Asynchronous]]
[[ReentrantLock]]
Brian Goetz, Java Concurrency in Practice, §5.3 Blocking Queues and the Producer-Consumer Pattern

[Java] Collection

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.Collection<E> 는 그룹으로 묶인 객체들을 표현하는 최상위 인터페이스. JCF (Java Collections Framework) 의 입구이자, [[List]] / Set / Queue / Deque 모두 이를 확장한다.

Collection 자체는 직접 인스턴스화하지 않는다. 하위 인터페이스의 구현체 ([[ArrayList]], HashSet, LinkedList 등) 만이 실제 객체가 된다.

상속 관계:

Iterable<E>
  └─ Collection<E>
       ├─ List<E>     → ArrayList, LinkedList, Vector, CopyOnWriteArrayList
       ├─ Set<E>      → HashSet, LinkedHashSet, TreeSet, CopyOnWriteArraySet
       ├─ Queue<E>    → PriorityQueue, ArrayDeque, ConcurrentLinkedQueue
       │   └─ Deque<E> → ArrayDeque, LinkedList, ConcurrentLinkedDeque
       └─ (Map 은 Collection 이 아니다, 별도 계층)

[!IMPORTANT] Map 은 Collection 의 자식이 아니다. key-value pair 의 모음이라 일반적인 element 모음과 의미가 달라 별도 계층. Map.entrySet() / Map.keySet() / Map.values() 가 Set/Collection 을 반환해 다리를 놓는다.

핵심 메서드 그룹

추가/삭제

add(E e): 원소 추가, 추가 됐으면 true (Set 이 이미 갖고 있으면 false)
remove(Object o): 첫 매칭 원소 제거
addAll(Collection), removeAll(Collection), retainAll(Collection)
clear(): 모두 삭제

조회

contains(Object o): 포함 여부
containsAll(Collection): 모두 포함하는지
size(), isEmpty()
iterator(): 순회용 ([[Iterable]] 에서 상속)
stream(), parallelStream(): Java 8+ Stream API 입구

배열 변환

toArray(): Object[] 반환
toArray(T[] a): 지정 타입 배열 반환
toArray(IntFunction<T[]> generator): Java 11+, 더 명확

Collection<String> c = List.of("a", "b", "c");

Object[] arr1 = c.toArray();                // Object[]
String[] arr2 = c.toArray(new String[0]);    // String[] (관행: 빈 배열 전달)
String[] arr3 = c.toArray(String[]::new);    // String[] (Java 11+ 권장)

Collection 의 약속과 한계

Collection 인터페이스 자체는 순서, 중복 허용, 동기화 에 대한 약속이 없다.

특성	Collection	List	Set	Queue
순서 보장	✗	✓ (인덱스)	구현 의존	✓ (FIFO 등)
중복 허용	✗	✓	✗	구현 의존
`get(int)`	✗	✓	✗	✗

따라서 코드에서 변수 타입을 Collection<E> 로 받으면 인덱스 접근, 정렬, 중복 검사 같은 가정을 못 한다. 함수 매개변수에서 일부러 약한 약속만 쓸 때 유용.

자주 쓰이는 구현 한눈에

구현	하위 인터페이스	특징
[[ArrayList]]	List	가장 흔한 기본
[[LinkedList]]	List, Deque	양방향 연결 리스트
[[Vector]]	List	레거시 synchronized
[[CopyOnWriteArrayList]]	List	읽기 多, 쓰기 少
`HashSet`	Set	해시 기반, 순서 없음
`LinkedHashSet`	Set	삽입 순서 유지
`TreeSet`	Set	정렬 (Comparable / Comparator)
`PriorityQueue`	Queue	힙 기반
`ArrayDeque`	Queue, Deque	배열 기반 deque (스택보다 빠름)
`ConcurrentLinkedQueue`	Queue	동시성 lock-free

Map 은 별도 계층

Map<K,V>
  ├─ HashMap, LinkedHashMap, TreeMap
  ├─ Hashtable (legacy)
  ├─ ConcurrentHashMap
  └─ EnumMap, IdentityHashMap, WeakHashMap

Map 은 Collection 을 extends 하지 않는다. 다만 다음 메서드로 view 를 제공.

Map<String, Integer> map = ...;
Set<String> keys = map.keySet();              // key 만 Set
Collection<Integer> values = map.values();    // value 모음
Set<Map.Entry<String, Integer>> entries = map.entrySet();  // 쌍

이 view 들을 통해 Collection 인터페이스와 호환된다.

컬렉션 view 와 변경 전파

Map.keySet(), subList(), Arrays.asList() 등은 view 를 반환. view 에 대한 변경이 원본에 전파된다.

Map<String, Integer> map = new HashMap<>(Map.of("a", 1, "b", 2));
Set<String> keys = map.keySet();
keys.remove("a");                // ← map 에서도 "a" 삭제

List<Integer> view = list.subList(1, 3);
view.set(0, 99);                 // ← list[1] = 99

[!CAUTION] view 의 추가/삭제는 원본에 영향을 준다. 독립 사본이 필요하면 new ArrayList<>(view), new HashSet<>(keys) 등으로 명시적 복사.

불변 컬렉션 (Java 9+)

List.of(), Set.of(), Map.of() 가 추가됐다. 반환되는 컬렉션은:

immutable: add/remove/clear 호출 시 UnsupportedOperationException
null 거부: null 원소를 넣으면 NullPointerException
구조 공유 없음: 안전한 공유 가능

List<Integer> primes = List.of(2, 3, 5, 7);
Set<String> langs = Set.of("Java", "Kotlin", "Scala");
Map<String, Integer> ages = Map.of("Alice", 30, "Bob", 25);

기존 Collections.unmodifiableList(...) 보다 권장.

동기화 (synchronized) 래퍼

Collections.synchronizedXxx(...) 가 모든 메서드를 synchronized 로 감싼 래퍼를 반환.

List<Integer> safe = Collections.synchronizedList(new ArrayList<>());
Map<String, Integer> safeMap = Collections.synchronizedMap(new HashMap<>());
Set<Integer> safeSet = Collections.synchronizedSet(new HashSet<>());

[[Vector]] 와 비슷한 메서드별 락 패턴. 복합 연산은 외부 동기화 필요.

synchronized (safe) {            // ← 외부 동기화 필수
    for (Integer x : safe) {     // 순회도 락 안에서
        ...
    }
}

진짜 동시성에는 [[CopyOnWriteArrayList]], [[ConcurrentHashMap]] 등 동시성 컬렉션 권장.

Collection 의 함정 정리

1. `Collection.removeAll(c)` 비용

list.removeAll(otherList);   // O(n × m), otherList 가 List 면 contains 가 O(m)
list.removeAll(otherSet);    // O(n), Set 의 contains 가 O(1)

removeAll 의 매개변수는 contains() 가 빠른 컬렉션을 넘기는 게 좋다.

2. `Collection.equals` 는 List/Set 별로 다르다

List<Integer> a = List.of(1, 2);
Set<Integer> b = Set.of(1, 2);
a.equals(b);   // false! List.equals 와 Set.equals 의 의미가 다름

Collection 자체는 equals 의미를 명세하지 않음. 하위 인터페이스가 정의.

3. raw type 금지

// ❌ Java 5 이전 스타일
Collection c = new ArrayList();
c.add("hello");
c.add(42);     // 컴파일은 됨, 런타임에 ClassCastException

// ✓ generic
Collection<String> c = new ArrayList<>();

참고

[[Object]]
[[Iterable]]
[[List]]
[[ArrayList]]
[[LinkedList]]
[[Vector]]
[[CopyOnWriteArrayList]]
[[fail-fast iterator]]
Joshua Bloch, Effective Java (3rd ed.), Items 28-31 (배열보다 리스트, 한정적 와일드카드 등)

[Java] ConcurrentHashMap

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.concurrent.ConcurrentHashMap<K,V> 는 고동시성 환경에서 사용 가능한 Map 구현. JSR-166 (Java 5) 도입, Java 8 에서 내부 구조가 크게 재작성됐다.

HashMap 과 같은 인터페이스를 제공하면서 thread-safe. Hashtable (legacy) 보다 압도적으로 빠르고, Collections.synchronizedMap(...) 보다 훨씬 좋은 동시성을 제공한다.

실무에서 thread-safe Map 이 필요할 때 거의 항상 첫 번째 선택.

시각화

{}

내부 구조 (Java 8+)

public class ConcurrentHashMap<K,V> extends AbstractMap<K,V>
    implements ConcurrentMap<K,V>, Serializable {

    transient volatile Node<K,V>[] table;       // 버킷 배열
    private transient volatile Node<K,V>[] nextTable;  // resize 중 임시 테이블
    private transient volatile long baseCount;
    private transient volatile int sizeCtl;

    static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        volatile V val;
        volatile Node<K,V> next;
    }
}

table: 버킷 (bin) 배열. 각 버킷은 Node 의 linked list 또는 (TREEIFY 임계 이상이면) red-black tree.
volatile: 모든 핵심 필드가 volatile, 락 없이 일관된 view.
CAS: 새 노드 삽입은 Unsafe.compareAndSwapObject 로 atomic.
synchronized (Node): 같은 버킷에 충돌이 생기면 그 버킷의 첫 노드 에 synchronized.

Java 7 까지는 segment-based 였다 (16개 segment 로 분할 동기화). Java 8 부터는 bin-level (버킷 단위) 동기화 로 진화. 충돌 단위가 더 작아져 동시성이 크게 향상.

핵심 알고리즘

get, 락 없이

public V get(Object key) {
    int h = spread(key.hashCode());
    Node<K,V>[] tab = table;
    int n = tab.length;
    Node<K,V> e = tabAt(tab, (n - 1) & h);   // volatile read
    while (e != null) {
        if (e.hash == h && key.equals(e.key)) return e.val;
        e = e.next;
    }
    return null;
}

읽기에는 락이 없다. 모든 필드가 volatile 이라 다른 스레드의 쓰기가 즉시 보인다. 사실상 HashMap.get() 만큼 빠르다.

put, 빈 버킷이면 CAS, 충돌이면 synchronized

final V putVal(K key, V value, boolean onlyIfAbsent) {
    int h = spread(key.hashCode());
    Node<K,V>[] tab = table;
    while (true) {
        int i = (tab.length - 1) & h;
        Node<K,V> f = tabAt(tab, i);
        if (f == null) {
            // 빈 버킷, CAS 로 새 노드 삽입 (lock-free)
            if (casTabAt(tab, i, null, new Node<>(h, key, value, null)))
                break;
        } else {
            // 충돌, 첫 노드에 synchronized
            synchronized (f) {
                if (tabAt(tab, i) == f) {     // double-check
                    // 같은 버킷에 추가 또는 갱신
                    ...
                }
            }
            break;
        }
    }
}

핵심 통찰:

충돌이 없으면 락도 없다. CAS 한 번으로 끝.
충돌이 있으면 그 버킷에만 락. 다른 버킷은 영향 없음.
락의 단위가 버킷 1 개 (보통 노드 0-2 개).

동시성 특성

작업	동시성
다른 키의 `get` / `put`	완전 병렬
같은 버킷의 `put`	직렬 (synchronized)
`get` 과 `put`	`get` 은 락 없음, 진행 가능
`resize`	다른 스레드도 도와줌 (cooperative)

즉, 같은 키에 동시 put 하지 않는 한 거의 모두 병렬.

Iterator 는 weakly consistent

[[fail-fast iterator]] 가 아니다. 순회 중 다른 스레드가 수정해도 ConcurrentModificationException 을 던지지 않는다.

Map<String, Integer> map = new ConcurrentHashMap<>();
map.put("a", 1); map.put("b", 2);

Iterator<Map.Entry<String, Integer>> it = map.entrySet().iterator();
map.put("c", 3);                    // 순회 중 추가
while (it.hasNext()) {
    System.out.println(it.next());  // CME 안 던짐
}

대신 weakly consistent, 순회 시작 후 변경된 내용이 보일 수도 있고 안 보일 수도 있다. 일관된 snapshot 이 아니다.

원자 연산 메서드들

ConcurrentHashMap 은 단순 put / get 외에도 원자성을 보장하는 복합 연산 을 제공한다.

// 키가 없으면 추가, 있으면 기존 값 반환
map.putIfAbsent("key", 1);

// 키가 있으면 람다 적용해 값 갱신, 없으면 추가
map.compute("key", (k, v) -> v == null ? 1 : v + 1);

// 키가 없을 때만 람다 호출해 추가
map.computeIfAbsent("key", k -> expensiveCompute(k));

// 키가 있을 때만 람다 호출해 갱신
map.computeIfPresent("key", (k, v) -> v + 1);

// 추가 또는 람다로 병합
map.merge("key", 1, Integer::sum);

이 메서드들은 버킷 단위 락 안에서 람다를 실행 한다. 람다 안에서 다시 같은 map 을 수정하면 deadlock 가능, 주의.

Java 8 의 추가 기능

// 병렬 처리 (forEach, search, reduce)
map.forEach(1, (k, v) -> process(k, v));   // 1 = 병렬 threshold
map.search(1, (k, v) -> v > 100 ? k : null);
long sum = map.reduceValues(1, 0L, Long::sum);

지정한 threshold (병렬 진입 한계) 보다 entry 가 많으면 ForkJoinPool 로 병렬 실행. 큰 map 의 일괄 처리에 유리.

size 의 약점

ConcurrentHashMap.size() 는 정확한 값이 아닐 수 있다. Java 8 부터는 LongAdder 기반으로 분산 카운터를 사용하므로 빠르지만 여전히 동시 수정 중에는 부정확.

int count = map.size();          // 호출 시점의 추정
// 다른 스레드가 그 사이 추가/삭제하면 실제와 다를 수 있음

정확한 카운트가 필요한 시나리오라면 외부 카운터를 따로 유지하거나, snapshot 을 위해 외부 동기화.

null 비허용

HashMap 과 달리 key 도 value 도 null 불가. null 을 넣으면 NullPointerException.

Map<String, Integer> chm = new ConcurrentHashMap<>();
chm.put(null, 1);    // ❌ NPE
chm.put("a", null);  // ❌ NPE
chm.get(null);       // ❌ NPE

이유: get(null) 이 반환한 null 이 “키가 없음” 인지 “키는 있는데 값이 null” 인지 동시성 안에서 구분 불가능. 처음부터 허용하지 않는 게 안전.

HashMap / Hashtable / synchronizedMap 비교

항목	HashMap	Hashtable	synchronizedMap	ConcurrentHashMap
Thread-safe	✗	✓ (메서드별 lock)	✓ (메서드별 lock)	✓ (bin-level)
null key/value	1 / 다수	✗	1 / 다수	✗
도입	JDK 1.2	JDK 1.0	JDK 1.2	JDK 1.5
동시 read 처리량	n/a	직렬화	직렬화	병렬
동시 write 처리량	n/a	직렬화	직렬화	버킷별 직렬, 다른 버킷 병렬
Iterator	fail-fast	fail-fast	fail-fast	weakly consistent
권장	단일 스레드	✗ legacy	가벼운 보호	동시성 표준

실무 사용 예

1. 캐시

private final Map<String, User> cache = new ConcurrentHashMap<>();

public User getUser(String id) {
    return cache.computeIfAbsent(id, this::loadFromDb);
}

computeIfAbsent 가 원자성을 보장하므로 같은 id 로 동시 호출 시 한 번만 loadFromDb 실행.

2. 카운터

private final Map<String, LongAdder> counts = new ConcurrentHashMap<>();

public void increment(String key) {
    counts.computeIfAbsent(key, k -> new LongAdder()).increment();
}

LongAdder 가 고경합에 강함. AtomicLong 보다 빠를 때가 많다.

3. Spring 의 빈 레지스트리

Spring 내부에 ConcurrentHashMap 이 많이 쓰인다 (DefaultListableBeanFactory.singletonObjects 등). 캐시류는 거의 모두 이 자료구조.

함정

1. compute 안의 부수효과

map.compute("key", (k, v) -> {
    map.put("other", 99);    // ❌ 같은 버킷이면 deadlock, 다른 버킷이면 UB
    return v + 1;
});

람다 안에서 같은 map 수정 금지.

2. size + put 두 번 호출

if (map.size() < 100) {       // ← race
    map.put(key, value);
}

이 사이에 다른 스레드가 추가했을 수 있다. compute, merge 같은 원자 메서드로 표현 가능한지 먼저 검토.

3. iterator 의 snapshot 가정

weakly consistent 라서 일관된 view 가 아니다. 정합성 있는 read 가 필요하면 별도 동기화 또는 CopyOnWriteArrayList 같은 snapshot 컬렉션.

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[CopyOnWriteArrayList]]
[[Vector]]
[[fail-fast iterator]]
[[volatile]]
[[ReentrantLock]]
[[Non-Blocking]]
Brian Goetz, Java Concurrency in Practice, §5.2 Concurrent Collections

[Java] ConcurrentLinkedDeque

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.concurrent.ConcurrentLinkedDeque<E> 는 lock-free [[Deque]]. [[ConcurrentLinkedQueue]] 의 양방향 버전. JDK 1.7 추가.

양 끝 모두에서 add/remove 가능, 모든 연산이 CAS 기반.

내부 구조

이중 연결 리스트 (prev, next 모두 volatile) 를 lock-free 알고리즘으로 관리. ConcurrentLinkedQueue 의 단방향보다 복잡하다.

복잡도

작업	시간	동시성
`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), 부정확	약함

사용 사례

양 끝에서 동시 작업이 일어나는 큐 (예: 일부 work-stealing 패턴)
stack + queue 혼용 동시성

ConcurrentLinkedQueue 와의 선택

대부분의 경우 ConcurrentLinkedQueue 가 충분. 양쪽 끝 연산이 모두 필요할 때만 Deque 선택.

시나리오	권장
FIFO 만	[[ConcurrentLinkedQueue]]
양 끝 add/remove	ConcurrentLinkedDeque
Producer-Consumer (blocking)	[[BlockingQueue]] 구현체

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Queue]]
[[Deque]]
[[ConcurrentLinkedQueue]]
[[BlockingQueue]]

[Java] ConcurrentLinkedQueue

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.concurrent.ConcurrentLinkedQueue<E> 는 lock-free 로 구현된 unbounded thread-safe [[Queue]]. Michael & Scott 의 non-blocking queue 알고리즘 (1996) 기반.

[[BlockingQueue]] 가 아닌 단순 큐. 큐가 비어 있으면 poll() 이 즉시 null 반환 (block 하지 않음).

시각화

{}

내부 구조

public class ConcurrentLinkedQueue<E> ... {
    private transient volatile Node<E> head;
    private transient volatile Node<E> tail;

    static final class Node<E> {
        volatile E item;
        volatile Node<E> next;
    }
}

head, tail, item, next 모두 volatile. 모든 갱신이 [[volatile]] write/CAS 로 수행돼 lock-free.

offer 의 흐름 (Michael & Scott)

offer(x):
  newNode = Node(x)
  loop:
    t = tail
    next = t.next
    if (next == null) {
      // tail 의 next 가 비어있음, 여기에 CAS
      if (CAS(t.next, null, newNode)) {
        CAS(tail, t, newNode)         // tail 이동 (best-effort)
        return
      }
    } else {
      // 다른 스레드가 추가했지만 tail 이 아직 안 옮겨짐
      CAS(tail, t, next)               // 도와서 tail 이동
    }

핵심: tail 이동이 best-effort, 즉 다른 스레드가 도와서 옮길 수 있다. 따라서 어떤 스레드든 큐의 일관성을 유지.

poll 의 흐름

poll():
  loop:
    h = head
    next = h.next
    if (next == null) return null     // 비어 있음
    if (CAS(head, h, next)) {
      e = next.item
      next.item = null                // GC 친화
      return e
    }

복잡도

작업	시간	동시성
`offer(e)`	amortized O(1)	lock-free, CAS 재시도
`poll()`	amortized O(1)	lock-free, CAS 재시도
`peek()`	O(1)	volatile read
`size()`	O(n)	약함, 정확하지 않을 수 있음
`contains`	O(n)	약함
순회	O(n)	weakly consistent

[!IMPORTANT] size() 가 O(n) 이고 부정확하다. 동시 수정 중에는 정확한 카운트 보장 안 됨. 정확한 개수가 필요하면 외부 카운터.

BlockingQueue 와의 차이

항목	ConcurrentLinkedQueue	[[BlockingQueue]] (LinkedBlockingQueue 등)
비어 있을 때 poll	즉시 null	(take 는) block
가득 차 있을 때 offer	(unbounded 라 발생 X)	(put 은) block
락	lock-free (CAS)	ReentrantLock
백프레셔	✗ (unbounded)	✓
메모리 보호	✗ (OOM 가능)	✓ (bounded 설정 가능)

생산자-소비자 같은 패턴에는 [[BlockingQueue]] 가 보통 더 적합. CLQ 는 polling 기반 처리, 비어 있을 때 다른 일 하는 패턴에 적합.

사용 예

작업 큐 (polling)

Queue<Task> queue = new ConcurrentLinkedQueue<>();

// Producer
queue.offer(new Task());

// Consumer (polling)
while (running) {
    Task t = queue.poll();
    if (t == null) {
        Thread.sleep(10);    // 잠시 쉬고 다시
        continue;
    }
    process(t);
}

비어 있을 때 즉시 반환되므로 polling 으로 직접 backoff 가능.

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Queue]]
[[ConcurrentLinkedDeque]]
[[BlockingQueue]]
[[volatile]]
[[Non-Blocking]]
Maged M. Michael & Michael L. Scott, “Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms” (PODC 1996)

[Java] ConcurrentModificationException

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.ConcurrentModificationException (CME) 는 [[fail-fast iterator]] 가 컬렉션의 구조 변경을 탐지했을 때 던지는 unchecked 예외 (RuntimeException).

이름과 달리 반드시 동시성 (멀티스레드) 문제일 때만 발생하는 것이 아니다. 단일 스레드에서도 자기 자신을 잘못 수정하면 발생한다.

java.util 의 거의 모든 컬렉션 ([[ArrayList]], [[LinkedList]], [[Vector]], HashMap, TreeMap, HashSet, TreeSet) 의 iterator 가 던질 수 있다.

가장 흔한 두 시나리오

1. 순회 중 자기 수정 (단일 스레드)

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

for (Integer x : list) {           // iterator 사용
    if (x % 2 == 0) {
        list.remove(x);            // ❌ CME 던짐
    }
}

for-each 는 내부적으로 iterator() 를 호출. 그 iterator 가 만들어진 뒤 list.remove() 가 modCount 를 증가시킨다. 다음 it.next() 에서 검사 실패 → CME.

2. 멀티스레드 동시 수정

List<Integer> shared = new ArrayList<>();
// Thread A
for (Integer x : shared) { /* 읽기 */ }
// Thread B (동시 실행)
shared.add(99);  // ← Thread A 의 다음 next() 에서 CME

이 경우 CME 는 best-effort 신호. CME 가 안 나도 안전한 것은 아니다 (더 무서운 [silent corruption] 가능).

메시지에 없는 정보

CME 의 메시지에는 누가 수정했는지 가 적혀 있지 않다.

Exception in thread "main" java.util.ConcurrentModificationException
    at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1095)
    at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1049)
    at MyApp.main(MyApp.java:23)

Itr.next() 가 trigger 일 뿐, 진짜 원인은 그 사이에 일어난 다른 어딘가의 수정. 디버깅을 위해서는:

iterator 와 같은 스택 위쪽 코드 부터 살핀다. 같은 메서드 안에 add/remove 가 있는지.
공유 컬렉션이라면 다른 스레드의 호출 을 추적한다. 보통 lambda, async, scheduled task.
ArrayList 등에 디버거를 걸어 modCount 변화를 추적 한다.

해결 패턴

`Iterator.remove()` 사용

Iterator<Integer> it = list.iterator();
while (it.hasNext()) {
    Integer x = it.next();
    if (x % 2 == 0) {
        it.remove();   // ✓ iterator 가 expectedModCount 도 함께 갱신
    }
}

Iterator.remove() 는 컬렉션의 remove() 를 호출한 뒤 expectedModCount = modCount 로 동기화한다. 그래서 CME 가 발생하지 않는다.

`removeIf` 사용 (Java 8+)

list.removeIf(x -> x % 2 == 0);

내부적으로 Iterator.remove() 와 같은 안전한 방식. 더 짧고 명확.

복사본 순회

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

복사 비용을 감수하는 대신 가장 단순한 해결.

동시성 컬렉션 사용

진짜 멀티스레드 환경이라면 fail-fast 컬렉션 자체를 피한다.

// 읽기 많음, 쓰기 적음
List<Integer> list = new CopyOnWriteArrayList<>();

// 키-값
Map<String, Integer> map = new ConcurrentHashMap<>();

// 큐
Queue<Task> q = new ConcurrentLinkedQueue<>();

이들은 CME 를 던지지 않으면서 동시 수정/순회를 지원한다.

잡으면 안 된다

// ❌ 안 좋은 패턴
try {
    for (Integer x : list) {
        if (cond) list.remove(x);
    }
} catch (ConcurrentModificationException e) {
    // 무시
}

이 catch 는 버그를 숨길 뿐. iterator 가 일관성 없는 상태로 더 진행하지 않은 것은 다행이지만, 그래도 “왜 동시 수정이 일어났는가” 라는 진짜 문제는 그대로다.

[!IMPORTANT] CME 는 잡지 말고 고쳐라. “왜 이게 던져졌는가” 라는 질문에서 출발해 코드의 동시성 가정을 다시 본다. CME 가 사라지도록 위의 해결 패턴 중 하나를 적용.

자주 만나는 추가 사례

`Stream.forEach` 도 동일

list.stream().forEach(x -> {
    if (cond) list.remove(x);  // ❌ CME
});

내부적으로 iterator 사용. 같은 함정.

`HashMap` 순회 중 `put`

Map<String, Integer> map = new HashMap<>();
for (var entry : map.entrySet()) {
    map.put("new", 1);   // ❌ CME (key 가 새로 추가되면 구조 변경)
}

값만 바꾸는 것 (entry.setValue(...)) 은 OK.

nested loop

for (Integer a : listA) {
    for (Integer b : listB) {
        if (cond) listA.remove(a);  // ❌ outer 의 CME
    }
}

자주 놓치는 케이스, outer loop 에 영향.

참고

[[fail-fast iterator]]
[[ArrayList]]
[[LinkedList]]
[[Vector]]
[[CopyOnWriteArrayList]]
Brian Goetz, Java Concurrency in Practice, §5.1.2

[Java] ConcurrentSkipListMap

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

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

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

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

시각화

{}

Skip List 의 구조

Level 3: head ─────────────────────► 25 ─────────► null
Level 2: head ────────► 10 ────────► 25 ──► 40 ──► null
Level 1: head ─► 5 ──► 10 ──► 17 ──► 25 ──► 40 ──► null
Level 0: head ─► 5 ──► 10 ──► 17 ──► 25 ──► 33 ── 40 ─► null
                                            ↑
                                    실제 데이터 lane

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

복잡도

작업	평균	최악
`get`, `put`, `remove`	O(log n)	O(n) (매우 드뭄, 동전이 다 같은 면)
`firstKey`, `lastKey`	O(1)	O(1)
`containsKey`	O(log n)
순회	O(n)
`size()`	O(n)	약함

사용 예

시간순 정렬된 동시성 맵

ConcurrentNavigableMap<Instant, Event> log = new ConcurrentSkipListMap<>();

// Producer thread
log.put(Instant.now(), event);

// Consumer thread
NavigableMap<Instant, Event> recent = log.tailMap(Instant.now().minusSeconds(60));
recent.forEach((t, e) -> process(e));

Range 쿼리 + 동시성

ConcurrentNavigableMap<Integer, String> levels = new ConcurrentSkipListMap<>();
levels.put(0, "free");
levels.put(100, "basic");
levels.put(1000, "premium");

// 어느 등급에 해당하는지
String tier = levels.floorEntry(user.points()).getValue();

ConcurrentHashMap vs ConcurrentSkipListMap

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

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

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Map]]
[[TreeMap]]
[[ConcurrentHashMap]]
[[ConcurrentSkipListSet]]
[[Non-Blocking]]
William Pugh, “Skip Lists: A Probabilistic Alternative to Balanced Trees” (CACM 1990)

[Java] ConcurrentSkipListSet

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.concurrent.ConcurrentSkipListSet<E> 는 [[ConcurrentSkipListMap]] 을 백킹으로 사용하는 정렬된 thread-safe [[Set]]. [[TreeSet]] 의 동시성 버전.

NavigableSet 인터페이스 구현. floor, ceiling, subSet 등 정렬 기반 연산 제공.

복잡도

[[ConcurrentSkipListMap]] 의 성질.

작업	평균
`add`, `remove`, `contains`	O(log n)
`first`, `last`, `floor`, `ceiling`	O(log n)
`size`	O(n), 부정확

사용 예

NavigableSet<Integer> sorted = new ConcurrentSkipListSet<>();
sorted.add(10); sorted.add(20); sorted.add(30);

sorted.floor(15);                // 10
sorted.ceiling(15);              // 20
sorted.subSet(10, 30);           // [10, 30)

HashSet / TreeSet / ConcurrentSkipListSet

항목	HashSet	TreeSet	ConcurrentSkipListSet
시간	O(1)	O(log n)	O(log n)
정렬	✗	✓	✓
Thread-safe	✗	✗	✓
Range 쿼리	✗	✓	✓

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Set]]
[[Map]]
[[TreeSet]]
[[ConcurrentSkipListMap]]

[Java] CopyOnWriteArrayList

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

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

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

시각화

{}

내부 구조

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);
        return true;
    } finally {
        lock.unlock();
    }
}

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

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

주요 연산 비용

메서드	시간	락	비고
`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 없음, 순회 중 다른 스레드가 수정해도 안전
순회 중 수정 자유, 단 그 수정은 다음 순회부터 보임

단점:

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

메모리 관점

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

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

언제 CopyOnWriteArrayList 가 답인가

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

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

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

다른 동시성 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

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[List]]
[[ArrayList]]
[[Vector]]
[[ConcurrentHashMap]]
[[volatile]]
[[ReentrantLock]]
[[fail-fast iterator]]
[[Non-Blocking]]
Brian Goetz, Java Concurrency in Practice, §5.2 Copy-on-Write Collections

[Java] CopyOnWriteArraySet

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.concurrent.CopyOnWriteArraySet<E> 는 [[CopyOnWriteArrayList]] 를 백킹으로 사용하는 thread-safe [[Set]]. 중복 검사를 위해 매 add 마다 contains (O(n)) 를 수행.

[[CopyOnWriteArrayList]] 의 모든 특성 (snapshot iterator, 읽기 lock-free, 쓰기 시 전체 복사) 을 물려받는다.

내부 구조

public class CopyOnWriteArraySet<E> extends AbstractSet<E> ... {
    private final CopyOnWriteArrayList<E> al;

    public boolean add(E e) {
        return al.addIfAbsent(e);    // 선형 검색 후 없으면 추가
    }
}

복잡도

작업	시간
`add(e)`	O(n) (검색 + 전체 복사)
`contains(o)`	O(n) (선형 검색)
`remove(o)`	O(n) (검색 + 복사)
순회	O(n) (snapshot)

[!CAUTION] add 가 O(n) 이다. n 이 작거나 (수십 이하), 쓰기가 거의 없는 경우에만 사용. n 이 크면 [[ConcurrentHashMap]] 의 newKeySet() 또는 Collections.synchronizedSet(new HashSet<>()) 이 훨씬 빠르다.

사용 사례

[[CopyOnWriteArrayList]] 와 동일한 패턴.

이벤트 리스너 집합
옵저버 패턴 구독자
설정 / 메타데이터 집합, 변경 드묾

동시성 Set 비교

옵션	add	contains	iterator
CopyOnWriteArraySet	O(n) + 전체 복사	O(n)	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, 정렬

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Set]]
[[CopyOnWriteArrayList]]
[[ConcurrentHashMap]]
[[ConcurrentSkipListSet]]

[Java] CountDownLatch

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

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

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

시각화

{}

핵심 메서드

CountDownLatch latch = new CountDownLatch(N);

latch.countDown();              // count - 1
latch.await();                  // count == 0 될 때까지 block
latch.await(timeout, unit);     // timeout 까지만 block
latch.getCount();               // 현재 count (참고용)

가장 흔한 두 패턴

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

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

for (int i = 0; i < N; i++) {
    pool.submit(() -> {
        try { doWork(); }
        finally { done.countDown(); }   // 반드시 finally
    });
}
done.await();                          // 모든 작업 끝날 때까지 block
System.out.println("all done");

2. 시작 신호 (start gate)

CountDownLatch startGate = new CountDownLatch(1);

for (int i = 0; i < N; i++) {
    new Thread(() -> {
        startGate.await();              // start 신호 대기
        run();
    }).start();
}
// 준비 완료 시
startGate.countDown();                  // 모든 스레드 동시 출발

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

CountDownLatch vs CyclicBarrier

항목	CountDownLatch	[[CyclicBarrier]]
사용 횟수	일회용	재사용 가능
누가 기다리는가	한 명 또는 여러 명	모두가 서로 기다림
도착 콜백	없음	barrier action 실행 가능
reset	불가	`reset()` 가능

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

함정

1. 0 이후 다시 못 쓴다

재사용이 필요하면 [[CyclicBarrier]] 또는 [[Phaser]].

2. countDown 빠뜨리면 영원히 block

worker 가 예외로 종료되면서 countDown 을 호출 안 하면 main 이 영영 대기. 항상 finally 블록에서 호출.

참고

[[CyclicBarrier]]
[[Semaphore]]
[[Phaser]]
[[Blocking]]

[Java] CyclicBarrier

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.concurrent.CyclicBarrier 는 N 개의 스레드가 모두 도착할 때까지 서로 기다리는 synchronizer. 모두 도착하면 동시에 출발, 다시 사용 가능 (cyclic).

시각화

{}

핵심 메서드

CyclicBarrier barrier = new CyclicBarrier(N);
CyclicBarrier withAction = new CyclicBarrier(N, () -> {
    // 모두 도착 시 한 번 실행되는 action
    System.out.println("all arrived");
});

barrier.await();                   // 도착, 다른 스레드도 도착할 때까지 block
barrier.await(timeout, unit);
barrier.getNumberWaiting();        // 현재 대기 중인 스레드 수
barrier.reset();                   // 모든 대기자 깨우고 BrokenBarrierException 던짐

가장 흔한 패턴, 단계별 동시 실행

CyclicBarrier barrier = new CyclicBarrier(4);

for (int i = 0; i < 4; i++) {
    new Thread(() -> {
        for (int phase = 0; phase < 3; phase++) {
            doPhaseWork(phase);
            barrier.await();          // 다른 3 스레드 도착 대기
            // 모두 같은 phase 완료 후 다음 phase 진입
        }
    }).start();
}

병렬 계산의 각 phase 가 모두 끝나야 다음 phase 시작 가능한 경우 (예: 시뮬레이션 stepping).

BrokenBarrierException

한 스레드가 await 도중 인터럽트되거나 timeout 되거나 reset() 호출되면 다른 모든 대기자가 BrokenBarrierException 으로 깨어남. 한 명이 broken 이면 모두 broken.

try {
    barrier.await();
} catch (InterruptedException | BrokenBarrierException e) {
    // 처리
}

CountDownLatch vs CyclicBarrier vs Phaser

항목	[[CountDownLatch]]	CyclicBarrier	[[Phaser]]
재사용	✗	✓	✓
대칭	비대칭 (N → 0)	대칭 (N 만남)	대칭 + 동적
참여자 수	고정	고정	동적 (register/deregister)
콜백	✗	barrier action	onAdvance hook
도입	JDK 1.5	JDK 1.5	JDK 1.7

CyclicBarrier 는 N 이 고정이지만 반복, Phaser 는 N 이 매 phase 마다 바뀔 수 있다.

참고

[[CountDownLatch]]
[[Phaser]]
[[Semaphore]]
[[Blocking]]

[Java] DelayQueue

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

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

시각화

{}

Delayed 인터페이스

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

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

class DelayedTask implements Delayed {
    private final long readyAt;
    private final Runnable job;

    public DelayedTask(long delayMs, Runnable job) {
        this.readyAt = System.currentTimeMillis() + delayMs;
        this.job = 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);
    }

    public void run() { job.run(); }
}

동작

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

DelayedTask t = q.take();   // 1초 뒤에 반환
t.run();
t = q.take();               // 추가로 4초 뒤
t.run();

take() 는 큐의 가장 앞 원소의 getDelay 가 ≤ 0 이 될 때까지 block.

사용 사례

스케줄러

ScheduledThreadPoolExecutor 내부에서 비슷한 자료구조 (DelayedWorkQueue) 를 사용. 일정 시간 뒤 실행되는 작업을 관리.

캐시 만료 (TTL)

class CacheEntry implements Delayed {
    private final String key;
    private final long expiresAt;
    // getDelay, compareTo ...
}

DelayQueue<CacheEntry> expirations = new DelayQueue<>();

// 별도 스레드가 만료된 entry 를 캐시에서 제거
new Thread(() -> {
    while (true) {
        CacheEntry e = expirations.take();
        cache.remove(e.key);
    }
}).start();

// 캐시 add 시
expirations.put(new CacheEntry("k", now + ttl));
cache.put("k", v);

Retry 큐

실패한 요청을 일정 시간 뒤 재시도.

복잡도

내부는 [[PriorityQueue]] (heap).

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

참고

[[BlockingQueue]]
[[PriorityQueue]]
[[Blocking]]

[Java] Deque

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.Deque<E> (Double-Ended Queue) 는 [[Queue]] 의 확장 인터페이스. 양쪽 끝 (head, tail) 모두에서 add/remove/examine 가능한 자료구조.

JDK 1.6 도입. Queue, Stack, 일반 List 의 양 끝 연산을 모두 한 인터페이스로 통합.

메서드 매트릭스

위치	insert (throw)	insert (특수값)	remove (throw)	remove (특수값)	examine
head	`addFirst(e)`	`offerFirst(e)`	`removeFirst()`	`pollFirst()`	`peekFirst()`
tail	`addLast(e)`	`offerLast(e)`	`removeLast()`	`pollLast()`	`peekLast()`
Queue (= tail/head)	`add(e)`	`offer(e)`	`remove()`	`poll()`	`peek()`
Stack (= head)	`push(e)`	(= addFirst)	`pop()`	(= removeFirst)	`peek()`

push / pop 이 head 쪽에 동작하는 점이 중요. Stack 으로 쓸 때 head 가 top 이 된다.

구현체

구현	특징
[[ArrayDeque]]	권장 기본, 원형 배열
[[LinkedList]]	양방향 연결 리스트, 메모리 多
[[ConcurrentLinkedDeque]]	thread-safe (lock-free)
`LinkedBlockingDeque`	thread-safe + blocking

[!IMPORTANT] 새 코드의 Stack 은 Deque<E> stack = new ArrayDeque<>() 가 권장. 레거시 java.util.Stack 은 Vector 상속이라 비효율적.

// Stack 패턴
Deque<Integer> stack = new ArrayDeque<>();
stack.push(1); stack.push(2); stack.push(3);
stack.peek();    // 3
stack.pop();     // 3

// Queue 패턴
Deque<Integer> queue = new ArrayDeque<>();
queue.offer(1); queue.offer(2); queue.offer(3);
queue.peek();    // 1
queue.poll();    // 1

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Queue]]
[[ArrayDeque]]
[[LinkedList]]
[[ConcurrentLinkedDeque]]

[Java] Fail-Fast Iterator

koa (김신건) — Thu, 18 Jun 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 를 쓴다.

메커니즘, 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 가 증가하는 작업은 컬렉션의 크기를 바꾸거나 내부 배열을 새로 할당하는 작업.

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, 구조 변경 아님
}

트리거 예시

단일 스레드의 자기 수정

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

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

안전한 패턴

// ✓ Iterator.remove() 만 fail-fast 영향 없음
Iterator<Integer> it = list.iterator();
while (it.hasNext()) {
    if (it.next() == 2) it.remove();
}

// ✓ Java 8+: Collection.removeIf
list.removeIf(x -> x == 2);

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

멀티스레드에서

다른 스레드가 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 해서 삼키지 말고, 동시성 컬렉션을 쓰거나 동기화를 추가하라.

참고

[[ConcurrentModificationException]]
[[List]]
[[ArrayList]]
[[LinkedList]]
[[Vector]]
[[CopyOnWriteArrayList]]
Joshua Bloch, Effective Java (3rd ed.), Item 80 (스레드보다는 실행자, 태스크, 스트림을 애용하라)
Brian Goetz, Java Concurrency in Practice, §5.1.2 Iterators and ConcurrentModificationException

[Java] HashMap

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.HashMap<K,V> 는 해시 테이블 로 구현된 [[Map]]. 평균 O(1) 의 put/get/remove 를 보장하고 단일 스레드 환경의 사실상 표준.

JDK 1.2 도입, Java 8 에서 충돌 시 linked list → red-black tree 로 자동 변환 하는 큰 개선이 있었다.

시각화

{}

내부 구조

public class HashMap<K,V> extends AbstractMap<K,V>
    implements Map<K,V>, Cloneable, Serializable {

    transient Node<K,V>[] table;          // 버킷 배열
    transient int size;
    int threshold;                         // capacity * loadFactor
    final float loadFactor;                // 기본 0.75

    static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        V value;
        Node<K,V> next;                    // chaining (linked list)
    }
}

table: 버킷 배열, 기본 길이 16, 2^n 형태로 grow
Node: linked list 의 노드
Java 8+: 한 버킷의 노드가 8 개 이상 이면 TreeNode (red-black tree) 로 변환 → 64 미만 이면 다시 list

put 의 흐름

hash = key.hashCode() 후 spread (상위 16비트 XOR)
index = (table.length - 1) & hash
버킷이 비어 있으면 → 새 Node 삽입
같은 key 가 있으면 → 값 교체
충돌 → linked list 끝에 append (또는 tree 에 insert)
size > threshold → resize (2x grow + rehash)

public V put(K key, V value) {
    int h = spread(key.hashCode());
    int i = (table.length - 1) & h;
    Node<K,V> first = table[i];
    if (first == null) {
        table[i] = new Node<>(h, key, value, null);
    } else {
        // chain 순회, 같은 key 발견 시 교체
        // 끝에 도달하면 append, 8 개 이상이면 treeify
    }
    if (++size > threshold) resize();
    return null;
}

충돌 처리, chaining 과 treeify

같은 버킷에 여러 key 가 매핑되면 (해시 충돌):

TREEIFY_THRESHOLD = 8: 한 버킷에 8 노드 이상이면 tree 로 변환 (단, table 크기가 64 이상일 때만)
UNTREEIFY_THRESHOLD = 6: tree 가 6 노드 이하로 줄면 다시 list
MIN_TREEIFY_CAPACITY = 64: table 이 작을 때는 resize 가 우선

tree 로 변환되면 그 버킷의 최악 검색이 O(log n). 악의적 hash collision (수많은 입력이 같은 hash) 으로부터 보호.

복잡도

작업	평균	최악 (Java 8+)	최악 (Java 7 이전)
`get`, `put`, `remove`	O(1)	O(log n)	O(n)
`containsValue`	O(n)	O(n)	O(n)
iterator 순회	O(n + capacity)	같음	같음

containsKey 의 평균이 O(1) 인 이유는 해시 충돌이 적기 때문. 충돌이 폭주하지 않으려면 equals/hashCode 가 잘 분포해야 한다.

load factor 와 resize

loadFactor (기본 0.75): size / capacity 가 이를 초과하면 resize
resize(): table 길이를 2 배로 늘리고 모든 entry 를 새 위치로 rehash. O(n) 비용.

생성 시 초기 capacity 지정으로 미리 줄일 수 있다.

// 1000 개 entry 예상 → capacity 가 1000 / 0.75 ≈ 1334 보다 커야 resize 안 함
Map<String, Integer> map = new HashMap<>(2048);

null 허용

HashMap 은 key 와 value 모두 null 허용. key 가 null 이면 항상 버킷 0 에 매핑.

map.put(null, 1);              // OK
map.put("a", null);            // OK
map.get(null);                 // 1

[[ConcurrentHashMap]] 과의 가장 큰 차이.

함정

1. 가변 객체를 key 로 쓰면 안 됨

Map<List<Integer>, String> map = new HashMap<>();
List<Integer> key = new ArrayList<>(List.of(1, 2));
map.put(key, "v");
key.add(3);                      // hashCode 변경
map.get(key);                    // null! (다른 버킷으로 가게 됨)

불변 객체 (String, Integer, Long, Enum, record) 를 key 로 사용 권장.

2. equals 만 override 하고 hashCode 안 함

[[Object]] 의 규약 위반. HashMap 이 조용히 잘못 동작.

3. 동시 수정

HashMap 은 thread-safe 가 아니다. 동시 put 으로 무한 루프 가 발생한 사례가 유명 (특히 Java 7 의 resize 중 chain 역전 버그). [[ConcurrentHashMap]] 사용.

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

순회 중 수정 → [[ConcurrentModificationException]].

HashMap vs Hashtable vs ConcurrentHashMap

항목	HashMap	Hashtable	ConcurrentHashMap
Thread-safe	✗	✓ (메서드)	✓ (bin-level)
null key/value	✓	✗	✗
도입	JDK 1.2	JDK 1.0 (legacy)	JDK 1.5
성능	가장 빠름	느림 (전체 락)	동시성 최적
권장	단일 스레드	절대 X	동시성

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Map]]
[[LinkedHashMap]]
[[TreeMap]]
[[ConcurrentHashMap]]
[[Spring] ConcurrentReferenceHashMap]]
[[fail-fast iterator]]
[[ConcurrentModificationException]]
Joshua Bloch, Effective Java (3rd ed.), Items 10-11 (equals, hashCode)

[Java] HashSet

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.util.HashSet<E> 는 [[HashMap]] 을 백킹으로 사용하는 [[Set]] 구현. 내부적으로 모든 원소를 HashMap 의 key 로 저장하고, value 는 dummy 상수 PRESENT.

평균 O(1) 의 add/remove/contains. 순서는 보장되지 않는다. 가장 흔한 Set 구현.

내부 구조

public class HashSet<E> extends AbstractSet<E> implements Set<E>, ... {
    private transient HashMap<E, Object> map;
    private static final Object PRESENT = new Object();

    public boolean add(E e) {
        return map.put(e, PRESENT) == null;
    }
    public boolean contains(Object o) {
        return map.containsKey(o);
    }
    // ...
}

HashMap 의 모든 동작과 성능 특성을 그대로 물려받는다. capacity/loadFactor, treeify 같은 내용은 [[HashMap]] 참고.

복잡도

작업	평균	최악 (Java 8+)
`add`	O(1)	O(log n)
`contains`	O(1)	O(log n)
`remove`	O(1)	O(log n)
순회	O(n + capacity)	같음

null 허용

원소 하나는 null 가능 (HashMap 의 null key 처럼).

Set<String> s = new HashSet<>();
s.add(null);                     // OK
s.add(null);                     // false (이미 있음)
s.contains(null);                // true

Set.of(null) 은 NPE.

함정

[[HashMap]] 의 함정이 그대로 적용.

가변 객체 사용 금지
equals / hashCode 규약 준수
thread-safe 가 아님 → 동시성 필요 시 Collections.synchronizedSet 또는 ConcurrentHashMap.newKeySet()
iterator 는 [[fail-fast iterator]]

참고

[[Object]]
[[Iterable]]
[[Collection]]
[[Set]]
[[Map]]
[[HashMap]]
[[TreeSet]]
[[ConcurrentHashMap]]

[Java] Iterable

koa (김신건) — Thu, 18 Jun 2026 00:00:00 GMT

정의

java.lang.Iterable<T> 는 for-each 루프로 순회 가능한 모든 타입의 최상위 인터페이스. 단 하나의 추상 메서드, iterator() 를 정의한다.

public interface Iterable<T> {
    Iterator<T> iterator();

    default void forEach(Consumer<? super T> action) { ... }
    default Spliterator<T> spliterator() { ... }
}

[[Collection]] 인터페이스가 Iterable 을 extends 하므로 [[ArrayList]], [[LinkedList]], HashSet, LinkedList 등 모든 컬렉션이 자동으로 for-each 대상이 된다. 컬렉션이 아닌 사용자 정의 타입 도 Iterable 만 구현하면 같은 문법으로 순회 가능.

for-each 문의 desugaring

for (String s : myIterable) {
    System.out.println(s);
}

위 코드는 컴파일 시 아래로 변환된다.

Iterator<String> $it = myIterable.iterator();
while ($it.hasNext()) {
    String s = $it.next();
    System.out.println(s);
}

즉 for-each 는 단순히 iterator() 호출 + hasNext() / next() 패턴의 문법 설탕. 배열의 경우는 컴파일러가 인덱스 기반 for 로 변환 (배열은 Iterable 이 아님, 특별 케이스).

Iterator 인터페이스

Iterable.iterator() 가 반환하는 객체는 Iterator<E> 를 구현해야 한다.

public interface Iterator<E> {
    boolean hasNext();         // 다음 원소가 있는가
    E next();                  // 다음 원소를 반환, 커서 전진
    default void remove() { ... }  // 마지막에 반환한 원소를 삭제 (선택)
    default void forEachRemaining(Consumer<? super E> action) { ... }
}

3가지 약속:

hasNext() 가 true 인 동안에만 next() 호출 가능, 아니면 NoSuchElementException
remove() 는 직전 next() 호출이 있어야 호출 가능, 아니면 IllegalStateException
remove() 두 번 연속 호출 금지, 다음 next() 가 있어야 다시 가능

사용자 정의 Iterable

Iterable 구현은 매우 간단하다. 예: 1 부터 N 까지 정수를 순회하는 타입.

public class Range implements Iterable<Integer> {
    private final int end;

    public Range(int end) { this.end = end; }

    @Override
    public Iterator<Integer> iterator() {
        return new Iterator<>() {
            int i = 1;
            @Override public boolean hasNext() { return i <= end; }
            @Override public Integer next() {
                if (!hasNext()) throw new NoSuchElementException();
                return i++;
            }
        };
    }
}

// 사용
for (int x : new Range(5)) {
    System.out.println(x);   // 1, 2, 3, 4, 5
}

기본 메서드 두 가지

`forEach(Consumer)`

Java 8 부터 추가. 람다와 함께 더 간결.

list.forEach(System.out::println);
list.forEach(x -> log.info("item: {}", x));

내부적으로 iterator() 사용. 따라서 [[fail-fast iterator]] 의 영향을 받는다 (수정 중이면 CME).

`spliterator()`

Java 8 부터 추가. Stream / 병렬 처리를 위해 컬렉션을 분할 가능한 형태로 노출.

list.spliterator();          // 단일 spliterator
list.stream();               // Stream API 의 입구
list.parallelStream();       // 병렬 Stream

대부분의 사용자가 직접 spliterator() 를 호출할 일은 없다. Stream API 가 알아서 사용.

Iterable vs Collection vs Stream

	Iterable	Collection	Stream
크기 알 수 있나	보장 안 됨	`size()` 있음	보장 안 됨
재사용 가능한가	✓ (여러 번 iterator 생성 가능)	✓	✗ (1회 소비)
수정 가능한가	정의 안 함	add/remove 정의	✗ (불변 파이프라인)
무한 가능한가	✓	✗	✓
상위 관계	최상위	extends Iterable	별도 인터페이스

[!IMPORTANT] Iterable 은 크기와 무한성에 대한 약속이 없다. 무한 시퀀스를 Iterable 로 모델링해도 합법. 다만 for-each 가 영원히 안 끝나니 break 가 필요. 대안으로 Stream 의 limit(n) / takeWhile 이 더 명확.

무한 Iterable 의 예

피보나치 수열을 무한 시퀀스로:

public class Fibonacci implements Iterable<Long> {
    @Override
    public Iterator<Long> iterator() {
        return new Iterator<>() {
            long a = 0, b = 1;
            @Override public boolean hasNext() { return true; }  // 무한
            @Override public Long next() {
                long r = a;
                long next = a + b;
                a = b; b = next;
                return r;
            }
        };
    }
}

// 사용
for (long x : new Fibonacci()) {
    if (x > 1000) break;
    System.out.println(x);
}

Iterable 의 강점은 이런 lazy / 무한 시퀀스도 자연스럽게 표현되는 점.

Stream 으로 변환

Iterable 을 Stream 으로 바꾸는 표준 방법:

Iterable<String> it = ...;
Stream<String> stream = StreamSupport.stream(it.spliterator(), false);

false 는 순차 스트림, true 는 병렬. Iterable 이 spliterator() 의 기본 구현을 갖고 있어 가능.

자주 만나는 함정

1. iterator() 가 매번 새 인스턴스를 반환해야 함

// ❌ 잘못된 구현 - iterator 를 캐시
public class BadIterable<T> implements Iterable<T> {
    private final Iterator<T> it;  // 단 하나 보관
    @Override public Iterator<T> iterator() { return it; }
}
// → for-each 두 번 돌리면 두 번째에서 hasNext() == false

매 iterator() 호출이 새 인스턴스를 반환해야 다회 순회가 가능.

2. `for-each` 안에서 수정 → CME

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

[[ConcurrentModificationException]] 참조.

3. `next()` 의 결과를 두 번 부르면 두 원소가 진행됨

Iterator<Integer> it = list.iterator();
if (it.next() > 0 || it.next() > 0) { ... }
//   ^^^^^^^^^^      ^^^^^^^^^^
//   첫 원소         두 번째 원소 (의도와 다를 수 있음)

it.next() 는 부수효과 (커서 전진) 가 있다. 한 번만 부르고 변수에 저장하라.

참고

[[Object]]
[[Collection]]
[[List]]
[[fail-fast iterator]]
[[ConcurrentModificationException]]

[Java] LinkedBlockingQueue

koa (김신건) — Thu, 18 Jun 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.

시각화

{}

내부 구조

public class LinkedBlockingQueue<E> ... {
    private final int capacity;
    private final AtomicInteger count = new AtomicInteger();

    transient Node<E> head;
    private transient Node<E> last;

    private final ReentrantLock takeLock = new ReentrantLock();
    private final Condition notEmpty = takeLock.newCondition();

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

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

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

두 락의 협력

public void put(E e) throws InterruptedException {
    putLock.lockInterruptibly();
    try {
        while (count.get() == capacity) notFull.await();
        enqueue(new Node<>(e));
        int c = count.getAndIncrement();
        if (c + 1 < capacity) notFull.signal();   // 다음 put 대기자 깨움 (선택적)
    } finally { putLock.unlock(); }
    if (c == 0) signalNotEmpty();                  // take 대기자 깨움 (락 풀고)
}

public E take() throws InterruptedException {
    takeLock.lockInterruptibly();
    try {
        while (count.get() == 0) notEmpty.await();
        E e = dequeue();
        int c = count.getAndDecrement();
        if (c > 1) notEmpty.signal();
    } finally { takeLock.unlock(); }
    if (c == capacity) signalNotFull();
}

복잡도 및 동시성

작업	시간	동시성
`put`	O(1)	putLock 직렬
`take`	O(1)	takeLock 직렬
`put` ↔ `take` 동시	O(1)	병렬 (다른 락)

함정

1. unbounded 가 기본

new LinkedBlockingQueue<>() 는 Integer.MAX_VALUE 크기. producer 가 빠르면 OOM. 반드시 bounded 지정.

BlockingQueue<Task> q = new LinkedBlockingQueue<>(1000);   // 권장

2. 노드 객체 GC 압력

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

LinkedBlockingQueue vs ArrayBlockingQueue

[[ArrayBlockingQueue]] 의 비교 표 참고. 결론적으로 high throughput 이 필요하면 LinkedBlockingQueue, 메모리 예측이 중요하면 ArrayBlockingQueue.

참고

[[BlockingQueue]]
[[ArrayBlockingQueue]]
[[ReentrantLock]]
[[Blocking]]

김신건의 로그 - 위키 / java

[Java] Reflection: Class, Method, Field, MethodHandle

정의

Class 객체 얻기

메타데이터 조회

동적 호출

어노테이션 처리

동적 프록시

MethodHandle (JDK 7+, 현대적 대안)

성능 비용

함정과 베스트 프랙티스

관련 위키

[Java] JavaBean 프로퍼티 규약

정의

명명 규칙

Introspector

no-args constructor 의 이유

@ConstructorProperties

record (JDK 14+)

Lombok 과의 관계

framework 별 의존

베스트 프랙티스

관련 위키

[Java] Servlet API: HttpServletRequest, HttpServletResponse

정의

javax → jakarta 네임스페이스

가장 간단한 Servlet

HttpServletRequest 핵심 API

HttpServletResponse 핵심 API

ServletContext

ServletConfig

Servlet 3.0+ Async 처리

함정과 베스트 프랙티스

관련 위키

[Java] Servlet Filter

정의

Filter 인터페이스

시각화

chain.doFilter 의 의미

등록 방법

1. @WebFilter annotation

2. web.xml

3. Spring Boot FilterRegistrationBean

흔한 패턴

인증

CORS

문자 인코딩

응답 압축 / 캐싱 (wrapper)

OncePerRequestFilter (Spring)

Filter vs HandlerInterceptor vs AOP

함정과 베스트 프랙티스

관련 위키

[Java] Servlet 생명주기

정의

인스턴스 수: 1

init: lazy vs eager

service 의 dispatch

destroy

컨테이너의 인스턴스 관리

hot deploy 와 ClassLoader

비동기 lifecycle

함정과 베스트 프랙티스

관련 위키

[Java] ThreadLocal

정의

시각화

기본 사용

내부 구조

메모리 누수 함정

InheritableThreadLocal

ScopedValue (JDK 21+)

Spring 활용

베스트 프랙티스

관련 위키

[Java] ArrayBlockingQueue

정의

시각화

내부 구조

동작

복잡도

용량 확장 (`grow()`)

1. `remove(int)` vs `remove(Object)` 모호성

3. `subList()` 는 뷰일 뿐