출처: https://yozm.wishket.com/magazine/detail/1531/

📌 한 줄 요약

Atomic Design은 엄격한 규칙이 아닌 멘탈 모델이며, 프로젝트 특성에 맞게 하이브리드로 변형해서 쓰는 것이 Best Practice다.

1. Atomic Design이란?

Brad Frost가 화학 개념을 UI 설계에 적용한 5단계 계층 구조

핵심: 선형 프로세스가 아니라, UI를 "전체이자 부분의 모음"으로 바라보게 해주는 사고 도구

2. 도입 후 마주친 문제들

❶ Molecules vs Organisms 경계 모호

• 실제 컴포넌트는 재사용 범위가 다양해서 분류가 애매함
• 사람마다 기준이 달라 팀 내 혼선 발생

❷ 계층만으로는 부족

• 도메인/기능별 구분도 필요 (Header, Footer, 검색 영역 등)
• 5단계만으로는 현실의 복잡성을 담기 어려움

❸ Template vs Pages와 데이터 바인딩 불명확

• 상태관리(Redux, Riverpod 등)와 함께 쓸 때 역할 경계가 흐려짐

❹ 고민 유발 구조의 역설

"어디에 넣을지 고민하게 만드는 구조는 좋은 구조가 아니다"

3. Best Practice: 하이브리드 접근법

기본 원칙

• Atomic 계층 구조 유지 + 의미론적(도메인) 구분 추가
• 기획/디자인 용어와 개발 폴더명 통일

폴더 구조 예시

/components
  ㄴ /공통            ← 뷰 컴포넌트 (다른 프로젝트에서도 재사용 가능)
      ㄴ /atoms
      ㄴ /molecules
      ㄴ /organisms
  ㄴ /일정관리         ← 비즈니스 컴포넌트 (이 프로젝트 전용)
      ㄴ /molecules
      ㄴ /organisms
      ㄴ /templates

뷰 vs 비즈니스 컴포넌트 구분

계층 판단 기준 (뷰 컴포넌트)

Atoms      → 외부 import 없음
Molecules  → 다른 컴포넌트를 import함 (예: SelectBox = Input + Dropdown)
Organisms  → 독립적으로 동작하는 단위 (예: Modal Popup)

4. 결론

1. Atomic Design은 엄격한 규칙이 아닌 이해 도구로 활용
2. 팀의 기획·디자인·개발 용어를 통일해서 폴더명에 반영
3. 뷰/비즈니스 컴포넌트를 먼저 분리한 뒤 Atomic 계층 적용
4. 폴더 구조는 단순 정리가 아닌 팀의 사고체계를 반영하는 것

"분류 기준을 많이 만들어 두고, 좋은 이름을 붙이고, 명확한 규칙을 만드는 것" — 좋은 폴더 구조의 조건

직렬화란?

이펙티브 자바에서 말하는 직렬화(Serializable) 는 객체의 상태를 바이트 스트림으로 변환하는 것을 의미한다. 반대로 바이트 스트림을 다시 객체로 복원하는 과정은 역직렬화다.

바이트 스트림을 사용하는 이유는 네트워크, 파일, DB 등 출발지와 목적지 모두가 이해할 수 있는 공통 표현이기 때문이다.

왜 직렬화를 사용할까?

• 자바 객체는 그대로 전송할 수 없음

• 전송을 위해 모두가 이해 가능한 형태(byte) 로 변환 필요

• 대표적인 예

  • 문자열 → 바이트 (소켓 통신)
  • 객체 → JSON 문자열 (웹 API)

JSON 직렬화는 보통 Jackson 같은 라이브러리가 대신 처리해준다.

자바 직렬화 방법

• 객체가 Serializable 인터페이스를 구현하면 가능
• ObjectOutputStream.writeObject()로 직렬화
• ObjectInputStream.readObject()로 역직렬화
• Serializable은 마커 인터페이스로, 직렬화 가능 여부만 표시

자바 직렬화의 문제점

자바 직렬화의 핵심 문제는 보안과 성능이다.

⚠️ 보안 문제

• readObject()는 반환 타입이 Object
• 클래스패스에 있는 거의 모든 객체를 생성 가능
• 역직렬화 과정에서 해당 객체의 모든 코드가 실행됨
• 결과적으로 공격 표면이 매우 넓어짐

⚠️ 성능 문제

• 직렬화 데이터 크기가 큼
• 역직렬화 시 의도적으로 만든 구조로 인해 엄청난 연산 비용(역직렬화 폭탄) 이 발생할 수 있음

➡️ 신뢰할 수 없는 데이터를 역직렬화하는 행위 자체가 위험하다.

어떻게 대처해야 할까?

• 가장 좋은 방법: 자바 직렬화를 사용하지 않는 것

• 대안

  • JSON, protobuf 같은 명시적 포맷 사용

• 불가피하게 역직렬화해야 한다면

  • Java 9의 ObjectInputFilter 사용
  • 허용된 클래스만 역직렬화하도록 제한

Item 86 -Serializable을 구현할지는 신중히 결정하라

Serializable을 구현하면 객체를 쉽게 직렬화할 수 있다. 하지만 이는 단기적으로는 편해 보이지만, 장기적으로 매우 큰 비용을 초래하는 결정이다.

왜 위험한가?

1️⃣ 직렬화 형태 = 공개 API

• Serializable 구현 순간

  • 클래스의 내부 구조가 외부에 고정

• private 필드도 직렬화 대상

• 한번 배포되면

  • 과거 형태와의 호환성 유지 필수

2️⃣ 클래스 수정이 거의 불가능해진다

발생 가능한 문제

• 필드 추가 / 삭제 / 타입 변경

• 역직렬화 시

  • InvalidClassException

serialVersionUID

• 직렬화 버전 식별자
• 반드시 명시

private static final long serialVersionUID = 1L;

단, UID를 고정해도

• 구조 변경까지 안전해지는 것은 아님

3️⃣ 버그와 보안 취약점의 원인

• 역직렬화는 생성자를 호출하지 않음

• 생성자에서 보장하던 불변식 무력화

• 결과

  • 잘못된 상태의 객체 생성
  • 보안 취약점 발생 가능

➡️ 역직렬화 = 숨겨진 생성자

4️⃣ 테스트 비용 폭증

클래스를 수정할 때마다

• 구버전 → 신버전
• 신버전 → 구버전

Serializable 클래스 수 × 릴리스 횟수 → 테스트 복잡도 급증

언제 사용해야 할까?

자바 직렬화를 사용하는 프레임워크용 클래스이거나, Serializable을 반드시 요구하는 컴포넌트라면 선택의 여지가 없다. 하지만 그 외의 경우라면 이득과 비용을 반드시 비교해야 한다. 값 객체나 컬렉션은 직렬화를 지원하는 경우가 많지만, 스레드 풀처럼 “동작”을 표현하는 객체는 대부분 지원하지 않는다.

Item 87 - 커스텀 직렬화 형태를 고려하라

기본 직렬화 형태가 괜찮은 경우

✔ 객체의 물리적 표현 = 논리적 내용일 때

• 물리적 표현: 코드 내부 구현 방식
• 논리적 내용: 객체가 의미하는 실제 데이터

public class Name implements Serializable {
    private final String lastName;
    private final String firstName;
    private final String middleName;
}

• 필드 자체가 의미를 직접 표현
• 내부 구현 변경 가능성 낮음 → 기본 직렬화 사용해도 문제 없음

기본 직렬화 형태가 위험한 경우

객체의 물리적 표현과 논리적 내용이 다른 경우

public final class StringList implements Serializable {
    private int size;
    private Entry head;

    private static class Entry implements Serializable {
        String data;
        Entry next;
        Entry previous;
    }
}

문제점 정리

1️⃣ 내부 구현이 공개 API로 고정됨

• 연결 리스트 → 배열로 변경 불가
• 과거 직렬화 형태를 영구 지원해야 함

2️⃣ 불필요하게 큰 직렬화 데이터

• 노드 연결 정보까지 전부 직렬화
• 네트워크/저장 비용 증가

3️⃣ 직렬화 성능 저하

• 객체 그래프를 직접 순회
• O(n) 비용 발생

4️⃣ 스택 오버플로 위험

• 재귀 순회 구조
• 노드 수 많으면 위험

Item 88 - readObject 메서드는 방어적으로 작성하라

readObject는 단순히 객체를 복원하는 메서드가 아니다. 역직렬화 과정에서 객체를 새로 만들어내는 또 하나의 생성자라고 봐야 한다.

직렬화된 데이터라고 해서 항상 정상적이라고 가정하면 안 된다. 잘못된 바이트 스트림이 전달되면, 생성자를 거치지 않고도 불변식이 깨진 객체가 만들어질 수 있다.

readObject 작성 시 기본 원칙

• readObject는 public 생성자처럼 다룬다
• 어떤 바이트 스트림이 와도 유효한 객체만 생성해야 한다
• 입력 데이터는 절대 신뢰하지 않는다

불변 클래스도 안전하지 않다

불변 클래스라도 내부에 Date 같은 가변 객체를 참조하고 있다면 위험하다. 역직렬화 과정에서 이 참조가 외부로 노출되면, final 필드라도 내부 상태가 변경될 수 있다.

생성자에서의 방어적 복사만으로는 충분하지 않으며, readObject에서도 동일한 방어가 필요하다.

반드시 지켜야 할 작성 규칙

1. 불변식 검증 역직렬화 직후 객체 상태를 검사하고, 위반 시 InvalidObjectException을 던진다.

2. 방어적 복사 클래스 내부의 모든 가변 필드는 반드시 복사본으로 교체한다.

3. 재정의 가능 메서드 호출 금지 하위 클래스가 완전히 복원되기 전에 실행될 수 있다.

Item 89 - 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라

싱글턴은 애플리케이션 전체에서 단 하나의 인스턴스만 존재함을 보장하는 패턴이다. 하지만 이 싱글턴이 Serializable을 구현하는 순간, 우리가 기대한 보장은 쉽게 깨진다.

직렬화가 싱글턴을 깨뜨리는 이유

클래스에 implements Serializable을 추가하면 역직렬화 과정에서 새로운 인스턴스가 생성된다.

• 기본 직렬화를 쓰지 않아도
• readObject를 직접 구현해도
• 심지어 불변 클래스로 만들어도

역직렬화는 항상 새로운 객체를 만들어낸다. 즉, 직렬화 가능한 싱글턴은 더 이상 싱글턴이 아니다.

readResolve로 해결할 수 있을까?

readResolve는 역직렬화로 만들어진 객체를 다른 객체로 교체할 수 있는 훅(hook)이다.

이를 이용하면:

• 역직렬화된 객체는 버리고
• 클래스 초기화 시 생성된 기존 싱글턴 인스턴스를 반환해
• 겉보기엔 싱글턴처럼 동작하게 만들 수 있다

이 방식이 바로 전통적인 직렬화 싱글턴 구현법이다.

하지만 readResolve는 매우 취약하다

문제는 readResolve가 실행되기 전이다.

• 싱글턴이 transient가 아닌 참조 필드를 가지고 있다면

• 그 필드들은 readResolve 이전에 이미 역직렬화된다

• 이 틈을 이용하면 공격자가

  • 역직렬화 중인 싱글턴 객체의 참조를 훔쳐
  • 진짜 싱글턴과 별도의 인스턴스를 확보할 수 있다

즉, 순간적으로라도 싱글턴이 두 개 존재하게 된다.

이를 막으려면:

• 모든 참조 타입 필드를 transient로 선언해야 하고
• 구현 난이도와 실수 가능성이 급격히 올라간다

가장 안전한 해법: 열거 타입

이 모든 문제를 한 번에 해결하는 방법이 있다. 바로 싱글턴을 열거 타입(enum) 으로 구현하는 것이다.

• JVM 차원에서 인스턴스 개수가 보장된다
• 직렬화/역직렬화가 자동으로 안전하게 처리된다
• 리플렉션 공격에도 강하다

public enum Elvis {
    INSTANCE;
}

이 방식은:

• 가장 간결하고
• 가장 안전하며
• 유지보수 비용도 가장 낮다

readResolve가 필요한 경우도 있다

열거 타입이 항상 가능한 것은 아니다.

• 인스턴스의 개수가 컴파일 타임에 결정되지 않는 경우
• 상속 구조를 반드시 유지해야 하는 경우

이런 상황에서는 readResolve를 사용할 수밖에 없다. 단, 모든 참조 필드를 transient로 선언해야 하며 보안과 불변식 유지에 각별히 신경 써야 한다.

정리

• 직렬화는 싱글턴을 쉽게 깨뜨린다
• readResolve는 해결책이지만 매우 취약하다
• 인스턴스 통제가 목적이라면 열거 타입이 최선의 선택이다
• 불가피할 때만 readResolve를 사용하되, 모든 참조 필드는 transient로

Item 90 - 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라

Serializable을 구현하면 객체는 생성자를 거치지 않고 생성될 수 있다. 이로 인해 불변식이 깨지거나 보안 문제가 생길 수 있는데, 이를 해결하는 방법이 직렬화 프록시 패턴이다.

직렬화의 문제점

일반적인 직렬화는 다음과 같은 위험을 가진다.

• 생성자와 유효성 검사를 우회한다
• 가짜 바이트 스트림 공격이 가능하다
• 내부 필드 탈취 위험이 있다
• 불변 클래스를 보장하기 어렵다

직렬화 프록시 패턴 개념

직렬화 프록시 패턴은 실제 객체 대신 프록시 객체를 직렬화하는 방식이다.

• 직렬화 시 writeReplace로 프록시 객체를 반환
• 바깥 클래스의 readObject는 예외를 던져 차단
• 프록시의 readResolve에서 생성자를 통해 객체 복원

이를 통해 역직렬화가 항상 정상적인 생성 경로를 따르게 된다.

장점

• 가짜 바이트 스트림 및 필드 탈취 공격 차단
• 필드를 final로 선언 가능 → 진정한 불변 클래스
• 역직렬화 시 추가 검증 코드 불필요
• 직렬화 전후 클래스가 달라도 안전하게 동작

한계

• 상속 가능한 클래스에는 적용 불가
• 객체 그래프에 순환 참조가 있으면 사용 불가
• 성능은 다소 떨어진다

핵심 정리

• 직렬화는 객체 생성 규칙을 쉽게 무너뜨린다
• 직렬화 프록시 패턴은 이를 구조적으로 차단한다
• 확장할 수 없는 클래스라면 직렬화 프록시를 우선 고려하자

참고 블로그 https://github.com/Meet-Coder-Study/book-effective-java/blob/main/12%EC%9E%A5/90_%EC%A7%81%EB%A0%AC%ED%99%94%EB%90%9C_%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4_%EB%8C%80%EC%8B%A0_%EC%A7%81%EB%A0%AC%ED%99%94_%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%82%AC%EC%9A%A9%EC%9D%84_%EA%B2%80%ED%86%A0%ED%95%98%EB%9D%BC_%ED%99%A9%EC%A4%80%ED%98%B8.md

(1) 핵심 정리

• 여러 스레드가 가변 데이터를 공유한다면 그 데이터를 읽고 쓰는 동작은 반드시 동기화 해야 한다.
• 동기화하지 않는다면 한 스레드가 수행한 변경을 다른 스레드가 보지 못할 수도 있다.
• 배타적 실행은 필요 없고 스레드끼리의 통신만 필요하다면 volatile 한정자만으로 동기화할 수 있다. 다만, 올바로 사용하기가 까다롭다.

(2) 동기화의 기능

2.1 배타적 실행

• 한 스레드가 변경하는 중이라면 다른 스레드가 보지 못하게 막는 용도를 말한다.
• 즉, Lock 을 걸어 동시에 여러 스레드가 접근하는 것을 차단한다.

2.2 스레드 사이의 안정적 통신

• 동기화 없이는 한 스레드가 만든 변화를 다른 스레드에서 확인하지 못할 수 있다.
• 즉, Lock 의 보호하에 수행된 모든 이전수정의 최종 결과를 보게 해준다.

(3) 원자적 연산

3.1 원자적 연산

• 중단될 수 없는 연산
• 여러 스레드가 동시에 접근해도 연산 결과가 깨지지 않음

Java에서의 특징:

• long, double을 제외한 기본 타입의 읽기/쓰기는 원자적

단, 원자적 = 스레드 안전 은 아니다 ❌

3.2 왜 long / double 은 원자적이지 않을까 ?

• 자바 메모리 모델(JMM)은 32비트 단위 연산을 기준으로 설계됨
• long, double은 64비트 → 32비트씩 두 번에 나눠 처리될 수 있음
• 이 과정에서 다른 스레드가 끼어들면 찢어진 값(torn read) 발생 가능

3.3 그렇다면 JVM 64-bit machine 에서도 원자적이지 않을까??

• 최신 64-bit JVM에서는 대부분 원자적으로 구현되어 있음
• 하지만 자바 언어 명세(JLS)는 이를 보장하지 않는다

따라서 명세에 의존한 안전한 코드를 작성해야 하며, volatile 또는 synchronized 사용이 정석이다.

(4) Synchronized

4.1 Synchronized 란 ?

• Java 에서는 synchronized 키워드를 통해 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장한다.

4.2 예제

• 기능
  • boolean 필드를 polling 하면서 값을 체크하는 로직으로 Thread 를 정지

• AS-IS: 무한 루프

    public class StopThread {
  
        private static boolean stopRequest;
  
        public static void main(String[] args) throws InterruptedException {
  
            Thread thread = new Thread(() -> {
                int i = 0;
                while (!stopRequest) {
                    i++;
  
                    /**
                     *  print 를 하니까 정상 종료 됨 ??
                     *  System.out.println("i: " + i + "stopRequest: " + stopRequest); 
                     */
                }
            });
  
            thread.start();
  
            TimeUnit.SECONDS.sleep(1);
            stopRequest = true;
        }
    }

• TO-BE: 1초 후 Stop

    public class StopThreadSync {
  
        private static boolean stopRequested;
  
        // write
        private static synchronized void requestStop() {
            stopRequested = true;
        }
  
        // read
        private static synchronized boolean stopRequest() {
            return stopRequested;
        }
  
        public static void main(String[] args) throws InterruptedException {
  
            Thread thread = new Thread(() -> {
                int i = 0;
  
                while (!stopRequest()) {
                    i++;
                }
            });
  
            thread.start();
  
            TimeUnit.SECONDS.sleep(1);
            requestStop();
        }
    }

• 위 예제 코드를 살펴보면 쓰기/읽기 모두 synchronized 키워드가 붙어 있음을 볼 수 있다.

• 즉, 쓰기/읽기 모두 동기화되지 않으면 동작을 보장하지 않는다.

4.3 Thread.stop()을 사용하지 않은 이유

• Thread.stop() 은 안전하지 않아, Java 11 에서 deprecated 되었다.
• 오라클 문서에서는 아래와 같이 설명하고 있다.

• Thread.stop() 을 호출하는 순간, 해당 스레드를 바라보고 있던 다른 스레드들에 대한 lock 이 해제가 된다.
• stop() 메서드가 호출 ---> ThreadDeath exception 전파 ---> 바라보고 있는 스레드의 lock 해제
• 따라서 객체의 일관성을 보장하기 어려울 뿐만 아니라, ThreadDeath 객체는 특별한 경고 없이 스레드를 죽이기 때문에 개발자가 캐치하기 어렵다.

(5) Volatile

5.1 Volatile ?

• Volatile 한정자는 배타적 수행과는 상관없지만 항상 가장 최근에 기록된 값을 읽게 됨을 보장한다.

5.2 예제

public class StopThreadVolatile {

    private static volatile boolean stopRequested;

