Hello world

Docker IP 대역 변경

말차쟁이 — Wed, 3 Dec 2025 18:04:27 +0900

IP 대역을 변경해야 하는 이유

우리 회사의 서비스는 Docker 기반이며 고객사 서버에 배포하는 방식으로 구축한다.

어느 한 고객사에도 마찬가지로 Docker 기반으로 배포하여 개발을 하던 중 고객사에서 우리가 사용 중인 특정 IP 대역을 다른 IP 대역으로 변경해 달라는 요청이 들어왔다.

특정 IP 대역은 서비스를 배포한 Docker에서 사용 중이었기 때문에 Docker의 IP 대역을 변경해야 한다는 뜻이었다. Docker의 IP 대역을 변경해본 적이 없어서... 가능한건가? 라는 생각이 들었지만 여러 블로그 글들을 보며 해결하여 사내에도 공유했다.

요청사항

`172.17.x.x` `172.18.x.x` 대역 모두 고객사 사내망에서 사용 중이므로 변경요청
변경할 IP 대역 : `100.64.x.x`

서비스가 설치된 호스트의 라우팅 테이블

라우팅 테이블

`172.17.x.x` : docker0
`172.18.x.x` : docker_gwbride

docker0, docker_gwbridge에서 `172.17.x.x` `172.18.x.x` 대역을 사용 중이므로 모두 라우팅 테이블에서 제외해야 한다.

docker0, docker_gwbridge의 IP

docker0

docker를 설치하면 `docker0`의 IP는 자동으로 `172.17.0.1`로 할당되며, 호스트의 eth0 네트워크 인터페이스와 직접적으로 연결되는 네트워크 인터페이스

docker_gwbridge

docker container 간 통신을 위한 docker swarm에 사용되는 네트워크 인터페이스

Docker IP 대역 변경

1. daemon.json 수정

docker 설정파일 수정 (없으면 생성)

/etc/docker/daemon.json

{
	"log-driver": "json-file",
	"log-opts": {
		"max-size": "10m",
		"max-file": "3"
	},
	"bip": "100.64.x.x",
	"default-address-pools": [
		{
			"base": "100.64.x.x",
			"size": 24
		}
	]
}

bip

docker가 사용하는 기본 bridge network 대역

default-address-pools.base

docker network가 사용하는 대역 (새로운 Docker network를 생성할 때 이 설정을 기반으로 IP 대역을 할당함)

docker 재시작

systemctl restart docker

docker0 인터페이스의 IP 대역이 변경된 것을 확인할 수 있다.

2. 설정 및 설치파일 수정

컨테이너 배포 설정 관련 파일 내에서 IP 변경(`100.64.x.x`)

.properties
.conf

3. docker_gwbridge 삭제 및 swarm 재설치

docker swarm leave --force
docker network rm docker_gwbridge

master, slave 구조라면 각각 위처럼 docker_gwbridge를 삭제한다.

그 후 master, slave 모두 swarm 재설치 및 join

4. 컨테이너 배포 및 재배포

컨테이너를 신규로 배포하거나 재배포한다.

docker0, docker_gwbridge 인터페이스 모두 IP 대역이 변경된 것을 확인할 수 있다.

참고

https://waspro.tistory.com/635

https://bluese05.tistory.com/15

https://velog.io/@lijahong/0부터-시작하는-Docker-Swarm-공부-더-자세한-Docker-Swarm-Network

https://velog.io/@loveelf1/Docker-default-network-대역-변경

Gson으로 파싱할 때 double 자동변환

말차쟁이 — Tue, 2 Dec 2025 22:37:57 +0900

실수형 데이터

회사에서 테스트하던 도중 데이터를 확인했는데 정수형(`Integer`)이어야 할 데이터가 실수형(`Double`)으로 들어가 있었다.

분명 클라이언트에서 넘어오는 파라미터도 정수형이었는데 뭐가 문제일까?

String json = "{\"params\":{\"num\":9999}}";
Host host = gson.fromJson(json, Host.class);

코드를 추적해보니 json 문자열 파라미터를 전달받은 후 `gson`을 이용해 객체로 변환할 때 객체의 필드가 실수로 변환되고 있었다.

실행결과

원인

`Gson`의 Object to Number 정책의 기본값이 `Double`이므로 따로 설정을 세팅해주지 않으면 `Double`로 변환되는 것이었다.

Gson의 기본 정책

해결

Gson을 커스텀해서 따로 util 클래스로 만들어 사용하고 있었는데 `gson` 인스턴스를 빌드할 때 Object to Number 변환정책을 `LONG_OR_DOUBLE`로 세팅함

public static Gson makeGson() {
    GsonBuilder builder = new GsonBuilder();
    ...
    builder.setObjectToNumberStrategy(ToNumberPolicy.LONG_OR_DOUBLE);

    return builder.create();
}

`LONG_OR_DOUBLE` : 숫자로 변환될 객체가 `Long` 또는 `Double` 타입으로 변환될 수 있을 때 해당 타입으로 변환

변환 우선순위

`Long`
`Double`

참고

https://velog.io/@kimnow/LocalDate-Gson-jackson

https://jcchu.medium.com/gson변환-시-int가-double로-773e5e81c105

CAS (Compare And Swap)

말차쟁이 — Thu, 13 Nov 2025 17:03:49 +0900

비동기적 동시성 제어 기법 중 하나로, 여러 스레드가 동시에 데이터를 수정하려고 할 때 데이터의 일관성을 보장하는 방법이다. CAS는 원자적 연산(atomic operation)으로, 멀티스레드 환경에서 안전하게 데이터를 읽고 쓸 수 있게 한다.

원자적 연산

컴퓨터 과학에서 사용하는 원자적 연산(atomic operation)은 해당 연산이 더 이상 나눌 수 없는 단위로 수행된다는 것을 의미한다.

int i = 0;

위와 같은 변수가 있을 때

`i = 1`

이 연산은 둘로 쪼갤 수 없는 원자적 연산이다.

단 하나의 순서로 실행되기 때문이다.

오른쪽에 있는 1을 왼쪽의 `i`변수에 대입한다.

`i = i + 1`

하지만 이 연산은 원자적 연산이 아니다.

다음 순서로 나누어 실행되기 때문이다.

오른쪽에 있는 `i`의 값을 읽는다. `i`의 값은 10이다.
읽은 10에 1을 더해서 11을 만든다.
11을 왼쪽의 `i`변수에 대입한다.

멀티스레드 환경

원자적 연산은 멀티스레드 환경에서 아무런 문제가 발생하지 않는다. 하지만 원자적 연산이 아닌 경우에는 synchronized나 Lock 등을 사용해서 안전한 임계 영역을 만들어야 한다.

원자적이지 않은 연산

public class AtomicInteger {
    private int value;

    public void increment() {
        value++;
    }

    public int get() {
        return value;
    }
}

public class AtomicMain {
    private static final int THREAD_COUNT = 10;
    private static AtomicInteger atomicInteger = new AtomicInteger();

    public static void main(String[] args) throws InterruptedException {
        List<Thread> threads = new ArrayList<>();

        for (int i=0; i<THREAD_COUNT; i++) {
            Thread thread = new Thread(new AtomicTask());
            threads.add(thread);
            thread.start();
        }

        for (Thread thread : threads) {
            thread.join();
        }

        System.out.println("atomicInteger: " + atomicInteger.get());
    }

    static class AtomicTask implements Runnable {
        @Override
        public void run() {
            for (int i=0; i<1000; i++) {
                atomicInteger.increment();
            }
        }
    }
}

위 코드를 실행했을 때 스레드 10개가 각각 1000번씩 `increment()`하기 때문에 기댓값은 10,000이다.

하지만 코드를 돌려보면 다른 결과가 나온다.

atomicInteger: 9690
atomicInteger: 9993
atomicInteger: 9874

왜 그럴까?

`AtomicInteger`의 `increment()`가 원자적이지 않기 때문이다.

public void increment() {
    value++;
}

`value++`은 `value = value + 1`와 같으며, 다음 순서로 실행된다.

`value`의 값을 읽는다.
`value`에 1을 더한다.
`value`에 1을 더한 값을 `value`에 대입한다.

여러 스레드들이 increment()를 실행할 때 어떤 스레드가 `value`에 1을 더해 `value`에 대입하기 전에 다른 스레드가 `value`

의 값을 읽어서 연산을 진행한다면 1을 더하는 연산이 누락되는 문제가 발생한다.

원자적 연산

public class AtomicInteger {
    private int value;

    public synchronized void increment() {
        value++;
    }

    public int get() {
        return value;
    }
}

`increment()`에 `synchronized`를 붙여준다면 기댓값인 10,000이 출력된다.

`synchronized`로 임계 영역을 설정해 연산을 원자적으로 수행하도록 했기 때문에 멀티 스레드 환경에서도 안전하게 동작했다.

Lock 기반 방식

멀티스레드 환경에서 공유 자원에 동시에 접근하는 문제(Race Condition)를 해결하기 위해 Lock을 사용하여 동시에 하나의 스레드만 접근하도록 제한하는 방식이다.

Lock이 걸려 있는 동안 다른 스레드들은 공유 자원에 접근할 수 없고, Lock이 해제될 때까지 대기해야 한다.

대표적으로 `synchronized` `Lock(ReentrantLock)`이 Lock 기반 방식에 속한다.

동작 방식

Lock이 있는지 확인
Lock을 획득하고 임계 영역에 들어감
작업 수행
Lock을 반납

Lock 기반 방식은 임계 구역을 Lock으로 제어하는 구조이기 때문에 직관적이고 유지보수가 용이하다는 장점이 있지만, 임계 영역에 접근할 때마다 Lock을 획득하고 해제하는 비용이 발생하기 때문에 상대적으로 비용이 비싼 방식이다.

Lock 프리(Free) 방식

Lock 기반 방식과 반대로 멀티스레드 환경에서 Lock을 사용하지 않고 동기화하는 방식이다.

Lock 대신 원자적 연산을 통해 공유 자원을 안전하게 변경한다. Lock을 완전히 대체하는 것은 아니고, 작은 단위의 일부 영역에 적용할 수 있다.

대표적으로 CAS(Compare And Swap) 연산이 있다.

CAS (Compare And Swap)

메모리의 값이 기댓값과 같다면 새로운 값으로 교체(Swap)하고, 그렇지 않으면 실패를 알리는 원자적(atomic) 연산이다.

성공/실패 여부가 반환되므로 실패하면 다시 시도하는 재시도 전략을 적용할 수 있다.

쉽게 말하면, 현재 값이 내가 예상한 값과 같다면 교체하는 연산이다.

동작 원리

CAS에 필요한 3가지 값

메모리 주소 : 변경하고자 하는 데이터의 위치
기댓값 (expected value) : 현재 메모리 주소에 저장된 값으로 예상되는 값
새로운 값 (new value) : 메모리 주소에 저장하고자 하는 새로운 값

public class AtomicInteger extends Number implements java.io.Serializable {
	...

