눙눙의 개발일지

[F-Lab] 자바 백엔드 멘토링 1개월 후기

oniwon — Tue, 19 May 2026 17:07:22 +0900

[F-Lab 멘토링 할인 코드]
커넥터스2385

왜 F-Lab이었나

SI 회사 퇴사 전부터 실제 트래픽을 받는 서비스 회사에 들어가 개발하고 싶다는 마음이 컸다.

회사를 다니면서 가장 아쉬웠던 부분인 멘토의 부재를 채우기 위해,

1:1 멘토링의 장점이 있는 F-Lab을 신청하게 되었다.

자세한 신청 동기는 [F-Lab] 0주차 시작에 정리해 두었다.

한 달 동안 무엇을 학습했는가

자바의 신 1, 2권을 완독했다.

단순히 '책을 읽었다'에 그치는 것이 아니라,

책에 없는 깊이 있는 내용들까지 함께 학습했다.

원래 알고 있다고 생각했던 자바 개념들을 처음부터 다시 들여다보는 시간이었다.

주차별 회고에 기록했듯이, 멘토링에서 그동안 다룬 주제만 해도 꽤 많다.

동시성: synchronized, AtomicInteger, Mutex와 Semaphore, ThreadLocal
컬렉션: ArrayList/LinkedList/Vector, HashSet/TreeSet/LinkedHashSet, 해시맵 버킷 계산의 비트 연산
객체지향: 다형성, 상속, 컴포지션, DI, 인터페이스 vs 추상 클래스
자바 키워드와 동작: equals/hashCode, enum, final/transient, String, finalize/clone
네트워크: 블로킹, 논블로킹 × 동기, 비동기 4조합, TCP/UDP

이 외에도 훨씬 많은 개념들을 공부했다.

개념 학습 뿐만 아니라 JDK 내부 동작을 살펴보면서 JVM, 메모리, 네트워크 측면에서도 함께 생각해 볼 수 있었고, 이 과정에서 시야가 한 단계 넓어졌다고 느낀다.

멘토님

멘토링을 시작하기 전에 얻고 싶은 바가 분명한 편이었다.

대표적으로 깊이 있는 꼬리 질문, 그리고 커리어 방향에 대한 이야기였다.

지금 멘토님은 이 기준에서 충분히 만족스럽다.
특히 AI에 관한 이야기를 나누면서,

그동안 내가 미처 보지 못했던 관점들이 많았다는 걸 알게 됐다.

소통적인 면에서도 슬랙에 질문을 남기면 답이 빠르신 편이라,
일주일 동안 막히는 부분이 있어도 흐름이 끊기지 않아서 좋았다.

1개월 이후 시점의 만족도

4주차가 된 지금 시점에서 말하자면, 대체적으로 만족스럽다고 할 수 있다.

크게 세 가지 측면으로 정리해 봤다.

1. 정의를 정확히 말하게 만드는 압박
"알고 있다"와 "설명할 수 있다"는 완전히 다르다는 걸 1주차에 바로 깨달았다.
개념을 말로 직접 꺼내 보면서 어설프게 알던 부분이 드러나고,
멘토링 이후에 그 개념들을 정확하게 다시 정리하게 된다.

2. 개념과 개념이 연결됨
자바의 pass by value와 익명 클래스의 변수 캡처가 서로 이어지는 개념인 것처럼,
별개라고 생각했던 개념들을 구조화할 수 있다.

3. 학습 외의 상담
3주차엔 이력서를 같이 봐주시고 프로젝트 관련 조언을 받았다.
기술 멘토링만이 아니라, 커리어 방향까지 함께 이야기할 수 있다는 게 장점이다.

굳이 아쉬운 점을 한 가지 꼽자면, 오프라인 네트워킹 기회가 생각보다 많지는 않았다.

앞으로

이번 주는 JSP 주요 챕터와 객체지향 관련 도서를 학습하고 있다.

병행해서 프로젝트가 남아 있다.

AI에게 작업을 위임하려면

개발자 본인이 전체 아키텍처 구조를 이해하고 병목 지점을 짚어낼 수 있어야 한다고 생각한다.

즉 AI에게 일을 시키는 설계자가 되어야 한다고 생각한다.

아직은 초기 구현 단계라 많이 부족하다고 느끼지만,

한 달 뒤의 후기에서는 감을 잡고 한 단계 발전한 모습이 되고 싶다.

에프랩 관련 질문은 오픈채팅 남겨주시면 제가 아는 선에서 답변드리겠습니다!

추천인 코드: 커넥터스2385

[F-Lab] 4주차 정리 및 회고

oniwon — Tue, 19 May 2026 15:50:14 +0900

[F-Lab 멘토링 할인 코드]
커넥터스2385

사전 학습

자바의 신 2 4장 ~ 10장

멘토링 질문

ArrayList 와 LinkedList 차이, Vector
ConcurrentModificationException
HashSet, TreeSet, LinkedHashSet 차이
Thread와 Process 차이
Thread를 왜 써야 할까?
synchronized 키워드
AtomicInteger, AtomicBoolean 등의 클래스
Mutex와 Semaphore 차이
TCP, UDP 차이
비대칭 키 암호화
AutoClosable 인터페이스
Thread Local

과제

C/C++로 소켓 통신 구현 실습
프로젝트 기획 및 기능 구체화
JSP 책의 세션, 쿠키, 필터 관련 챕터 읽기
객체지향 관련 도서 읽기

추가 학습

Arrays.copyOf가 얕은 복사인 이유 — 어셈블리까지 내려가기

멘토링 Q&A

프로젝트 기획 관련 질문

회고

벌써 이번 주를 끝으로 '자바의 신'이 마무리됐다.

한 달이 지났다는 게 믿기지 않는다.

약 4주간 자바 공부에 거의 집중하면서

평소 알고 있던 것보다 훨씬 깊이 있게 자바를 들여다볼 수 있었다.

배운 내용을 프로젝트에 바로 적용해 볼 수 있다는 점도 좋은 것 같다.

이번주는 개인 프로젝트도 시작했는데,

AI를 어떻게 잘 활용할지도 같이 고민하게 된다.

처음부터 기획을 너무 확실하게 짜다 보니

(완벽주의 성향이 이럴 땐 오히려 독이 된다고 느꼈다..)

구현이 불필요하게 복잡해졌다.

MVP 위주로 먼저 구현하고

살을 붙여 단계별로 확장해 나가는 게 좋은 방법이라는 걸 깨닫고,

그 방식으로 다시 구현하고 있다.

에프랩 관련 질문은 오픈채팅 남겨주시면 제가 아는 선에서 답변드리겠습니다!

추천인 코드: 커넥터스2385

[Java] Arrays.copyOf가 얕은 복사인 이유 — 어셈블리까지 내려가기

oniwon — Tue, 19 May 2026 15:28:39 +0900

ArrayList가 가득 차면 어떻게 동작할까?

내부 배열이 1.5배로 리사이징되면서 `Arrays.copyOf()`로 기존 요소를 복사한다.

이때 복사된 배열은 원본과 같은 객체를 참조한다. 얕은 복사이기 때문이다.

그런데 얕은 복사인 걸 어떻게 알 수 있을까?

그걸 확인하기 위해 JDK 소스부터 HotSpot 소스, 그리고 어셈블리 stub까지 따라가 봤다.

전체 호출 체인

  ArrayList.add(E)
    → ArrayList.grow()
      → Arrays.copyOf(T[], int)
        → System.arraycopy(...)              // native 진입점
          → JVM_ArrayCopy (jvm.cpp)
            → ObjArrayKlass::copy_array
              → ArrayAccess::oop_arraycopy
                → Copy::conjoint_oops_atomic
                  → pd_conjoint_oops_atomic   // oop* → jlong* 캐스팅
                    → _Copy_conjoint_jlongs_atomic  // 어셈블리 stub

1. 자바 레이어 - 객체를 새로 만들지 않음