    public static void main(String[] args) throws InterruptedException {

        Thread thread = new Thread(() -> {
            int i = 0;

            while (!stopRequested) {
                i++;
            }
        });

        thread.start();

        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

5.3 Volatile 원리

• Volatile 키워드가 붙은 데이터는 메인 메모리에 저장이된다.

• Multi-thread 환경

  • task 를 수행하는 동안 성능 향상을 위해 CPU cache 에 저장하고 활용한다.

  • 즉, 각각의 스레드의 CPU cache 에 저장된 값이 다르기 때문에 동시성 문제가 발생한다.

    
    

• 따라서 Volatile 키워드를 사용하면 해당 변수를 메인 메모리에 저장하고 읽기 때문에 항상 최근에 기록된 값을 읽을 수 있다.
• 하지만 CPU cache 보다 메인 메모리에 접근하면 비용이 더 발생한다.

5.4 Volatile 한계

• 증가 연산자(++) 와 같이 필드를 두 번 접근하는 연산은 한다면 동시성을 보장할 수 없다.
• 따라서 Volatile 키워드는 하나 이상의 스레드가 write 하는 상황에서는 동시성을 보장한다고 볼 수 없다.

👉 실무에서는 volatile를 잘 쓰지 않는다?

• volatile은 가시성만 보장하고 원자성은 보장하지 않는다
• 실무에서 동시성 이슈의 핵심은 대부분 쓰기의 원자성 문제 웹 애플리케이션 특성상 → 최신 값이 잠시 보이지 않아도 치명적이지 않은 경우가 많음
• 그래서 현업에서는 volatile보다 Atomic / Lock / Concurrent 컬렉션을 주로 사용한다
• volatile은 종료 플래그 같은 단순 상태 공유에만 제한적으로 사용됨

Item 79 - 과도한 동기화는 피하라

동기화 안에서 외부 코드(콜백)를 호출하지 마라. → 성능 저하, 예외, 교착상태 위험

• 과도한 동기화 문제

  • 성능 나빠짐
  • 교착상태(서로 기다리다 멈춤)
  • 예상 못 한 버그 발생

• synchronized 블록 안에서 클라이언트가 준 코드(람다, 콜백)를 실행하지 마라

→ 이걸 제어권을 클라이언트에 넘긴다고 함

왜 위험한가?

1️⃣ ConcurrentModificationException

• 동기화된 상태에서
• 관찰자가 자기 자신을 제거
• → 순회 중 컬렉션 수정 → 예외 발생

2️⃣ 교착상태 (Deadlock)

• 메인 스레드가 락 잡고 있음
• 콜백에서 다른 스레드가 락 요청
• 서로 기다리다 멈춤

문제 원인

• 동기화 영역 안에서
• 언제 끝날지 모르는 외부 코드 실행
• 이런 메서드를 열린 호출(Open Call) 이라고 함

해결 방법

방법 1. 스냅샷 떠서 밖에서 실행

synchronized (observers) {
    snapshot = new ArrayList<>(observers);
}
for (SetObserver<E> observer : snapshot)
    observer.added(this, element);

방법 2. CopyOnWriteArrayList 사용

• 동기화 문제 자동 해결
• 관찰자 패턴에 특히 잘 맞음

정리

• 동기화 블록 안에서는 최소한의 일만
• 계산, 콜백, IO → ❌ 밖으로 빼기

Item 80 - 스레드보다는 실행자, 태스크, 스트림을 애용하라

Effective Java 초판에서는 작업 큐(work queue)를 직접 구현하는 방법을 소개했지만, 이는 코드가 복잡하고 동시성 오류에 취약했다. 스레드 생성과 관리, 예외 처리까지 모두 개발자가 책임져야 했기 때문이다.

이후 자바에는 java.util.concurrent 패키지, 즉 Executor Framework가 도입되었다. Executor를 사용하면 스레드나 큐를 직접 다룰 필요 없이 작업 실행을 간단히 처리할 수 있다.

ExecutorService exec = Executors.newSingleThreadExecutor();
exec.execute(runnable);
exec.shutdown();

ExecutorService는 작업 실행뿐 아니라 작업 완료 대기, 결과 수집, 주기적 실행 등 다양한 기능을 제공한다. 작은 규모의 프로그램에는 newCachedThreadPool이 적합하며, 기존 스레드를 재사용하고 필요 시 새 스레드를 생성한다. 반면 대규모 애플리케이션에서는 스레드 수가 고정된 newFixedThreadPool을 사용하는 것이 안전하다.

저자가 스레드보다 Executor 사용을 권장하는 이유는, Thread가 작업의 단위와 실행 메커니즘을 함께 가지고 있기 때문이다. Executor Framework에서는 이 둘이 분리된다. 작업의 단위는 태스크이며, Runnable과 Callable이 이에 해당한다. 덕분에 실행 정책을 바꾸더라도 작업 코드는 영향을 받지 않는다.

자바 7부터는 ForkJoinPool을 통해 fork-join 작업을 지원하며, 이를 기반으로 한 parallel stream은 병렬 처리를 더 쉽고 효율적으로 만들어준다.

Item 81 - wait와 notify보다는 동시성 유틸리티를 사용하라

자바는 오래전부터 wait, notify, notifyAll을 통해 스레드 간 협력을 지원해왔다. 하지만 Java 5 이후 도입된 고수준 동시성 유틸리티 덕분에, 이 저수준 메서드들을 직접 사용할 이유는 점점 줄어들었다.

wait / notify란?

• wait()

  • 고유 락을 반납하고 스레드를 대기 상태로 만듦
  • 반드시 synchronized 블록 내부에서 호출해야 함

• notify()

  • 대기 중인 스레드 하나를 임의로 깨움

• notifyAll()

  • 대기 중인 모든 스레드를 깨움

👉 세 메서드 모두 Object에 정의되어 있다.

wait 사용 시 반드시 지켜야 할 규칙

synchronized (obj) {
    while (condition) {
        obj.wait();
    }
}

• wait는 조건 검사 반복문(wait loop) 안에서만 사용
• 깨어난 뒤에도 조건을 다시 검사해야 함
• 그렇지 않으면 락이 보호하는 불변식이 깨질 수 있음

조건이 충족되지 않았는데 깨어나는 경우

• 다른 스레드가 상태를 변경한 경우
• 실수 또는 악의적인 notify 호출
• notifyAll로 모든 스레드가 깨어난 경우
• 허위 각성(spurious wakeup)

➡️ 이 모든 상황을 고려해야 하므로 구현 난이도가 매우 높다.

synchronized의 한계

• 메서드 진입·탈출 시 오버헤드 발생
• 읽기 전용 작업도 락 때문에 대기
• 락 경쟁이 심해질수록 성능 저하

👉 단순히 synchronized 키워드 하나 차이로도 성능이 크게 달라질 수 있다.

동시성 유틸리티가 필요한 이유

Java 5부터 제공되는 java.util.concurrent는 안전성 + 성능 + 가독성을 모두 개선한다.

주요 동시성 유틸리티 분류

1️⃣ 실행자 프레임워크

• ExecutorService, Executors
• 스레드 생성과 관리 책임을 프레임워크에 위임

2️⃣ 동시성 컬렉션

• ConcurrentHashMap, ConcurrentLinkedQueue
• 외부 락 없이 높은 동시성 제공
• Collections.synchronizedMap보다 성능 우수

3️⃣ 동기화 장치(Synchronizer)

• CountDownLatch : 특정 조건까지 대기
• Semaphore : 자원 접근 개수 제한
• 의도가 명확하고 사용이 안전함

결론

• wait와 notify는 저수준 도구로 사용이 어렵고 위험하다
• synchronized 기반 설계는 성능과 확장성에 한계가 있다
• 특별한 이유가 없다면 👉 동시성 유틸리티를 우선적으로 사용하자

Item 82. 스레드 안전성 수준을 문서화하라

멀티스레드 환경에서 여러 스레드가 동시에 메서드를 호출할 때의 동작 방식은 클래스와 클라이언트 사이의 중요한 계약이다. 하지만 API 문서에 스레드 안전성에 대한 설명이 없다면, 사용자는 스스로 가정을 할 수밖에 없고 이는 심각한 오류로 이어질 수 있다. 동기화가 부족하면 버그가 발생하고, 과도하면 성능이 급격히 저하된다.

따라서 멀티스레드 환경에서도 API를 안전하게 사용하려면, 클래스가 지원하는 스레드 안전성 수준을 반드시 문서로 명확히 밝혀야 한다. 단순히 메서드에 synchronized를 붙였다고 해서 스레드 안전하다고 판단해서는 안 된다.

스레드 안전성 수준 분류

불변 (Immutable)

• 인스턴스 상태가 절대 변하지 않음
• 외부 동기화 불필요
• 예: String, Long

무조건적 스레드 안전

• 내부 동기화로 항상 안전
• 외부 동기화 필요 없음
• 예: AtomicLong, ConcurrentHashMap

조건부 스레드 안전

• 기본적으로 안전
• 일부 메서드는 외부 동기화 필요
• 예: Collections.synchronizedList

스레드 안전하지 않음

• 동시 사용 시 클라이언트가 직접 동기화
• 예: ArrayList, HashMap

스레드 적대적

• 외부 동기화로도 안전하지 않음
• 주로 정적 필드를 동기화 없이 수정
• 예: nextSerialNumber++ 같은 구현

정리

• 모든 클래스는 자신의 스레드 안전성 수준을 문서화해야 한다
• 스레드 안전성은 암묵적인 추측에 맡기면 안 된다
• synchronized는 문서화를 대신할 수 없다

Item 83 - 지연 초기화는 신중히 사용하라

1. 지연 초기화란?

• 값이 처음 필요할 때 초기화
• 안 쓰이면 아예 초기화 안 함

2. 언제 쓰나?

• 해당 클래스의 인스턴스 중 그 필드를 사용하는 인스턴스의 비율이 낮고, 그 필드를 초기화하는 비용이 클 때 (hashCode)
• 지연 초기화 적용 전후의 성능을 측정

3. 단점

• 생성은 빨라짐
• 대신 접근할 때 비용 증가
• 멀티 스레드면 동기화 필수

4. 초기화 방법 한눈에 보기

a. 일반 초기화

private final FieldType field = compute();

• 가장 안전하고 단순

b. synchronized 접근자

private FieldType field;
private synchronized FieldType get() {
  if (field == null) field = compute();
  return field;
}

• 초기화 순환 문제 해결
• 느림

  c. 정적 필드: 홀더 클래스 (베스트)

private static class Holder {
  static final FieldType field = compute();
}
static FieldType get() { return Holder.field; }

• 빠르고 안전
• 정적 필드 지연 초기화의 정석

d. 인스턴스 필드 + 성능 중요 → 이중 검사

private volatile FieldType field;
FieldType get() {
  FieldType r = field;
  if (r != null) return r;
  synchronized(this) {
    if (field == null) field = compute();
    return field;
  }
}

• 초기화 후엔 락 안 씀
• 반드시 volatile

  e. 단일 검사 (중복 초기화 OK)

private volatile FieldType field;
FieldType get() {
  if (field == null)
    field = compute();
  return field;
}

• 여러 번 초기화돼도 상관없을 때
• 드문 케이스

Item 84 - 프로그램의 동작을 스레드 스케줄러에 기대지 말라

• 멀티스레드 환경에서 어떤 스레드를 얼마나 실행할지는 OS 스레드 스케줄러가 결정한다.

• 스케줄링 정책은 운영체제마다 다르며, 정확성이나 성능이 스케줄러에 의존하는 프로그램은 이식성이 떨어진다.

• 좋은 멀티스레드 프로그램의 핵심은 실행 가능한 스레드 수를 프로세서 수보다 과도하게 늘리지 않는 것이다.

• 이를 위해 스레드는

  • 할 일이 없으면 대기 상태로 전환되어야 하며
  • 당장 처리할 작업이 없으면 실행되면 안 된다.

바쁜 대기(Busy Waiting)

• 바쁜 대기란

  • 공유 자원의 상태가 바뀌었는지 쉬지 않고 반복 검사하는 방식

• 문제점

  • CPU를 소모하면서 아무 일도 하지 않음
  • 시스템 전체 성능 저하

• 스레드는 조건이 만족될 때까지 기다려야지, 확인해서는 안 된다.

Thread.yield

• Thread.yield()

  • 현재 스레드가 다른 스레드에게 실행 기회를 양보
  • 단, 실제 동작은 전적으로 스케줄러 판단에 달림

• 문제점

  • 효과가 플랫폼·환경마다 다름
  • 테스트 불가능
  • 증상이 완화될 수는 있으나 근본 해결책이 아님

➡️ 스레드가 제대로 실행되지 않는다고 yield로 고치려는 유혹을 반드시 피해야 한다.

올바른 접근 방식

• 스케줄러에 기대지 말고

  • 프로그램 구조를 개선해
  • 동시에 실행 가능한 스레드 수 자체를 줄여라

• 스레드는

  • 작업이 있을 때만 실행
  • 없으면 대기(wait / blocking) 상태 유지

접근법

처음에 봤을 때

1. 모든 칸을 돌면서 동시에 visited[][] 갱신하면서, 국경선 열지 판단하는 것
2. 한번 열면 다 합쳐서 sum / N 해서 갱신하는 것
3. 차이가 L~R일 때까지 위 과정을 반복하는 것.. 이라고 생각하고 코드를 짰다.

잘못된 점

처음에 코드를 구현했을 때 잘못된 점은

• visited를 한 번만 만들고 끝냈다는 거였다 👉 이 문제는 하루마다 다시 방문 가능하기 때문에 매 day마다 초기화해야한다.

정리해보자면

1. main에서 모든 칸을 순회한다. 방문하지 않은 칸이라면 isOpen을 통해 bfs 4방향 탐색을 진행한다. 1-1. isOpen이 true을 반환하면 인구이동이 있었다는 것, false면 없었다는 것이기 때문에 해당 반복문을 종료한다.
2. isOpen에서는 기존에 했었던 bfs 4방향 탐색을 돌리는데 ArrayList<int[]> union = new ArrayList<>();를 선언해서 연합 지역을 관리 및 계산해야한다는 게 핵심이다. 2-1. 또한 sum을 통해서 국경선이 열렸을 때 해당 좌표의 값을 sum에 계속해서 더해야 한다.
3. 4방향 탐색을 돌리면서 Math.abs()를 통해 차이를 구하고 이 차이가 L 이상 R 이하라면 visited, q, union, sum을 갱신한다.
4. 모든 탐색이 끝났다면 union을 통해 인구 이동을 시키면 된다. 4-1. 연합이 2 이상이면 avg를 만들어서 모두 평균만큼 인구를 이동시킨다.

정답 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.LinkedList;
import java.util.Queue;
import java.util.StringTokenizer;

public class BOJ_16234_인구이동_G4 {
    static int N, L, R;
    static int[][] arr;
    static boolean[][] visited;
    static int[] dx = {1, -1, 0, 0};
    static int[] dy = {0, 0, 1, -1};

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        L = Integer.parseInt(st.nextToken());
        R = Integer.parseInt(st.nextToken());
        arr = new int[N][N];
        visited = new boolean[N][N];

        for (int i = 0; i < N; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < N; j++) {
                arr[i][j] = Integer.parseInt(st.nextToken());
            }
        }

        int day = 0;

        while (true) {
            visited = new boolean[N][N];
            boolean moved = false;

            for (int i = 0; i < N; i++) {
                for (int j = 0; j < N; j++) {
                    if (!visited[i][j]) {
                        if (isOpen(i, j)) moved = true;
                    }
                }
            }

            if (!moved) break;
            day++;
        }

        System.out.println(day);
    }

    public static boolean isOpen(int x, int y) {
        // 여기선 bfs로 4방향을 탐색해야함
        Queue<int[]> q = new LinkedList<>();
        ArrayList<int[]> union = new ArrayList<>();

        q.add(new int[]{x, y});
        union.add(new int[]{x, y});
        visited[x][y] = true;

        int sum = arr[x][y];

        while (!q.isEmpty()) {
            int[] cur = q.poll();
            int cx = cur[0];
            int cy = cur[1];

            for (int d = 0; d < 4; d++) {
                int nx = cx + dx[d];
                int ny = cy + dy[d];

                if (nx < 0 || ny < 0 || nx >= N || ny >= N) continue;
                if (visited[nx][ny]) continue;

                int diff = Math.abs(arr[cx][cy] - arr[nx][ny]);
                if (diff >= L && diff <= R) {
                    visited[nx][ny] = true;
                    q.add(new int[]{nx, ny});
                    union.add(new int[]{nx, ny});
                    sum += arr[nx][ny];
                }
            }
        }

        // 연합이 2개 이상이면 인구 이동 발생
        if (union.size() > 1) {
            int avg = sum / union.size();
            for (int[] p : union) {
                arr[p[0]][p[1]] = avg;
            }
            return true;
        }
        return false;
    }
}

예외는 오직 예외 상황에서만 써야 한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다. 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다.

    try {
        int i = 0;
        while(true) {
            range[i++].climb()
        }
    } catch (ArrayIndexOutOfBoundsException e) {
}

해당 코드의 문제점

• 해당 코드는 무슨일을 하는 코드인지 알 수가 없다.
• 무한루프를 돌다가 배열의 끝에 도달해 ArrayIndexOutOfBoundsException이 발생해야 끝이난다.

첫 번째 예시에서는 왜 Exception을 던져줬을까? 바로 JVM에서 배열에 접근할 때마다 경계를 넘지 않는지 검사하는데, 일반적인 반복문도 배열 경계에 도달하면 종료된다는 희망에 던져졌을 것이라고, 책에서 말해준다. 하지만, 책에서는 세가지 면에서 잘못된 추론이라고 한다.

• 예외는 예외 상황에 쓸 용도로 설계되었으므로 예외에서는 최적화에 별로 신경 쓰지 않았을 가능성이 크다.
• 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한 된다.
• 배열을 순회하는 표준 관용구는 앞서 걱정한 중복 검사를 수행하지 않는다. JVM이 알아서 최적화해 없애준다.

해당 코드를 다시 리팩토링 한다면,

for (Mountain m : range) {
    m.climb();
}

아래와 같은 장점을 가지게 된다.

• 무슨일을 하는 코드인지 직관적이게 확인할 수 있다.
• forLoop가 끝나면 해당 코드는 끝나기 때문에 불필요한 Exception을 던질 필요가 없다.

요번 아이템은 바로 장점 중에 두번째에 해당하는 Exception에 올바른 쓰임에 대해 2가지 항목으로 정리하며 끝내고 있다.

• 예외는 오직 예외 상황에서만 써야 한다. 절대로 첫번째 예시처럼, 일상적인 제어 흐름용으로 쓰여선 안된다.
• 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야한다.

아이템 70 - 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용해라

1. 검사 예외(Checked Exception)

• 반드시 예외처리를 해야한다.
  • throw, try-catch를 이용하여 예외처리를 강제화한다.
  • 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용해야한다.
• 복구에 필요한 정보를 알려주는 메소드를 정의하는게 좋다.
  • 예를 들어 물건을 구입하는데 잔고가 부족하다면, 잔고가 얼마나 부족한지 알려줘야한다.

2. 비검사 예외 (Unchecked Exception)

• 종류
  • 런타임 예외
  • 에러
• 프로그램에서 잡을 필요가 없다.
  • 복구가 불가능하거나 더 실행해봤자 의미가 없기 때문 → 예외처리를 강제화하지 않는다.
  • 프로그래밍 오류를 나타낼 때에는 비검사 예외를 사용해야한다.
• 우리가 구현하는 비검사 예외는 모두 RuntimeException을 상속 받아야한다.
  • Error는 상속 받지 말아야할 뿐만아니라, 직접 throw 하는 일도 없어야한다. (AssertionError 제외)
  • Exception, RuntimeException, Error를 상속하지 않은 throwble은 만들지 말자
    • 이로운 것이 없다.
    • API 사용자에게 혼동을 줄 수도 있다.