	public final boolean compareAndSet(int expectedValue, int newValue) {
	    return U.compareAndSetInt(this, VALUE, expectedValue, newValue);
	}
}

CAS를 사용하는 `AtomicInteger` 클래스의 `compareAndSet()`를 보면 기댓값(`expectedValue`), 새로운 값(`newValue`)을 인자로 받아서 CAS를 수행한다.

자바에서 대표적으로 CAS를 사용하는 사례

java.util.concurrent.atomic 패키지의 클래스들 (`AtomicInteger` `AtomicLong` 등)
java.util.concurrent 패키지의 `ConcurrentHashMap`

내부적으로는 `Unsafe` 클래스의 CAS 메서드를 사용한다.

`compareAndSetReference()`

CAS 연산 과정

1. 읽기 (Read)

메모리 주소의 현재 값을 읽는다.

2. 비교 (Compare)

읽은 현재 값이 기댓값(`expected value`)과 같은지 비교한다.

3. 교체 (Swap)

다르다면 교체하지 않고 실패로 반환한다. (다른 스레드가 그 사이에 값을 변경했음을 의미함)

같다면 현재 값을 새로운 값(`new value`)으로 원자적(`Atomic`)으로 교체한다.

4. 결과 반환 (Return)

실패 시 : `false` (재시도 전략을 적용하거나, 다른 적절한 처리를 할 수 있도록 함)

성공 시 : `true`

어떻게 원자적일까?

대부분의 CPU(예: x86)는 `CMPXCHG` 같은 특수한 명령어를 제공하는데, 이 명령어는 메모리 주소에 대한 비교와 교체를 단일 명령어로 처리한다. CAS 과정 중 읽기, 비교, 교체를 원자적으로 수행한다는 뜻이다.

단일 명령어(원자적)으로 처리되기 때문에 CAS 중에는 다른 스레드나 CPU가 끼어들거나 값을 변경할 수 없다. 이것은 하드웨어 수준에서 원자성을 보장해준다는 것을 의미한다.

하드웨어 수준에서 보장해주는 원자성 덕분에 Lock 없이도 동시성 제어(Lock-Free)를 구현할 수 있다.

하지만 CAS는 메모리 가시성 문제와 결합되므로 프로그래밍 언어/플랫폼의 메모리 모델(예: Java Memory Model)에서 `volatile`혹은 메모리 배리어(memory barrier)를 통해 가시성을 보장해야 한다.

왜 CAS 연산 중 다른 CPU가 값을 변경하지 못할까?

CPU에서 `CMPXCHG`를 수행할 때, 해당 메모리 주소가 속한 캐시 라인에 대해서 독점적 접근 권한을 얻는다.

즉, 해당 캐시 라인이 다른 CPU의 캐시에 포함되어 있다면 접근 불가 상태로 변경되어 해당 CPU는 접근하지 못한다.

해당 메모리 주소에 대한 독점적 접근 권한은 MESI 캐시 일관성 프로토콜을 통해 얻게 되며, `CMPXCHG` 명령어가 처리될 때까지 해당 메모리 주소는 보호된다.

장점

Lock을 사용하지 않고 동시성를 제어할 수 있다.
Lock을 사용하지 않기 때문에 Lock 관련 오버헤드(문맥 교환, 교착 상태, Lock 획득/해제 비용)가 발생하지 않는다.
임계 영역에서 Lock을 사용하지 않기 때문에 스레드들이 블로킹되지 않기 때문에 성능이 더 좋아질 수 있다. 하지만 장점이자 단점이 될 수 있는데, 상황에 따라 다르다.
- 충돌 가능성이 낮은 상황 : 반복적으로 재시도하는 스핀 비용이 발생하지 않을 가능성이 높기 때문에 성능이 향상된다.
- 충돌 가능성이 높은 상황 : 반복적으로 재시도하는 스핀 비용이 발생할 가능성이 높기 때문에 성능이 저하된다.

단점

Busy-wait
- CAS는 CPU가 메모리를 확인하고 수정하기 위해 반복적으로 재시도하기 때문에, 값이 변경될 때까지 CPU 자원이 소모된다.
  - CPU 자원을 소모하면서 대기하기 때문에 바쁜 대기라고 하며, CPU 자원이 낭비될 수 있다.
  - 특히 경쟁이 치열할수록 반복적인 재시도로 인한 스핀 비용이 더 많이 발생한다.
- CAS를 계속 실패하면 Lock을 잠깐 사용하거나, 스핀 횟수를 제한한 뒤 Thread.yield()로 양보하는 방법으로 CPU 자원 낭비를 방지할 수 있다.
ABA 문제
- 스레드1이 값이 `A`인지 확인 후 `C`로 변경하려고 하는데 다른 스레드2가 `A → B → A`로 값을 변경했을 때, 스레드1이 봤을 때는 변경을 감지하지 못하고 CAS를 성공 처리하게 됨.
  - 하지만 실제로 중간에 변경이 있었음
- 값에 버전을 붙여 버전 관리를 하는 방법으로 해결 가능

언제 사용하는 것이 좋을까?

공유 데이터에 대한 경쟁이 약할 때
Lock을 사용하기에는 오버헤드가 큰, 짧고 단순한 연산일 때
숫자 카운팅, 자료 구조의 데이터 추가 및 삭제 등 CPU 사이클이 금방 끝나지만 안전한 임계 영역 또는 원자적인 연산이 필요한 경우에 사용

데이터베이스를 기다리거나 다른 서버의 API를 기다리는 것처럼 오래 기다리는 작업에 CAS를 사용하면 CPU를 계속 사용하며 기다리는 최악의 결과가 나올 수도 있다. 이런 경우는 동기화 Lock을 사용해야 한다.

충돌 가능성이 낮은 환경에서는 매우 효율적이지만, 충돌 가능성이 높은 환경에서는 성능 저하가 발생할 수 있다.

참고

김영한의 실전 자바 고급 1편

https://curiousjinan.tistory.com/entry/java-concurrent-hash-map-cas

https://velog.io/@jinh2352/멀티코어에서의-캐시-coherency-보장-프로토콜

https://bbagwang.com/posts/game-server-development/2-atomic/

상속이 캡슐화를 위반하는 이유

말차쟁이 — Tue, 4 Nov 2025 23:00:35 +0900

객체지향 공부를 하던 중 객체지향의 특징인 상속이 캡슐화를 위반한다는 글을 보게 되었다.

결론부터 말하자면 상속이 항상 캡슐화를 위반하는 것은 아니다.

그럼 어떤 상속이 캡슐화를 위반할까?

한번 알아보자.

상속

객체 지향에서의 상속은 상위 클래스의 특성을 하위 클래스에서 상속(특성 상속)받고 거기에 더해 필요한 특성을 추가하는 것.

즉, 확장해서 사용할 수 있다는 뜻이다.

캡슐화

객체의 데이터와 동작을 하나로 묶어 실제 구현 내용을 외부에 공개하지 않는 것

즉, 객체가 내부적으로 기능을 어떻게 구현하는지를 감추는 것이다.

상속과 캡슐화는 객체지향의 4대 특성이다.

하지만, 아이러니하게도 상속은 캡슐화를 위반한다.

예제를 통해 알아보자.

// Broken - Inappropriate use of inheritance!
public class InstrumentedHashSet<E> extends HashSet<E> {
    // The number of attempted element insertions
    private int addCount = 0;
    
    public InstrumentedHashSet() {
    }
    
    public InstrumentedHashSet(int initCap, float loadFactor) {
        super(initCap, loadFactor);
    }
    
    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }
    
    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }
    
    public int getAddCount() {
        return addCount;
    }
}

`InstrumentedHashSet`는 `HashSet`에 추가되는 요소 개수를 계산하는 클래스이다.

요소가 추가될 때마다 계산하기 위해 `add()`와 `addAll()`을 오버라이딩하여 addCount에 요소 개수를 카운팅한다.

public class ExtendsTest {
    public static void main(String[] args) {
        InstrumentedHashSet<String> set = new InstrumentedHashSet<>();
        set.addAll(List.of("Snap", "Crackle", "Pop"));

        System.out.println("addCount: " + set.getAddCount());
    }
}

"Snap", "Crackle", "Pop" 3개의 요소를 추가했다.

그럼 `InstrumentedHashSet`에서 오버라이딩한 `addAll()`이 호출될 것이고, `addCount`의 기댓값은 3일 것이다.

하지만, `addCount`의 값은 6이 된다.

분명 3개의 요소를 추가했는데 `addCount`가 6이 된다니? 왜일까?

`addAll()`의 코드를 살펴보면 이유를 알 수 있다.

@Override
public boolean addAll(Collection<? extends E> c) {
    addCount += c.size();
    return super.addAll(c);
}

`addCount += c.size()`

addCount = 3

`super.addAll(c)`

상위 클래스(`HashSet`)의 `addAll()`를 호출한다.

public boolean addAll(Collection<? extends E> c) {
    boolean modified = false;
    for (E e : c)
        if (add(e))
            modified = true;
    return modified;
}

위 코드는 상위 클래스 `HashSet`의 `addAll()`이다. 살펴보면 내부 구현에서는 `add()`를 호출하는 것을 볼 수 있다.

현재 인스턴스는 `HashSet`이 아닌 `InstrumentedHashSet`이기 때문에 `add()`는 오버라이딩된 `InstrumentedHashSet`의 `add()`가 호출된다.

요소 3개만큼 반복문을 진행하기 때문에 `add()`가 3번 더 호출되어 `addCount`는 6이 되는 것이다.

문제점

`InstrumentedHashSet`는 `HashSet`의 `addAll()`의 내부 구현을 모르는 상태로 오버라이딩했지만 메서드가 오작동함.
코드를 수정하려면 `HashSet`의 `addAll()`의 내부 구현을 알아야 함.

여기서 문제점은 이러한 문제를 해결하려면 부모 클래스의 구현 내용을 알아야 하고, 이를 해결에 반영하면 그 내용을 노출할 가능성이 발생한다.

부모 클래스의 구현 내용을 노출하게 된다면 캡슐화 위반이 되는 것이다.

그럼 오버라이딩때문에 캡슐화를 위반한 것일까?

`addAll()`을 오버라이딩함으로써 캡슐화를 위반하게 됐다.

하지만, 오버라이딩으로 인해 무조건 캡슐화를 위반하는 것은 아니다.

class Animal {
    public void breathe() {
        System.out.println("호흡하다");
    }
}

class Whale extends Animal {
    public void breathe() {
        System.out.println("폐로 호흡하다");
    }
}

`breathe()`는 하위 클래스에서 오버라이딩했지만, 상위 클래스와 하위 클래스에서 각각 다르게 구현됐다.

이 경우 오버라이딩으로 인해 상위 클래스의 내부 동작이 노출되거나 변경되지 않는다.

즉, 하위 클래스에서 오버라이딩을 해도, 상위 클래스와 하위 클래스 모두 해당 메서드를 독립적으로 구현해서 상위 클래스의 내부 동작이 노출되거나 변경되지 않는다면 캡슐화를 위반하지 않는다.