public static <T,U> T[] copyOf(U[] original, int newLength, Class<? extends T[]> newType) {
  T[] copy = ((Object)newType == (Object)Object[].class)
      ? (T[]) new Object[newLength]
      : (T[]) Array.newInstance(...);
  System.arraycopy(original, 0, copy, 0, Math.min(original.length, newLength));
  return copy;
}

new Object[newLength]로 만든 것은 null로 채워진 빈 배열이다. 자바 코드 어디에서도 원소 객체를 새로 생성하지 않는다.

실제 복사는 native 메서드인 System.arraycopy로 위임된다.

@IntrinsicCandidate
public static native void arraycopy(Object src, int srcPos,
                                  Object dest, int destPos, int length);

@IntrinsicCandidate 덕분에 핫 코드에서는 JIT가 이 호출을 통째로 어셈블리로 치환한다. 이하 C++ 경로는 인터프리터/콜드 코드 기준이다.

2. HotSpot 진입 — 배열 타입에 따른 분기

`hotspot/share/prims/jvm.cpp`의 JVM_ArrayCopy로 들어온 뒤 다음 한 줄에서 가상 디스패치가 일어난다.

arrayOop s = arrayOop(JNIHandles::resolve_non_null(src));
s->klass()->copy_array(s, src_pos, d, dst_pos, length, thread);

여기서 s->klass()는 객체 헤더의 klass 포인터를 따라가 해당 객체의 메타클래스를 반환한다.

자바의 모든 객체는 헤더에 자신의 타입을 가리키는 klass 포인터를 가지고 있다.

copy_array는 Klass 기반 클래스의 가상 함수이며, 각 하위 클래스가 자기 방식대로 오버라이드한다.

따라서 가상 디스패치는 객체의 실제 타입에 따라 다른 구현으로 분기된다.

Object[]로 생성된 배열의 klass는 ObjArrayKlass의 인스턴스 → ObjArrayKlass::copy_array
int[]로 생성된 배열의 klass는 TypeArrayKlass의 인스턴스 → TypeArrayKlass::copy_array

3. 인덱스를 메모리 오프셋으로 변환

ObjArrayKlass::copy_array는 인덱스를 바이트 오프셋으로 바꾼다.

size_t src_offset = (size_t) objArrayOopDesc::obj_at_offset<oop>(src_pos);
size_t dst_offset = (size_t) objArrayOopDesc::obj_at_offset<oop>(dst_pos);

obj_at_offset<oop>은 "n번째 oop 슬롯의 위치"를 계산한다. 이 시점에서 코드는 복사 대상을 "객체"가 아니라 "oop 슬롯"으로 명시한다.

oop(Ordinary Object Pointer): HotSpot이 자바 객체를 가리킬 때 쓰는 포인터. 64비트 JVM에서는 8바이트.

4. GC 배리어 — 객체 배열 경로에만 존재

객체 배열 복사는 GC 배리어로 감싸여 있다.

bool oop_arraycopy_in_heap(...) {
bs->write_ref_array_pre(dst_raw, length, false);   // pre-barrier
Raw::oop_arraycopy(...);                            // 실제 비트 복사
bs->write_ref_array((HeapWord*)dst_raw, length);    // post-barrier (카드 마킹)
}

각 단계가 무엇을 하는지 구체적인 예시로 살펴보자.

길이 10짜리 String[]을 길이 15짜리 새 배열로 확장하는 상황을 가정한다.

(1) Pre-barrier

dst = [null, null, null, null, null, null, null, null, null, null, ...]

기존 배열에 덮어쓰는 경우 GC에 옛 참조를 알리는 처리가 일어난다.
이 예시처럼 새로 할당된 빈 배열이라면 옛 참조 자체가 없으므로 실질적인 동작이 없다.

(2) 비트 복사

  src = [str0, str1, str2, ..., str9]
↓     ↓     ↓           ↓
  dst = [str0, str1, str2, ..., str9, null, null, null, null, null]

src 슬롯의 oop 값이 dst 슬롯으로 그대로 옮겨진다.

(3) Post-barrier

G1은 dst의 해당 영역에 대응하는 카드 테이블 엔트리를 "dirty"로 표시한다.

다음 GC가 "이 카드 범위에 새 참조가 생겼으니 스캔해야 한다"는 것을 알게 된다.

왜 post-barrier가 필요한가

세대별 GC는 minor GC를 빠르게 처리하기 위해 "old gen이 young gen을 가리키는 참조"를 따로 추적한다. 카드 테이블 마킹이 그 추적의 핵심 메커니즘이다.

old gen에 있는 객체 배열의 슬롯에 young gen의 객체 참조가 새로 들어가는 상황을 떠올려보자.
(이 코드 경로는 모든 객체 배열 복사가 공유하므로 이런 경우도 처리해야 한다)

이때 post-barrier가 없으면 minor GC는 old gen을 스캔하지 않으므로, 그 배열이 young gen의 객체를 참조하고 있다는 사실을 알지 못한다. 그 결과 살아있는 객체가 회수돼버린다.

post-barrier가 카드를 dirty로 마킹해두어야 minor GC가 그 영역을 추가로 스캔해 참조 관계를 발견한다.

비대칭이 보여주는 것

원시 타입 배열 복사 경로에는 이 배리어가 없다. 슬롯에 들어있는 값이 주소가 아니라 값 자체이므로 GC가 추적할 새로운 참조 관계가 발생하지 않기 때문이다.

객체 배열 경로에만 배리어가 붙는 이유는 복사가 새로운 참조를 생성하기 때문이다.

이 비대칭 자체가 "객체 배열 복사는 참조값을 다룬다"는 증거이다.

5. oop* → jlong* 캐스팅

비트 복사를 따라가면 `hotspot/os_cpu/linux_x86/copy_linux_x86.hpp`(OS+CPU 조합별로 정의)에 도착한다.

static void pd_conjoint_oops_atomic(const oop* from, oop* to, size_t count) {
#ifdef AMD64
assert(BytesPerLong == BytesPerOop, "jlongs and oops must be the same size");
_Copy_conjoint_jlongs_atomic((const jlong*)from, (jlong*)to, count);
#endif
}

이 두 줄이 의미하는 바는 아래와 같다.

oop* (객체 포인터 배열) → jlong* (8바이트 정수 배열)로 캐스팅
이후 호출되는 _Copy_conjoint_jlongs_atomic은 long[] 복사에 쓰이는 바로 그 함수

캐스팅 이후의 코드는 "이 8바이트가 객체 주소인지 단순 정수인지" 구분하지 않는다. 8바이트 단위로 N개를 옮기는 동작만 남는다.

6. 어셈블리 stub — movq 두 줄

`_Copy_conjoint_jlongs_atomic`은 일반 C++ 함수가 아니라 JVM 부팅 시 메모리에 동적으로 써넣는 어셈블리 stub이다.

L_copy_8_bytes:
movq rax, [from + qword_count*8 - 8]
movq [to + qword_count*8 - 8], rax
dec  qword_count
jnz  L_copy_8_bytes

x86에는 메모리 간 직접 이동 명령이 없으므로 레지스터(rax)를 거쳐 8바이트를 옮긴다.

이 루프가 N번 반복되면서 src 슬롯의 oop 값(=객체 주소)을 dst 슬롯에 복사한다.

복사 결과

복사 전

src[0] → 0x1010 → "hello" 객체 (힙)
dst[0] → null

복사 후

src[0] → 0x1010 ─┐
                 ├──→ "hello" 객체 (힙, 그대로 1개)
dst[0] → 0x1010 ─┘

객체 자체는 힙에서 움직이지 않고, dst 슬롯과 src 슬롯이 동일한 주소값을 갖게 된다.

정리

Arrays.copyOf의 복사는 6단계의 호출 체인을 거쳐 어셈블리 movq 두 줄로 귀결된다.
객체 배열 복사 경로에만 GC 배리어가 붙으며, 이는 복사 대상이 참조값임을 보여준다.
pd_conjoint_oops_atomic이 oop*를 jlong*로 캐스팅하는 시점부터 코드는 객체 주소를 단순한 8바이트 정수로 취급한다.
따라서 Arrays.copyOf의 복사는 얕은 복사이다.