뭘 사용할지 모르겠다면 아마 비검사 예외를 사용하는 것이 더 나을 것이다 (아이템 71 참고)

3. 결론

• 복구해야하는 상황이면 → 검사 예외
• 프로그래밍 시 나타나는 오류라면 → 런타임 예외
• 확실하지 않은 예외라면 → 비검사 예외
• Error 클래스를 상속해 하위 클래스를 만드는 일 → 하지말자
• Exception, RuntimeException, Error를 상속하지 않은 throwble → 만들지 말자

아이템 71 - 필요없는 검사 예외 사용은 피하라

1. 검사 예외 (Checked Exception)

• 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높힐 수 있다.

• 물론, 과하게 사용하면 오히려 쓰기 불편한 APi 가 될 수 있다.

  • (1) try/catch 블록, throws

      public class Example {
    
          public void example() {
    
              try {
    
              } catch (IOException e) {
    
              } 
    
              try {
    
              } catch (IOException e) {
    
              } 
    
              try {
    
              } catch (IOException e) {
    
              } 
    
              ...
          }
      }     

  • (2) Java 8, Stream

      public class Test {
    
          public static void main(String[] args) {
              String[] names = {"자바", "파이썬", "고", "Trigger"};
    
              Arrays.stream(names)
                      .map(Example::verifyName)   // <--- compile error
                      .collect(toSet());           
          }
    
          public static class Example {
    
              public String verifyName(String name) throws Exception {
                  if (name == "trigger") {
                      throw new Exception("fail");
                  }
                  return name;
              }
          }    
    
      }

2. 검사 예외를 회피하는 방법

(1) Optional

• 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 된다.

• 예시

  • AS-IS

      Long userId = 1L;
      try {
         User user = userService.findUserById(userId); 
      } catch (Exception e) {
          log.error("fail to find user, userId: {}", userId)
          user = new User(userId);
      }

  • TO-BE

      Long userId = 1L;
    
      User user = repository.findUserById(userId)
                      .orElseGet(() -> new User(userId)); 

(2) 메서드를 두 개로 분할하여 비검사 예외로 바꾼다.

• 이 방식에서 첫 번째 메서드는 예외가 던져질지 여부를 boolean 값으로 반환한다.

• 예시

  • AS-IS

      try {
          obj.action(args);
      } catch (TheCheckedException e) {
          ... // 예외 상황에 대처한다.
      }

  • TO-BE

      if(obj.actionPermitted(args)){
          obj.action(args);
      } else {
          ... // 예외 상황에 대처한다.
      }

• 하지만 외부 요안에 의하여 상태가 변할 수 있다면, 이 방법은 적절치 않다.

• 꼭 필요한 곳에만 사용한다면, 검사 예외는 프로그램의 안정성을 높여준다. 하지만 남용하면 쓰기 어려운 API 를 낳는다.

• 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.
• 복구가 가능하고 호출자가 그 처리를 해주길 바란다면, 우선 옵셔널을 반환해도 될지 고민하자.
• 옵셔널만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.

아이템 72 - 표준 예외를 사용하라.

자바 라이브러리는 대부분 API 에서 쓰기에 충분한 수의 예외를 제공한다. 표준 예외를 재사용하면 얻는 게 많다.

1. API가 다른 사람이 익히고 사용하기 쉬워진다는 것
2. API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다는 장점
3. 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다.

자주 재사용하는 예외

• IllegalArgumentException

  호출자가 인수로 부적절한 값을 넘길 때 던지는 예외

예시

  public class MainRunner {

      List<Integer> list = new ArrayList<>();

      public void positiveAdd(Integer number) {
          if (number < 0) {
              throw new IllegalArgumentException("음수값은 허용하지 않음");
          }
          list.add(number);
      }

      public static void main(String[] args) {
          MainRunner mainRunner = new MainRunner();
          mainRunner.positiveAdd(-1);
      }
  }

• IllegalStateException

  대상 객체의 상태가 호출된 메서드를 수행하기에 적합하지 않을 때 주로 사용한다.

예시

  public class MainRunner {

      List<Integer> list = new ArrayList<>();

      public void evenIndexAdd(Integer number){
          if(list.size()%2 != 0){
              throw new IllegalStateException("짝수 인덱스에 들어갈 준비가 되지 않음");
          }
          list.add(number);
      }

      public static void main(String[] args) {
          MainRunner mainRunner = new MainRunner();
          mainRunner.evenIndexAdd(0);
          mainRunner.evenIndexAdd(1);
      }
  }

• NullPointerException

  null 값을 허용하지 않는 메서드에 null 을 건네는 경우 사용한다.

예시

  public class MainRunner {

      List<Integer> list = new ArrayList<>();

      public void add(Integer number){
          if(Objects.isNull(number)){
              throw new NullPointerException("값이 null 입니다.");
          }
          list.add(number);
      }

      public static void main(String[] args) {
          MainRunner mainRunner = new MainRunner();
          mainRunner.add(null);
      }
  }

• IndexOutOfBoundsException

  시퀀스의 허용범위를 넘는 값을 건널때 사용한다.

예시

  public class MainRunner {

      List<Integer> list = new ArrayList<>();

      public void add(Integer number){
          if(list.size()>1){
              throw new IndexOutOfBoundsException("요소를 3개 이상 설정 할 수 없습니다.");
          }
          list.add(number);
      }

      public static void main(String[] args) {
          MainRunner mainRunner = new MainRunner();
          mainRunner.add(1);
          mainRunner.add(2);
          mainRunner.add(3);
      }
  }

• ConcurrentModificationException

  단일 스레드에서 사용하려고 설계한 객체를 여러 스레드가 동시에 수정하려 할 때 사용함.

• UnsupportedOperationException

  클라이언트가 요청한 동작을 대상 객체가 지원하지 않을 때 던진다. 대부분 객체는 자신이 정의한 메서드를 모두 지원하니 흔히 쓰이는 예외는 아니다.

아이템 73 - 추상화 수준에 맞는 예외를 던져라

예외 변역이란?

• 상위 계층에서 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던지는것

• try {
    ...
  } catch (LowerLevelException e) {
    throw new HigherLevelException(...);
  }

• /**
  * ...
  * @throws IndexOutOfBoundsException ...
  */
  public E get(int index) {
      try {
          return listIterator(index).next();
      } catch (NoSuchElementException exc) {
          throw new IndexOutOfBoundsException("Index: " + index);
      }
  }

예외 번역을 하지 않으면?

• 수행하려는 일과 관련없어 보이는 예외가 튀어나와 프로그래머를 당황시킨다
• 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킨다
• 다음 릴리즈에서 구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수 있다

예외 연쇄를 사용해서 번역할 수도 있다.

• 예외 연쇄 : 문제의 근본 원인인 저수준 예외를 고수준 예외에 실어 보내는 방식

• Throwable.getCause()를 통해 언제든 저수준 예외를 꺼내볼 수 있다

• 저수준 예외가 디버깅에 도움을 줄 수 있다

• try {
    ...
  } catch (LowerLevelException cause) {
    throw new HigherLevelException(cause);
  }

  class HigherLevelException extends Exception {
    HigherLevelException(Throwable cause) {
      super(cause);
    }
  }

하지만 예외 번역을 남용해서는 안된다.

• 가능하다면 저수준 메서드가 반드시 성공하도록 하여 아래 계층에서는 예외가 발생하지 않도록 하는 것이 최선이다

  • 어떻게? 상위 계층 메서드의 매개변수 값을 하위 계층 메서드로 건네기 전에 미리 검사해서 예외가 발생할 만한 매개변수를 하위 계층 메서드로 전달되지 않게끔 해서.

  • public void function1(...) {
      //미리 검사
      function2(...);
    }

• 하위 계층에서의 예외를 피할 수 없다면?

  • 상위 계층에서 조용히 처리하여 예외를 API 클라이언트에까지 전파하지 않고 로그를 남길 수도 있다

  • 이렇게 하면 클라이언트 코드에 문제를 전파하지 않음 + 로그분석을 통해 조치를 취할 수 있음

  • public void function1(...) {
      ...
      try {
        function2(...);
      } catch(...) {
        //로그 기록
      }
    }

아이템 74 - 메서드가 던지는 모든 예외를 문서화하라

체크 예외는 항상 개별적으로 선언하라, 또한 어떠한 조건에서 예외가 발생하는지 기재하라

• javaDoc의 @throws 태그를 달아서 예외가 발생하는 조건을 설명하면 된다.
• 여러 예외를 하나의 슈퍼 클래스 예외로 선언하지 마라. (Exception, Throwable 이 가장 대표적임)
• 단 하나의 예외 사항이 있다면, main 함수에서 던지는 Exception 이나 Throwable 이 있다.

언체크 예외는 다룰 수가 없다. 어떻게 문서화 해야할까?

• 잘 문서화된 언체크 예외는 사전조건으로 설명하라.(아이템 56번)
• 아이템 56번에 따르면, 모든 public 메서드는 사전조건(precondtions)를 설명해야 한다.
• 특히, 인터페이스의 메서드가 던질 수 있는 언체크 예외를 문서화하는 것이 중요하다.

Javadoc의 @throws 태그를 사용하여 체크 예외에 대한 설명을 하라, 다만 언체크 예외에 throws 키워드를 사용하면 안된다.

• 만약 언체크 예외를 Javadoc의 @throws 태그로 명시하였다면, 예외가 체크되지 않았다는 강력한 시각적 암시를 나타낸다.

하나의 클래스의 여러 메서드가 던지는 예외가 같은 이유로 설명된다면, 클래스 수준의 문서화 주석을 남겨라

• 가장 대표적인 예는 NullpointerException 일 것이다.
• 예를 들어, "이 클래스의 모든 메서드는 NullPointerException을 던질 수 있음" 이라고 설명하면 된다.

아이템 75 - 예외의 상세 메시지에 실패 관련 정보를 담으라

• 실패 순간을 정확히 포착하기위해선 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메세지에 담아야 한다.

예시를 살펴보자.

잘못된 예외 메세지

public static void main(String[] args) {
    Member member = Member.create("kjj", "재준", 99);
}

누군가 만든 Member.create() 호출하여 새로운 회원을 생성하고자 했을때

만약 다음과 같은 메세지를 만나게 된다면 해당 메서드를 사용한 클라이언트는 왜 오류가나는지 전혀 알수없다.

결국에는 소스코드를 타고들어가서 예외를 발생시키는 원인을 분석하게된다.

이러한 행동은 결국 나의 리소스를 낭비하게 됩니다.

잘 설계된 예외 메세지

public static void main(String[] args) {
    Member member = Member.create("kjj", "재준", 99);
}

Member.create() 을 호출했을때 예외가 발생한다면

이처럼 메세지, 대상필드, 입력값 등을 포함하여 예외를 발생시킨다면 다음과 같은 장점이 존재합니다.

1. 왜 예외가 발생하는지 코드를 살펴보지 않아도 알 수 있음
2. 비지니스 로직 파악이 쉬움(객체의 불변식을 한눈에 볼 수 있음)

아이템 76 - 가능한 한 실패 원자적으로 만들라

실패 원자적 (failure-atomic)인 메서드

• 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 하는 메서드

  어떻게 실패 원자적인 메서드를 만들까?

  1. 불변 객체로 만들기

• 불변 객체는 태생적으로 실패 원자적이다.
• 메서드가 실패하면 새로운 객체가 만들어지지는 않을 수 있으나 기존 객체가 불완전한 상태에 빠지는 일은 결코 없다. 불변 객체의 상태는 생성 시점에 고정되어 절대 변하지 않기 때문이다!

2. 가변 객체의 메서드의 경우 작업 수행 전 매개변수의 유효성을 검사하기

• 객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성 대부분을 걸러낼 수 있는 방법이다.

  public Object pop() {
    if (size == 0)
        throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; // 다 쓴 참조 해제
    return result;
  }

• 실패 가능성이 있는 모든 코드를, 객체의 상태를 바꾸는 코드보다 앞에 배치하기

  • 계산을 수행해보기 전에는 인수의 유효성을 검사해볼 수 없을 때 앞의 방식에서 덧붙여 쓸 수 있는 기법

3. 객체의 임시 복사본에서 작업을 수행한 다음, 작업이 성공적으로 완료되면 원래 객체와 교체하는 것

• 데이터를 임시 자료구조에 저장해 작업하는 게 더 빠를 때 적용하기 좋은 방식
  • 예를 들어, 어떤 정렬 메서드에서는 정렬을 수행하기 전에 입력 리스트의 원소들을 배열로 옮겨 담는다. 배열을 사용하면 정렬 알고리즘의 반복문에서 원소들에 훨씬 빠르게 접근할 수 있기 때문이다.
  • 물론, 정렬에 실패하더라도 입력 리스트는 변하지 않는 효과를 덤으로 얻게 된다.

4. 작업 도중 발생하는 실패를 가로채는 복구 코드를 작성하여 작업 전 상태로 되돌리는 방법

• 주로 (디스크 기반의) 내구성(durability)을 보장해야 하는 자료구조에 쓰이는데, 자주 쓰이는 방법은 아니다.

실패 원자성은 항상 달성할 수 있을까?

실패 원자성은 일반적으로 권장되는 덕목이지만 항상 달성할 수 있는 것은 아니다. 예를 들어 두 스레드가 동기화 없이 같은 객체를 동시에 수정한다면 그 객체의 일관성이 깨질 수 있다.

따라서 ConcurrentModificationException을 잡아냈다고 해서 그 객체가 여전히 쓸 수 있는 상태라고 가정해서는 안 된다.

한편, Error는 복구할 수 없으므로 AssertionError에 대해서는 실패 원자적으로 만들려는 시도조차 할 필요가 없다.

실패 원자성을 항상 보장해야 할까?

실패 원자적으로 만들 수 있더라도 항상 그리 해야 하는건 아니다. 실패 원자성을 달성하기 위한 비용이나 복잡도가 아주 큰 연산도 있기 때문이다. 그래도 문제가 무엇인지 알고 나면 실패 원자성을 공짜로 얻을 수 있는 경우가 더 많다.

메서드 명세에 기술한 예외라면 설혹 예외가 발생하더라도 객체의 상태는 메서드 호출 전과 똑같이 유지돼야 하는 것이 기본 규칙이다. 이 규칙을 지키지 못한다면 실패 시의 객체 상태를 API 설명에 명시해야 한다. 이것이 이상적이나, 아쉽게도 지금의 API 문서 상당 부분이 잘 지키지 않고 있다.

아이템 77 - 예외를 무시하지 말라

예외를 무시하지 말라

API 설계자가 메서드 선언에 예외를 명시하는 까닭은 그 메서드를 사용할 때 적절한 조치를 취해달라고 말하는 것 → 예외를 무시하는 것은 화재 경보를 무시하는 수준을 넘어 아예 꺼버리는 것고 같은 것이다 → 예외를 절!대! 무시하지 말자 = try-catch의 catch 블럭을 비워두지 말자!

예외를 무시하는 하면?

예외를 무시하면 그 프로그램은 오류를 내재한 채 동작하게 된다 어느 순간 문제의 원인과 관계 없는 곳에서 프로그램이 죽을 수도 있다

예외를 무시할 수 있는 경우

FileInputStream은 읽기 전용 스트림이고, 이를 닫을 때 예외가 발생하면 어떤 조치를 해줄 필요가 없다 이런 경우 catch 블록안에 주석으로 이유를 남기고, 예외 변수를 ignored로 표기한다

Future<Integer> f = exec.submit(planarMap::chromaticNumber);
int numColors = 4;  // 기본값
try {
    numColors = f.get(1L, TimeUnit.SECONDS);
} catch(TimeoutException | ExecutionException ignored) {
    // 기본값을 사용한다(색상 수를 최소화하면 좋지만, 필수는 아니다)
}

정리

검사 예외든, 비검사 예외든 예외를 무시하지 말자! 예외를 적절히 처리해서 오류를 피하거나, 최소한 무시하지 않고 바깥으로 전파되게라도 두어 디버깅 정보를 남긴 채 프로그램이 신속히 중단되게 하라.

https://github.com/Meet-Coder-Study/book-effective-java

Assembled by GimunLee (2019-10-28)

Goal

• Garbage Collection의 역할에 대해 설명할 수 있다.
• Garbage Collection의 메모리 해제 과정을 3단계로 설명할 수 있다.
• Generational Gabage Collection에 대해 설명할 수 있다.
• Generational Garbage Collection 과정에 대해 설명할 수 있다.
• Minor GC와 Major GC의 차이점에 대해 설명할 수 있다.

Abstract

C/C++ 프로그래밍을 할 때 메모리 누수(Memory Leak)를 막기 위해 객체를 생성한 후 사용자하지 않는 객체의 메모리를 프로그래머가 직접 해제 해주어야 했습니다. 하지만, JAVA에서는 JVM(Java Virtual Machine)이 구성된 JRE(Java Runtime Environment)가 제공되며, 그 구성 요소 중 하나인 Garbage Collection(이하 GC)이 자동으로 사용하지 않는 객체를 파괴합니다.

GC에 대해서 알아보기 전에 'stop-the-world'라는 용어를 알아야합니다. 'stop-the-world'란, GC를 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 것입니다. 어떤 GC 알고리즘을 사용하더라도 'stop-the-world'는 발생하게 되는데, 대개의 경우 GC 튜닝은 이 'stop-the-world' 시간을 줄이는 것이라고 합니다.

GC를 해도 더이상 사용 가능한 메모리 영역이 없는데 계속 메모리를 할당하려고 하면, OutOfMemoryError가 발생하여 WAS가 다운될 수도 있습니다. 행(Hang) 즉, 서버가 요청을 처리 못하고 있는 상태가 됩니다.

따라서 규모 있는 JAVA 애플리케이션을 효율적으로 개발하기 위해서는 GC에 대해 잘 알아야한다고 합니다. 이번에는 GC에 대해 간단하게 알아보겠습니다.

Garbage Collection

C/C++ 언어와 달리 자바는 개발자가 명시적으로 객체를 해제할 필요가 없습니다. 자바 언어의 큰 장점이기도 합니다. 사용하지 않는 객체는 메모리에서 삭제하는 작업을 GC라고 부르며 JVM에서 GC를 수행합니다.

기본적으로 JVM의 메모리는 총 5가지 영역(class, stack, heap, native method, PC)으로 나뉘는데, GC는 힙 메모리만 다룹니다.

일반적으로 다음과 같은 경우에 GC의 대상이 됩니다.

1. 객체가 NULL인 경우 (ex. String str = null)
2. 블럭 실행 종료 후, 블럭 안에서 생성된 객체
3. 부모 객체가 NULL인 경우, 포함하는 자식 객체

GC는 Weak Generational Hypothesis 에 기반합니다. 우선 GC의 메모리 해제 과정에 대해 살펴보겠습니다.

GC의 메모리 해제 과정

1. Marking

   

   • 프로세스는 마킹을 호출합니다. 이것은 GC가 메모리가 사용되는지 아닌지를 찾아냅니다. 참조되는 객체는 파란색으로, 참조되지 않는 객체는 주황색으로 보여집니다. 모든 오브젝트는 마킹 단계에서 결정을 위해 스캔되어집니다. 모든 오브젝트를 스캔하기 때문에 매우 많은 시간을 소모하게 됩니다.

2. Normal Deletion

   

   • 참조되지 않는 객체를 제거하고, 메모리를 반환합니다. 메모리 Allocator는 반환되어 비어진 블럭의 참조 위치를 저장해 두었다고 새로운 오브젝트가 선언되면 할당되도록 합니다.