결론

상속 관계에서 상위 클래스의 내부 동작이 노출 또는 변경되지 않으면 캡슐화를 위반하지 않는다.

하지만, 오버라이딩으로 인해 상위 클래스의 내부 동작이 노출되거나 변경될 가능성이 발생한다.

상속이 캡슐화는 위반하는 이유는 캡슐화를 위반할 가능성이 있는 오버라이딩을 상속이 제공해주기 때문이다.

그래서 제임스 고슬링도 상속보다는 구현을 권장한다고 한다!

참고

https://inpa.tistory.com/entry/OOP- -객체-지향의-상속-문제점과-합성Composition-이해하기

https://unluckyjung.github.io/oop/2021/03/17/Inheritance-and-Encapsulation/

https://dev-rootable.tistory.com/156

~~https://blogs.oracle.com/javamagazine/post/java-inheritance-composition~~

Joshua Bloch의 글에 있는 예제를 인용했는데 글이 삭제되었다…

hashCode()와 equals()를 같이 오버라이딩해야 하는 이유

말차쟁이 — Thu, 30 Oct 2025 22:31:39 +0900

`hashCode()`와 `equals()`는 Object 클래스에 선언된 메서드며, 모든 객체가 사용할 수 있다.

두 메서드는 같이 오버라이딩해야 하는 이유가 있다. 그 이유를 알아보자.

일단 `hashCode()`와 `equals()`부터 알아보자.

JDK 21 기준

public class Object {

    @IntrinsicCandidate
    public native int hashCode();

    public boolean equals(Object obj) {
        return (this == obj);
    }
}

hashCode()

객체의 해시 값을 반환한다.

메모리 주소와 무관한 난수 값을 사용해서 해시를 생성하는 해시 함수다.

해시가 뭘까? 해시 함수부터 알아보자.

해시 함수

임의의 길이의 데이터를 입력으로 받아, 고정된 길이의 해시 값(해시 코드)을 출력하는 함수

public int testHashCode() {
	...
}

여기서 고정된 길이는 저장 공간의 크기를 뜻한다.

아래 메서드의 반환 값처럼 4byte(`int`)를 차지하는 고정된 길이

좋은 해시 함수일수록 해시 충돌 확률이 낮아진다.

주요 특징

일관성 : 동일한 입력에 대해서는 항상 동일한 결과가 나온다.
단방향성 : 해시 값으로부터 원본 데이터를 유추하기 어렵다. (사실상 복호화 불가능)

주요 용도

데이터 무결성 검사 : 원본 데이터의 해시 값을 미리 저장해두고, 데이터가 변경되었을 때 해시 값을 비교해 데이터의 변조 여부를 확인한다.
자료구조 : 해시 테이블과 같은 해시 기반 자료구조에서 데이터를 효율적으로 저장하고 검색하기 위해 사용된다.
암호화 : 비밀번호 등 중요한 정보를 안전하게 저장하기 위해 사용된다. 원본 비밀번호 대신 해시 값을 저장하고, 로그인 시 입력된 비밀번호의 해시 값과 저장된 해시 값을 비교한다.

해시는 해시 함수를 통해 반환되는 결과이다.

equals()

문자열 비교에 자주 사용해서 문자열을 비교하는 메서드라고 알고 있을 수도 있겠지만,

엄밀히 말하면 객체 비교에 사용하는 메서드다.

객체 비교는 두 가지 방식이 있다.

동일성(Identity) : 두 객체가 동일한지 비교한다. (두 객체가 동일한 메모리 주소를 참조하는지 비교)
- 비교 연산 : `==`

동등성(Equality) : 두 객체가 논리적으로 동일한 값(내용)을 가지는지 비교한다.
- 비교 연산 : `equals()`

public static void main(String[] args) {
    Member member1 = new Member("test");
    Member member2 = member1;
    Member member3 = new Member("test");

    // 동일성 비교
    boolean identity = member1 == member2;
    System.out.println(identity); // true

    // 동등성 비교
    boolean equals = member1.equals(member3);
    System.out.println(equals); // true
}

static class Member {
    private String name;

    public Member(String name) {
        this.name = name;
    }
    
    @Override
    public boolean equals(Object object) {
        Member member = (Member) object;
        return name.equals(member.name);
    }
}

동일성 비교

member1과 member2가 동일한 인스턴스인지 비교한다.

member2에 member1의 인스턴스를 대입했으니 `true`가 된다.

동등성 비교

member1과 member3이 논리적으로 동일한지 비교한다.

Member 클래스는 `equals()`를 오버라이딩하여 name이 같으면 같은 객체라고 판단한다.

member1과 member3의 name이 같으므로 `true`가 된다.

String의 equals()

문자열 비교에 흔히 사용하는 메서드다.

Object 클래스의 equals()를 오버라이딩했다.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    return (anObject instanceof String aString)
            && (!COMPACT_STRINGS || this.coder == aString.coder)
            && StringLatin1.equals(value, aString.value);
}

동일성 비교

`if (this == anObject)`

두 문자열이 같은 인스턴스인지 비교한다.

동등성 비교

`StringLatin1.equals(value, aString.value)`

두 객체의 값(문자열)을 비교한다.

// 문자열 비교
String str1 = "hello";
String str2 = "hello";
String str3 = new String("hello");

System.out.println(str1 == str2);       // true
System.out.println(str1 == str3);       // false
System.out.println(str1.equals(str3));  // true

자바에서는 일반적으로 객체는 `new` 키워드를 사용해 인스턴스를 생성한다.

하지만 String 클래스는 조금 다른데, 2가지의 객체 생성 방식이 있다.

new 키워드 사용 : `String str3 = new String(”hello”);`
문자열 리터럴 : `String str1 = "hello";`

`new` 키워드를 사용하는 방식은 일반적으로 사용되지 않고, 대부분 문자열 리터럴(literal) 방식을 사용한다.

리터럴 방식으로 생성한 `hello` 문자열은 String Constant pool(문자열 상수 풀)이라는 특별한 메모리 영역에 저장되어 JVM 종료까지 하나의 `hello` 문자열 인스턴스만 존재한다.

때문에 같은 `hello` 문자열을 리터럴 방식으로 생성한 `str1`와 `str2`는 같은 인스턴스를 참조하게 되고, 동일성 비교했을 때 true인 것이다.

하지만 `new` 키워드를 사용하면 String Constant pool에 저장되지 않고, 다른 인스턴스처럼 Heap 영역에 저장된다.

따라서 `str1`와 `str3`은 같은 `hello`문자열이더라도 다른 인스턴스를 참조하고 있기 때문에 false이다.

그래서 hashCode()와 equals()를 같이 오버라이딩해야 하는 이유는 뭘까?

`hashCode()`는 해시 기반 자료구조에서 데이터를 효율적으로 저장하고 검색하기 위해 사용된다고 했다.

대표적인 해시 기반 자료구조인 `HashMap`을 살펴보자.

public class HashMap<K,V> extends AbstractMap<K,V>
    implements Map<K,V>, Cloneable, Serializable {
    
    public V get(Object key) {
        Node<K,V> e;
        return (e = getNode(key)) == null ? null : e.value;
    }

    final Node<K,V> getNode(Object key) {
        Node<K,V>[] tab; Node<K,V> first, e; int n, hash; K k;
        if ((tab = table) != null && (n = tab.length) > 0 &&
            (first = tab[(n - 1) & (hash = hash(key))]) != null) {
            if (first.hash == hash && // always check first node
                ((k = first.key) == key || (key != null && key.equals(k))))
                return first;
            if ((e = first.next) != null) {
                if (first instanceof TreeNode)
                    return ((TreeNode<K,V>)first).getTreeNode(hash, key);
                do {
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        return e;
                } while ((e = e.next) != null);
            }
        }
        return null;
    }
		
    static final int hash(Object key) {
        int h;
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
    }
}

`HashMap`에서 값을 가져오는 메서드인 `get()`을 살펴 보자.

return (e = getNode(key)) == null ? null : e.value;

전달 받은 key를 `getNode()`로 전달한다.

final Node<K,V> getNode(Object key) {
    Node<K,V>[] tab; Node<K,V> first, e; int n, hash; K k;
    if (... && (hash = hash(key))) != null) {
    
        ...
        if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
              return e;
        }
        ...
        
    }
    return null;
}

hash = hash(key)

`hash()`로 해시를 생성하여 hash 변수에 대입한다.

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

해시 값을 생성하는 `hash()`에서 `key.hashCode()`가 사용된다.

해시 테이블의 해시 인덱스를 생성하는 용도

if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
      return e;
}

객체 간 비교한다.

`key` : 클라이언트에서 값을 찾으려고 전달한 키

`hash` : `key`로 생성한 해시

`e` : 버킷에 담겨 있는 노드

`k` : 버킷에 담겨 있는 노드의 키

1. 버킷에 담겨 있는 노드(`e`)와 `key`로 생성한 해시(`hash`)를 비교

`e.hash == hash`

2. 버킷에 담겨 있는 노드의 키(`k`)와 `key`를 동일성 비교

`(k = e.key) == key`

3. `key`가 null이 아니라면, `key`와 `k`를 동등성 비교

`key != null && key.equals(k)`

여기서 동등성 비교인 `equals()`가 사용된다. 여기까지 진행됐다는 것은 두 객체의 해시가 같다는 뜻이다. 그 다음 객체 간 비교할 수 있는 수단이 필요한데, 그 수단이 `equals()`인 것이다.

결론

`hashCode()` : 해시 기반 자료구조에서 객체를 찾기 위한 힌트 (버킷 입장권 느낌)

`equals()` : 두 객체가 내용적으로 같은지 비교 (논리적으로 동등한지)

해시 충돌이 적을 수록 좋은 해시 함수지만 해시의 범위에는 한계가 있고, 객체의 수가 많아질수록 해시 충돌 가능성이 높아져 해시 값이 같은 두 객체가 나타날 수 있다.

그때 해시 값이 같은 두 객체 간 비교에 `equals()`로 논리적으로 동등한지 판단해야 한다.

따라서 `hashCode()`와 `equals()`를 같이 오버라이딩해야 해시 기반 자료구조(ex. 컬렉션 프레임워크)에서 객체 간 논리적 동등성이 일치한다.

`hashCode()`를 항상 오버라이딩해야 하는 것은 아니다. 해시 기반 자료 구조를 사용할 경우에만 `hashCode()`와 `equals()`를 같이 오버라이딩하면 될 것 같다.

직접 오버라이딩하는 것은 쉽지 않기 때문에 IDE의 도움을 받아도 좋을 것 같다.

IntelliJ IDE에서 자동 생성할 수 있다.

참고

https://jiwondev.tistory.com/113

https://velog.io/@hsh111366/Java-hashCode-메모리-주소일까

김영한의 실전 자바 중급 2편

ConcurrentHashMap의 동작원리

말차쟁이 — Tue, 28 Oct 2025 22:47:31 +0900