[F-Lab] 3주차 정리 및 회고

oniwon — Sun, 17 May 2026 12:54:57 +0900

[F-Lab 멘토링 할인 코드]
커넥터스2385

사전 학습

자바의 신 1 10장 ~ 18장
이력서 작성

멘토링 질문

다형성이란? 왜 필요한가?
상속이 왜 위험한가
API란?
finalize(), clone()
Interface vs Abstract Class 차이
try - catch - finally 구문
Checked Exception vs Unchecked Exception
Inner class란?

과제

RFC 6749
Inner class에서 GC를 방해하는 상황

추가 학습

다형성, 컴포지션, DI - 세 개념을 한줄로 잇기

멘토링 Q&A

이력서 관련 질문

회고

이번 주 멘토링은 절반은 이력서와 회사 지원 이야기, 절반은 자바 꼬리 질문 위주로 진행됐다.

이력서는 4~5번 정도 수정해서 그런지 큰 수정 사항은 거의 없었다.

원티드 중심으로 채용 공고를 보고 있는데,

5월이라 그런지 생각보다 공고가 많지는 않은 느낌이다.

개인 프로젝트도 구상하고 있다.

예전부터 앱스토어에 내 앱 하나 출시해보는 게 목표였는데,

이번에는 끝까지 만들어서 실제로 출시까지 하고 싶다.

요즘은 깊게 공부하고 있는 것과 별개로 언제 취업할 수 있을지

걱정과 불안이 공존하는 시기인 것 같다.

조급해지기보다는 컨디션 관리 잘하면서
지치지 않고 꾸준히 가야겠다.

에프랩 관련 질문은 오픈채팅 남겨주시면 제가 아는 선에서 답변드리겠습니다!

추천인 코드: 커넥터스2385

[Java] 다형성, 컴포지션, DI - 세 개념을 한 줄로 잇기

oniwon — Sun, 17 May 2026 01:42:08 +0900

다형성을 학습하다가 Effective Java의 "상속보다는 컴포지션을 사용하라"는 문장이 떠올랐다.

그 과정에서 implements와 컴포지션의 관계가 머릿속에서 명확히 정리되지 않아 개념을 다시 정리해본다.

다형성이란

다형성(polymorphism)은 같은 메소드 호출이 실제 객체에 따라 다르게 동작하는 성질이다.

Payment payment = new KakaoPayment();
payment.pay(1000);

위 코드에서 변수 타입은 Payment지만, 실제 실행되는 것은 KakaoPayment.pay()다.

즉 다형성의 핵심은

부모 타입(인터페이스/상위 클래스)으로 객체를 다룰 수 있고
실제 어떤 구현이 실행될지는 런타임에 결정된다는 점이다.

왜 필요한가 - 결제 예시

다형성이 없는 코드

public class OrderService {
  public void checkout(String type, int amount) {
      if (type.equals("kakao")) {
          new KakaoPayment().pay(amount);
      } else if (type.equals("naver")) {
          new NaverPayment().pay(amount);
      }
      // 결제 수단이 추가될 때마다 분기 추가
  }
}

결제 수단이 늘어날 때마다 클라이언트 코드를 매번 수정해야 한다. if / switch가 코드 곳곳에 박힌다.

다형성을 적용한 뒤

public class OrderService {
  private final Payment payment;

  public OrderService(Payment payment) {
      this.payment = payment;
  }

  public void checkout(int amount) {
      payment.pay(amount); // 카카오든 네이버든 신경 안 씀
  }
}

클라이언트는 Payment라는 추상 타입만 의존한다. OrderService는 내부 구현체를 알 필요가 없다.

추상화와의 관계

클라이언트는 Payment 인터페이스에만 의존한다.
구체적인 구현은 인터페이스 뒤로 캡슐화된다.
각 구현체의 내부 동작 방식은 서로 달라도 무방하다.

클라이언트는 구현 방식과 무관하게 payment.pay()만 호출한다.

런타임에 결정된다

다형성의 핵심은 어떤 구현체가 실행될지 컴파일 타임이 아니라 런타임에 결정된다는 점이다.

Payment payment = getPayment(userChoice);
payment.pay(1000);

payment의 타입은 Payment로 고정돼 있지만, 실제 호출되는 객체는 런타임에 들어온 값에 따라 다르다.

KakaoPayment.pay()
NaverPayment.pay()

이것이 동적 바인딩(dynamic binding)이다.

implements / 컴포지션 / DI

처음 던졌던 질문으로 돌아가면, implements와 컴포지션은 함께 쓰이는 개념이다.

1. 인터페이스 구현 (implements) — 타입 공유

public interface Payment {
  void pay(int amount);
}

public class KakaoPayment implements Payment { ... }
public class NaverPayment implements Payment { ... }

KakaoPayment와 NaverPayment는 Payment라는 타입을 공유한다.

개념적으로 implements도 넓은 의미의 상속이다.

2. 컴포지션 (Composition) — 객체를 보유

public class OrderService {
  private final Payment payment;
}

OrderService는 Payment를 상속하지 않고 객체를 필드로 가진다. is-a가 아닌 has-a 관계다.

3. DI (의존성 주입) — 외부에서 주입

@Service
public class OrderService {
  private final Payment payment;

  public OrderService(Payment payment) {
      this.payment = payment;
  }
}

OrderService가 직접 객체를 생성하지 않는다.

어떤 구현체를 넣을지는 외부(스프링 컨테이너)가 결정한다.

여러 개의 구현체가 동시에 존재한다면 전략 패턴(Strategy Pattern)을 쓸 수 있다.

인터페이스에 supports() 같은 메소드를 두고, 컨테이너가 모든 구현체를 List로 주입해주면, 런타임에 조건에 맞는 구현체를 골라서 호출한다.

public interface Payment {

    boolean supports(PaymentType type);

    void pay(int amount);
}

@Service
@RequiredArgsConstructor
public class OrderService {
  private final List<Payment> payments; // 모든 구현체가 주입됨

  public void checkout(PaymentType type, int amount) {
      payments.stream()
          .filter(p -> p.supports(type))
          .findFirst()
          .orElseThrow()
          .pay(amount);
  }
}

새 결제 수단이 추가돼도 @Service만 붙이면 자동으로 List에 포함된다.

"상속보다 컴포지션"의 의미

처음 이 문장을 봤을 때 의문이 들었다.

implements도 상속의 일종인데, 그러면 implements도 쓰지 말라는 뜻일까?

그것은 아니다.

여기서 말하는 “상속”은 대부분 클래스 상속(extends)을 의미한다.

인터페이스 상속(implements) — 타입 상속이라 권장된다.
클래스 상속(extends) — 구현 상속이라 강한 결합 발생 가능성이 있다.

대표적인 사례가 Stack이다.

Vector를 extends한 Stack

자바 표준 라이브러리의 Stack은 Vector를 상속한다.

public class Stack<E> extends Vector<E> { ... }

이것의 단점이 있다.

1. 의도하지 않은 동작까지 상속됨

Vector의 모든 메소드는 synchronized로 선언되어 있다. thread-safe를 보장하기 위해서다.

문제는 Stack이 Vector를 extends하는 순간, Stack도 자동으로 모든 메소드가 synchronized가 된다는 것이다.

새로 정의한 push(), pop()도 synchronized
부모(Vector)에서 내려온 get(), size()도 synchronized

Stack을 쓸 때 락이 필요 없는 상황에서도 무조건 모니터 락이 걸린다.

void doSomething() {
  Stack<Integer> stack = new Stack<>(); // 지역 변수, 한 스레드만 접근
  stack.push(1);
  stack.pop();
  // 메소드 끝나면 사라짐 — 동기화가 전혀 필요 없는데도 락 오버헤드 발생
}