3. Compacting

   

   • 퍼포먼스를 향상시키기 위해, 참조되지 않는 객체를 제거하고 또한 남은 참조되어지는 객체들을 묶습니다. 이들을 묶음으로서 공간이 생기므로 새로운 메모리 할당 시에 더 쉽고 빠르게 진행 할 수 있습니다.

Generational Garbage Collection 배경

위와 같이 모든 객체를 Mark & Compact 하는 JVM은 비효율적입니다. 다음과 같은 그래프를 보시겠습니다.

Y축은 할당된 바이트의 수이고 X축은 바이트가 할당될 때의 시간입니다. 보시다시피 시간이 갈수록 적은 객체만이 남습니다. 위와 같은 그래프에 기반한 것이 Weak Generational Hypothesis 입니다.

Weak Generational Hypothesis

신규로 생성한 객체의 대부분은 금방 사용하지 않는 상태가 되고, 오래된 객체에서 신규 객체로의 참조는 매우 적게 존재한다는 가설입니다.

이 가설에 기반하여 자바는 Young 영역과 Old 영역으로 메모리를 분할하고, 신규로 생성되는 객체는 Young 영역에 보관하고, 오랫동안 살아남은 객체는 Old 영역에 보관합니다.

Generational Gabage Collection

1. Young 영역(Yong Generation 영역)

   새롭게 생성한 객체의 대부분이 여기에 위치합니다. 대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많은 객체가 Young 영역에 생성되었다가 사라집니다. 이 영역에서 객체가 사라질때 Minor GC 가 발생한다고 말합니다.

2. Old 영역(Old Generation 영역)

   접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체가 여기로 복사됩니다. 대부분 Young 영역보다 크게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생합니다. 이 영역에서 객체가 사라질 때 Major GC(혹은 Full GC) 가 발생한다고 말합니다.

3. Permanet 영역

   Method Area라고도 합니다. JVM이 클래스들과 메소드들을 설명하기 위해 필요한 메타데이터들을 포함하고 있습니다. JDK8부터는 PermGen은 Metaspace로 교체됩니다.

Generational Garbage Collection 과정

1. 어떠한 새로운 객체가 들어오면 Eden Space에 할당합니다.

   

   ---

2. Eden space가 가득차게 되면, minor garbage collection이 시작됩니다.

   

   ---

3. 참조되는 객체들은 첫 번째 survivor(S0)로 이동되어지고, 비 참조 객체는 Eden space가 clear 될 때 반환됩니다.

   

   ---

4. 다음 minor GC 때, Eden space에서는 같은 일이 일어납니다. 비 참조 객체는 삭제되고 참조 객체는 survivor space로 이동하는 것 입니다. 그러나 이 케이스에서 참조 객체는 두 번째 survivor space로 이동하게 됩니다. 게다가 최근 minor GC에서 첫 번째 survivor space로 이동된 객체들도 age가 증가하고 S1 공간으로 이동하게 됩니다. 한번 모든 surviving 객체들이 S1으로 이동하게 되면 S0와 Eden 공간은 Clear 됩니다. 주의해야할 점은 이제 우리는 다른 aged 객체들을 서바이버 공간에 가지게 되었다는 것입니다.

   

   ---

5. 다음 minor GC 때, 같은 과정이 반복 됩니다. 그러나 이 번엔 survivor space들은 switch 됩니다. 참조되는 객체들은 S0로 이동합니다. 살아남은 객체들은 aged되죠. 그리고 Eden과 S1 공간은 Clear 됩니다.

   

   ---

6. 아래 그램은 promotion을 보여줍니다. minor GC 후 aged 오브젝트들이 일정한 age threshold(문지방)을 넘게 되면 그들은 young generation에서 old로 promotion 되어집니다. 여기서는 8을 예로 들었습니다.

   

   ---

7. minor GC가 계속되고 계속해서 객체들이 Old Generation으로 이동됩니다.

   

   ---

8. 아래 그림은 전 과정을 보여주고 있습니다. 결국 major GC가 old Generation에 시행되고, old Generation은 Clear 되고, 공간이 Compact 되어집니다.

지역변수의 유효 범위를 최소로 줄이면 코드의 가독성과 유지보수성이 높아지고, 오류가 발생할 가능성은 낮아진다. 지역변수의 범위를 줄이는 가장 강력한 기법은 ‘가장 처음 쓰일 때 선언하기’다. 거의 모든 지역변수는 선언과 동시에 초기화하는 것이 바람직하다.

• 반복문은 변수 범위를 자연스럽게 최소화해주는 대표적인 구조다. 반복 변수의 값을 반복문이 끝난 뒤에 사용할 필요가 없다면, while문보다는 for문을 사용하는 편이 낫다.

• for문이 유리한 이유는 반복 변수의 유효 범위가 for문 블록 안으로 제한되기 때문이다. 이 덕분에 같은 이름의 변수를 여러 반복문에서 사용하더라도 서로 영향을 주지 않으며, 코드의 안정성이 높아진다.

  아이템 58 - 전통적인 for문보다는 for-each문을 사용하라

  반복자와 인덱스 변수는 모두 코드를 지저분하게 할 뿐 우리에게 진짜 필요한 건 원소들뿐이다. 혹시라도 잘못된 변수를 사용했을 때 컴파일러가 잡아준다는 보장도 없고... 등 문제가 많은데 이걸 for-each문을 사용하면 모두 해결이 된다!

  for (Element e : elements) {
  ... // e로 무언가를 한다.
  }

• for-each문은 중첩 순회할 때 이점이 더 커진다. 정말 운이 나빠서 바깥 컬렉션의 크기가 안쪽 컬렉션 크기의 배수라면 이 반복문은 예외를 던지지 않고 종료한다.

• for-each문은 컬렉션과 배열은 물론 Iterable 인터페이스를 구현한 객체라면 무엇이든 순회할 수 있다!

하지만 for-each문을 사용할 수 없는 상황 세 가지 존재한다!

1) 파괴적인 필터링 - 컬렉션을 순회하면서 선택된 원소를 제거해야 한다면 반복자의 remove 메서드를 호출해야 한다. 자바 8부터는 Collection의 removeIf 메서드를 사용해 컬렉션을 명시적으로 순회하는 일을 피할 수 있다. 2) 변형 - 리스트나 배열을 순회하면서 그 원소의 값 일부 혹은 전체를 교체해야 한다면 리스트의 반복자나 배열의 인덱스를 사용해야한다. 3) 병렬 반복 - 여러 컬렉션을 병렬로 순회해야 한다면 각각의 반복자와 인덱스 변수를 사용해 엄격하고 명시적으로 제어해야 한다.

아이템 59 - 라이브러리를 익히고 사용하라

static Random rnd = new Random();

static int random(int n) {
  return Math.abs(rnd.nextInt()) % n;
}

문제점

1) n이 그리 크지 않은 2의 제곱수라면 얼마 지나지 않아 같은 수열이 반복된다. 2) n이 2의 제곱수가 아니라면 몇몇 숫자가 평균적으로 더 자주 반환된다. 3) 지정한 범위 '바깥'의 수가 종종 튀어나올 수 있다. rnd.nextInt()가 반환한 값을 Math.abs를 이용해 음수가 아닌 정수로 매핑하기 때문이다.

• 이 문제점을 해결하려면 의사난수 생성기, 정수론, 2의 보수 계산 등에 조예가 깊어야한다. 다행히 Random.nextInt(int)가 다 해결해준다.
• 자바 7부터는 Random을 더 이상 사용하지 않는 게 좋다. ThreadLocalRandom으로 대체하면 대부분 잘 작동한다. 더 고품질의 무작위 수 생성 & 속도도 빠름

*표준 라이브러리를 사용하면 좋은 점 *

• 그 코드를 작성한 전문가의 지식과 여러분보다 앞서 사용한 다른 프로그래머들의 경험을 활용할 수 있다.
• 핵심적인 일과 크게 관련 없는 문제를 해결하느라 시간을 허비하지 않아도 된다.
• 따로 노력하지 않아도 성능이 지속해서 개선된다.
• 기능이 점점 많아진다.
• 자연스럽게 다른 개발자들이 더 읽기 좋고, 유지보수하기 좋고, 재활용하기 쉬운 코드가 된다.

java.util.concurrent를 알아두면.. 동시성 기능에 좋다? 하여튼간 자바 표준 라이브러리를 잘 이용해보자. 근데 원하는 기능이 거기 없다면 다음 선택지는 고품질의 서드파티 라이브러리에서 찾으면 되고.... (ex. 구글의 구아바 라이브러리) 그것도 없으면 직접 구현해야한다.

아이템 60 - 정확한 답이 필요하다면 float와 double은 피하라

float와 double은 넓은 범위의 수를 빠르게 정밀한 '근사치'로 계산하도록 설계되어 정확한 결과가 필요할 때는 사용하면 안 된다. 특히 금융 관련 계산과는 맞지 않는다!!

그래서 금융 계산에는 BigDecimal, int, long을 사용해야한다. 하지만 BigDecimal에는 단점이 두가지가 있다. 기본 타입보다 쓰기가 훨씬 불편하고 훨씬 느리다. 그래서 대안으로 int/long을 쓸 수도 있다. 이 경우에는 다룰 수 있는 값의 크기가 제한되고 소수점을 직접 관리해야 한다.

아이템 61 - 박싱된 기본 타입보다는 기본 타입을 사용하라

자바의 데이터 타입은 크게 두 가지로 나눌 수 있다.

1) int, double, boolean 같은 기본 타입 2) String, List 같은 참조 타입 int, double, boolean에 대응하는 박싱된 기본 타입은 Integer, Double, Boolean이다.

기본 타입과 박싱된 기본 타입의 주된 차이

1. 기본 타입은 값만 가지고 있으나, 박싱된 기본 타입은 값에 더해 식별성이란 속성을 갖는다.
2. 기본 타입의 값은 언제나 유효하나, 박싱된 기본 타입은 유효하지 않은 값, 즉 null을 가질 수 있다.
3. 기본 타입이 박싱된 기본 타입보다 시간과 메모리 사용면에서 더 효율적이다.

박싱된 기본 타입 사용 시 발생할 수 있는 문제

• 박싱된 기본 타입에 == 연산자를 사용하면 값 비교가 아니라 객체 참조 비교가 이루어진다. 이로 인해 의도하지 않은 오류가 발생할 수 있다.

해결 방법

• 비교가 필요하다면 Comparator나 naturalOrder()를 사용한다.
• 박싱된 타입의 값을 기본 타입 변수에 담아 비교 연산을 수행한다.

기본 타입과 박싱된 기본 타입을 혼용한 연산에서는 대부분 자동 언박싱이 일어난다. 하지만 실수로 지역변수를 박싱된 타입으로 선언하면, 눈치채지 못한 채 박싱·언박싱이 반복되어 성능 저하가 발생할 수 있다.

박싱된 기본 타입을 사용해야 하는 경우

• 컬렉션의 원소, 키, 값
• 매개변수화 타입이나 매개변수화 메서드 (ThreadLocal<Integer> 등)
• 리플렉션을 통한 메서드 호출

아이템 62 - 다른 타입이 적절하다면 문자열 사용을 피하라

문자열은 만능 타입처럼 보이지만, 다음과 같은 경우에는 적절하지 않다.

1. 다른 값 타입을 문자열로 대신하는 경우 수치 데이터는 숫자 타입으로, 예/아니오 값은 boolean이나 열거 타입으로 표현하는 것이 좋다.
2. 열거 타입을 문자열로 표현하는 경우 열거 타입을 사용하면 가독성과 타입 안정성이 크게 향상된다.
3. 혼합 타입을 문자열로 표현하는 경우

   String compoundKey = className + "#" + i.next();

이 방식은 문자열 파싱이 필요해 번거롭고 오류 가능성이 크며, equals, toString, compareTo 같은 메서드를 제대로 활용할 수 없다.

전용 클래스를 만드는 편이 훨씬 낫다.

4. 문자열로 권한을 표현하는 경우 스레드 구분용 키를 문자열로 사용하면 전역에서 키가 충돌해 값이 공유되는 문제가 발생할 수 있다.

아이템 63 - 문자열 연결은 느리니 주의하라

문자열 연결 연산자 +는 간편하지만, 문자열을 많이 연결하는 경우 성능 문제가 심각해진다. 문자열 n개를 +로 연결하는 시간은 n²에 비례한다.

성능을 고려해야 한다면 StringBuilder를 사용하자. StringBuilder는 문자열 개수에 따라 선형적으로 성능이 증가한다.

public String statement2() {
    StringBuilder b = new StringBuilder(numItems() * LINEWIDTH);
    for (int i = 0; i < numItems(); i++)
        b.append(lineForItem(i));
    return b.toString();
}

저자의 실험 기준으로 StringBuilder를 사용한 코드가 약 6.5배 더 빨랐다고 한다.

성능을 신경써야 한다면 많은 문자열을 연결할 때는 문자열 연결 연산(+)를 피하자. 대신 StringBuilder의 append 메서드를 사용하라. 문자 배열을 사용하거나, 문자열을 (연결하지 않고) 하나씩 처리하는 방법도 있다.

아이템 64 - 객체는 인터페이스를 사용해 참조하라

적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라.

인터페이스 사용 장점

• 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해진다.
• 나중에 구현 크래스를 교체하고자 한다면, 그저 새 클래스의 생성자(혹은 다른 정적 팩터리)를 호출해주기만 하면 된다.

인터페이스 대신 클래스 타입을 사용해도 되는 경우 적합한 인터페이스가 없다면 당연히 클래스로 참조해야 한다.

1. String과 BigInteger 같은 값 클래스 값 클래스를 여러 가지로 구현될 수 있다고 생각하고 설계하는 일은 거의 없다. 값 클래스는 매개변수, 변수, 필드, 반환 타입으로 사용해도 무방하다.

2. 클래스 기반으로 작성된 프레임워크가 제공하는 객체들 이런 경우라도 특정 구현 클래스보다는 (보통은 추상 클래스인) 기반 클래스를 사용해 참조하는게 좋다. OutStream 등 java.io 패키지의 여러 클래스가 이 부류에 속한다.

3. 인터페이스에는 없는 특별한 메서드를 제공하는 클래스 예시) PriorityQueue 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다.

이러한 클래스 타입을 직접 사용하는 경우, 클래스 타입에서 제공하는 추가 메서드를 꼭 사용해야 하는 경우로 최소화해야 하며, 절대 남발하지 말아야 한다.

아이템 65 - 리플렉션보다는 인터페이스를 사용하라

1. 리플렉션이란?

   java.lang.reflect API

• 실행 중에 임의의 클래스에 접근할 수 있다.
• 클래스, 인터페이스, 메서드를 찾을 수 있다.
• 객체를 생성하거나 변수를 변경할 수 있고 메서드를 호출 할 수 있다.
• 나아가 Constructor, Method, Field 인스턴스를 이용해 실제 생성자, 메서드, 필드를 조작할 수 있다.

2. 리플렉션 단점

• 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다.
• 예외 검사도 마찬가지다. 프로그램이 리플렉션 기능을 써서 존재하지 않는 혹은 접근할 수 없는 메서드를 호출하려고 하면 런타임 오류가 발생한다.
• 리플렉션을 이용하면 코드가 지저분하고 장황해진다.
• 성능이 떨어진다.
• 리플렉션을 통한 메서드 호출은 일반 메서드 호출보다 훨씬 느리다.

3. 정리 리플렉션은 런타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드와의 의존성을 관리할 때 적합하다. 하지만 단점도 많기 때문에 되도록 객체 생성에만 사용하고, 적절한 인터페이스나 상위 클래스로 형변환해 사용하자.

아이템 66 - 네이티브 메서드는 신중히 사용하라

네이티브 메서드

• 자바 네이티브 인터페이스(Java Native Interface, JNI)는 자바 프로그램이 네이티브 메서드 를 호출하는 기술을 말한다.
• 네이티브 메서드 란 C나 C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드를 말한다.

네이티브 메서드는 주로 다음과 같은 용도로 사용된다.

1. 플랫폼 특화 기능 사용
2. 네이티브 코드로 작성된 기존 라이브러리 (레거시 라이브러리가 그 예다)
3. 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영역만 따로 네이티브 언어로 작성

그러나 네이티브 메서드를 성능을 개선할 목적으로 사용하는 것은 권장하지 않는다.

네이티브 메서드의 단점

1. 네이티브 언어가 안전하지 않으므로 네이티브 메서드를 사용하는 애플리케이션도 메모리 훼손 오류로부터 더 이상 안전하지 않다.
2. 네이티브 언어는 자바보다 플랫폼을 많이 타기 때문에 이식성이 낮다.
3. 디버깅이 더 어렵다.
4. 주의하지 않으면 속도가 오히려 느려질 수도 있다.
5. 가비지 컬렉터가 네이티브 메모리는 자동 회수하지 못한다. 심지어 추적조차 할 수 없다.
6. 네이티브 메서드와 자바 코드 사이의 접착 코드(glue code)를 작성해야 한다. 이는 작업하기 귀찮을 뿐만 아니라 가독성도 떨어진다.

아이템 67 - 최적화는 신중히 하라

모든 사람이 마음 깊이 새겨야 할 최적화 격언 세 개를 소개 한다.

(맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다. (심지어 효율을 높이지도 못하면서) - 윌리엄 울프

(전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. - 도널드 크누스

최적화를 할 때는 다음 두 규칙을 따르라. 첫 번째, 하지 마라. 두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라.

M. A 잭슨 최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다. 빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어를 탄생시키는 것이다.

• 빠른 프로그램보다 좋은 프로그램을 작성하라.
• 설계 단계에서 성능을 반드시 염두에 두어야 한다.
  • 성능을 제한하는 설계를 피하라.
  • API를 설계할 때 성능에 주는 영향을 고려하라.
  • "최적화 시도 전후로 성능을 측정하라"

아이템 68 - 일반적으로 통용되는 명명 규칙을 따르라

자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 그중 많은 것이 자바 언어 명세[JLS, 6.1]에 기술되어 있다. 자바의 명명 규칙은 크게 철자 규칙과 문법 규칙, 두 범주로 나뉜다.

1. 철자 규칙 (Lexical Rules)

2. 문법 규칙 (Grammatical Rules)

명명 규칙은 단순한 스타일 문제가 아니라, 가독성·일관성·API 품질을 좌우하는 설계 요소다. 자바의 관례를 따르는 것만으로도 코드의 신뢰도가 크게 올라간다.

접근 방법

• 깊이가 N이면 그때 합이 S인지 확인
• 현재 arr[idx]를 합한 경우도 고려해야되고 합하지 않은 경우도 고려해야 함
• S == 0일 때, 공집합이 생기므로 정답-1 해줘야 함

공집합이 생기는 경우

idx=0, total=0
 → 선택X
idx=1, total=0
 → 선택X
idx=2, total=0
 → 선택X
idx=3, total=0
 → 선택X
idx=4, total=0
 → 선택X
idx=5 == N → total == S(0)

정답 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class BOJ_1182_부분수열의합_S2 {
    static int N, S, answer;
    static int[] arr;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        S = Integer.parseInt(st.nextToken());
        arr = new int[N];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < N; i++)
            arr[i] = Integer.parseInt(st.nextToken());

        dfs(0, 0);

        if (S == 0)
            answer--;
        System.out.println(answer);
    }

    public static void dfs(int idx, int total) {
        if (idx == N) {
            if (total == S)
                answer++;
            return;
        }

        // 현재 원소를 선택하는 경우
        dfs(idx + 1, total + arr[idx]);

        // 현재 원소를 선택하지 않는 경우
        dfs(idx + 1, total);
    }
}

접근 방식