ConcurrentHashMap은 실무에서 처음 사용해 봤었다. 코드리뷰를 진행하다가 HashMap을 사용한 코드에 대해서 Thread-Safe한 HashMap인 ConcurrentHashMap을 사용해야 한다고 피드백을 받았다. 그 후로 동시성 문제가 발생할 만한 곳은 ConcurrentHashMap을 사용하여 해결했다.

그러다 문득 동시성 문제를 어떻게 해결하는지 궁금해져서 파헤쳐 보기로 했다.

JDK 21 기준

일단 키-값 쌍 구조인 HashTable을 구현한 클래스는 크게 3가지가 있다.

HashMap (Thread-Unsafe)
HashTable (Thread-Safe)
ConcurrentHashMap (Thread-Safe)

ConcurrentHashMap이 Thread-Safe한 HashMap이라고 했는데, HashTable은 뭘까?

사실 ConcurrentHashMap 이전에 JDK 1.0 버전에 Thread-Safe한 HashMap이 있었다.

바로 `HashTable`이다.

왜 Thread-Safe한 HashMap이 두 개나 있는 걸까?

HashTable부터 파헤쳐 보자.

HashTable

public class Hashtable<K,V> extends Dictionary<K,V>
    implements Map<K,V>, Cloneable, java.io.Serializable {

	public synchronized int size() {
    	...
	}
		
    public synchronized boolean isEmpty() {
        ...
    }

    public synchronized boolean containsKey(Object key) {
        ...
    }

    public synchronized V get(Object key) {
        ...
    }

    public synchronized V put(K key, V value) {
        ...
    }

    ...
}

HashTable의 코드를 파헤쳐 보면 일부 메서드를 제외하고 모두 `synchronized`가 붙어있는 것을 볼 수 있다.

이것은 무엇을 의미할까?

자바의 모든 인스턴스는 각각의 모니터 락을 보유하고 있다. 스레드가 `synchronized`가 적용된 메서드에 접근하려면 해당 인스턴스의 모니터 락을 획득해야 접근할 수 있고, 그동안 다른 스레드들은 블로킹된다. 심지어 읽기 메서드인 `get()`조차도 `synchronized`가 적용됐기 때문에 블로킹된다.

블로킹된 스레드들은 모니터 대기 큐(Entry Queue)에서 무한 대기하게 된다.

무한 대기 : 블로킹된 스레드들은 모니터 락을 획득할 때까지 무한 대기한다.
- 타임아웃 X
- 인터럽트 X

BLOCKED 상태로 아무 일도 못한 채 대기하게 되어 스레드의 유휴시간이 많아지고, 결과적으로 성능 저하가 발생한다.

따라서 HashTable은 동시성 문제를 해결함과 동시에 성능저하가 발생한다.

ConcurrentHashMap

JDK 1.5에 HashTable에서 성능이 개선된 클래스인 ConcurrentHashMap이 나왔다.

ConcurrentHashMap은 HashMap을 사용하면서 발생할 수 있는 동시성 문제를 해결하는 Thread-Safe한 HashMap이다.

Table

ConcurrentHashMap의 해시 테이블로, 키-값 쌍이 저장되는 노드(`Node<K, V>`) 들의 배열이다. 이 배열의 각 요소는 버킷(bucket)이다. 버킷에는 노드가 저장되며, 해시 충돌이 발생하면 노드들이 연결 리스트(체인)나 트리 구조로 구성된다.

HashMap와 동일한 Node 배열이다.

Node

주석에 나와있듯이 ConcurrentHashMap 내에서 엔트리를 나타내는 객체다.

hash : 해시
key : 키
val : 값
next : 다음 노드

next(다음 노드)는 버킷이 연결 리스트나 트리 구조를 구성할 때 사용된다.

get()

public V get(Object key) {
    Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
    
    int h = spread(key.hashCode());
    
    if ((tab = table) != null && (n = tab.length) > 0 &&
        (e = tabAt(tab, (n - 1) & h)) != null) {
        if ((eh = e.hash) == h) {
            if ((ek = e.key) == key || (ek != null && key.equals(ek)))
                return e.val;
        }
        else if (eh < 0)
            return (p = e.find(h, key)) != null ? p.val : null;
        while ((e = e.next) != null) {
            if (e.hash == h &&
                ((ek = e.key) == key || (ek != null && key.equals(ek))))
                return e.val;
        }
    }
    return null;
}

int h = spread(key.hashCode());

`spread()`를 통해 해시를 더 균등하게 분산시킨다.

해시 충돌을 줄여 해시 테이블 성능 최적화

e = tabAt(tab, (n - 1) & h)

원자적으로 해시 인덱스에 해당하는 버킷의 노드를 읽어온다.

`tabAt()`를 좀 더 파헤쳐 보면 아래 코드를 볼 수 있다.

public final class Unsafe {
    /**
     * Fetches a reference value from a given Java variable, with **volatile**
     * load semantics. Otherwise identical to {@link #getReference(Object, long)}
     */
    @IntrinsicCandidate
    public native Object getReferenceVolatile(Object o, long offset);
}

Unsafe의 getReferenceVolatile()는 원자성과 가시성을 보장해준다.

원자성 : CPU 수준에서 원자성을 보장
가시성 : 메모리 배리어를 사용해 가시성을 보장

그 다음은 조건에 따라 분기된다.

tabAt()로 읽어온 노드의 해시와 파라미터로 전달받은 키로 만든 해시가 같을 때

if ((eh = e.hash) == h) {
    if ((ek = e.key) == key || (ek != null && key.equals(ek)))
        return e.val;
}

노드의 키가 파라미터로 전달받은 키와 같은 인스턴스거나 == (동일성)

노드의 키가 파라미터로 전달받은 키와 같다면 equals (동등성)

노드의 값을 반환한다.

해시 충돌이 발생하지 않아 버킷에 노드가 한 개인 경우다. 대부분 이 경우에 속한다.

노드의 해시값이 음수일 때

else if (eh < 0)
	return (p = e.find(h, key)) != null ? p.val : null;

아래 코드를 보면 음수 값을 가지는 `MOVED` `TREEBIN` 상수를 볼 수 있다.

static final int MOVED     = -1; // hash for forwarding nodes
static final int TREEBIN   = -2; // hash for roots of trees

static final class ForwardingNode<K,V> extends Node<K,V> {
	...
}
static final class TreeNode<K,V> extends Node<K,V> {
	...
}

ForwardingNode : 리사이징 중 새 테이블로 전송되는 것을 도와주는 노드
TreeNode : 해시충돌이 많아지면서 임계점 초과 시 성능을 위해 버킷이 트리 구조로 변환됨

TreeNode, ForwardingNode는 해시를 저장하지 않고, 음수 해시 값을 가지고 있다.

따라서 노드의 해시값이 음수라는 것은 버킷의 구조가 트리라는 걸 의미한다.

그 후 트리 구조를 순회하면서 노드의 값을 반환한다.

해시 충돌이 발생하여 버킷에 노드가 여러 개일 때

while ((e = e.next) != null) {
    if (e.hash == h && ((ek = e.key) == key || (ek != null && key.equals(ek))))
        return e.val;
}

노드의 next를 따라가며 null이 아닐 때까지 순차적으로 탐색한다.

그리고 해시가 같고, 같은 인스턴스거나(동일성), equals()로 같다면(동등성) 노드의 값을 반환한다.

마지막으로 키에 해당하는 노드가 없을 경우 null을 반환한다.

그런데 HashTable의 `get()`와 달리 `synchronized`를 찾아볼 수 없는 데다가 다른 동기화 기법도 찾아볼 수 없다. 왜일까?

`get()`은 내부에 값을 담는 버킷 배열의 구조를 변경하지 않기 때문에 동기화 없이 여러 스레드에서 동시에 호출되어도 문제가 없다.

1. 메모리 가시성 문제는 내부에 값을 담는 버킷 배열(`table`)을 `volatile`로 선언해 해결했다.
`synchronized`는 메모리 가시성을 보장해 준다.

2. ConcurrentHashMap은 Lock Striping(분할 잠금: 버킷 단위로 잠금을 사용하는 방식)을 사용하기 때문에 특정 버킷만 읽으면 되기 때문에 `get()`전체에 동기화를 할 필요가 없다.

이렇게 `synchronized`를 적용하지 않음으로써 읽기 성능을 최적화했다.

put()

`put()`은 ConcurrentHashMap의 핵심이다.

public V put(K key, V value) {
    return putVal(key, value, false);
}

클라이언트는 공개 인터페이스인 `put()`을 호출하지만, 내부적으로는 `putVal()`이 호출된다.

/** Implementation for put and putIfAbsent */
final V putVal(K key, V value, boolean onlyIfAbsent) {
    if (key == null || value == null) throw new NullPointerException();
    int hash = spread(key.hashCode());
    int binCount = 0;
    for (Node<K,V>[] tab = table;;) {
        Node<K,V> f; int n, i, fh; K fk; V fv;
        if (tab == null || (n = tab.length) == 0)
            tab = initTable();
        // 버킷이 비어있으면 CAS 연산으로 삽입
        else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
            if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value)))
                break;                   // no lock when adding to empty bin
        }
        else if ((fh = f.hash) == MOVED)
            tab = helpTransfer(tab, f);
        else if (onlyIfAbsent // check first node without acquiring lock
                 && fh == hash
                 && ((fk = f.key) == key || (fk != null && key.equals(fk)))
                 && (fv = f.val) != null)
            return fv;
        // 버킷이 비어있지 않으면 버킷을 동기화하고 삽입
        else {
            V oldVal = null;
            synchronized (f) {
                if (tabAt(tab, i) == f) {
                    if (fh >= 0) {
                        binCount = 1;
                        for (Node<K,V> e = f;; ++binCount) {
                            K ek;
                            if (e.hash == hash &&
                                ((ek = e.key) == key ||
                                 (ek != null && key.equals(ek)))) {
                                oldVal = e.val;
                                if (!onlyIfAbsent)
                                    e.val = value;
                                break;
                            }
                            Node<K,V> pred = e;
                            if ((e = e.next) == null) {
                                pred.next = new Node<K,V>(hash, key, value);
                                break;
                            }
                        }
                    }
                    else if (f instanceof TreeBin) {
                        Node<K,V> p;
                        binCount = 2;
                        if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
                                                       value)) != null) {
                            oldVal = p.val;
                            if (!onlyIfAbsent)
                                p.val = value;
                        }
                    }
                    else if (f instanceof ReservationNode)
                        throw new IllegalStateException("Recursive update");
                }
            }
            if (binCount != 0) {
                if (binCount >= TREEIFY_THRESHOLD)
                    treeifyBin(tab, i);
                if (oldVal != null)
                    return oldVal;
                break;
            }
        }
    }
    addCount(1L, binCount);
    return null;
}