2. 추상화가 깨진다

Stack은 LIFO(Last-In-First-Out)라는 약속을 가진 자료구조다.
그런데 Vector를 상속하면서 Vector의 임의 위치 접근 메소드까지 그대로 노출된다.

Stack<Integer> stack = new Stack<>();
stack.push(1);
stack.push(2);
stack.push(3);

stack.remove(0);          // 가장 아래(1)를 제거 — LIFO 위반
stack.insertElementAt(99, 0); // 중간에 끼워넣기 — LIFO 위반
stack.get(1);             // 임의 위치 조회 — LIFO 위반

자식이 원하지 않아도 부모의 모든 public 메소드는 그대로 자식의 API가 되는 단점이 있다.

이것이 "상속보다 컴포지션"이라는 말이 나온 이유다.

정리

다형성은 같은 호출이 객체에 따라 다르게 동작하는 성질이다.
보통 인터페이스(implements)로 공통 타입을 만들고, 클라이언트는 구현체 대신 추상 타입에 의존한다.
컴포지션은 객체를 상속(extends)하지 않고 필드로 조합하는 방식이다.
DI는 객체 생성 책임을 외부로 분리하는 것이다.
"상속보다 컴포지션"은 extends를 두고 한 말이다. implements는 타입만 공유하지만, extends는 부모의 API와 동작까지 전부 따라오기 때문이다.

[F-Lab] 2주차 정리 및 회고

oniwon — Fri, 15 May 2026 20:22:33 +0900

[F-Lab 멘토링 할인 코드]
커넥터스2385

사전 학습

자바의 신2 9장까지

멘토링 질문

enum
블로킹, 논블로킹 / 동기, 비동기 4가지 조합
toString() 호출 결과
자바 생성자 특징
jpa에서 protected 이상의 기본 생성자가 필요한 이유
static 사용 시 주의점
자바에서 NullPointerException 발생 이유
익명 클래스의 변수 캡처
자바 패키지

과제

이력서 작성
익명 클래스에 전달한 값은 어떤 복사인가
패키지와 네임스페이스
패키지 이름으로 금지된 예약어

추가 학습

enum - 왜 안전한가, private 생성자로 강등되는 이유

멘토링 Q&A

static 변수 저장 위치
해시맵 버킷 계산 시 비트 연산 원리

회고

한 주제를 깊게 파고들다 보니 다른 주제에 할애할 시간이 부족하다고 느낄 때가 있었다.

학습량을 골고루 배분하는 방식으로 균형을 잘 잡아야겠다.

별개라고 생각했던 개념들이 하나로 이어질 때 흥미롭다.

자바가 pass by value라는 것은 알고 있었지만

익명 클래스가 캡처한 값이 같은 원리라는 것은 모르고 있었다.

녹음본 스크립트를 다시 보면서 답변할 때의 습관도 알게 됐다.

가끔 질문에 질문으로 되묻는 것.

의도적으로라도 내 생각을 짧게 먼저 말하고

필요한 부분만 되묻는 방식으로 바꿔봐야겠다.

에프랩 관련 질문은 오픈채팅 남겨주시면 제가 아는 선에서 답변드리겠습니다!

추천인 코드: 커넥터스2385

[Java] enum - 왜 안전한가, private 생성자로 강등되는 이유

oniwon — Thu, 14 May 2026 23:57:14 +0900

enum이란

enum은 상수(변하지 않는 고정된 값)의 집합을 표현하는 열거형 클래스다.

상수를 단순히 `public static final int`로 정의하지 않고 enum으로 정의하면, 컴파일러가 여러 안전장치를 자동으로 끼워준다.

그 안전장치들이 어떻게 만들어지는지, 왜 enum이 "싱글톤처럼 동작한다"고 불리는지 정리해봤다.

enum은 왜 안전한가

1. 타입 체크 가능

상수를 int나 String으로 관리하면, 메서드 파라미터로 정해진 상수 외의 다른 값이 넘어와도 컴파일러가 막지 못해 런타임에 가서야 터진다.

반면 반면 enum은 타입 자체가 정해져 있어 잘못된 값이 넘어오는 순간 컴파일 에러로 막힌다.

enum Status {
    WAITING, PROCESSING, DONE
}

void process(Status status) { ... }

process(999);            // 컴파일 에러
process("WAITING");      // 컴파일 에러
process(Status.WAITING); // 정상

2. new로 생성 불가 / 정해진 값만 존재 / 반드시 먼저 초기화

// 개발자가 작성
enum Status {
    WAITING, PROCESSING, DONE
}

// 컴파일러가 변환
static {
    WAITING = new Status("WAITING", 0);
    PROCESSING = new Status("PROCESSING", 1);
    DONE = new Status("DONE", 2);
}

흐름을 정리하면 다음과 같다.

컴파일러가 private 생성자 자동 생성
↓
외부에서 new Status() 불가
↓
컴파일러만 static {} 블록에서 new로 생성
↓
클래스 로딩 시점에 딱 1번 미리 생성
↓
정해진 상수만 존재, 반드시 먼저 초기화됨

의문: Oracle 문서는 두 가지 생성자를 허용하는데, 실제는?

Oracle 공식 튜토리얼 문서에는 enum 생성자 관련하여 다음과 같이 적혀 있다.

(Oracle Java Tutorial - Enum Types)

"enum 타입의 생성자는 반드시 package-private 또는 private 접근 제어자를 가져야 한다. 이 생성자는 enum 본문 시작 부분에 정의된 상수들을 자동으로 생성한다. 개발자가 직접 enum 생성자를 호출할 수는 없다."

그래서 package-private과 private 둘 다 가능한 줄 알았다.

그런데 실제로 생성자를 따로 작성하지 않은 enum 코드를 컴파일하고 javap -p -c로 바이트코드를 확인해보니, 결과가 달랐다.

확인에 사용된 코드

public enum Status {
    WAITING, PROCESSING, DONE;
}

javap -p -c Status.class 결과 중 일부

public final class Status extends java.lang.Enum<Status> {
  public static final Status WAITING;
  public static final Status PROCESSING;
  public static final Status DONE;
  ...
  private Status();        // ← 소스에 안 적었는데도 private 생성자가 자동 생성됨
    Code:
       0: aload_0
       1: aload_1
       2: iload_2
       3: invokespecial #28  // Method java/lang/Enum."<init>":(Ljava/lang/String;I)V
       6: return

  static {};               // ← static 블록에서 상수들을 new로 생성
    Code:
       0: new           #1  // class Status
       3: dup
       4: ldc           #32 // String WAITING
       6: iconst_0
       7: invokespecial #33 // Method "<init>":(Ljava/lang/String;I)V
      10: putstatic     #3  // Field WAITING:LStatus;
      ...
}

생성자를 아예 선언하지 않았는데도 `private Status();`가 박혀 있다. 분명히 default(package-private)도 허용된다고 했는데, 결과는 private이었다.

JLS 8.9.2 확인

JLS(Java Language Specification) 8.9.2를 보면 답을 찾을 수 있다.

(JLS 8.9.2 Enum Body Declarations)

"enum 선언 안에서 접근 제어자를 생략한 생성자는 (default가 아니라) private으로 해석된다."

즉 소스 코드에서 접근 제어자를 생략해서 작성하면 일반 클래스와 달리 package-private이 아니라 private으로 해석된다고 명세에 적혀 있다.

그럼 왜 생성자를 private으로 강등시킬까?

핵심은 JVM 차원에서 enum 인스턴스의 유일성을 보장하기 위해서다.

그리고 이 유일성 보장이 곧 enum이 "싱글톤처럼 동작한다" 고 불리는 이유다.

싱글톤은 하나의 JVM(프로세스) 안에서 인스턴스가 딱 1개만 존재하는 것이다. 그 조건은 두 가지다.

1. 단 하나의 인스턴스가 만들어진다.

클래스 로딩 시점에 static {} 블록에서 1회 생성