• 집이랑 치킨집을 따로 ArrayList로 관리
• dfs로 깊이가 M이면 치킨거리 계산해서 최소치킨거리 계산하게!
• 한번 selected에 들어가서 조합 처리됐으면 백트래킹으로 복구시켜놓기

👉 치킨집 M개 조합을 전부 탐색해서 최솟값을 구하는 문제

코드 설명

조합 생성 (combi)

static void combi(List<int[]> selected, int start, int depth)

• 치킨집 중 M개를 선택하는 모든 조합 생성

파라미터

조합 로직

for (int i = start; i < chickens.size(); i++) {
    selected.add(chickens.get(i));
    combi(selected, i + 1, depth + 1);
    selected.remove(selected.size() - 1);
}

• 중복 없는 조합
• i + 1부터 탐색 → 이미 선택한 치킨집 재사용 X
• DFS + 백트래킹 구조

📌 예시 치킨집 5개 중 M=3이면 → (0,1,2), (0,1,3), (0,1,4), ...

도시 치킨 거리 계산

static int getCityChickenDistance(List<int[]> selected)

for (int[] home : homes) {
    int minDist = Integer.MAX_VALUE;
    for (int[] chicken : selected) {
        int dist = Math.abs(home[0]- chicken[0]) 
                 + Math.abs(home[1] - chicken[1]);
        minDist = Math.min(minDist, dist);
    }
    sum += minDist;
}

• 각 집마다:

  • 선택된 치킨집들과의 거리 중 최솟값 계산

• 모든 집의 최소 거리 합 → 도시 치킨 거리

정답 코드

public class BOJ_15686_치킨배달_G5 {
    static int N, M;
    static int[][] arr;
    static List<int[]> homes = new ArrayList<>();
    static List<int[]> chickens = new ArrayList<>();
    static int min = Integer.MAX_VALUE;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken()); // 치킨 집 수
        arr = new int[N][N];

        for (int i = 0; i < N; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < N; j++) {
                arr[i][j] = Integer.parseInt(st.nextToken());
                if (arr[i][j] == 1)
                    homes.add(new int[]{i, j});
                if (arr[i][j] == 2)
                    chickens.add(new int[]{i, j});
            }
        }

        combi(new ArrayList<>(), 0, 0);
        System.out.println(min);
    }

    static void combi(List<int[]> selected, int start, int depth) {
        if (depth == M) {
            min = Math.min(min, getCityChickenDistance(selected));
            return;
        }

        for (int i = start; i< chickens.size(); i++) {
            selected.add(chickens.get(i));
            combi(selected, i+1, depth+1);
            selected.remove(selected.size()-1);
        }
    }

    static int getCityChickenDistance(List<int[]> selected) {
        int sum = 0;
        for (int[] home : homes) {
            int minDist = Integer.MAX_VALUE;
            for (int[] chicken : selected) {
                int dist = Math.abs(home[0]- chicken[0]) + Math.abs(home[1] - chicken[1]);
                minDist = Math.min(minDist, dist);
            }
            sum+= minDist;
        }
        return sum;
    }
}

1단계 문제 이해 및 설계 범위 확정

요구사항 정의

• 어떤 종류의 알림
• 실시간 시스템인지
• 어떤 종류의 단말을 지원해야하는지: iOS 단말, 안드로이드 단말, 랩톱/데스크톱 등
• 사용자에게 보낼 알림은 누가 만들 수 있나요?
  • 클라이언트 애플리케이션 프로그램이 만들 수도 있고, 서버 측에서 스케줄링도 가능
• 사용자의 알림 설정 가능 유무
• 하루에 몇 건의 알림을 보낼 수 있는지

2단계 개략적 설계안 제시 및 동의 구하기

알림 유형별 지원 방안

iOS, 안드로이드, SMS 메시지, 이메일의 알림 메커니즘이 어떻게 동작하는지 알아보자.

1. iOS 푸시 알림

iOS에서 푸시 알림을 보내기 위해서는 세 가지 컴포넌트가 필요하다. APNS 동작 방식에 대해 자세히 알고싶다면 해당 사이트를 참고하면 좋다.

• 구성 요소
  • 알림 제공자(provider) : 알림 요청을 만들어 애플 푸시 알림 서비스(APNS)로 보내는 주체이고 알림 요청을 만들려면 단말 토큰(device token), 페이 로드(payload) 가 필요하다.
  • APNS(Apple Push Notification Service) : 애플이 제공하는 원격 서비스로 푸시 알림을 iOS로 보내는 역할을 담당한다.
  • iOS 단말 : 푸시 알림을 수신하는 사용자 단말이다.
• 요소: 단말 토큰(Device Token)과 페이로드(Payload)가 필요.

2. 안드로이드 푸시 알림

안드로이드에서 푸시 알림을 보내기 위해서는 세 가지 컴포넌트가 필요하다. FCM 동작 방식에 대해 자세히 알고싶다면 해당 사이트를 참고하면 좋다.

알림 제공자(provider) : 알림 요청을 만들어 애플 푸시 알림 서비스(FCM)로 보내는 주체이고 알림 요청을 만들려면 단말 토큰(device token), 페이 로드(payload) 가 필요하다. FCM(Firebase Cloud Messaging) : Google Firebase에서 제공하는 원격 서비스로 푸시 알림을 iOS로 보내는 역할을 담당한다. 안드로이드 단말 : 푸시 알림을 수신하는 사용자 단말이다.

SMS 메시지

SMS 메시지를 보낼 때는 트윌리오, 넥스모 같은 제3사업자의 서비스를 많이 이용한다.

이메일

많은 회사가 상용 이메일 서비스를 이용한다. 센드그리드, 메일침프와 같은 서비스가 있다.

연락처 정보 수집 절차

그렇다면 각 서비스는 알림을 보낼 단말을 어떻게 찾아서 알림을 보낼까? 알림을 보내려면 기기 단말 토큰, 전화번호, 이메일 등의 정보가 필요하다. 이 정보들은 사용자가 앱을 설치하거나, 처음으로 계정을 등록할 때 API서버에서 사용자의 정보를 수집하여 데이터베이스에 저장한다.

개략적 설계안 (초안)

• 각각의 서비스 : 마이크로서비스, 크론잡, 과금서비스와 같은 다양한 서비스다.
• 알림 시스템 : 알림 시스템은 알림 전송/수신 처리의 핵심으로 현재는 서버 1개만 사용하는 시스템이라고 가정했다.
  • 제3자 서비스에 전달할 알림 페이로드를 만들어 낼 수 있어야한다.
  • 이 시스템은 서비스 1~N에 알림 전송을 위한 API를 제공해야한다.
• 제3자 서비스(third party services) : 이 서비스들은 사용자에게 알림을 실제로 전달하는 역할을 한다.

그러나 이 설계에는 몇가지 문제가 있다.

• SPOF(Single-Point-Of-Failure) : 알림 서비스 서버가 장애가 생기면 전체 서비스 장애로 이어진다.
• 규모 확장성 : 한대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로, 데이터베이스 / 캐시 등 중요한 컴포넌트의 규모를 개별적으로 늘릴 방법이 없다.
• 성능 병목 : 알림을 처리하고 보내는 것은 자원을 많이 필요로 한다. 따라서 모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템 과부하 상태에 빠질 수 있다.

개략적 설계안 (개선된 버전)

주요 개선 방향

• 데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리한다.
• 알림 서버를 증설하고 자동으로 수평적 규모 확장이 이루어질 수 있도록 한다.
• 메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊는다.
• 각각의 서비스 : 알림 시스템 서버의 API를 통해 알림을 보낼 서비스이다.

구성 요소

• 알림 서버

  • 알림 전송 API : 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용가능하다.
  • 알림 검증 : 이메일 주소, 전화번호 등에 대한 기본적 검증을 수행한다.
  • 데이터베이스 또는 캐시 질의 : 알림에 포함시킬 데이터를 가져오는 기능이다.
  • 알림 전송 : 알림 데이터를 메시지 큐에 넣는다. 하나 이상의 메시지 큐를 사용하므로 알림을 병렬적으로 처리할 수 있다.

• 캐시 : 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시한다.

• 데이터 베이스 : 사용자, 알림, 설정 등 다양한 정보를 저장한다.

• 메시지 큐 : 시스템 컴포넌트 간 의존성을 제거하기 위해 사용한다. 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 한다.

• 작업 서버 : 메시지 큐에서 전송할 알림을 꺼내서 제3자 서비스로 전달하는 역할을 담당하는 서버이다.

3단계 상세 설계

지금까지 개략적 설계를 진행해봤다. 몇가지 사항을 더 고려하여 최종 설계안을 도출해보자.

• 안정성 : 데이터 손실 방지, 알림 중복 전송 방지
• 추가로 필요한 컴포넌트 및 고려사항 : 알림 템플릿, 알림 설정, 전송률 제한, 재시도 메커니즘, 보안

안정성

데이터 손실 방지

알림 전송 시스템의 가장 중요한 요구사항 중 하나는 어떤 상황에서도 알림이 소실되면 안 된다는 것이다. (알림이 지연되거나 순서가 보장되지는 않아도 된다.)

알림 중복 전송 방지

같은 알림이 여러 번 반복되는 것을 완전히 막는 것은 가능하지 않다. 대부분 알림은 딱 한번 전송되지만 분산 시스템 특성상 가끔은 같은 알림이 중복되어 전송되기도 한다.

• 보내야할 알림이 도착하면 그 이벤트 ID를 검사하여 이전에 본 적 있는 이벤트인지 살피고 중복이벤트라면 버린다. 그렇지 않으면 알림을 발송한다.
• 즉, 이벤트 ID 기반 중복 검증 후 이전 전송 기록을 단기 캐시에 저장하여 중복 수신 방지.

추가로 필요한 컴포넌트 및 고려사항

알림 템플릿

대형 알림 시스템은 하루에도 수백만 건 이상의 알림을 처리하고 대부분 알림 메시지 형식이 비슷하다. 변수 치환 기반 템플릿 사용으로 효율적 메시지 생성하낟.

본문: 인기 상품 [item_name]이 재입고 되었습니다. 현재 잔여 수량은 [item_cnt] 입니다.

알림 설정

많은 웹사이트와 앱에서는 사용자가 알림 설정을 상세히 조정할 수 있도록 하고있다. 알림 설정 테이블에 보관되며 다음과 같은 필드들이 필요하다.

user
channel(알림이 전송될 채널, 푸시 알림, 이메일 등)
opt_in(해당 채널로 알림을 받을 것인지 여부)

전송률 제한

• 사용자별/서비스별 전송 빈도를 제어한다.
• Redis 등 캐시 시스템을 활용한 제한 구현 가능하다.

재시도 방법

제3자 서비스가 알림 전송에 실패하면 해당 알림을 재시도 전용 큐에 넣는다. (만약 같은 문제가 계속 발생하면 개발자에게 통지해야함)

푸시 알림과 보안

iOS와 안드로이드 앱의 경우, 알림 전송 API는 appKey, appSecret을 사용하여 보안을 유지한다. 인증되었거나 승인된 클라이언트만 해당 API를 사용하여 알림을 보낼 수 있도록 한다.

수정된 설계안

지금까지 설명한 내용을 모두 반영하여 수정한 설계안이다.

4단계 마무리

• 안정성(Reliability) : 메시지 전송 실패율을 낮추기 위해 안정적인 재시도 메커니즘을 도입했다.
• 보안(Security) : 인증된 클라이언트만 알림을 보낼 수 있도록 한다.
• 이벤트 추적 및 모니터링 : 알림이 만들어진 후 성공적으로 전송되기까지의 과정을 추적, 시스템 상태를 모니터링하기 위해 알림 전송의 각 단계마다 이벤트를 추적한다.
• 사용자 설정 : 사용자가 알림 수신 설정을 조정할 수 있도록 하였다. 알림을 보내기 전 반드시 해당 설정을 확인하고 알림을 보낼 수 있도록 해야한다.

참고

• 동시성은 여러 작업이 “논리적으로 동시에 진행되는 것처럼 보이도록” 스케줄링하는 개념이고, 병렬성은 실제로 여러 작업이 같은 시점에 물리적으로 동시에 실행되는 상태를 말합니다.[1][3]
• 예를 들어 단일 코어 CPU에서 여러 스레드를 번갈아 실행해 사용자에게 동시에 돌고 있는 것처럼 보이면 동시성이고, 멀티 코어에서 서로 다른 코어가 각각의 스레드를 진짜 동시에 실행하면 병렬성입니다.[3][1]

“동시성은 시간 분할로 번갈아 실행해서 동시에처럼 보이게 하는 것이고, 병렬성은 멀티 코어 위에서 실제로 동시에 실행되는 것입니다.”

Thread-safe와 동시성 이슈

• Thread-safe하다는 것은 여러 스레드가 동시에 같은 객체나 함수에 접근하더라도, 데이터가 꼬이거나 잘못된 결과가 발생하지 않도록 설계·구현되어 있다는 의미입니다.[7][9]
• 자바에서 대표적인 동시성 이슈는 레이스 컨디션, 가시성 문제(메모리 가시성), 원자성(atomicity) 깨짐, 데드락 등이 있으며, 공유 mutable 상태를 어떻게 보호하느냐가 핵심입니다.[9][7]

면접용 포인트: “Thread-safe = 여러 스레드가 동시에 접근해도 상태 일관성이 깨지지 않는 설계/구현”이라고 짧게 말하고, 바로 레이스 컨디션 예시 하나를 붙여주면 좋습니다.

가시성 문제와 원자성 문제

• 가시성 문제는 한 스레드가 공유 변수 값을 변경했는데, 다른 스레드가 그 최신 값을 보지 못하고 자신의 캐시/레지스터에 남은 옛 값으로 계속 동작하는 상황입니다.[7]
• 원자성 문제는 ++, += 같은 복합 연산이 실제로는 “읽기 → 계산 → 쓰기” 여러 단계로 나뉘는데, 이 사이에 다른 스레드가 끼어들어 연산이 중간에 섞여 버리는 문제를 말합니다.[9][7]

"가시성은 ‘변경이 다른 스레드에 보이는가’ 문제, 원자성은 ‘연산이 쪼개지지 않고 한 번에 수행되는가’ 문제입니다.”

자바 동시성 이슈 해결 방법

• 전통적인 방법으로는 synchronized 블록/메서드, wait/notify, volatile, 그리고 java.util.concurrent의 락(ReentrantLock), Condition, ConcurrentHashMap 같은 고수준 동시성 컬렉션을 사용합니다.[7]
• 더 나아가 ExecutorService, 스레드 풀, Future/CompletableFuture 등으로 스레드 직접 생성 대신 태스크 기반으로 동시성을 관리하고, 공유 상태를 줄여서 문제를 근본적으로 완화하는 방향이 많이 사용됩니다.[7]

volatile 키워드

• volatile은 변수에 대한 “메모리 가시성”을 보장해서, 한 스레드가 쓴 값을 다른 스레드가 즉시 메인 메모리에서 읽도록 강제하는 키워드입니다.[7]
• 다만 volatile은 읽기/쓰기 자체만 원자적으로 만들 뿐, 복합 연산(증가, 조건 검사 + 변경 등)에 대한 원자성을 보장해주지는 못하므로, 카운터 증가 같은 곳에는 적합하지 않습니다.[7]

“volatile은 가시성을 해결해 주지만, 동기화(mutex) 대신이 될 수는 없습니다.”

synchronized 키워드와 구현·문제점

• synchronized는 한 번에 하나의 스레드만 진입할 수 있는 임계 구역(critical section)을 만들어서, 객체 모니터(모니터 락)를 기준으로 상호 배제를 보장합니다.[7]
• 내부적으로는 객체마다 모니터 락이 있고, 진입 시 락을 획득하고, 블록/메서드가 끝나면 락을 해제하며, 이 과정에서 OS의 락/뮤텍스 또는 JVM 레벨 최적화(경량 락, 편향 락 등)를 사용합니다.[7]

문제점 관점에서 말할 것들:

• 락 경합이 심해지면 컨텍스트 스위칭 비용이 커지고 성능이 떨어진다.[7]
• 블로킹 방식이라, 락을 기다리는 동안 스레드가 멈춰 있게 되고 데드락·기아(starvation) 위험도 있다.[7]

“synchronized는 모니터 락 기반 상호 배제라서 간단하지만, 블로킹과 락 경합으로 인한 성능 저하, 데드락 위험이 문제라서 고수준 동시성 API와 함께 적절히 써야 합니다.”

atomic의 의미와 Atomic 타입

• atomic하다는 것은 어떤 연산이 중간 상태를 외부에 노출하지 않고 “쪼개지지 않는 하나의 단위”로 실행된다는 뜻입니다.[7]
• 자바의 java.util.concurrent.atomic 패키지에는 AtomicInteger, AtomicLong, AtomicReference 등 CAS(Compare-And-Swap) 기반으로 원자적인 읽기·갱신을 제공하는 타입들이 있습니다.[7]

“AtomicInteger의 incrementAndGet은 내부적으로 CAS를 사용해 다른 스레드와 섞이지 않는 원자적 증가를 제공합니다.”

가시성 문제 심화 질문 포인트

• 여러 스레드가 같은 CPU의 캐시만 사용한다면 가시성 문제는 줄어들 수 있지만, 실제 환경에서는 여러 코어와 각각의 캐시, 재정렬, 컴파일러 최적화 등 요인 때문에 “항상 안전하다”고 볼 수 없습니다.[3][7]
• 그래서 자바 메모리 모델(JMM)은 volatile, synchronized, final 등으로 happens-before 관계를 정의하고, 이 규칙을 통해 스레드 사이의 가시성과 순서를 보장합니다.[7]

“하나의 CPU 캐시만 쓴다는 가정 자체가 비현실적이고, 재정렬까지 고려해야 해서 언어 차원의 메모리 모델 도움 없이 직접 가시성을 보장하기는 매우 어렵습니다.”

CAS 알고리즘 개념

• CAS(Compare-And-Swap)는 “현재 값이 기대한 값과 같을 때만 새로운 값으로 바꾸는” 원자적 연산으로, 실패하면 다시 읽고 재시도하는 방식입니다.[7]
• 이 방식은 락을 쓰지 않고도 경쟁 조건을 제어할 수 있어 lock-free 자료구조 구현에 많이 사용되지만, 충돌이 심하면 반복 재시도로 인해 비용이 커질 수 있습니다.[7]

“CAS는 기대값 비교 후 조건부 교체를 통해 락 없이 원자적 갱신을 보장하는 알고리즘이고, 자바 Atomic 클래스들이 이를 활용합니다.”

Synchronized 컬렉션 vs 동시성 컬렉션

• Vector, Hashtable, Collections.synchronizedXXX는 전체 메서드에 synchronized를 걸어 한 번에 하나의 스레드만 접근하게 하므로, 락 경합이 많고 병렬성이 떨어지는 것이 단점입니다.[7]
• CopyOnWriteArrayList는 쓰기 시 새 배열을 복사하고, 읽기는 락 없이 기존 배열 스냅샷을 보는 구조라서 “읽기 위주” 환경에 적합하고, ConcurrentHashMap은 버킷/세그먼트 단위 락 또는 CAS로 동시성을 극대화합니다.[7]

질문별 키워드 정리:

• SynchronizedList vs CopyOnWriteArrayList

  • SynchronizedList: 모든 접근에 락, 읽기·쓰기 모두 블로킹, 쓰기 적고 읽기 많을 때 비효율적.[7]
  • CopyOnWriteArrayList: 쓰기 시 전체 복사, 읽기는 락 없이 빠르지만 쓰기 비용이 크므로 “읽기 매우 많고 쓰기 적은 환경”에 적합.[7]