for (Node<K,V>[] tab = table;;) {

특정 조건이 충족될 때까지 무한 반복한다.

CAS 연산 실패 시 재시도하는 전략

if (key == null || value == null) throw new NullPointerException();

HashMap과 달리 ConcurrentHashMap은 key와 value 모두 null을 허용하지 않는다.

그 다음은 조건에 따라 분기된다.

테이블이 없을 때

if (tab == null || (n = tab.length) == 0) tab = initTable();

`table`이 아직 초기화되지 않았거나 크기가 0이면 CAS 연산으로 초기화한다.

버킷이 비어있을 때

else if ((f = *tabAt*(tab, i = (n - 1) & hash)) == null) {

key의 해시인덱스에 해당하는 버킷이 비어있다면

if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value)))
	break;                   // no lock when adding to empty bin

CAS 연산으로 해당 버킷에 노드를 추가한다.

노드가 Forwarding Node일 때

else if ((fh = f.hash) == MOVED)

static final int MOVED     = -1; // hash for forwarding nodes

`MOVED`는 Node가 Forwarding Node라는 것을 나타낸다.

tab = helpTransfer(tab, f);

그것은 현재 테이블이 리사이징 중이라는 의미이기 때문에 리사이징을 돕는 메서드를 호출한다.

노드가 비어있지 않을 때

else if (onlyIfAbsent && fh == hash &&
         ((fk = f.key) == key || (fk != null && key.equals(fk))) &&
         (fv = f.val) != null)
return fv;

`putIfAbsent()`를 호출하면 `onlyIfAbsent`가 true이기 때문에 이 조건을 검사하게 된다.

key에 해당하는 값이 없을 때만 put 하게 되고, 값이 있을 때는 그 값을 반환한다.

그 외 (버킷이 비어있지 않을 때)

버킷이 비어있지 않다면 버킷을 `synchronized`로 동기화한다.

그 후 버킷의 구조에 따라 분기된다.

버킷이 연결 리스트 구조일 때
버킷이 Red-Black 트리 구조일 때

버킷이 연결 리스트 구조일 때

// 해시가 음수면 트리 구조
if (fh >= 0) {
    binCount = 1;
    
    // 버킷을 순회한다.
    for (Node<K,V> e = f;; ++binCount) {
        K ek;
        
        // 동일한 key를 찾았을 때
        // put() 일 경우 값 교체
        // putIfAbsent()를 호출했을 경우 값 유지
        if (e.hash == hash &&
            ((ek = e.key) == key ||
             (ek != null && key.equals(ek)))) {
            oldVal = e.val;
            if (!onlyIfAbsent)
                e.val = value;
            break;
        }
        Node<K,V> pred = e;
        
        // key가 동일하지 않을 때 다음 노드가 없으면 노드 추가 (연결 리스트)
        if ((e = e.next) == null) {
            pred.next = new Node<K,V>(hash, key, value);
            break;
        }
    }
}

버킷이 Red-Black 트리 구조일 때

else if (f instanceof TreeBin) {
    Node<K,V> p;
    binCount = 2;
    // 노드가 추가되지 않았을 때
    if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key, value)) != null) {
        oldVal = p.val;
        // put()를 호출했을 경우 값 교체
        if (!onlyIfAbsent)
            p.val = value;
    }
}

`putTreeVal()`는 노드를 찾거나 추가한다.

null을 반환 : 노드가 추가됨
null이 아닌 노드를 반환 : key에 해당하는 노드를 찾음

버킷을 동기화하고 노드를 추가하는 작업을 수행하고 노드 수를 확인한다.

if (binCount != 0) {
    if (binCount >= TREEIFY_THRESHOLD)
        treeifyBin(tab, i);
    if (oldVal != null)
        return oldVal;
    break;
}

노드를 추가하면서 `binCount`를 증가시키는데 `binCount`가 임계값(`TREEIFY_THRESHOLD`)을 넘기면 버킷의 구조를 변경한다.

버킷의 사이즈가 커질수록 검색 속도가 느려지기 때문에 성능을 위해서 아래 조건을 모두 충족할 경우 버킷의 구조를 연결 리스트 구조에서 Red-Black 트리 구조로 변경한다.

하나의 버킷에 저장된 노드 수가 8개 이상(`TREEIFY_THRESHOLD = 8`)일 경우
전체 배열 크기(`capacity`)가 64 이상(`MIN_TREEIFY_CAPACITY = 64`)일 경우

버킷에 저장된 노드 수(연결 리스트)가 8 이상이어도 전체 배열 크기(`table`)가 64 미만이면 리사이즈 작업을 수행한다.

반대로 Red-Black 트리에서 연결 리스트로 구조가 변경되는 경우도 있다.

버킷에 저장된 노드 수가 6개 이하(`UNTREEIFY_THRESHOLD = 6`)일 경우

왜 버킷의 구조를 변경하는 걸까?

각 키에 해당하는 버킷의 노드가 하나뿐이라면 O(1)의 성능을 가진다.

하지만, 해시 충돌이 발생하여 버킷에 여러 개의 노드가 저장되어 있다면?

버킷에 노드가 많아질수록 연결 노드를 다 순회하면서 탐색해야 하기 때문에 O(n)의 성능을 가진다.

노드가 많아지면 많아질수록 탐색 시간이 늘어나는 것이다.

`spread()`로 해시 충돌을 줄여 성능 최적화를 하더라도 한계가 있다.

그래서 성능 최적화를 위해 균형 이진 탐색 트리인 Red-Black 트리 구조로 변경한 것이다.

Red-Black 트리는 충돌이 아무리 많아도 탐색, 삽입, 삭제 모두 O(log n)으로 유지가 가능하다.

Red-Black 트리 구조가 항상 좋은 것은 아니다.

위에서 버킷에 저장된 노드 수가 6개 이하일 경우 Red-Black 트리에서 연결 리스트로 구조로 변경된다고 했다. 이 경우 적은 수의 노드를 트리 구조로 구성하면 오히려 불필요한 오버헤드가 발생하기 때문에 일정 노드 수(6개)로 줄어든다면 연결 리스트로 변경하는 것이다.

addCount(1L, binCount);

마지막으로 노드 개수를 증가시킨다.

해시테이블의 전체 노드 수를 증가시키고, 특정 조건이 만족되면 해시 테이블을 리사이징하는 역할을 한다.

Constructor

// Creates a new, empty map with the default initial table size (16).
public ConcurrentHashMap() {
}

// Creates a new, empty map with an initial table size accommodating
// the specified number of elements without the need to dynamically resize.
public ConcurrentHashMap(int initialCapacity) {
    this(initialCapacity, LOAD_FACTOR, 1);
}

// Creates a new map with the same mappings as the given map.
public ConcurrentHashMap(Map<? extends K, ? extends V> m) {
    this.sizeCtl = DEFAULT_CAPACITY;
    putAll(m);
}

// Creates a new, empty map with an initial table size based on the given
// number of elements (initialCapacity) and initial table density (loadFactor)
public ConcurrentHashMap(int initialCapacity, float loadFactor) {
    this(initialCapacity, loadFactor, 1);
}

// Creates a new, empty map with an initial table size based on the given
// number of elements (initialCapacity), initial table density (loadFactor),
// and number of concurrently updating threads (concurrencyLevel).
public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
    if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
        throw new IllegalArgumentException();
    if (initialCapacity < concurrencyLevel)   // Use at least as many bins
        initialCapacity = concurrencyLevel;   // as estimated threads
    long size = (long)(1.0 + (long)initialCapacity / loadFactor);
    int cap = (size >= (long)MAXIMUM_CAPACITY) ?
        MAXIMUM_CAPACITY : tableSizeFor((int)size);
    this.sizeCtl = cap;
}

ConcurrentHashMap의 생성자는 총 5개다.

첫 번째 기본 생성자의 주석을 보면 해시 테이블의 기본 사이즈는 16이 된다.

그리고 모든 생성자의 코드를 보면 해시 테이블(`table`)에 대한 초기화 코드가 없는 것을 볼 수 있다.

이것은 지연 초기화 방식을 적용했기 때문이다.

실제로 `put()`으로 데이터를 삽입할 때 `initTable()`를 호출하여 해시테이블을 초기화한다.

생성자의 주요 파라미터

initialCapacity
- 초기 용량을 결정한다. ConcurrentHashMap의 구현체들은 loadFactor를 고려하여 용량을 수용하기 위해 리사이징 작업을 수행한다.
loadFactor
- 초기 해시 테이블의 크기를 설정하기 위해 사용되며, 해시테이블의 밀도를 나타낸다.
- 해시 테이블의 버킷 점유율 임계치를 나타낸다.
  - (노드 수 / 버킷 수)가 loadFactor를 넘으면 리사이징 작업이 수행된다.
concurrencyLevel
- 동시에 업데이트되는 스레드의 예상 수
- JDK 8 이상부터 `deprecated`

참고

https://curiousjinan.tistory.com/entry/java-concurrent-hash-map-cas

https://velog.io/@alsgus92/ConcurrentHashMap의-Thread-safe-원리#4-concurrenthashmap-생성자

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html

잘못된 정보나 내용에 대해 피드백해주시면 감사하겠습니다!

제네릭 타입 소거 (Type Erasure)

말차쟁이 — Thu, 3 Jul 2025 00:21:44 +0900

제네릭은 타입 안정성을 보장하기 위해 JDK 1.5부터 도입됐으며, 이전 자바 버전의 코드와의 호환성을 위해 컴파일 타임에 제네릭 타입은 사라진다.

제네릭의 작동 방식

public class Node<T> {
    private T data;
    private Node<T> next;

    public Node(T data, Node<T> next) {
        this.data = data;
        this.next = next;
    }

    public T getData() { return data; }
    // ...
}

제네릭 타입인 `Node` 클래스는 컴파일되면 아래 코드로 변환된다.

public class Node {

    private Object data;
    private Node next;

    public Node(Object data, Node next) {
        this.data = data;
        this.next = next;
    }

    public Object getData() { return data; }
    // ...
}

`T` 타입 매개변수가 제거되고 `Object`로 치환되었다.

타입 소거

이렇게 컴파일 타임에 제네릭 타입이 제거되어 런타임에는 제네릭 타입이 사라지는 것(다른 타입으로 치환되는 것)을 타입 소거라고 한다.

제네릭 타입을 해당 범위로 바꾸거나, 제네릭 타입에 제한이 없는 경우 Object로 치환한다. 따라서 생성된 바이트코드에는 제네릭 타입이 존재하지 않는다.
필요한 경우 컴파일러가 타입 안전성을 유지하기 위해 형변환을 추가한다.
상한 경계에서 컴파일러가 다형성을 유지하기 위해 브릿지 메서드를 생성한다.

타입 소거는 매개변수화된 타입에 대해 새로운 클래스가 생성되지 않도록 보장하여 제네릭은 런타임 오버헤드를 발생시키지 않는다.

제네릭 타입 치환 규칙

기본 타입 : `<T>` -> `Object`
상한 경계 (upper bounded) : `<T extends Number>` -> `Number`
하한 경계 (lower bounded) : `<T super Integer>` -> `Object`

실체화 타입(Reifiable Types) / 비실체화 타입(Non-Reifiable Types)

실체화 타입