2. 그 외 어떤 경로로도 추가 인스턴스가 만들어질 수 없다.

직접 new 호출 → private 생성자로 차단
그 외 우회 경로(리플렉션, 역직렬화, clone) → JVM 차원에서 별도 차단

이 중 첫 번째 통로인 직접 new 호출을 막는 장치가 바로 private 생성자다. 만약 enum 생성자가 package-private이면, 같은 패키지 안의 다른 클래스가 그냥 new Status(...)로 새 인스턴스를 만들어버릴 수 있다.

그래서 enum 생성자의 접근 제어자를 private 또는 생략(= 암묵적 private) 으로만 허용한다. 개발자가 public이나 protected로 선언하면 컴파일 에러가 난다.

equals()가 아니라 ==로 비교해도 true가 나온다. 같은 주소를 가리키는 같은 객체이기 때문이다.

Status.WAITING == Status.WAITING // 항상 true

직접 구현한 싱글톤은 리플렉션, 역직렬화, clone() 같은 우회로로 뚫릴 수 있지만, enum은 이 모든 경로까지 막혀 있다. 그 차단 방식은 아래와 같다.

enum 인스턴스의 유일성은 어떻게 보장될까

private 생성자만으로는 부족하다. 자바에는 생성자를 우회해서 객체를 만들 수 있는 경로가 더 있기 때문이다.

enum은 이 경로들도 전부 막혀 있다.

1. 같은 패키지 내에서의 직접 호출
생성자가 package-private이면 같은 패키지의 다른 클래스가 그냥 호출할 수 있다. private이면 같은 패키지여도 호출 불가다.

2. 리플렉션을 통한 호출
Constructor.newInstance()로 우회 생성을 시도할 수 있다. JVM은 enum 타입에 대해 이 호출 자체를 명시적으로 차단한다.

Constructor.newInstance()가 enum 타입이면 IllegalArgumentException("Cannot reflectively create enum objects")을 던지도록 구현되어 있다.

(https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/reflect/Constructor.java)

3. 직렬화/역직렬화
일반 클래스는 역직렬화 시 생성자를 거치지 않고 객체가 만들어질 수 있다.

그래서 enum은 직렬화 메커니즘에서 특별 취급되어, 역직렬화 시 `Enum.valueOf()`로만 인스턴스를 가져오도록 강제되어 있다.

(https://docs.oracle.com/en/java/javase/21/docs/specs/serialization/serial-arch.html#serialization-of-enum-constants)

"enum 상수를 역직렬화할 때, ObjectInputStream은 스트림에서 상수의 이름만 읽어온다. 그리고 그 enum 타입과 이름을 Enum.valueOf()에 넘겨서, 이미 존재하는 상수를 찾아오는 방식으로 복원한다."

4. clone()
일반 객체는 clone()으로 똑같은 인스턴스를 하나 더 만들 수 있다. Enum.clone()은 final로 선언되어 있고 호출 시 CloneNotSupportedException을 던지도록 되어 있어, 오버라이드 자체가 불가능하다.

JVM 메모리 구조 관점에서 (static 관련)

enum 상수가 JVM 안에 왜 딱 1개밖에 존재할 수 없는지는 메모리 구조를 보면 명확해진다.

ClassLoader
└── Class 객체 (Status.class) — 힙에 존재
      ├── static final WAITING    → Status 인스턴스 (힙)
      ├── static final PROCESSING → Status 인스턴스 (힙)
      └── static final DONE       → Status 인스턴스 (힙)

static 블록은 해당 enum 클래스가 처음 사용되어 로딩되는 시점에 딱 한 번 실행된다.
Status.class 객체 안에 WAITING, PROCESSING, DONE의 참조값이 저장된다.
각 Status 인스턴스 객체는 힙의 별도 공간에 존재하고, Class 객체가 그것을 참조하고 있는 구조다.
Class 객체는 ClassLoader가 살아있는 한 함께 존재하기 때문에, enum 상수는 사실상 프로세스 종료 전까지 GC 대상이 되지 않는다.

즉, enum 상수는 클래스가 처음 로딩된 순간부터 프로세스 종료 시점까지 같은 주소에 살아있는 객체다.

정리

enum은 상수의 집합을 표현하는 열거형 클래스이다.
타입 체크가 컴파일 시점에 이루어져, 잘못된 값이 들어갈 수 없다.
enum의 생성자를 private으로 강등시키는 이유는, JVM 차원에서 enum 인스턴스 유일성 보장 체계를 작동시키기 위해서이다.
Class 객체가 ClassLoader 생명주기와 함께 가기 때문에, enum 상수는 프로세스 종료 전까지 GC되지 않고 같은 주소를 유지한다.

[F-Lab] 1주차 정리 및 회고

oniwon — Tue, 12 May 2026 17:43:21 +0900

[F-Lab 멘토링 할인 코드]
커넥터스2385

사전 학습

자바의 신 1 전체

멘토링 질문

blocking, non-blocking / synchronous, asynchronous
synchronized 란? 어디에 사용하면 좋을까?
상태의 두 가지 의미
동시성 제어 수단(자바 락, DB 락)
a = b, a == b, .equals()
자바 키워드 final, transient
리터럴 String vs 힙의 new String
equals() & hashCode()
연산자 종류
배열 초기화 방식(프리미티브, 참조형)

과제

equals() 테스트 코드 짜는 법
hashCode()가 무엇이고(31의 의미) 어디에서 사용하는지
Floating Point 오차 발생 이유

추가 학습

멘토링 Q&A

synchronized 가 실무에서 잘 안 쓰이는 이유
hashCode() 명세는 어디까지 정의되어 있는가
enum 생성자가 package-private / private 둘 다 허용임에도 컴파일 후 private 로 변하는 이유

회고

첫 날이라 역시나 긴장되고 떨렸다.

자바의 신 1 목차 순서대로 질문을 받을 줄 알았다.

그런데 멘토님께서 어려웠던 개념이 있었는지 물으셨고

블로킹/논블로킹과 동기/비동기 개념이 헷갈렸다고 대답했다.

블로킹과 논블로킹의 차이를 설명했는데, synchronous, asynchronous의 개념도 더해야된다고 하셔서

해당 용어는 처음 접해봤다고 답변했다.

하지만 이후 찾아보니 synchronous/asynchronous가 동기/비동기라는 것을 알게 되었다..

개념을 정확히 알아야 정확히 설명할 수 있다는 것을 느꼈다.

잘 알고 있다고 생각했던 개념도 막상 정의를 말하려니 기억이 안나거나

계층적으로 헷갈리는 개념들이 있었다.

예를 들어 자바 락과 DB 락의 동기화 영향을 구분하는 것, 원자성과 스레드 세이프를 구분하는 것 등

질문 주제가 자유롭게 오갔지만, 오히려 다양하게 생각해볼 수 있어서 좋았던 시간이었다.

에프랩 관련 질문은 오픈채팅 남겨주시면 제가 아는 선에서 답변드리겠습니다!

추천인 코드: 커넥터스2385

[Java] equals() & hashCode() 깊게 보기 - 31의 의미, String 내부 동작

oniwon — Tue, 12 May 2026 17:39:48 +0900

equals()와 hashCode()

Java에서 객체를 비교할 때 가장 헷갈리는 개념이 ==, equals(), hashCode()이다.

이 셋이 어떻게 다른지, 왜 equals()를 오버라이드하면 hashCode()도 같이 오버라이드해야 하는지,

그리고 hashCode() 내부에서 왜 하필 31을 곱하는지까지 정리해봤다.

객체 비교 3가지

=	대입 연산자
==	동일성 비교 — 같은 객체인가? (주소값)
equals()	동등성 비교 — 논리적으로 같은가? (내용)

기본형은 주소 개념이 없으니 ==으로 값 자체를 비교한다.

반면 참조형(객체)은 == 이 참조값을 비교하기 때문에 내용이 같아도 다른 객체로 판별된다.

Person p1 = new Person("홍길동", 20);
Person p2 = new Person("홍길동", 20);

p1 == p2        // false → 힙의 서로 다른 주소
p1.equals(p2)   // true  → 이름, 나이가 같으므로 같다고 정의

equals() 직접 구현

5가지 수학적 조건 (JDK 명세)

조건	의미
반사성	x.equals(x) = true — 자기 자신과 비교하면 항상 true
대칭성	x.equals(y) = true이면 y.equals(x) = true
추이성	x.equals(y) = true이고 y.equals(z) = true이면 x.equals(z) = true
일관성	비교에 쓰인 정보가 바뀌지 않는 한 여러 번 호출해도 항상 같은 결과
null 비교	x.equals(null) = false

구현 예시

@Override
public boolean equals(Object o) {
  if (this == o) return true;                       // 반사성 + 최적화
  if (o == null) return false;                      // null 비교
  if (getClass() != o.getClass()) return false;     // 타입 체크
  Person person = (Person) o;
  return age == person.age &&
         Objects.equals(name, person.name);
}

Lombok으로 자동 생성

@EqualsAndHashCode
public class Person {
  private String name;
  private int age;
}

@EqualsAndHashCode를 붙이면 컴파일 시점에 equals() + hashCode()가 자동 생성된다.

equals() 테스트 코드를 작성해야 하는 이유

equals()가 5가지 수학적 조건을 만족하는지는 눈으로 확인하기 어렵다.

특히 HashMap, HashSet 같은 컬렉션은 내부에서 equals()를 자동 호출하기 때문에 버그가 생기면 추적이 매우 어렵다. 반드시 테스트 코드로 검증해야 한다.

class PersonEqualsTest {

  @Test void 반사성() {
      Person a = new Person("홍길동", 20);
      assertThat(a.equals(a)).isTrue();
  }

  @Test void 대칭성() {
      Person a = new Person("홍길동", 20);
      Person b = new Person("홍길동", 20);
      assertThat(a.equals(b)).isTrue();
      assertThat(b.equals(a)).isTrue();
  }

  @Test void 추이성() {
      Person a = new Person("홍길동", 20);
      Person b = new Person("홍길동", 20);
      Person c = new Person("홍길동", 20);
      assertThat(a.equals(b)).isTrue();
      assertThat(b.equals(c)).isTrue();
      assertThat(a.equals(c)).isTrue();
  }

  @Test void 일관성() {
      Person a = new Person("홍길동", 20);
      Person b = new Person("홍길동", 20);
      for (int i = 0; i < 100; i++) {
          assertThat(a.equals(b)).isTrue();
      }
  }

  @Test void null비교() {
      Person a = new Person("홍길동", 20);
      assertThat(a.equals(null)).isFalse();
  }

  @Test void 다른객체() {
      Person a = new Person("홍길동", 20);
      Person b = new Person("김철수", 30);
      assertThat(a.equals(b)).isFalse();
  }
}

hashCode()를 반드시 같이 오버라이드해야 하는 이유

HashMap / HashSet 동작 원리

HashMap/HashSet 은 객체를 저장하거나 조회할 때 내부적으로 두 단계로 동작한다.

(이때 hashCode() 와 equals() 는 컬렉션이 자동으로 호출하기 때문에, 이 두 메서드를 클래스에 미리 오버라이드해두기만 하면 된다.)

1. 1단계: hashCode()로 버킷(저장 위치)을 결정
2. 2단계: 같은 버킷 안에서 equals()로 동일 객체인지 판별

예시)