• ConcurrentHashMap vs SynchronizedMap

  • SynchronizedMap: 전체 맵에 단일 락, 동시성 낮음.[7]
  • ConcurrentHashMap: 내부를 분할하거나 CAS를 활용해 여러 스레드가 동시에 다른 버킷을 업데이트 가능, 읽기 대부분은 락 없이 처리해 높은 동시성 제공.[7]

참고 블로그:

1 2 3 4 5 6 7 8 9 10

1. 왜 매개변수 검사가 중요한가?

✔ 메서드는 잘못된 입력을 절대 받아들이면 안 된다.

매개변수가 유효하지 않으면 즉시(fail-fast) 예외를 던져야 한다. 유효성 검사를 하지 않으면 다음 문제가 발생할 수 있다:

1.중간 실행 중 모호한 예외 발생 2. 잘못된 반환값 생성 3. 객체 상태(invariant)가 깨져 미래의 예측 불가한 시점에 오류 발생 → 이런 오류는 실패 원자성(Item 76)까지 깨뜨릴 수 있다.

따라서: 모든 public 메서드는 “메서드 본문이 실행되기 전에” 매개변수 유효성을 검사해야 한다.

2. 매개변수 제약은 문서화해야 한다

• 매개변수가 어떤 조건을 만족해야 하는지 반드시 명시해야 한다.
• public/protected 메서드라면 @throws 태그로 어떤 조건 위반 시 어떤 예외가 발생하는지 문서화할 것.
• 예: null, 범위, 크기, 인덱스 등

✔ 표준적으로 많이 쓰는 예외

• IllegalArgumentException
• IndexOutOfBoundsException
• NullPointerException

3. 유효성 검사 방법

3-1. null 검사 — Objects.requireNonNull

가장 간편하고 널리 쓰이는 null 체크 방식.

this.strategy = Objects.requireNonNull(strategy, "strategy must not be null");

3-2. 범위 검사 — Objects.checkIndex (Java 9+)

List/Array용 범위 체크 유틸리티.

int idx = Objects.checkIndex(index, list.size());

(※ 메시지는 지정할 수 없고 List/Array 전용이라는 제약이 있음)

3-3. assert 검사 — private 메서드용

• 내부 메서드에서만 사용 (외부 입력이 불가능한 경우)
• JVM 옵션 -ea 필요

private void sort(int[] arr, int offset, int length) {
    assert arr != null;
    assert offset >= 0 && length >= 0;
}

3-4. 저장해두는 매개변수는 더 철저히 검사

static List<Integer> intArrayAsList(int[] a) {
    Objects.requireNonNull(a);
    return new AbstractList<>() { ... };
}

→ null 검사가 없으면 List 뷰 생성은 되지만, 이후 사용하는 시점에 NPE 발생

4. 유효성 검사가 불필요한 경우

• 검사 비용이 지나치게 큰 경우
• 계산 과정에서 자동으로 유효성이 검증되는 경우

예: Collections.sort(list) → 비교 과정에서 자연스럽게 ClassCastException 발생하므로 사전 검증 불필요.

정리

1. 모든 public 메서드/생성자는 매개변수 유효성 검사를 메서드 시작 시점에 수행해야 한다.
2. 제약 조건과 위반 시 예외를 문서화(@throws)하고, null·범위·인덱스 등은 반드시 검증한다.
3. private 메서드는 assert 활용 가능하지만, public API는 반드시 명시적 검사(requireNonNull 등)를 사용한다.

✅ Item 50. 적시에 방어적 복사본을 만들라

1. 왜 방어적 복사가 필요한가?

Period 같은 불변 클래스를 만들어도, 가변 객체(Date 등)를 참조로 받으면 내부 불변식이 깨진다.

Period p = new Period(start, end);
end.setYear(78);   // p 내부가 수정됨 → 불변 아님

즉, 불변처럼 보이지만 실제로는 공격·버그에 취약하다.

2. 생성자에서 방어적 복사

✔ 핵심 원칙

“매개변수 유효성 검사 전에 복사하고, 복사본을 기준으로 검증해라.”

멀티스레드 환경에서

1. 원본 검증
2. 복사 사이에 다른 스레드가 원본을 변경할 수 있기 때문.

올바른 작성 예

public Period(Date start, Date end) {
    this.start = new Date(start.getTime());
    this.end   = new Date(end.getTime());

    if (this.start.compareTo(this.end) > 0) {
        throw new IllegalArgumentException(start + " after " + end);
    }
}

⚠ clone()을 쓰면 안 되는 이유

• 매개변수가 제3자가 만든 하위 클래스일 수 있음
• clone이 악의적으로 재정의되어 있으면 공격자가 내부를 조작할 수 있음 → 생성자/팩터리를 이용한 복사가 안전하다.

3. 접근자(getter)에서도 방어적 복사 필요

다시 “가변 필드”를 그대로 넘기면 내부가 수정된다.

p.getEnd().setYear(78);   // 내부 필드 수정 가능 → 불변 아님

올바른 접근자

public Date getStart() { return new Date(start.getTime()); }
public Date getEnd()   { return new Date(end.getTime()); }

여기서는 clone 사용 가능

Period가 내부적으로 보유한 Date는 java.util.Date로 확정적이므로 clone도 안전. 하지만 Item13에 따라 생성자를 쓰는 방식이 일반적으로 더 권장됨.

4. 방어적 복사의 목적 = “불변 클래스 만들기”만이 아니다

• 클라이언트가 준 객체를 내부에서 저장해야 하는 경우
• 내부 객체를 외부로 전달해야 하는 경우 → 가변 객체라면 항상 복사본 사용이 기본 룰.

핵심 원칙

“어떤 참조도 외부가 객체 내부를 바꿀 수 있게 해선 안 된다.”

5. 방어적 복사를 항상 할 수는 없다

방어적 복사에는 비용이 존재한다.

복사를 생략해도 되는 경우

• 복사 비용이 매우 큰 경우
• 클라이언트를 신뢰할 수 있는 내부 시스템
• 불변식이 깨져도 오로지 호출자에게만 영향이 있는 경우

정리

1. 가변 객체를 매개변수로 받거나 반환할 때는 반드시 방어적 복사를 해야 한다.
2. 생성자에서는 유효성 검사보다 ‘복사’가 먼저이며, clone은 절대 쓰지 않는 것이 안전하다.
3. getter에서도 내부 가변 객체를 그대로 노출하지 말고 반드시 복사 후 반환한다.
4. 방어적 복사를 하면 불변식이 깨지는 공격/버그를 완전히 차단할 수 있다.
5. 비용이 크거나 신뢰 가능한 상황에서만 복사를 생략하며, 그 경우 반드시 문서화한다.

✅ Item 51. 메서드 시그니처를 신중히 설계하라

1. 메서드 이름은 신중하게

• 표준 명명 규칙(Item68)을 반드시 따르고 읽는 사람이 의도를 바로 이해할 수 있어야 한다.
• 같은 패키지/프로젝트 내 다른 이름들과 일관성을 유지하는 것이 가장 중요하다.
• 너무 긴 이름은 피하고, 애매하면 자바 표준 라이브러리의 이름 패턴을 참고하자.

2. “편의 메서드”를 너무 많이 만들지 말자

• 편의 메서드(convenience method)는 사용자를 위해 복잡한 작업을 쉽게 해주는 메서드.
• 하지만 편의 메서드를 남발하면 클래스에 메서드가 너무 많아지고, 학습·사용·문서화·테스트·유지보수 모두 어려워진다.
• 각 기능을 완벽히 수행하는 메서드만 두고, 정말 자주 쓰이는 경우에만 약칭 메서드를 제공하라.

3. 매개변수 목록은 짧게 유지하자

• 일반적으로 4개 이하가 이상적이다.
• 특히 동일 타입의 매개변수 여러 개가 연속되는 경우는 매우 위험하다. (순서를 바꿔 입력해도 컴파일되므로, 의도와 다르게 동작하기 쉬움)

4. 매개변수를 줄이는 실전 기법 3가지

① 여러 메서드로 기능을 쪼갠다

• 원래 긴 매개변수 목록이 들어가는 한 메서드를 → 의미 있는 기능 단위로 쪼개서 → 더 적은 파라미터를 받도록 만드는 방식.
• 이는 “직교성(orthogonality)”을 높여 오히려 메서드 수를 줄이는 효과도 있다.
• 예) subList + indexOf 조합으로 3개 매개변수가 필요한 작업을 해결.

② 도우미(helper) 클래스를 사용한다

• 두 개 이상의 매개변수가 하나의 개념을 이룬다면 이를 묶는 클래스를 만든다.
• 보통 정적 멤버 클래스(Item24)로 구현한다.
• 예) 카드의 숫자(rank) + 무늬(suit)는 항상 함께 다니므로 Card라는 클래스로 묶기.

이렇게 하면:

• 메서드는 Card 하나만 받으면 되고,
• 내부 구현도 훨씬 깔끔해지고,
• 의미도 명확해진다.

③ 메서드 호출에 ‘빌더 패턴’을 응용한다

• 매개변수 개수가 많거나 일부만 선택적으로 설정하면 되는 경우 유용.
• “설정 객체(파라미터 객체)”를 만들어 setter 형태로 필요한 인자만 채운 뒤 마지막에 execute() 같은 메서드를 호출해서 실행.

예)

QueryBuilder qb = new QueryBuilder()
        .limit(10)
        .orderBy("name")
        .filter("age > 20");
qb.execute();

이는

• 긴 시그니처를 피할 수 있고,
• 선택적 매개변수 처리가 쉬워지며,
• 최종 실행 전에 유효성 검사도 할 수 있다.

5. 매개변수 타입은 구체 클래스보다 인터페이스로 받자

• 매개변수로 사용할 인터페이스가 있다면 반드시 인터페이스로 받자.
• 예: HashMap을 받도록 설계하지 말고 Map을 받도록 하자. → 그럼 HashMap, TreeMap, ConcurrentHashMap 등 모든 Map 구현체 사용 가능 → 클라이언트를 특정 구현체로 제한하지 않는다.
• 클래스 타입을 받으면 클라이언트가 “형 변환” 또는 “복사 비용”을 치르게 된다.

6. boolean 파라미터 대신 두 값짜리 enum을 사용하라

• boolean을 쓰면 호출 시 의미가 명확하지 않다.
• 온도 단위 예시:

Thermometer.newInstance(true); // 의미 모호
Thermometer.newInstance(TemperatureScale.CELSIUS); // 명확

• 확장성도 좋아서 이후 KELVIN 같은 값도 쉽게 추가할 수 있다.
• 또한 enum 상수에 각 단위를 처리하는 메서드를 포함시킬 수도 있다.

정리

1. 메서드 이름은 일관성 있고 이해 가능하게 지어라.
2. 편의 메서드 남발은 해롭다 — 각 메서드는 자신의 역할만 하게 하라.
3. 매개변수는 4개 이하로, 특히 같은 타입 여러 개는 피하라.
4. 매개변수는 쪼개기·도우미 클래스·빌더 패턴으로 줄여라.
5. 매개변수 타입은 인터페이스로 받고, boolean보다 enum을 사용하라.

✅ Item 52. 다중정의(Overloading)는 신중히 사용하라

1. 왜 다중정의가 위험한가?

✔ 다중정의는 정적으로(compile-time) 선택된다

오버라이딩은 런타임 타입(runtime type) 이 기준이지만, 오버로딩은 컴파일 타입(compile-time type) 만 보고 어떤 메서드를 호출할지 결정한다.

즉:

whatIsThisClass(Collection<?> c);

여기서 실제 런타임 객체가 Set, List여도 컴파일 타입이 Collection이면 Collection 버전이 항상 호출된다.

그래서 아래 예제에서 3번 모두 "컬렉션"이 출력된다:

🧨 다중정의 실패 예시

public String whatIsThisClass(Set<?> set) { return "셋"; }
public String whatIsThisClass(List<?> list) { return "리스트"; }
public String whatIsThisClass(Collection<?> c) { return "컬렉션"; }

Collection<?>[] arr = { new HashSet<>(), new ArrayList<>(), map.values() };
for (Collection<?> c : arr) {
    System.out.println(whatIsThisClass(c)); 
}

→ 문제의 핵심

• 다형성처럼 보이지만 다형성을 제공하지 않는다.
• 타입 계층에 따라 메서드가 선택되는 것이 아니라 컴파일러가 정한 하나만 호출된다.

2. 반면 오버라이딩은 런타임에 동작이 결정된다

Burger -> ChickenBurger -> Whopper

Burger b = new Whopper();
b.print();  // "와퍼"

→ 여기서는 런타임 타입(실 객체 타입) 이 기준이므로 기대한 대로 동작한다.

✦ 결론: 오버라이딩은 다형성. 오버로딩은 단순한 이름 재사용 기능.

3. 다중정의가 헷갈리는 이유

다중정의는 아래 상황에서 특히 혼란을 일으킨다:

• 서로 관련된 타입 (예: Object, Collection, List)
• 매개변수 수가 같은 메서드
• 오토박싱, varargs, 형변환 등이 끼어 있을 때
• 컴파일러가 선택하는 메서드가 사람 기대와 다름

4. 안전하게 설계하는 방법

✔ 1) 매개변수 수가 같은 오버로딩은 피하라

특히 타입 계층이 얽혀 있는 경우(Set, List, Collection 등)는 더욱 금지.

✔ 2) 이름을 완전히 다르게 만들어라

가장 안전한 해결책.

readInt(), readLong()  

✔ 3) varargs(가변인수)와 오버로딩은 절대 같이 쓰지 마라

컴파일러가 어떤 메서드에 매칭할지 극도로 모호함.

✔ 4) 타입이 헷갈릴 수 있으면 아예 받지 마라

예: Integer용 오버로딩과 Object 오버로딩을 함께 두는 경우

5. 결론

다중정의(Overloading) — 정적 바인딩 → 컴파일타임 결정 재정의(Overriding) — 동적 바인딩 → 런타임 결정

🚫 위험한 다중정의는 피하고

• 매개변수 수가 같거나
• 타입 계층이 서로 관련되어 있고
• varargs가 얽혀 있으면 → 메서드 이름을 다르게 만들어라.

✔ 안전한 다중정의만 허용

• 서로 전혀 다른 타입
• 직관적으로 명확한 차이
• 자동 형변환/오토박싱/상속 계층이 얽히지 않는 경우

✅ Item 53. 가변인수(varargs)는 신중히 사용하라

1. 가변인수(varargs)란?

• 개수가 정해지지 않은 인자를 받을 수 있는 메서드 기능 (int... numbers, String... args)
• 호출 시 인수 개수만큼 배열을 새로 만들어 전달한다.
• 인수를 하나도 넘기지 않아도 되고, 여러 개 넘겨도 된다.

✔ 내부적으로는 배열 생성 → 값 복사 → 메서드 호출의 오버헤드가 항상 존재한다.

2. 기본 사용 예시

✔ 간단한 가변인수 메서드 (정상 예시)

static int sum(int... args) {
    int sum = 0;
    for (int arg : args)
        sum += arg;
    return sum;
}

sum(1,2,3); // 6
sum();      // 0

3. 문제 상황: 인수가 1개 이상 필요한 경우

❌ 잘못된 구현

static int min(int... args) {
    if(args.length == 0)
        throw new IllegalArgumentException();
    int min = args[0];
    for(int i = 1; i < args.length; i++)
        if(args[i] < min)
            min = args[i];
    return min;
}

문제점

• min() 호출 시 런타임 오류 발생
• 매개변수 유효성 검사를 매번 해야 함
• 첫 요소를 미리 뽑아 쓰므로 코드가 깔끔하지 않음

4. ✔ 올바른 설계: "필수 매개변수 + 가변인수"

static int min(int firstArg, int... remainingArgs) {
    int min = firstArg;
    for (int arg : remainingArgs)
        if (arg < min)
            min = arg;
    return min;
}

장점

• 최소 하나는 반드시 전달됨
• 가독성 증가
• 유효성 체크 불필요

5. 성능 최적화가 필요한 경우

가변인수는 매 호출마다 배열 생성 비용이 든다 → 비용이 크다.

✔ 해결 전략: 다중정의 + 마지막에만 varargs

public void test() {}
public void test(int a1) {}
public void test(int a1, int a2) {}
public void test(int a1, int a2, int a3) {}
public void test(int a1, int a2, int a3, int... rest) {}

효과:

• 인수 0~3개 호출은 가변인수 배열을 생성하지 않음 → 빠름
• 인수가 많을 때만 varargs 배열 생성
• EnumSet의 정적 팩터리도 이 방식 사용(성능 최적화)

6. 가변인수 메서드 호출 과정 (중요)

1. 인수 개수만큼 길이를 가진 배열 생성
2. 전달된 인수들을 해당 배열에 복사
3. 메서드가 이 배열을 매개변수로 받음

→ 호출할 때마다 “배열 생성 + 복사” 오버헤드 발생

정리

1. 인수 개수가 정해져 있지 않다면 가변인수를 사용한다.
2. 필수 인수는 가변인수 앞에 두어야 한다.
3. 1개 이상 전달해야 하는 경우는 firstArg + varargs 형태로 만들 것.
4. 성능 민감 코드라면 다중정의로 배열 생성을 최소화한다.
5. 내부적으로 가변인수 호출 시 항상 배열을 새로 만든다.

✅ Item 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라

1) 절대 null 을 반환하지 마라

다음과 같은 코드처럼, “값이 없으니 null 반환”은 흔하지만 나쁜 API 설계다.

return cheesesInStock.isEmpty() ? null : new ArrayList<>(cheesesInStock);

이렇게 하면 클라이언트 코드가 매 호출마다 null 체크를 강제당한다.

List<Cheese> cheeses = shop.getCheeses();
if (cheeses != null && cheeses.contains(Cheese.Mozzarella)) {
    ...
}

→ API 사용성이 떨어지고, null 체크가 누락되면 NPE 발생 위험이 커진다.

2) 빈 컬렉션을 반환하는 것이 더 안전 & 더 편리하다

✔ 빈 컬렉션 할당 비용은 성능 문제를 일으키지 않는다

• JVM 최적화 때문에 빈 리스트 생성 비용은 매우 낮다.
• 성능 프로파일링을 해보면 문제 원인은 대부분 다른 데 있음.
• "빈 컬렉션을 만든다고 성능이 떨어진다"는 잘못된 걱정.

3) 더 효율적인 방법 — 불변(empty) 컬렉션 반환

빈 컬렉션을 매번 새로 생성하지 않고 불변 싱글턴 컬렉션을 쓰면 된다.

return cheesesInStock.isEmpty() 
        ? Collections.emptyList() 
        : new ArrayList<>(cheesesInStock);

Collections.emptyList()는

• 불변 싱글턴
• 재사용 가능 (새 객체 생성 X)
• 안전하고 성능에도 유리

Set/Map도 동일하게 emptySet(), emptyMap() 제공.

4) 배열도 null 대신 길이 0짜리 배열을 반환하라

❌ 잘못된 방식

return null;

✔ 올바른 방식

private static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0];

public Cheese[] getCheeses() {
    return cheesesInStock.toArray(EMPTY_CHEESE_ARRAY);
}

new Cheese[0] 배열은 불변이기 때문에 재사용이 가능하다.

정리 ✔ null 대신 빈 컬렉션/배열을 반환하라 ✔ API 사용성 ↑, NPE ↓ ✔ 성능 문제 거의 없음 ✔ 필요하면 Collections.emptyXxx() 같은 불변 빈 컬렉션 사용 ✔ 배열도 0길이 배열 싱글턴 사용

✅ Item 56. 공개된 API 요소에는 항상 문서와 주석을 작성하라

1. 공개 API에는 반드시 Javadoc을 달아라

Javadoc = Java 코드에서 API 문서를 생성하는 공식 주석 시스템