런타임에 타입 정보가 있는 타입이다.

primitive type : int, long 등 원시 타입
non-generic types : String, Integer 등 제네릭을 사용하지 않는 비제네릭 타입
raw type : List, Map 등 타입 매개변수가 없는 제네릭 타입
- List<E>의 raw type은 List

비실체화 타입

비실체화 타입은 타입 소거로 인해 런타임에 타입 정보가 없는 타입이다.

List<String>, List<Number> 등 제네릭 타입

타입 소거 과정

1. 제네릭 타입을 제거한다.

제네릭 타입 변환 규칙에 따라 제네릭 타입에 해당하는 타입으로 치환한다.

public class Queue<T extends Node> {
	private List<T> list = new ArrayLiat();
	
	public T add(T node) {
		list.add(node);
	}
	
	public T get(int index) {
		return list.get(index);
	}
}

public class Queue {
	private List list = new ArrayLiat();
	
	public Node add(Node node) {
		list.add(node);
	}
	
	public Node get(int index) {
		return list.get(index);
	}
}

2. 타입 안정성을 위해 형변환을 추가한다.

public class Queue {
	private List list = new ArrayLiat();
	
	public Node add(Node node) {
		list.add(node);
	}
	
	public Node get(int index) {
		return (Node) list.get(index);
	}
}

list는 제네릭 타입이 없는 `Object` 타입이다. 하지만 get 메서드는 반환 타입이 `Node` 타입인데 list의 타입은 `Object` 라서 형변환 불일치가 발생한다. 컴파일러가 형변환 불일치를 해결하기 위해서 형변환을 추가한다.

브릿지 메서드 (Bridge Method)

컴파일러는 상한 경계 제네릭 타입에 대해서 타입 소거를 해도 다형성을 보존하게 하기위해 별도의 bridge method를 생성한다.

public class Node<T> {
    public T data;
    
    public Node(T data) { this.data = data; }

    public void setData(T data) {
        System.out.println("Node.setData");
        this.data = data;
    }
}

public class MyNode extends Node<Integer> {
    public MyNode(Integer data) { super(data); }

    public void setData(Integer data) {
        System.out.println("MyNode.setData");
        super.setData(data);
    }
}

public class Main {
	public static void main(String[] args) {
		MyNode mn = new MyNode(5);
		Node n = mn;            // A raw type - compiler throws an unchecked warning
		n.setData("Hello");     // Causes a ClassCastException to be thrown.
		Integer x = mn.data;    
	}
}

위 코드에서 에러가 발생한다.

왜?

public class Node {
    public Object data;

    public Node(Object data) {
	    this.data = data;
    }

    public void setData(Object data) {
        System.out.println("Node.setData");
        this.data = data;
    }
}

public class MyNode extends Node {
    public MyNode(Integer data) {
	    super(data);
    }

    public void setData(Integer data) {
        System.out.println("MyNode.setData");
        super.setData(data);
    }
}

`Node` `MyNode` 클래스는 타입 소거 후 이런 코드가 된다.

`MyNode` 클래스는 `Node` 클래스의 `setData` 메서드를 오버라이딩했지만 타입 소거로 인해 타입 매개변수(`T`)가 `Object` 타입으로 치환되었고, 메서드 시그니처가 일치하지 않아 오버라이딩이 아닌 오버로딩 처리가 되어버린 것이다.

따라서 `ClassCastException`이 발생한 것이다.

class MyNode extends Node {
    // Bridge method generated by the compiler
    public void setData(Object data) {
        setData((Integer) data);
    }

    public void setData(Integer data) {
        System.out.println("MyNode.setData");
        super.setData(data);
    }

    // ...
}

그래서 컴파일러는 위와 같은 문제를 해결하고 타입 소거 후에도 타입의 다형성을 보존하기 위해 브릿지 메서드를 생성한다.

참고

ArrayList는 왜 제네릭 타입 E[]가 아닌 Object[]으로 요소를 관리할까?

말차쟁이 — Thu, 12 Jun 2025 19:44:08 +0900

제네릭을 공부하다가 제네릭을 사용하는 클래스 중 대표적으로 자주 사용되는 ArrayList에 대해 파헤치기 시작했다.

그런데 이상한 점을 하나 발견했다.

내부 요소들을 관리하는 자료구조가 Object[] 이었던 것이다.

ArrayList가 제네릭을 사용하니 E[] 를 사용해도 될 것 같은데, 왜 Object[] 를 사용하고 있을까?

ArrayList

제네릭을 이용해 구현한 ArrayList

private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};

public ArrayList(int initialCapacity) {
    if (initialCapacity > 0) {
        this.elementData = new Object[initialCapacity];
    }
    ...
}

public ArrayList() {
    this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
}

ArrayList의 생성자들을 보면 elementData에 인스턴스를 할당하는 것을 볼 수 있다.

elementData는 ArrayList의 요소들을 관리하는 필드다.

public E get(int index) {
    Objects.checkIndex(index, size);
    return elementData(index);
}

@SuppressWarnings("unchecked")
E elementData(int index) {
    return (E) elementData[index];
}

ArrayList의 요소들을 가져오는 get() 메서드를 호출했을 때 elementData의 값을 E 제네릭 타입으로 반환해주는 것을 볼 수 있다. 실제 요소들은 Object[] 타입으로 관리하고 외부로 반환할 때는 E 제네릭 타입으로 형변환 후 반환해주는 것이다.

`elementData`를 `Object[]` 타입으로 선언했을 때 단점

요소를 반환할 때 E 타입으로 형변환 후 반환해야 한다.
`Object` -> `E` 로의 형변환은 ClassCastException 예외를 발생시킬 수 있다.
- 게다가 unchecked 경고를 무시하기 위해 `@SuppressWarnings`를 사용했다.

그런데 굳이 `Object[]` 타입으로 사용하는 이유는 뭘까?

이유는 제네릭의 타입 소거 때문이다.

제네릭 타입 소거 (Type Erasure)

제네릭은 타입 안정성을 보장하기 위해 JDK 1.5부터 도입됐으며, 이전 자바 버전의 코드와의 호환성을 위해 컴파일 타임에 제네릭 타입은 사라진다.제네릭의 작동 방식public class Node { private T data;

shine-17.tistory.com

타입 소거

제네릭 타입은 컴파일 타임에만 존재하여 타입 안정성을 제공하고 런타임에는 타입 정보가 소거된다.

E elementData(int index) {
    return (E) elementData[index];
}

위 코드가 컴파일 과정에서 타입 소거되어

Object elementData(int index) {
    return elementData[index];
}

이런 코드가 된다.

그럼 만약 `elementData`를 `E[]` 타입으로 사용한다면 어떻게 될까?

E element = new E();         // 컴파일 에러
E[] elementData = new E[10]; // 컴파일 에러

위 코드는 컴파일 에러가 발생한다.
왜?
자바는 구체적인 타입이 있어야 인스턴스를 생성할 수 있다. 하지만 위 코드는 컴파일 타임에 타입 소거되어 런타임에서는 E 타입에 대한 정보를 가지고 있지 않다. 그래서 런타임에 JVM이 E의 구체적인 타입 정보를 알 수 없어 컴파일 에러가 발생하는 것이다.

그래서 애초에 제네릭 타입의 인스턴스를 생성할 수 없다.

하지만 한 가지 방법은 있다.

E[] elementData = (E[]) new Object[10];

이렇게 하면 컴파일 에러는 발생하지 않지만, 문제점이 있다.

타입 안정성이 보장되지 않는다.

public class ArrayList<E> {
    public E[] elementData = (E[]) new Object();
    ...
}

public class Main {
	public static void main(String[] args) {
        // Integer[] elementData = (Integer[]) new Object();
        List<Integer> list = new ArrayList<>();
        list.add(1);
        list.add(2);

        // ClassCastException 발생
        Integer[] intList = list.elementData;
    }
}

Object[]를 E[]로 강제 형변환하기 때문에 컴파일 에러는 발생하지 않지만 Object[] 타입의 인스턴스가 Integer[] 타입을 참조하게 되면서 ClassCastException가 발생하게 된다.
Object[]를 E[]로 강제 형변환하기 때문에 컴파일러가 제대로 타입 체크를 못할 가능성이 있다.

왜 제네릭 타입의 인스턴스를 생성하지 못할까?

제네릭은 비실체화 타입이기 때문이다.

비실체화 타입 : 컴파일 타임에 타입 소거에 의해 타입 정보가 제거된 타입

컴파일 타임에 타입 소거로 인해 런타임에는 타입 정보를 가지고 있지 않다.

그래서 제네릭 타입의 객체 또는 배열 인스턴스를 생성할 수 없는 것이다.

그렇다면 제네릭은 왜 비실체화 타입일까?

제네릭은 JDK 1.5에 처음 도입되었고, 기존 코드와의 호환성을 위해 타입 소거를 통해 타입 정보를 유지하지 않기로 했다. 그로 인해 제네릭은 런타임에 타입 정보가 없는 비실체화 타입이 된 것이다.

결론

애초에 제네릭 타입의 배열 `E[]`을 생성할 수 없어서 `Object[]`을 사용한 것이다.

강제 형변환을 통해 제네릭 타입의 배열을 사용할 수는 있지만 타입 안정성을 보장할 수 없어 권장하지 않는다.

참고

https://velog.io/@bedshanty/자바의-ArrayList가-제네릭-타입-E가-아닌-Object를-저장하는-이유#자바-제네릭의-작동-방식

https://docs.oracle.com/javase/tutorial/java/generics/genTypes.html

https://docs.oracle.com/javase/tutorial/java/generics/genMethods.html

https://docs.oracle.com/javase/tutorial/java/generics/nonReifiableVarargsType.html

https://docs.oracle.com/javase/tutorial/java/generics/restrictions.html

https://pompitzz.github.io/blog/Java/whyCantCreateGenericsArray.html#제네릭-배열-사용하기

잘못된 정보나 내용에 대해 피드백해주시면 감사하겠습니다!

[백준] [자바/JAVA] 11723번 - 집합

말차쟁이 — Wed, 23 Oct 2024 00:12:49 +0900

https://www.acmicpc.net/problem/11723

문제

문제 그대로 공집합 S에 아래 연산을 수행한다.

add x : S에 x를 추가 (S에 x가 이미 있는 경우에는 연산을 무시)
remove x : S에서 x를 제거 (S에 x가 없는 경우에는 연산을 무시)
check x : S에 x가 있으면 1을, 없으면 0을 출력
toggle x : S에 x가 있으면 x를 제거, 없으면 x를 추가
all : S를 {1, 2, ..., 20} 으로 변경
empty : S를 공집합으로 변경 (S를 비운다)

조건

1 ≤ x ≤ 20

빨간색 마킹표시를 정리하면 아래 내용과 같다.

S에 x를 추가
S에서 x를 제거
S에 x가 있는지 없는지 유무 확인

위 기능들을 보면 자바에서 떠오르는 자료구조들이 있을 것이다.

Collection의 List, Set 이 있고 Map도 위 기능들을 수행할 수 있다.

주어진 값들을 키 - 값 구조로 넣을 필요는 없으니 Map은 제외하고, 주어진 연산의 수의 최댓값이 300만이니 List보다 속도가 빠른 Set으로 구현해보겠다.

사실 처음에 Set으로 구현하면 풀겠다 라고 생각했지만 로직을 잘못 구현해 자꾸 시간초과가 났었다.

그래서 문제의 힌트인 비트마스킹으로 풀었고, Set으로도 다시 풀어서 성공했다.

총 2가지 방법으로 풀이했다.

문제풀이

방법 1 - 비트마스킹

비트마스킹은 정수의 이진수 표현을 자료구조로 쓰는 기법이다.

먼저 비트연산자를 알아보자.

비트 연산	자바 비트 연산	설명
AND	&	대응하는 두 비트가 모두 1이면 1
OR	\|	대응하는 두 비트 중 하나라도 1이면 1, 아니면 0
XOR	^	대응하는 두 비트가 다르면 1, 같으면 0
NOT	~	비트의 값을 반전
SHIFT	<<. >>	비트를 왼쪽 또는 오른쪽으로 이동

이제 이진수 표현을 자료구조로 어떻게 사용하는지 알아보자.

int는 4바이트 자료형이다. 4바이트 = 32비트 = 2³²

그리고 x는 1 ~ 20 범위의 정수다.

int로 표현할 수 있는 값은 2³² 0000 0000 0000 0000 0000 0000 0000 0000 으로 표현할 수 있다.

여기서 1 ~ 20 범위인 x를 위의 2진수에서 각 자리수를 x와 매칭시켜 아래 그림처럼 표현할 수 있다.

그럼 2진수인 형태에서 연산을 수행하면 아래와 같다.

x = 1 이라고 가정한다.

add x : S에 x를 추가 (S에 x가 이미 있는 경우에는 연산을 무시)
자바 비트 연산 : S |= (1 << x)
- 1을 x만큼 왼쪽으로 이동 후 S의 x자리와 OR 연산

remove x : S에서 x를 제거 (S에 x가 없는 경우에는 연산을 무시)
자바 비트 연산 : S &= ~(1 << x)
- 1을 x만큼 왼쪽으로 이동 후 반전시키면 0이 됨. 0과 S의 x자리와 AND 연산

check x : S에 x가 있으면 1을, 없으면 0을 출력
자바 비트 연산 : (S & (1 << x)) != 0
- 1을 x만큼 왼쪽으로 이동 후 S의 x자리와 AND 연산 후 값이 1이면 있는 것이고 0이면 없는 것

remove 하여 1이 제거되었으니 0을 출력

toggle x : S에 x가 있으면 x를 제거, 없으면 x를 추가
자바 비트 연산 : S ^= (1 << x)
- 1을 x만큼 왼쪽으로 이동 후 S의 x자리와 XOR 연산 (S의 x자리에 값이 있다면 0으로 변환(제거), 없다면 1로 변환(추가))

all : S를 {1, 2, ..., 20} 으로 변경
자바 비트 연산 : S = (1 << 21) - 1;
- 1을 21만큼 왼쪽으로 이동 후 1을 빼게되면, 10 0000 0000 0000 0000 에서 1을 빼는 것이니 1부터 20자리까지 1로 변환됨

empty : S를 공집합으로 변경 (S를 비운다)
자바 비트 연산 : S = 0
- S에 0을 대입하면 모든 자리가 0으로 변환됨

비트 연산만 이해되면 바로 풀 수 있다.

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

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

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        try {
            int m = Integer.parseInt(br.readLine());
            StringTokenizer st;
            StringBuilder sb = new StringBuilder();

            // 공집합 S
            int set = 0;

            for(int i=0; i<m; i++) {
                st = new StringTokenizer(br.readLine());
                String op = st.nextToken();

                if(op == null || op.isBlank()) continue;

                int value = 0;
                if(!op.equals("all") && !op.equals("empty")) {
                    value = Integer.parseInt(st.nextToken());
                }

                switch (op) {
                    case "add":
                        set |= (1 << value);
                        break;
                    case "remove":
                        set &= ~(1 << value);
                        break;
                    case "check":
                        sb.append((set & (1 << value)) != 0 ? 1 : 0).append("\n");
                        break;
                    case "toggle":
                        set ^= (1 << value);
                        break;
                    case "all":
                        // 1~20 의 수를 표현해야 되기때문에 21자리로 시트프 후 -1을 해서 20자리를 맞춤
                        set = (1 << 21) - 1;
                        break;
                    case "empty":
                        set = 0;
                        break;
                }
            }

            System.out.println(sb);

        } catch(Exception e) {}
    }
}