Person.hashCode() 내부 연산
→ 여러 필드를 하나의 int로 섞음 (예: 54321)

HashMap/HashSet 버킷 결정
→ 그 int를 버킷 개수로 나눈 나머지
→ 54321 % 16 = 1번 버킷에 저장

※ 참고: 실제 HashMap 은 key.hashCode() 결과를 그대로 쓰지 않고, 내부 hash() 메서드에서 (h ^ (h >>> 16)) 로 상하위 비트를 한 번 섞은 뒤 (n - 1) & hash 로 버킷을 결정한다.

즉, hashCode()를 오버라이드하지 않으면 같은 버킷에 들어가지 않아서 equals()까지 도달하지 못한다.

equals()만 오버라이드하면 생기는 버그

Set<Person> set = new HashSet<>();
set.add(new Person("홍길동", 20));
set.add(new Person("홍길동", 20));

hashCode()를 오버라이드 안 하면 Object.hashCode()를 사용한다. 이때 JVM이 객체마다 보통 서로 다른 int 값을 부여한다. (메모리 주소나 xorshift 등 JVM 구현에 따라 다름)

set.size()  // 2

결과적으로 같은 사람인데 중복 저장되게 된다. (hashCode가 달라서 서로 다른 버킷에 들어감)

hashCode() 내부 동작

hashCode()가 하는 일은 단순하다. 임의의 객체를 받아 필드값들을 연산해 int(4바이트 숫자) 하나로 압축해서 반환하는 것이다.

31을 곱하는 이유

대부분의 hashCode() 구현에서 다음 패턴이 등장한다.

result = 31 * result + (element == null ? 0 : element.hashCode());

왜 하필 31일까? 네 가지 이유가 맞물려 있다.

1. 32비트 int에서 적당한 균형점
비트가 적당히 퍼지면서도, 누적 곱셈 시 앞쪽 정보가 너무 빨리 오버플로우로 손실되지 않는 경험적 균형점이다.

2. 홀수여야 한다
int는 32비트로 고정이다. 짝수를 곱하면 비트가 왼쪽으로 밀려서 결국 사라진다.

큰 숫자에 짝수를 계속 곱하면

10000000 00000000 00000000 00000001
* 2
00000000 00000000 00000000 00000010  ← 맨 왼쪽 비트 사라짐
* 2
00000000 00000000 00000000 00000100  ← 계속 사라짐
* 2
...
00000000 00000000 00000000 00000000  ← 결국 0

서로 다른 값인데 hashCode가 0으로 같아져 충돌이 발생한다. 홀수는 이런 정보 손실이 없다.

3. 소수(Prime Number)여야 한다

소수의 약수는 1과 자기 자신뿐이라, 해시값이 고르게 분산되어 충돌(같은 버킷에 몰리는 현상)이 최소화된다.

4. JVM 최적화가 가능하다

31 * x는 비트 시프트로 변환된다.

31 * x
= (32 - 1) * x
= 32 * x - x
= (x << 5) - x

곱셈보다 빠르게 처리된다.

필드가 하나일 때는 31을 안 곱해도 된다.

31을 곱하는 목적은 여러 필드를 섞기 위한 것이다.

// 필드 여러 개 → 섞어야 함
result = 31 * name.hashCode() + address.hashCode();

// 필드 하나 → 섞을 대상이 없음
return Objects.hashCode(name);

위에서 name.hashCode() 자체가 이미 분산된 int값이다. 거기에 31을 곱해봤자 숫자만 커질 뿐 분산에 도움이 되지 않는다.

특히 String은 내부에서 이미 31을 활용해 해시를 만들기 때문에, 필드가 하나라면 그 결과를 그대로 쓰면 된다.

Objects.hash() vs Objects.hashCode() 차이

본격적인 차이를 설명하기 전에, 이름이 비슷한 세 메서드를 먼저 구분해야 한다.

이름	소속 클래스	종류
Object.hashCode()	java.lang.Object	인스턴스 메서드 (native) — JVM이 처리
String.hashCode()	java.lang.String	인스턴스 메서드 (오버라이드) — 31 곱하기 로직
Objects.hashCode(o)	java.util.Objects	정적 유틸리티 — 내부에서 `o.hashCode()` 호출

우리가 쓰는 Objects.hashCode(o) 는 결국 o.hashCode() 를 호출하고,
그 객체가 hashCode를 오버라이드했다면 오버라이드된 버전(String, 우리가 만든 Person 등)이 실행되고,
오버라이드 안 했다면 Object.hashCode() 의 네이티브 구현까지 내려간다.