• 공개된 클래스, 인터페이스, 메서드, 필드에는 반드시 Javadoc 작성
• 특히 직렬화 가능한 클래스는 직렬화 형태까지 문서화해야 함
• 기본 생성자는 Javadoc을 달 수 없으므로 공개 API에서는 기본 생성자 사용 금지

2. 문서 주석은 “클라이언트와의 규약(계약)”을 정확히 기술해야 한다

메서드를 문서화할 때 반드시 아래 3개를 명시해야 한다.

✔ 1) 전제조건(preconditions) – @param, @throws

메서드 호출자가 만족해야 하는 조건 예: index >= 0, object != null

✔ 2) 사후조건(postconditions) – @return

메서드가 성공적으로 수행된 후 반드시 만족해야 하는 조건 예: “정렬된 리스트를 반환한다”

✔ 3) 부작용(side effects)

배경 스레드 생성, 전역 상태 변경 등 → 문서화하지 않으면 API 오용이 발생할 수 있음 (예: Thread.stop() API 문서처럼 상세히 설명해야 함)

📌 3. Javadoc 태그 정리

✔ @param

매개변수 설명

• 관례상 문장 끝에 마침표 생략

✔ @return

반환 값 설명

• Java 16부터 {@return} 사용 가능 → 중복 설명 줄어듬

✔ @throws

체크/언체크 예외 기술

4. 중요한 Javadoc 태그들

✔ {@code ...}

• 코드 폰트로 렌더링
• HTML 태그/다른 Javadoc 태그 무시 → 안전함

✔ {@literal ...}

• HTML 메타문자(<, > 등)를 escape해서 그대로 출력
• Mrs. 같은 문자열의 문장 종료 오해 문제 해결

✔ @implSpec

• 상속용 클래스의 “하위 클래스와의 계약(implementation requirements)”을 설명
• 활성화하려면 컴파일 옵션 필요 → -tag "implSpec:a:Implementation Requirements:"

✔ @summary (JDK 10+)

문서 첫 문장 생성 시 마침표 문제 해결하는 용도

✔ {@index ...} (JDK 9+)

검색 색인 기능 추가

5. 제네릭 / Enum / Annotation 문서화 규칙

✔ 제네릭 타입

모든 타입 매개변수에 반드시 @param 문서 작성

@param <K> 키 타입
@param <V> 값 타입

✔ Enum

각 상수까지 모두 문서화해야 하는 거의 유일한 타입

/** 플루트, 오보 등 목관악기 */
WOODWIND

✔ 애너테이션

애너테이션 자체 + 멤버 모두 문서화해야 함

• 필드 설명 = 명사구
• 애너테이션을 적용하면 어떤 동작이 발생하는지 = 동사구

6. API 단위 문서화 파일

✔ package-info.java

패키지 설명을 여기에 작성 (package 선언 포함)

✔ module-info.java

모듈 설명을 여기에 작성

7. 스레드 안정성 / 직렬화 문서화는 필수

• API에서 스레드 안전성을 반드시 명시 ("불변", "thread-safe", "not thread-safe", "조건부 thread-safe" 등)

• 직렬화 가능 클래스는 직렬화 형태(documented serialized form) 명시 → @serial, @serialField, @serialData 태그 사용 가능

8. Javadoc 상속 규칙

Javadoc이 문서를 자동 상속하는 우선순위:

1. 인터페이스 → 클래스 순으로 탐색
2. 존재하지 않으면 상위 인터페이스/상위 클래스 체인 따라감
3. 가장 먼저 찾은 문서를 사용

→ 즉, 인터페이스 문서가 가장 강력한 API 계약이 된다.

9. 링크 활용

복잡한 API라면 문서에 관련 클래스, 패키지 링크를 제공하는 것이 좋다.

See {@link java.util.Collections}

10. Javadoc 품질 검사

IDE와 JDK 자체에 Javadoc 검증 기능이 있음 (문서 누락, 태그 오류 등을 자동 검사)

정리 ✔ 공개된 API요소에는 반드시 Javadoc 작성 ✔ 메서드는 "계약(전제조건·사후조건·부작용)"을 정확히 문서화 ✔ 코드/HTML 안전성을 위해 {@code}, {@literal} 적극 활용 ✔ 상속용 API는 반드시 @implSpec 사용 ✔ 제네릭/Enum/Annotation 모두 문서화해야 함 ✔ thread-safety / serialization 도 문서에서 필수 ✔ Javadoc 상속 규칙 준수 (인터페이스 문서 = 최우선 계약)

참고 블로그: https://github.com/back-end-study/effective-java/tree/main/8%EC%9E%A5_%EB%A9%94%EC%84%9C%EB%93%9C

• 검색 엔진 인덱싱: 크롤러는 웹 페이지를 모아 검색 엔진을 위한 로컬 인덱스 만듦
• 웹 아카이빙: 나중에 사용할 목적으로 장기보관하기 위해 웹에서 정보를 모음
• 웹 마이닝
• 웹 모니터링

1단계 문제 이해 및 설계 범위 확정

• 웹 크롤러의 기본 알고리즘

1. 초기 URL 집합을 입력으로 받는다.
2. 각 URL에 연결된 웹 페이지를 다운로드한다.
3. 페이지를 파싱하여 새로운 URL을 추출한다.
4. 추출된 URL을 ‘다운로드할 URL 목록’에 추가한다.
5. 위 과정을 반복하여 탐색을 확장한다.

2단계 개략적 설계안 제시 및 동의 구하기

• 시작 URL 집합: 탐색을 시작할 초기 URL 그룹.
• 미수집 URL 저장소
  • 다운로드할 URL들을 FIFO 큐 방식으로 처리
• HTML 다운로더: HTTP 요청을 통해 페이지를 가져옴.
• 도메인 이름 변환기 (DNS Resolver):
  • URL을 IP 주소로 매핑하며, 캐싱을 통해 성능 향상.
• 콘텐츠 파서
  • 이상한 웹페이지는 문제 발생 & 저장공간 낭비, so 파싱과 검증 절차를 거쳐야 함.
  • 추가로, 크롤링 서버 안에 콘텐츠 파서를 구현하면 크롤링 과정이 느려지게 될 수 있으므로 독립된 컨포넌트로 만듦
• 중복된 컨텐츠인가?
  • 웹 페이지 해시값(예: MD5, SHA-1)을 활용해 동일 콘텐츠 판별.
  • 실제 웹의 약 25~30%가 중복 콘텐츠로 추정됨.
• 콘텐츠 저장소
  • HTML 문서를 보관하는 시스템
  • 데이터 양이 너무 많을 땐, 대부분의 콘텐츠는 디스크에 저장
  • 인기 있는 콘텐츠는 메모리에 두어 접근 지연시간 줄임
• URL 추출기
  • HTML 페이지를 파싱하여 링크들을 골라내는 역할
• URL 필터
  • 특정 조건(정규 표현식, 도메인 제한, 파일 확장자 등)에 해당하는 URL들을 크롤링 대상에서 배제하는 역할
• 이미 방문 URL?
  • 블룸 필터나 해시 테이블로 처리
• URL 저장소
  • 이미 방문한 URL 보관하는 저장소

3단계 상세 설계

DFS를 쓸 것인가, BFS를 쓸 것인가

웹은 유향 그래프나 같다. 페이지는 노드이고 하이퍼링크(url)은 edge라고 보면 된다.

• 그래프 탐색에는 보통 DFS, BFS가 많이 쓰이는데 DFS는 그래프 크기가 클 경우 어느 정도로 깊숙이 가게 될지 가늠이 어렵기에 좋은 선택이 아닐 가능성이 높다.

  그래서!! 웹 크롤러는 보통 BFS(너비 우선 탐색법)을 사용한다. BFS는 FIFO 큐를 사용한다. 큐의 한쪽으론는 탐색할 URL을 집어넣고, 다른 한쪽으로는 꺼내기만 한다. 하지만 이 구현법에는 두 가지 문제점이 있다. 1) 한 페이지에서 나오는 링크의 상당수는 같은 서버로 되돌아간다. 위키피디아 페이지에서 추출한 링크가 내부 링크, 위키피디아 서버의 다른 페이지를 참조하게 되는...그럼 위키피디아 서버는 수많은 요청으로 과부하가 걸리게 된다. 2) BFS는 URL 간에 우선순위를 두지 않는다. 하지만 페이지 순위, 사용자 트래픽의 양, 업데이트 빈도에 따라 우선순위 구별이 필요하다.

  미수집 URL 저장소

  미수집 URL 저장소로 위 문제 해결 가능!

  1) 예의 예의 바른 크롤러를 만드는 데 있어서 지켜야 할 한 가지 원칙은, 동일 웹 사이트에 대해서는 한 번에 한 페이지만 요청한다는 것이다. 2) 우선순위

  • 페이지랭크, 트래픽 양, 갱신 빈도
  • 순위결정장치: URL을 입력으로 받아 우선순위를 계산한다.
  • 전면 큐, 후면 큐 3) 신선도 모든 URL을 재수집하는 건 비효율 적. 최적화 전략: 웹 페이지의 변경 이력 활용, 우선순의를 활용하여 중요 페이지 더 자주 재수집

HTML 다운로더

• Robots.txt
• 성능 최적화
  • 분산 크롤러 구조: 여러 서버 간 작업 분할.
  • DNS 캐싱: 동일 도메인 요청 시 이름 해석 비용 최소화.
  • 네트워크 지역성(Locality): 지리적으로 가까운 서버 우선 요청.
  • 짧은 타임아웃: 응답이 느린 서버로 인한 병목 방지.
• 안정성
  • 크롤링 상태 및 수집 데이터 저장: 중단되었던 크롤링을 쉽게 재시작할 수 있게
  • 장애 시 안정 해시(Consistent Hashing) 로 URL 재분배.
  • 예외 처리 및 재시도 로직 존재.
• 확장성
• 문제 있는 콘텐츠 감지 및 회피
  • 중복 콘텐츠 (해시나 체크섬 사용)
  • 거미 덫: 크롤러를 무한 루프에 빠지게 함, 최대 길이를 제한하기
  • 데이터 노이즈: 가치 없는 콘텐츠들 예외

4단계 마무리

시간이 허락한다면 다음과 같은 것을 추가로 논의해보면 좋다.

• 서버 측 렌더링(동적 렌더링)
• 원치 않는 페이지 필터링
• 데이터베이스 다중화 및 샤딩
• 수평적 규모 확장성
• 가용성, 일관성, 안정성
• 데이터 분석 솔루션

접근 방식

• arr를 계속 갱신하면서 가장 자리 판별하면 될듯
  • 가장자리란? 상하좌우 중 한 곳이라도 치즈가 없으면 탈락!
  • 가장자리인 곳은 2로 바꿔서.. 판별하면 되지 않을까
• 답은 Queue로 만들어서 size 출력하고 poll()하기
• 처음엔 어떤 알고리즘을 적용해야될지 감이 안 잡혀서 일단 for문을 엄청 돌렸다...

잘못 구현한 부분

• 메인 해결 방법이 외부 공기를 매 턴 BFS로 다시 찾아야 한다는 것이 핵심이었다.
• 가장자리인 곳을 2로 바꾸고 없애는 코드를 안 넣었었다..

  time = 0
  lastMelt = 0
  

while (true): 외부공기 BFS() melt = 이번 턴에 녹일 치즈 리스트 if melt.size == 0: break lastMelt = melt.size melt 치즈를 모두 arr에서 0으로 바꿈 time++