방법 1 - Set 이용

문제에서 주어진 연산들을 모두 Set이 가지고 있기 때문에 Set을 이용하면 간단하다.

혹시 Set에 대해 아직 잘 모른다면 Set에 대해 조금 더 학습을 한 후 풀어보면 좋을 것 같다.

풀이는 간단하니 주석으로 대체하겠다.

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.HashSet;
import java.util.Set;
import java.util.StringTokenizer;

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

        try {
            int m = Integer.parseInt(br.readLine());
            StringTokenizer st;
            StringBuilder sb = new StringBuilder();

            // 공집합 S
            Set<Integer> set = new HashSet<>();

            for(int i=0; i<m; i++) {
                st = new StringTokenizer(br.readLine());
                String op = st.nextToken();

                // all이나 empty 연산은 값이 안 들어오기 때문에 예외처리 필요
                int value = st.hasMoreTokens() ? Integer.parseInt(st.nextToken()) : 0;

                switch (op) {
                    case "add":
                        // S에 x 추가
                        set.add(value);
                        break;
                    case "remove":
                        // S에서 x 제거
                        set.remove(value);
                        break;
                    case "check":
                        // S에 x가 있으면 1을, 없으면 0을 출력 (삼항 연산자)
                        sb.append(set.contains(value) ? 1 : 0).append("\n");
                        break;
                    case "toggle":
                        // S에 x가 있으면 x를 제거
                        if(set.contains(value)) set.remove(value);
                        // S에 x가 없으면 x를 추가
                        else set.add(value);
                        break;
                    case "all":
                        // S를 초기화
                        set.clear();
                        // 반복문을 통해 S에 {1, 2, ..., 20} 추가
                        for(int j=1; j<=20; j++) {
                            set.add(j);
                        }
                        break;
                    case "empty":
                        // S를 초기화
                        set.clear();
                        break;
                }
            }

            System.out.println(sb);

        } catch(Exception e) {}
    }
}

객체 지향 프로그래밍 (Object-Oriented Programming, OOP)

말차쟁이 — Sun, 4 Aug 2024 17:24:28 +0900

객체 지향 프로그래밍 (Object-Oriented Programming, OOP)

컴퓨터 프로그래밍 패러다임 중 하나로, 현실 세계의 사물이나 개념을 객체(Object)로 보고 그 객체들 간의 상호작용으로 프로그래밍하는 방법이다.

객체 지향 프로그래밍은 프로그램을 유연하고 변경이 쉽게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

구성 요소

클래스(Class) : 객체를 정의해놓은 것으로 객체를 생성하는데 사용된다. (객체를 생성하기 위한 설계도 또는 틀)
객체(Object) : 현실 세계의 사물이나 개념 (클래스에서 정의한 내용을 기반으로 생성된 실체)
메시지(Message) : 객체들 간의 상호작용에 사용되는 수단으로, 객체에 어떠한 행위를 하도록 지시하는 명령 또는 요구사항
- 인스턴스(Instance) : 클래스를 사용하여 실제로 메모리상에 할당된 객체
- 메서드(Method) : 다른 객체로부터 메시지를 수신할 때 메시지를 처리하는 로직 (객체가 수행하는 행위)

클래스는 객체를 생성하기 위한 설계도 역할을 하며, 클래스를 사용하여 객체를 생성한다.
이 때 생성된 객체가 실제 메모리에 할당되면 인스턴스라고 한다.

운전자가 브레이크를 밟아 차를 멈출 때 "차를 멈추다"라는 메시지를 자동차(객체)에게 전달한다.
"차를 멈추다"라는 메시지를 수신한 자동차(객체)는 차를 멈추는 것을 수행하는 로직을 메서드라고 한다.

특징

추상화 (Abstraction)
캡슐화 (Encapsulation)
상속 (Inheritance)
다형성 (Polymorphism)

추상화 (Abstraction)

예를 들어 포르쉐, 테슬라, 페라리가 있다고 하자. (모두 자동차의 종류)

이들은 모두 전진하다, 멈추다(기능), 핸들(속성)을 공통으로 가지고 있다.

이를 자동차라는 클래스(인터페이스)로 객체의 공통적인 속성과 기능을 추출하여 정의하는 것을 추상화라고 한다.

이처럼 공통 기능을 자동차에서 미리 정의를 하고 포르쉐, 테슬라, 페라리는 자동차라는 클래스(인터페이스)를 상속(구현)을 받아 미리 정의된 공통 기능을 각각 구현할 수 있다. 이렇게되면 공통 기능을 한 곳에서 정의를 했기 때문에 코드의 중복이 줄어든다.

캡슐화 (Encapsulation)

캡슐은 내용물을 외부에서 보이지 않게 포장한 형태를 말한다.

객체의 속성과 기능을 캡슐처럼 외부에서 직접 접근하지 못하도록 제한하는 정보은닉의 개념 중 하나이다.

자바로 예를 들면, Car 라는 클래스에 price 라는 변수가 있다고 하자.

Car는 price가 10,000 값으로 입력되어있는데 외부에서 임의로 다른 값으로 변경할 가능성이 있다.

그렇기 때문에 price는 외부에서 직접 접근하지 못하게 접근제어자로 제한하고 접근 가능한 메서드를 제공한다. getter/setter

또한 유효성 체크 로직을 통해 유효한 값만 넣을 수 있도록 제한할 수 있다.

public class Car {

    // private으로 접근 제한 (private: Car 클래스 내에서만 접근 가능)
    private int price = 10000;

    // price에 접근해서 조회할 수 있는 getter 메서드 (public: 모든 클래스에서 접근 가능)
    public int getPrice() {
        return price;
    }

    // price에 접근해서 값을 변경할 수 있는 setter 메서드 (public: 모든 클래스에서 접근 가능)
    public void setPrice(int price) {

        // price에 대한 유효성 검사
        if(price < 0) {
            return;
        }

        this.price = price;
    }
}

정보은닉

객체 지향에서 정보 은닉(data hiding)이란 사용자가 굳이 알 필요가 없는 정보는 사용자로부터 숨겨야 한다는 개념이다.

객체에 대한 구체적인 정보를 노출시키지 않도록 하는 기법

접근제어자

자바(JAVA)는 4가지의 접근제어자를 통해 객체의 캡슐화, 정보은닉을 구현한다