Objects.hash() 내부 동작

신버전: Objects.hash() 사용

@Override
public int hashCode() {
  return Objects.hash(name, address, email);
}

내부 구현을 따라가 보면 결국 다음과 같다.

public static int hash(Object... values) {
  return Arrays.hashCode(values);
}

public static int hashCode(Object[] a) {
  if (a == null) return 0;

  int result = 1;
  // 시작값이 1인 이유: 0으로 시작하면 31 * 0 = 0이 되어 첫 번째 요소가 영향을 주지 못함

  for (Object element : a)
      result = 31 * result + (element == null ? 0 : element.hashCode());

  return result;
}

구버전: 직접 전개

@Override
public int hashCode() {
  int result = Objects.hashCode(name);
  result = 31 * result + Objects.hashCode(address);
  result = 31 * result + Objects.hashCode(email);
  return result;
}

신/구 버전 모두 결국 같은 로직이다.

필드가 하나일 때 `Objects.hash()`를 쓰면 원본 hashCode()와 다른 값이 나온다.

String name = "홍길동";

name.hashCode()          // 예: 54321
Objects.hash(name)       // 예: 31 * 1 + 54321 = 54352  ← 다름!
Objects.hashCode(name)   // 예: 54321                   ← 이걸 써야 같음

이유는 Objects.hash()가 내부적으로 다음과 같이 동작하기 때문이다.

Objects.hash(name)
 = Arrays.hashCode(new Object[]{name})
 = 31 * 1 + name.hashCode()   // 1에서 시작해 31을 한 번 더 곱함

즉 Objects.hash() 는 내부적으로 varargs 배열을 생성한 뒤, 그 배열을 순회하며 각 요소의 hashCode를 31로 누적 곱셈하는 구조이다.

필드가 하나라면 배열을 만들 필요 자체가 없으므로 Objects.hashCode(field)를 쓰면 된다.

String.hashCode() 깊게 보기

왜 String은 내부에서 31을 한 번 더 곱하는가

int 같은 원시 타입은 값 자체가 하나라서 섞을 내부 데이터가 없다.

예시)

age = 20
  → 더 이상 쪼갤 게 없음
  → 그대로 20 반환
  → Arrays.hashCode()에서 31 한 번만 곱함

반면 String은 내부가 문자 배열(여러 문자)이라 자기 자신을 합칠 때 31이 필요하다.

예시)

name = "홍길동"
  → 내부적으로 ['홍', '길', '동']
  → 이 문자들을 하나의 int로 만들어야 함
  → String 내부에서 31로 한 번 섞음
  → 그 결과를 Arrays.hashCode()에서 다시 31로 섞음

String.hashCode() 코드

public int hashCode() {
  int h = hash;  // 캐시된 값 (처음엔 0)

  if (h == 0 && !hashIsZero) {
      h = isLatin1() ? StringLatin1.hashCode(value)
                     : StringUTF16.hashCode(value);

      if (h == 0) {
          hashIsZero = true;  // 진짜 0이면 다음에 재계산 방지
      } else {
          hash = h;           // 계산값 캐시
      }
  }
  return h;
}

String은 불변(immutable) 이라 한 번 계산한 hashCode는 절대 바뀌지 않는다.
→ 첫 계산 후 hash 필드에 캐싱
→ 다음 호출부터는 즉시 반환 (성능 최적화)

Latin1 vs UTF-16

Java String은 인코딩에 따라 두 가지 방식으로 해시를 계산한다.

1. Latin1 (영문/숫자, 1바이트 문자)

public static int hashCode(byte[] value) {
  int h = 0;
  for (byte v : value) {
      h = 31 * h + (v & 0xff);
  }
  return h;
}

2. UTF-16 (한글 등, 2바이트 문자)

public static int hashCode(byte[] value) {
  int h = 0;
  int length = value.length >> 1;  // 바이트 길이 / 2 = 문자 수
  for (int i = 0; i < length; i++) {
      h = 31 * h + getChar(value, i);  // 2바이트를 합쳐 char로 읽음
  }
  return h;
}

계산 예시 — "AB" (Latin1)

'A' = 0x41 = 65
'B' = 0x42 = 66
bytes = [0x41, 0x42]

h = 0
h = 31 * 0  + 65 = 65
h = 31 * 65 + 66 = 2081

계산 예시— "가나" (UTF-16, LE 플랫폼 예시)

'가' = 44032
'나' = 45208

UTF-16LE(하위 바이트가 앞으로) 저장 결과
bytes = [0x00, 0xAC, 0x98, 0xB0]
           ↑──가──↑    ↑──나──↑

i=0: getChar = (0xAC << 8) | 0x00 = 44032 ('가')
i=1: getChar = (0xB0 << 8) | 0x98 = 45208 ('나')

h = 0
h = 31 * 0     + 44032 = 44032
h = 31 * 44032 + 45208 = 1,410,200

정리

기본형은 값이 하나라서 Arrays 레벨에서 31을 한 번만 곱한다.
반면 String처럼 내부가 복합 구조인 타입은 31이 두 번 쓰인다.

int → 원자값 → 31 한 번
String → 복합값(문자 배열) → 자기 내부 합칠 때 31 한 번 + Arrays에서 다시 31 한 번

네이티브 hashCode JDK 명세

Object.hashCode()는 결국 네이티브 메서드다.

@IntrinsicCandidate
public native int hashCode();

규칙	내용
일관성	같은 객체 → 항상 같은 hashCode (단, JVM 재시작 시는 달라도 됨)
equals → hashCode	equals()가 true이면 hashCode()는 반드시 같아야 함
역방향은 보장 X	equals()가 false여도 hashCode()는 같을 수 있음 (= 충돌, 성능 저하 요인)

왜 역방향은 보장하지 않을까

hashCode()는 무한한 객체 공간을 유한한 int(약 42억 개)로 압축하기 때문이다. 서로 다른 객체가 같은 해시를 가질 수밖에 없다.

정리

==는 주소 비교, equals()는 내용 비교
equals()는 5가지 수학적 조건(반사성, 대칭성, 추이성, 일관성, null)을 만족해야 하고, 테스트 코드로 검증해야 한다.
equals()를 오버라이드하면 hashCode()도 반드시 같이 오버라이드해야 한다. 그렇지 않으면 HashMap/HashSet에서 같은 객체가 중복으로 들어간다.
hashCode()에서 31을 곱하는 이유는 (1) 적당한 분산, (2) 홀수라 정보 손실 없음, (3) 소수라 충돌 최소화, (4) JVM이 비트 시프트로 최적화 가능하기 때문이다.
필드 1개라면 Objects.hashCode(), 여러 개라면 Objects.hash()를 쓴다.
String.hashCode()는 불변 특성을 이용해 결과를 캐싱한다.

[Java] synchronized 동작 원리 - 모니터 락, CAS

oniwon — Tue, 12 May 2026 15:30:03 +0900

synchronized

`synchronized`는 같은 프로세스(JVM) 안에서 동기화를 보장하는 키워드이다.

동기화란, 여러 스레드/프로세스가 공유 자원(같은 객체나 변수)에 접근할 때 데이터를 일관되게 유지하도록 맞추는 것을 의미한다.

더 정확히 말하면, 실행 순서와 메모리 상태를 서로 맞추는 것이다.

단일 스레드 환경에서도 동작 자체는 보장되지만, 경쟁 자체가 없기 때문에 사실상 멀티 스레드 환경에서만 의미가 있다.

여기서 원자성(Atomicity) 과 Thread safe 의 개념을 구분해야 한다.

원자성 vs Thread safe

원자성

특정 연산이 중간에 끊기지 않고 완전히 실행되거나, 아예 실행되지 않는 성질을 말한다.

// i++는 사실 3단계 연산
int temp = i;     // 1. read
temp = temp + 1;  // 2. increment
i = temp;         // 3. write