## 왜 bfs? 
- dfs로도 가능하다고 함
- 외부 공기에 닿은 영역만 색출해내야 하니까, 내부 공기쪽은 XX
```java
// 빈 공간(0) → 계속 BFS 진행
if (arr[nx][ny] == 0) {
    visited[nx][ny] = true;
    q.add(new int[]{nx, ny});
}

// 치즈(1) → 외부공기와 닿았으므로 녹일 대상
else if (arr[nx][ny] == 1) {
    visited[nx][ny] = true;
    meltList.add(new int[]{nx, ny});
}

• 위 처럼 한번 닿았으면 visited=true 처리해서 더이상 깊게 안 들어가게 한다!

정답 코드

package algo.ct.M12;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class BOJ_2636_치즈_G5 {
    static int n, m;
    static int[][] arr;
    static boolean[][] visited;
    static int[] dx = {-1, 1, 0, 0};
    static int[] dy = {0, 0, -1, 1};

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        n = Integer.parseInt(st.nextToken());
        m = Integer.parseInt(st.nextToken());
        arr = new int[n][m];

        for (int i = 0; i < n; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < m; j++) {
                arr[i][j] = Integer.parseInt(st.nextToken());
            }
        }

        int time = 0;      // 총 시간
        int lastMelt = 0;  // 마지막에 녹은 치즈 개수

        while (true) {
            // 매 턴마다 외부 공기 범위가 달라지니까
            visited = new boolean[n][m];

            // 이번 턴에 녹을 치즈들
            List<int[]> meltList = bfs();  

            if (meltList.size() == 0) {
                // 녹일 치즈가 없으면 종료
                break;
            }

            lastMelt = meltList.size();
            time++;

            // 실제로 치즈 녹이기
            for (int[] cur : meltList) {
                arr[cur[0]][cur[1]] = 0;
            }
        }

        System.out.println(time);
        System.out.println(lastMelt);
    }

    // 외부 공기를 BFS로 탐색하면서, 외부 공기와 닿은 치즈를 meltList에 담아 반환
    public static List<int[]> bfs() {
        Queue<int[]> q = new LinkedList<>();
        List<int[]> meltList = new ArrayList<>();

        // 항상 외부 공기는 (0,0)에서 시작
        q.add(new int[]{0, 0});
        visited[0][0] = true;

        while (!q.isEmpty()) {
            int[] cur = q.poll();
            int x = cur[0];
            int y = cur[1];

            for (int i = 0; i < 4; i++) {
                int nx = x + dx[i];
                int ny = y + dy[i];

                // 범위 밖
                if (nx < 0 || ny < 0 || nx >= n || ny >= m) continue;

                if (visited[nx][ny]) continue;

                // 빈 공간(0) → 계속 BFS 진행
                if (arr[nx][ny] == 0) {
                    visited[nx][ny] = true;
                    q.add(new int[]{nx, ny});
                }

                // 치즈(1) → 외부공기와 닿았으므로 녹일 대상
                else if (arr[nx][ny] == 1) {
                    visited[nx][ny] = true;
                    meltList.add(new int[]{nx, ny});
                }
            }
        }

        return meltList;
    }
}

접근 방식

• 처음에는 어떤 방식으로 풀어야되지? 잘 모르겠어서 코드부터 써봤는데 알고보니 구현문제여서 그럴 수 밖에 없었다.
• n, dasom까지 받고 나머지를 배열로 받아 계속 Array.sorts하면서 비교했다.
• Array.sorts를 하면 내림차순으로 되는 줄 알고.. 있었는데 출력해보니 오름차순으로 정렬된다는 점을 알았다.

내 코드 & 개선할 점

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class BOJ_1417_국회의원선거_S5 {
    static int n, m;
    static int result = 0;
    static int dasom;
    static int[] arr;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        n = Integer.parseInt(br.readLine());
        dasom = Integer.parseInt(br.readLine());

        if (n > 1) {
            arr = new int[n - 1];
            for (int i = 0; i < n - 1; i++)
                arr[i] = Integer.parseInt(br.readLine());

            while (true) {
                if (dasom <= arr[n - 2]) {
                    arr[n - 2]--;
                    dasom++;
                    result++;
                } else if (dasom > arr[n - 2])
                    break;
            }
        }

        System.out.println(result);
    }
}

• S5 정도는 혼자 10분 내로 수월하게 풀 수 있는 정도인 것 같다. 그래서 더 시간이 짧은 다른 코드들을 참고했고 매번 돌면서 Arrays.sort가 실행되는 게 느리다는 것을 알게 되었다.

개선된 코드

import java.io.*;
import java.util.*;
public class Main {


    public static void main(String[] args) throws Exception{
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        int N = Integer.parseInt(br.readLine());

        int[] input = new int[N];
        for (int i = 0; i < N; i++) {
            input[i] = Integer.parseInt(br.readLine());
        }

        int num = 0;
        int vote = input[0];
        int answer=0;

        while(true){

            for (int i = 0; i < N; i++) {
                if(input[i] >= vote){
                    num = i;
                    vote = input[i];
                }
            }

            if(num == 0) break;

            input[0]++;
            input[num]--;
            answer++;
ㅐ
            vote = -1;
        }

        System.out.println(answer);
    }
}

가장 득표 많은 사람 찾기

for (int i = 0; i < N; i++) {
    if(input[i] >= vote){
        num = i;
        vote = input[i];
    }
}

• 전체 후보의 득표를 훑어서(0 ~ N-1)

• vote보다 크거나 같으면, ㅐ 이 루프가 끝나면:

• num → 가장 득표 높은 후보의 index

• vote → 그 후보의 득표수

다솜이 1등이면 종료

if(num == 0) break;

• num == 0 이면 1등이 다솜이므로 더 이상 뺏을 필요 없음.

다솜이 1등이 아니면 표 한 표 뺏어오기

input[0]++;     // 다솜 표 +1
input[num]--;   // 가장 강한 경쟁자 표 -1
answer++;       // 매수 횟수 증가

즉, 가장 위험한 경쟁자에게서 표를 뺏어서 다솜에게 줌*

다음 반복 준비

vote = -1;

• vote = -1 로 초기화해서 다음 for문에서 정상적으로 갱신되도록 함

1. 매 반복마다 “현재 최고 득표자”를 찾고
2. 그 사람에게서 표를 1개 가져와서 다솜에게 줘서
3. 다솜이 가장 높은 득표를 얻을 때까지 반복

즉, 다솜이 확실히 1등이 될 때까지 최소 횟수로 표를 훔치는 그리디 알고리즘.

멀티쓰레딩은 현대 애플리케이션에서 필수적인 개념이며, 특히 웹 서버·백엔드 개발에서는 요청을 병렬로 처리하기 위해 스레드 활용이 매우 중요합니다. 아래에서 Java의 스레드 생성 방식부터 스레드 풀과 스프링이 대규모 스레드 풀을 사용하는 이유까지 정리해보겠습니다.

✅ 1. Java에서 스레드를 만드는 방법

Java에서 스레드를 만드는 방법은 크게 세 가지입니다.

1) Thread 클래스를 상속

class MyThread extends Thread {
    @Override
    public void run() {
        System.out.println("Thread running");
    }
}

new MyThread().start();

특징

• 간단하지만, 이미 다른 클래스를 상속받고 있다면 사용 불가(단일 상속 제한)
• 재사용성이 낮음

2) Runnable 인터페이스 구현 (가장 일반적인 방식)

class MyTask implements Runnable {
    @Override
    public void run() {
        System.out.println("Task running");
    }
}

new Thread(new MyTask()).start();

특징

• 스레드 실행 로직(run)을 캡슐화
• Thread와 작업(task)을 분리하여 더 유연하게 사용 가능
• ThreadPoolExecutor 같은 스레드 풀에서 사용되는 기본 구조

3) Callable + Future (값 반환 + 예외 처리 가능)

Callable<Integer> task = () -> {
    return 42;
};

Future<Integer> result = Executors.newSingleThreadExecutor().submit(task);
System.out.println(result.get());

특징

• Runnable과 달리 결과 반환 및 예외 전파가 가능
• 비동기 작업에서 자주 사용

✔ 정리하면

✅ 2. 스레드 풀(Thread Pool)이란 무엇인가?

스레드 풀은 미리 여러 개의 스레드를 만들어 놓고 필요할 때 가져다 쓰는 구조입니다.

Java에서는 ExecutorService, ThreadPoolExecutor로 구현되어 있습니다.

장점

1) 스레드 생성 비용 절감

• 스레드를 새로 만드는 비용은 생각보다 매우 무겁다

  • OS 레벨에서 메모리 할당(Stack)
  • 커널에 스레드 등록
  • 스케줄러 관리 대상 추가 → 요청마다 새로 스레드를 만드는 것은 비효율적

2) 과도한 스레드 생성 방지

• 스레드를 계속 만들면?

  • 메모리 초과
  • CPU 문맥 교환(Context Switching) 폭증
  • 성능 급락

스레드 풀은 동시에 실행 가능한 스레드 개수를 제한하여 이를 제어한다.

3) 안정적인 시스템 운영

• 요청이 몰려도 스레드 수가 일정하게 유지되므로 시스템 과부하 방지
• Queue에 쌓아두고 순차적으로 처리 가능

✔ 스레드 풀의 종류 (Executors)

• newFixedThreadPool(n) : 고정 개수 스레드
• newCachedThreadPool() : 필요할 때 늘렸다가 비면 제거
• newSingleThreadExecutor() : 1개 스레드
• ThreadPoolExecutor : 직접 정책 설정(실무에서 가장 많이 사용)

✅ 3. 스프링(서버 프레임워크)은 왜 스레드 풀을 수백 개 이상으로 설정할까?

스프링 기반 웹 서버(Tomcat, Netty 등)는 보통 200~300개 이상의 스레드 풀을 사용합니다. 이는 문맥 교환(Context Switching)이 발생함에도 불구하고 선택하는 구조인데, 이유는 다음과 같습니다.

✔ 이유 1. 서버의 대기 시간이 CPU를 거의 사용하지 않기 때문

웹 서버의 대부분 시간은 I/O 대기 시간입니다.

• DB 응답 기다림
• Redis 대기
• 외부 API 응답 대기
• 파일/네트워크 I/O 대기

➡ CPU를 쓰는 시간이 매우 적다.

즉, 스레드는 일하는 시간이 짧고 기다리는 시간이 길다.

따라서 스레드가 많다고 해서 CPU를 과도하게 사용하지 않는다.

✔ 이유 2. I/O Bound 작업은 많은 스레드를 둘수록 처리량(Throughput)이 증가됨

CPU Bound 작업이면 스레드가 많으면 오히려 느려지지만, 웹 서버는 대부분 I/O Bound.

즉, 스레드 300개가 모두 일을 하는 것이 아니라

• 대부분 대기 상태(Waiting)
• 일부만 CPU를 점유

그래서 문맥 교환 비용보다 동시성(concurrency) 증가로 얻는 이익이 훨씬 크다.

✔ 이유 3. 웹 요청 자체가 동시성이 매우 높음

하나의 웹 서버에서 수백 개~수천 개의 요청이 동시에 들어온다.

만약 스레드가 50개뿐이라면?

• 나머지 요청은 전부 대기
• 응답 지연 증가
• 서버 처리량 감소

➡ 실무에서는 최소 200~300개 스레드를 둠

✔ 이유 4. 스프링 MVC는 요청당 스레드 1개가 필요 (Tomcat worker thread)

스프링 MVC는 Blocking I/O 모델이다.

• 요청 1개 → 스레드 1개 고정 점유
• DB 응답 기다리는 동안에도 스레드는 점유됨

따라서 처리량을 확보하려면 스레드 수를 많이 둘 수밖에 없다.

스프링 WebFlux(Non-blocking)는 스레드 수가 매우 적게 필요하지만 전통적인 MVC는 request-per-thread 구조라 스레드 풀을 크게 잡아야 한다.

✔ 정리: 문맥 교환 비용보다 더 큰 이득이 있기 때문

Context Switching 비용은 분명 존재한다. 하지만 서버 환경에서는 다음이 더 중요하다.

• I/O 대기 시간이 훨씬 크다
• 동시 접속 요청이 많다
• 스레드가 대부분 Waiting 상태다
• 스레드가 부족하면 처리량이 급격히 떨어진다

➡ 그래서 스레드 수백 개 운영이 훨씬 효율적

📌 정리

Java에서 스레드는 Thread 상속, Runnable 구현, Callable을 통해 생성할 수 있다. 하지만 요청마다 스레드를 새로 만드는 것은 비용이 커서, 보통 스레드 풀(Thread Pool)로 스레드를 재사용한다. 스프링을 포함한 대부분의 서버 프레임워크는 수백 개 이상의 스레드를 운영하는데, 이는 웹 서버의 대부분 로직이 CPU 작업이 아닌 DB·외부 API·네트워크 I/O 대기로 이루어져 있기 때문이다. 즉, 스레드는 CPU를 거의 사용하지 않고 대부분 대기 상태라 많은 스레드를 두어도 오버헤드보다 동시 처리량 증가의 이점이 훨씬 크다. 요청당 스레드를 하나씩 점유하는 스프링 MVC 구조에서는 특히 많은 스레드를 둘수록 안정적인 처리량을 확보할 수 있다.

처음 접근했을 때

• bfs(int idx, int depth)로 한번만 main 메소드에서 실행시켜서 depth가 2를 초과되면 return하게 해야하나?라는 생각이 들어 그렇게 구현했는데
  • 언제 return해야되는지... 이게 한번만 쭉 갔다가 되돌아오면 되는 게 아니라 depth가 2이하인 모든 곳을 방문해야하는데 그걸 구현하는 부분에서 막혔다.
• 일단 보자마자 BOJ 1260번 떠올라서 그거 코드를 생각하고 ArrayList<ArrayList<Integer>>로 구현한 건 잘했다...

잘못 판단한 부분

일단 너무 많은 걸 잘못했는데 ^^..

• 처음에 visited가 필요없을 거라고 생각했다. 왜지? 좀더 침착히 설계하도록.....
• 아래를 arr.add가 아니라 매번 선언하고 있었다... (arr = new ArrayList<>(); -> 뭐하세요?)

  for (int i = 0; i <= n; i++)
   arr.add(new ArrayList<>());

• bfs(idx, depth)가 아니라 bfs 안에서 depth는 따로 처리하면 된다.
• if (dep == 2) continue; 이 부분을 어디서 끊어줘야될지 헷갈렸다..
  • 결론적으로는 for문 전에 왜냐면 dep가 2면 더 들어가면 안되니까.. q.add()쪽을 못 가게 해야되니까..
• result++; 이것도 어디서 해야될지 고민됐다..
  • 일단 저기까지 왔다는 거는 dep이 2 미만이라는 것. 2라면 그 전에 continue 처리됐을 꺼니까
  • 그래서 방문하지 않았다면 방문 처리해주고 result++로 결혼식에 와라! 처리해주고 q.add() 처리해서 그 다음 친구도 볼 수 있게 하면 된다.
• for문의 역할 for (int next : arr.get(cur))
  • 지정된 cur과 연결된 친구를 끝까지 보는 역할 (dep는 계속 체크해주니까 안심하고..)

정답 코드

package algo.ct.M12;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.LinkedList;
import java.util.Queue;
import java.util.StringTokenizer;

public class BOJ_5567_결혼식_S2 {
    static int n, m;
    static ArrayList<ArrayList<Integer>> arr = new ArrayList<>();
    static int result = 0;
    static boolean[] visited;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        n = Integer.parseInt(br.readLine()); // 동기 수
        m = Integer.parseInt(br.readLine()); // 리스트 길이

        for (int i = 0; i <= n; i++)
            arr.add(new ArrayList<>());
        visited = new boolean[n+1];

        for (int i = 0; i < m; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());
            arr.get(a).add(b);
            arr.get(b).add(a);
        }

        bfs(1);
        System.out.println(result);
    }

    public static void bfs(int idx) {
        Queue<int[]> q = new LinkedList<>();
        q.add(new int[]{idx, 0});
        visited[idx] = true;

        while (!q.isEmpty()) {
            int[] now = q.poll();
            int cur = now[0];
            int dep = now[1];

            if (dep == 2) continue;

            for (int next : arr.get(cur)) {
                if (!visited[next]) {
                    visited[next] = true;
                    result++;
                    q.add(new int[]{next, dep + 1});
                }
            }
        }
    }
}

접근 방식

• 숫자 조합 + 연산자 조합을 일단 만들어서
• 그걸 계산한 후에
• Math.max, Math.min으로 계산하기 이렇게 3단계로 나눠야겠다고 생각했다.

헷갈렸던 부분

1. 숫자 조합과 연산자 조합 따로인줄

그래서 dfs 메소드를 두개로 나눠서 이걸 어떻게 조합하지..? StringBuilder? 이러고 헤맸는데 알고보니 dfs 안에서 백트래킹을 이용하면 다 해결가능했던 것..

• 숫자 조합은 매번 계산해서 결과 값을 넘겨주면 되고

• 연산자는 아래처럼 재귀를 사용하면 모든 경우 조합 가능하다

          for (int i = 0; i < 4; i++) {
            if (operator[i] > 0) {
                operator[i]--;
  
                int next = calculate(currentValue, arr[depth], i);
  
                dfs(depth + 1, next);
                operator[i]++; // 백트래킹
            }
        }

2. 넘겨주는 값 확인 잘하기

• dfs(1, arr[0])
  • 위 부분을 dfs(0, 0)으로 잘못 넣고 있어서 매우 이상한 값이 답으로 나옴
  • 애초에 처음부터 arr[0]을 결과값으로 넣으면 되기 때문에 arr[0]을 currentValue로 넣고
  • depth도 1부터 시작해야 N까지 탐색 가능하다.
    • 0부터 N-1이면 N번 탐색은 가능하지만 arr[N-1] 탐색이 안되기 때문에 안됨!
    • 아래 calculate 메소드 넘겨줄 때 arr[depth] 넘겨주니까~ 주의
• calculate(int sum, int num, int op)
  • 여기도 처음에 op이 아니라 operator[i]를 넘기고 있었다... 걍 생각없이 매개변수 넘기는 듯.. 주의하기

3. 나눗셈 간단하게 구현하기

          if (op == 3) {
            if (sum < 0 && num < 0) {
                sum *= -1;
                num *= -1;
                sum /= num;
            }
            else if (sum < 0) {
                sum *= -1;
                sum /= num;
                sum *= -1;
            }
            else if (num < 0) {
                num *= -1;
                sum /= num;
                sum *= -1;
            }
            else {
                sum /= num;
            }

• 음수일 경우를 판단하느라 노.가.다로 풀었는데 알고보니 아래 코드면 해결된다고 한다..
• 지금 보니 위 코드에서 num < 0은 왜 확인한거지;;

        if (op == 3) {
          if (sum < 0) return - ( Math.abs(sum) / num );
          else return sum / num;
      }

정답 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class BOJ_14888_연산자끼워넣기_S1 {
    static int N;
    static int[] arr;
    static int[] operator = new int[4]; // +, -, x, ÷
    static int maxAnswer = Integer.MIN_VALUE;
    static int minAnswer = Integer.MAX_VALUE;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st;

        N = Integer.parseInt(br.readLine());
        arr = new int[N];

        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < N; i++)
            arr[i] = Integer.parseInt(st.nextToken());
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < 4; i++)
            operator[i] = Integer.parseInt(st.nextToken());

        // 숫자조합
        // 연산자조합
        //index: arr에서 현재 몇 번째 숫자를 사용할지
        //currentValue: 앞까지 계산된 결과
        dfs(1, arr[0]);
        // 그 조합끼리 계산

        System.out.println(maxAnswer);
        System.out.println(minAnswer);

    }

    public static void dfs(int depth, int currentValue) {
        if (depth == N) {
            maxAnswer = Math.max(currentValue, maxAnswer);
            minAnswer = Math.min(currentValue, minAnswer);
            return;
        }

        for (int i = 0; i < 4; i++) {
            if (operator[i] > 0) {
                operator[i]--;

                int next = calculate(currentValue, arr[depth], i);

                dfs(depth + 1, next);
                operator[i]++; // 백트래킹
            }
        }

    }

    public static int calculate(int sum, int num, int op) {
        if (op == 0)
            sum += num;
        if (op == 1)
            sum -= num;
        if (op == 2)
            sum *= num;
        if (op == 3) {
            if (sum < 0) return - ( Math.abs(sum) / num );
            else return sum / num;
        }

        return sum;
    }
}

중복 조합(Combination with Repetition)

📌 문제 요약

N과 M이 주어졌을 때,

• 1부터 N까지 자연수 중에서
• 중복을 허용해서
• 비내림차순(오름차순 유지)으로
• 길이가 M인 수열을 모두 출력

예: N=4, M=2라면

1 1
1 2
1 3
1 4
2 2
2 3
2 4
3 3
3 4
4 4

이런 식의 "중복 조합" 형태가 나온다.

핵심 개념 정리

✔ 왜 start 파라미터가 필요할까?

중복은 허용하지만 비내림차순(이전 값보다 작으면 안 됨) 을 유지해야 한다.

즉,

• 이전에 선택한 값(i)을 다음 depth에서도 최소값으로 유지해야 오름차순이 유지됨
• 그래서 for (int i = start; i <= N; i++) 로 시작

start 가 핵심이다.

흐름 시각화 - 헷갈렸음..

예시: N=3, M=2

depth=0, start=1

dfs(0,1)
 └ i=1 → arr[0]=1
       → dfs(1,1)
           └ i=1 → arr[1]=1 → dfs(2,1) → 출력: 1 1
           └ i=2 → arr[1]=2 → 출력: 1 2
           └ i=3 → arr[1]=3 → 출력: 1 3
           └ i=4 → arr[1]=4 → 출력: 1 4
 └ i=2 …

시간 복잡도

전체 탐색 개수

중복 조합의 개수는

N,M ≤ 8 이므로 최대 약 6435개 정도.

한 수열을 만드는 비용

배열 8개 채우는 수준 → O(M)

🔥 전체 시간

6천 × 8 = 약 5만 연산

➡ Java에서는 0.001초 수준 ➡ 시간초과 걱정 전혀 없음

✅ 최종 코드

package algo.ct.M11;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class BOJ_15652_N과M4_S3 {
    static int[] arr;
    static int N, M;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());
        arr = new int[M];

        dfs(0, 1);
    }

    public static void dfs(int depth, int start) {
        if (depth == M) {
            for (int i = 0; i < M; i++)
                System.out.print(arr[i] + " ");
            System.out.println();
            return;
        }

        for (int i = start; i <= N; i++) {
            arr[depth] = i;
            dfs(depth + 1, i);
        }
    }
}

헷갈렸던 판단 부분

• start 값을 어디서부터 해야할지..
• 백트래킹인데 arr 되돌리는 코드 필요 없는 이유 -> 덮어쓰기라서

문제 요약

N×N 지도에서

• 1 → 집이 있는 곳
• 0 → 집이 없는 곳

상하좌우로 연결된 집들은 하나의 단지를 이룬다.

해야 할 일:

1. 전체 단지 개수를 구하고
2. 각 단지의 집 수를 오름차순으로 출력

핵심 개념

이 문제의 구조는 전형적인 2차원 BFS/DFS 영역 탐색 문제이다.

단지를 찾기 위해 필요한 조건

• 인접한 1들이 연결된 “덩어리” → 영역 탐색 문제
• 문제에서 “상하좌우"만 연결이라고 명시 → 대각선 X
• 단지마다 개수를 세어야 함 → BFS(또는 DFS)에서 count 증가

BFS가 필요한 이유

• 큐를 이용해 현재 위치에서 갈 수 있는 모든 ‘연결된 집’을 탐색
• 방문 체크로 중복 방문 방지
• 모든 단지를 탐색하기 위해 전체 map(N×N)을 훑으면서 BFS 시작 조건을 찾음

시간 복잡도 분석

지도 크기

• N ≤ 25
• 최대 칸 수: 25×25 = 625

모든 칸을 한 번씩만 방문한다.

💡 BFS 1회 시간

최대 625칸 → O(N²)

💡 BFS 시작점은 단지별로 다수일 수 있음

하지만 방문 체크 때문에 전체적으로 모든 칸은 단 한 번만 큐에 들어간다.

💡 전체 시간 복잡도

O(N²) = O(625)

연산량이 매우 적어서 Java·Python 모두 충분히 여유롭다.

풀이 흐름 정리

1. 입력을 받아 arr[][]에 저장

2. visited[][]로 방문 처리

3. (i, j)를 전체 순회하면서

   • 아직 방문하지 않고
   • arr[i][j] == 1인 지점이라면 → 새 단지 시작 → BFS 실행

4. BFS에서 연결된 모든 집 카운트

5. 단지 수 + 단지 내 집 수 기록

6. 오름차순 정렬 후 출력

🔍 BFS 템플릿 핵심

Queue<int[]> q = new LinkedList<>();
q.add(new int[]{x, y});
visited[x][y] = true;

while (!q.isEmpty()) {
    int[] cur = q.poll();

    for (4방향) {
        좌표 유효성 검사
        1인지 검사
        방문했는지 검사
        → 조건 통과 시 q.add()
        → visited = true
        → count++
    }
}

✅ 최종 코드

package algo.ct.M11;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class BOJ_2667_단지번호붙이기_S1 {
    static int N;
    static boolean[][] visited;
    static int[][] arr;
    static int[] nx = {-1, 1, 0, 0};   // 상하좌우
    static int[] ny = {0, 0, -1, 1};
    static ArrayList<Integer> answer = new ArrayList<>();

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        N = Integer.parseInt(br.readLine());
        arr = new int[N][N];
        visited = new boolean[N][N];

        // 지도 입력
        for (int i = 0; i < N; i++) {
            String line = br.readLine();
            for (int j = 0; j < N; j++) {
                arr[i][j] = line.charAt(j) - '0';
            }
        }

        // 전체 순회하며 단지 시작점 찾기
        for (int i = 0; i < N; i++) {
            for (int j = 0; j < N; j++) {
                if (arr[i][j] == 1 && !visited[i][j]) {
                    int cnt = bfs(i, j);
                    answer.add(cnt);
                }
            }
        }

        Collections.sort(answer);
        System.out.println(answer.size());
        for (int cnt : answer)
            System.out.println(cnt);
    }

    // BFS로 단지 하나의 집 개수 세기
    public static int bfs(int x, int y) {
        visited[x][y] = true;
        Queue<int[]> q = new LinkedList<>();
        q.add(new int[]{x, y});
        int count = 1;

        while (!q.isEmpty()) {
            int[] cur = q.poll();
            int curX = cur[0];
            int curY = cur[1];

            for (int i = 0; i < 4; i++) {
                int nextX = curX + nx[i];
                int nextY = curY + ny[i];

                if (nextX < 0 || nextY < 0 || nextX >= N || nextY >= N) continue;
                if (visited[nextX][nextY]) continue;
                if (arr[nextX][nextY] == 0) continue;

                visited[nextX][nextY] = true;
                q.add(new int[]{nextX, nextY});
                count++;
            }
        }

        return count;
    }
}

💡 헷갈렸던 판단 부분

• BFS 반복문 안에서 count 증가하는 타이밍은? → q에 추가될 때 (= 실제로 방문할 때)

• 4방향 탐색은 while 문 안에 !!

• 시간복잡도!!! 📌 “총 반복 횟수 × 한 반복에서의 처리 비용” 그 결과가,

  🟢 1천만(10⁷) 이하 → 매우 여유로움 🟡 1억(10⁸) 정도 → borderline (언어 따라 통과/시간초과 나뉨) 🔴 10억(10⁹) 이상 → 대부분 시간초과

  ✔ 단지번호붙이기 같은 경우.. N ≤ 25 → N² = 625 여기서 BFS·DFS는 각 칸을 최대 한 번 방문

  ➤ 전체 연산량: 최대 625번 O(N²) = 625

  625는 자바 기준으로 1억 연산 중 0.0006% 정도밖에 안 됨.