public : 모든 클래스에서 접근 가능
default : 같은 패키지에서만 접근 가능
protected : 같은 패키지이거나 해당 클래스를 상속받은 클래스에서만 접근 가능
private : 같은 클래스 내에서만 접근 가능

상속 (Inheritance)

객체들 간의 관계를 구축하는 개념이다.

상위 클래스(부모 클래스)로부터 속성(변수)과 기능(메서드)을 하위 클래스(자식 클래스)가 물려받는 것을 상속이라 한다.

상위 클래스 = 부모 클래스

하위 클래스 = 자식 클래스

상속 구성도 (화살표를 받는 쪽이 부모클래스이다)

위 그림으로 예시를 들어보자.

교통수단은 자동차의 상위 클래스이고,

자동차는 교통수단의 하위 클래스이자 포르쉐, 테슬라, 페라리의 상위 클래스이다.

포르쉐, 테슬라, 페라리 또한 자동차의 하위 클래스이다.

자동차는 상위 클래스인 교통수단으로부터 수송하다를 물려받았고,

포르쉐, 테슬라, 페라리는 상위 클래스인 자동차로부터 수송하다, 전진하다, 멈추다, 핸들을 물려받았다.

또한 오버라이딩을 통해 상위 클래스로부터 물려받은 기능(메서드)를 하위 클래스의 고유 기능으로 재정의할 수 있다.

이렇게 상속을 통해서 상위 클래스의 속성(변수)과 기능(메서드)을 하위 클래스에서 상속받아 코드 중복 제거, 코드 재사용의 장점을 얻을 수 있다.

다형성 (Polymorphism)

하나의 객체가 여러 가지 타입을 가질 수 있는 것

다형성은 객체 지향 프로그래밍의 상속과 인터페이스 개념을 통해 구현되며 코드 재사용성과 유연성을 향상시킨다.

위 그림에서 운전자는 자동차를 운전을 할 수 있다.

만약 운전자가 자동차의 한 종류인 포르쉐를 운전하다 사고가 났다. 다른 차로 변경해서 운전을 해야하는 상황에서 운전자는 자동차를 운전할 수 있기 때문에 포르쉐가 아닌 자동차의 다른 종류인 테슬라나 페라리로 변경해도 운전할 수 있다.

이렇게 자동차(객체)가 포르쉐, 테슬라, 페라리 등 여러 가지 자동차 종류(타입)를 가질 수 있는 것을 다형성이라고 한다.

다형성의 필수 조건

1. 상속관계

부모(상위) 클래스와 자식(하위) 클래스는 상속 관계여야 한다.

2. 오버라이딩 (Overriding)

다형성이 보장되기 위해 오버라이딩(자식 클래스 메서드의 재정의)이 반드시 필요하다.

3. 업캐스팅 (Upcasting)

자식 클래스의 객체가 부모 클래스의 타입으로 형변환(업캐스팅)해야 한다.

다형성이 하나의 객체가 여러 가지 타입을 가질 수 있는 것이라고 했다.

하지만 모든 타입을 가질 수 있는 것은 아니다.

아래 자바코드로 예시를 들어보겠다.

class Porsche extends Car {
    void heatedSeat() {}
}

public class Car {
    void drive() {}
}

1. 부모 타입의 참조변수로 자식 타입의 인스턴스를 참조할 수 있다.

Car car = new Porsche(); // O

자바에서는 다형성을 통해 부모 타입(Car)의 참조 변수로 자식 타입(Porsche)의 인스턴스를 참조할 수 있다.

2. 자식 타입의 참조변수로 부모 타입의 인스턴스를 참조할 수 없다.

Porsche porsche = new Car(); // X (컴파일 에러)

실제 인스턴스인 Car의 멤버 개수보다 Porsche 타입의 참조 변수 porsche가 사용할 수 있는 멤버 개수가 더 많기 때문이다.

Porsche 클래스가 Car 클래스를 상속받으면 Car 클래스의 모든 멤버(필드, 메서드)를 가지고 있기 때문에 Porsche 타입인 참조변수 porsche는 인스턴스 Car보다 사용할 수 있는 멤버 개수가 더 많다.

위 코드에서 참조변수 porsche는 Porsche 타입이므로 drive(), heatedSeat()을 사용할 수 있다.

(drive는 Car 클래스를 상속받았기 때문에 사용가능)

하지만 참조변수 porsche가 참조하고 있는 인스턴스는 Car 타입이고, Car 타입의 인스턴스에는 heatedSeat()가 존재하지 않기 때문에 문제가 발생한다.

이렇게 존재하지 않는 멤버를 사용할 가능성이 있으므로 자식 타입의 참조변수로 부모 타입의 인스턴스를 참조할 수 없다.

3. 참조변수가 사용할 수 있는 멤버의 개수는 인스턴스의 멤버 개수보다 같거나 적어야 한다.

Car car = new Porsche();

2번의 내용에 나왔던 것처럼

인스턴스 Porsche의 멤버 개수보다 참조 변수 car의 멤버 개수가 많으면, 존재하지 않는 멤버를 사용하는 문제가 발생할 수 있기 때문이다.

따라서 자식 타입의 참조변수로 부모 타입의 인스턴스를 참조할 수 없고,

참조변수가 사용할 수 있는 멤버의 개수는 인스턴스의 멤버 개수보다 같거나 적어야 한다.

참조변수의 타입과 인스턴스 타입에 따른 접근범위

Car 클래스와 Porsche 클래스의 상속관계를 도식화한 그림이다.

참조변수의 타입은 참조변수가 참조하는 인스턴스의 사용범위라고 이해하면 될 것 같다.

다형성을 활용한 자바코드

class Car extends Transportation {
    void accelerate() {}
    void stop() {}
}
class Porsche extends Car {
    void heatedSeat() {}
}
class Tesla extends Car {
    void selfDrive() {}
}
class Ferrari extends Car {
    void coolSeat() {}
}

public class Transportation {

    public void transport() {
        System.out.println("수송하다");
    }

    public static void main(String[] args) {
    	// 1. 참조변수의 타입과 인스턴스의 타입이 같음
        Transportation transportation = new Transportation();
        Car car = new Car();
        Porsche porsche = new Porsche();
        Tesla tesla = new Tesla();
        Ferrari ferrari = new Ferrari();

	// 2. 부모 타입의 참조변수로 자식 타입의 인스턴스 생성
        Transportation transportation1 = new Car();
        Transportation transportation2 = new Porsche();

	// 3. 부모 타입의 참조변수로 자식 타입의 인스턴스 생성
        Car car1 = new Porsche();
        Car car2 = new Tesla();
		
        // 4. 자식 타입의 참조변수로 부모 타입의 인스턴스 생성
        Car car3 = new Transportation(); // 컴파일 에러
        Porsche porsche1 = new Car(); // 컴파일 에러
    }
}

코드 중복 제거, 코드 재사용 : 상속을 기반으로 하기 때문에 상속이 가지고 있는 코드 중복 제거, 코드 재사용의 장점이 있다.
유지보수 용이 : 여러 객체를 하나의 타입으로 관리가 가능하기 때문에 유지보수가 용이하다.
유연성 : 다형성을 사용하면 객체를 추상화하고, 해당 객체를 사용하는 다른 객체에서 동일한 클래스 또는 인터페이스를 사용할 수 있다. 이를 통해 객체 간의 결합도를 낮추고 코드의 유연성과 확장성을 높일 수 있다.

정리

객체지향 프로그래밍

컴퓨터 프로그래밍 패러다임 중 하나로 현실 세계의 사물이나 개념을 객체로 보고 그 객체들 간의 상호작용으로 프로그래밍하는 방법

구성 요소

클래스 : 객체를 정의해놓은 것으로, 객체를 생성하는데 사용된다.
메시지 : 객체들 간의 상호작용에 사용되는 수단으로, 객체에 어떠한 행위를 하도록 지시하는 명령 또는 요구사항
객체 : 현실 세계의 사물이나 개념

특징

추상화 : 객체의 공통적인 속성과 기능을 추출하여 정의
캡슐화 : 객체의 속성과 기능을 캡슐처럼 외부에서 직접 접근하지 못하도록 제한하는 정보은닉의 개념 중 하나
상속 : 상위 클래스(부모 클래스)로부터 속성(변수)과 기능(메서드)을 하위 클래스(자식 클래스)가 물려받는 것
다형성 : 하나의 객체가 여러 가지 타입을 가질 수 있는 것

참고

자바의정석 [남궁성]
https://ko.wikipedia.org/wiki/%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

Hello world

Docker IP 대역 변경

IP 대역을 변경해야 하는 이유

요청사항

docker0

docker_gwbridge

Docker IP 대역 변경

1. daemon.json 수정

2. 설정 및 설치파일 수정

3. docker_gwbridge 삭제 및 swarm 재설치

4. 컨테이너 배포 및 재배포

참고

Gson으로 파싱할 때 double 자동변환

원인

해결

참고

CAS (Compare And Swap)

원자적 연산

멀티스레드 환경

원자적이지 않은 연산

원자적 연산

Lock 기반 방식

동작 방식

Lock 프리(Free) 방식

CAS (Compare And Swap)

동작 원리

CAS에 필요한 3가지 값

CAS 연산 과정

어떻게 원자적일까?

왜 CAS 연산 중 다른 CPU가 값을 변경하지 못할까?

장점

단점

언제 사용하는 것이 좋을까?

참고

상속이 캡슐화를 위반하는 이유

상속

캡슐화

문제점

그럼 오버라이딩때문에 캡슐화를 위반한 것일까?

결론

참고

hashCode()와 equals()를 같이 오버라이딩해야 하는 이유

hashCode()

해시 함수

equals()

String의 equals()

그래서 hashCode()와 equals()를 같이 오버라이딩해야 하는 이유는 뭘까?

결론

참고

ConcurrentHashMap의 동작원리

HashTable

ConcurrentHashMap

Table

Node

get()

put()

Constructor

참고

제네릭 타입 소거 (Type Erasure)

제네릭의 작동 방식

타입 소거

제네릭 타입 치환 규칙

실체화 타입(Reifiable Types) / 비실체화 타입(Non-Reifiable Types)

타입 소거 과정

브릿지 메서드 (Bridge Method)

참고

ArrayList는 왜 제네릭 타입 E[]가 아닌 Object[]으로 요소를 관리할까?

ArrayList

제네릭을 이용해 구현한 ArrayList

elementData를 Object[] 타입으로 선언했을 때 단점

그런데 굳이 Object[] 타입으로 사용하는 이유는 뭘까?

타입 소거

그럼 만약 elementData를 E[] 타입으로 사용한다면 어떻게 될까?

왜 제네릭 타입의 인스턴스를 생성하지 못할까?

그렇다면 제네릭은 왜 비실체화 타입일까?

결론

참고

[백준] [자바/JAVA] 11723번 - 집합

문제

조건

`elementData`를 `Object[]` 타입으로 선언했을 때 단점

그런데 굳이 `Object[]` 타입으로 사용하는 이유는 뭘까?

그럼 만약 `elementData`를 `E[]` 타입으로 사용한다면 어떻게 될까?