synchronized 없이는 스레드 A가 1번을 실행한 직후 스레드 B가 끼어들 수 있다. synchronized는 이 3단계를 하나의 블록으로 묶어 원자적으로 만든다.

Thread safe

멀티스레드 환경에서 공유 상태가 항상 일관성 있게 유지되는 성질이다.

이 둘을 굳이 구분하는 이유는, 원자성이 보장돼도 Thread safe가 아닐 수 있기 때문이다.

class Counter {
  private int count = 0;

  public synchronized void increment() { count++; } // 원자성 O
  public synchronized void decrement() { count--; } // 원자성 O

  // 문제: check-then-act 패턴
  public void incrementIfZero() {
      if (count == 0) {        // A 스레드가 여기서 0 확인
          // → B 스레드가 끼어들어 increment() 호출
          increment();         // A는 0이 아닌데 그냥 증가시킴
      }
  }
}

increment() 자체는 원자적이지만, incrementIfZero()는 read → check → write가 하나의 원자적 단위로 묶이지 않아서 Thread safe하지 않다.

즉, 원자성은 Thread safe를 위한 도구 중 하나일 뿐이다. synchronized로 원자성을 확보해도 설계 수준에서 경쟁 조건(race condition)을 제거해야 진정한 Thread safe가 된다.

Thread safe의 3요소
1. 원자성: 작업이 중간에 끊기지 않음 (상호 배제로 달성)
2. 가시성: 변경된 값을 다른 스레드가 즉시 볼 수 있음

3. 순서 보장: 명령어 재정렬 방지 — happens-before 규칙

synchronized가 단일 JVM에서만 동작하는 이유

synchronized는 JVM 힙에 있는 객체의 모니터 락을 기반으로 동작한다.

그런데 JVM 프로세스끼리는 메모리를 공유하지 않는다.

같은 JVM 안의 스레드들은 동일한 객체의 Mark Word를 보기 때문에 서로의 락 상태를 알 수 있지만, 다른 프로세스 간에는 락을 공유할 수 없다.

그래서 다중 서버 환경에서는 synchronized만으로는 부족하고, DB Lock, Redis Lock, Zookeeper 같은 외부 분산 락을 사용해야 한다.

모니터 락

모든 Java 객체는 힙 메모리에 존재하고, 객체 헤더(Object Header)에 락 상태를 기록한다. 그 안의 Mark Word에는 "지금 어떤 스레드가 이 객체를 점유 중인가" 가 기록된다.

평상시 (synchronized 안 쓸 때)

obj(공유 객체)
┌─────────────────────────────┐
│  Mark Word                  │  ← 해시코드, GC 정보 등 저장
│  (모니터 정보 없음)             │     모니터는 아직 생성 안 됨
└─────────────────────────────┘


synchronized 진입 시도 → 경량 락 먼저 시도

용어를 정리하면 다음과 같다.

스레드들은 같은 힙의 같은 객체를 참조하기 때문에 Mark Word를 공유할 수 있고, 그래서 동기화가 가능하다.
Mark Word: 객체 헤더의 일부로, 락 상태나 ObjectMonitor 포인터를 저장하는 공간
모니터(ObjectMonitor): `owner + Entry Set + Wait Set`을 포함하는 동기화 구조체
Mark Word는 무거운 락 진입 시 ObjectMonitor의 주소를 가리킨다.

CAS (Compare-And-Swap)

CAS는 메모리 주소의 값이 예상값과 일치할 때만 새 값으로 교체하는 CPU 단일 명령어이다.

CAS(메모리주소, 예상값, 새값)
→ 메모리주소의 현재값 == 예상값 → 현재값을 새값으로 교체, true 반환
→ 메모리주소의 현재값 != 예상값 → 아무것도 안 함, false 반환

예시로 보면 더 명확하다.

상황: count = 0, 스레드A와 스레드B가 동시에 count를 1로 바꾸려 함

스레드A 실행
CAS(count주소, 0, 1)
→ count 현재값(0) == 예상값(0)  → count를 1로 교체, true 반환
→ 락 획득 성공

스레드B 실행 (동시에 시도)
CAS(count주소, 0, 1)
→ count 현재값(1) != 예상값(0)  → 아무것도 안 함, false 반환
→ 락 획득 실패 → Entry Set 대기

"읽기 → 비교 → 쓰기" 3단계를 CPU의 단일 명령어(x86: CMPXCHG) 로 처리하므로 원자성이 보장된다.

경량 락 (Lightweight Lock)

경량 락은 락 획득 시 스레드 스택 프레임에 Lock Record를 생성하고, CAS로 Mark Word에 그 주소를 기록하는 방식이다.

ObjectMonitor를 생성하지 않기 때문에 무거운 락보다 비용이 적다.

Lock Record: 경량 락 획득 시 스레드 스택 프레임에 생성되는 구조체. 원래 Mark Word 값을 백업해두는 공간이자, 락 획득의 증거 역할을 한다.

경량 락에서 CAS 동작

공유 객체의 Mark Word 값을 내 스레드 스택의 Lock Record에 복사한다. 이후 그 복사한 값이 Mark Word 주소의 현재 값과 같다면, Lock Record 주소로 교체하여 락을 획득한다.

[락 획득]
CAS(MarkWord주소, 현재MarkWord값, Lock Record주소)

1단계: MarkWord 읽기
 temp = *(MarkWord주소)  → 현재 들어있는 값을 읽어옴

2단계: Lock Record에 백업
 Lock Record.displaced = temp  → 읽어온 값을 백업

3단계: CAS 시도
 CAS(MarkWord주소, temp, Lock Record주소)
 → MarkWord 안의 값이 아직 temp랑 같으면 → 교체 성공
 → 다른 스레드가 이미 바꿔놨으면 → 실패

[락 해제]
CAS(MarkWord주소, Lock Record주소, displaced MarkWord)
→ 백업해둔 원래 MarkWord 값 복원
→ Lock Record 소멸

무거운 락 (Heavyweight Lock)

경량 락 CAS가 실패하면, JVM이 ObjectMonitor를 생성하고 Mark Word를 그 주소로 교체한다. 이 과정을 팽창(inflate)이라고 부른다.

ObjectMonitor는 HotSpot JVM 내부(C++)에 정의된 구조체이다.

무거운 락에서 CAS 동작

[1단계: 팽창]

Mark Word를 ObjectMonitor 포인터로 교체

[2단계: 락 획득]

CAS(ObjectMonitor.owner, null, 현재스레드)
→ 성공: owner가 현재 스레드로 세팅 → 락 획득
→ 실패: Entry Set에 들어가서 BLOCK 상태로 대기

synchronized 진입 순간 (무거운 락)

obj(공유 객체)
┌─────────────────────────────┐
│  Mark Word                  │  ← ObjectMonitor 포인터로 교체됨
│  → ObjectMonitor 주소 가리킴   │
└─────────────────────────────┘
         ↓
  ObjectMonitor (JVM이 그때 생성)
┌──────────────────────────────┐
│ owner                        │  ← 현재 락을 점유한 스레드 포인터
│ (스레드A 포인터 저장)             │
├──────────────────────────────┤
│ Entry Set                    │  ← 락 얻으려고 대기 중인 스레드들
├──────────────────────────────┤
│ Wait Set                     │  ← wait() 호출한 스레드들
└──────────────────────────────┘

여기서 owner 필드가 곧 뮤텍스(상호 배제) 역할을 한다. 한 번에 한 스레드만 owner가 될 수 있고, 나머지는 Entry Set에서 대기한다.

정리

synchronized는 단일 JVM 내에서의 동기화를 보장하는 키워드다.
원자성과 Thread safe는 다른 개념이며, 원자성은 Thread safe의 한 요소일 뿐이다.
JVM은 비용이 적은 경량 락을 먼저 시도하고, 경합이 발생하면 무거운 락으로 팽창시킨다.
두 락 모두 CAS를 통해 원자적으로 락 상태를 변경한다.
다중 서버 환경에서는 synchronized로는 부족하므로 분산 락을 도입해야 한다.