10시간 걸리던 배치 처리를 30분으로 줄였다고 하면, 많은 분들이 이렇게 질문합니다.

“그냥 멀티스레드 쓰면 되는 거 아니야?”

저 역시 처음엔 그렇게 생각했습니다. 스레드 풀을 키우고, 병렬 처리하면 해결될 문제라고 생각했었습니다.

하지만 외부 API 호출이 중심인 배치 작업에서는 플랫폼 스레드 기반 멀티스레드가 생각보다 빠르게 한계에 부딪힌다는 걸 직접 경험했습니다.

이 글에서는 Java 21의 Virtual Thread를 도입하면서 왜 기존 멀티스레드 방식이 잘 맞지 않았는지, 그리고 Virtual Thread가 빛을 발한 조건과 그렇지 않은 조건을 이론이 아닌 실무 관점에서 정리해보려 합니다.

1. 문제 상황: 10시간 걸리는 배치

비즈니스 요구사항 저희는 매일 새벽, 차량 담보대출 약 30,000건에 대해 외부 기관 API를 호출해 차량 원부 정보를 조회합니다. 대출 리스크 관리를 위한 필수 작업이죠.

// 기존 코드 (단순화)
for (Loan loan : loans) {
    VehicleInfo info = externalApiClient.getVehicleInfo(loan.getVehicleNumber());
    loan.updateVehicleInfo(info);
    loanRepository.save(loan);
}

30,000건 × 평균 1.2초 = 약 10시간 00시에 시작해도 오전 10 시가 넘어야 끝나는 상황.

2. 1차 시도: Platform Thread 기반 멀티스레드

ExecutorService executor = Executors.newFixedThreadPool(50);

for (Loan loan : loans) {
    executor.submit(() -> {
        VehicleInfo info = externalApiClient.getVehicleInfo(loan.getVehicleNumber());
        loanRepository.save(loan);
    });
}

Platform Thread의 한계

• Context Switching 비용 증가
• I/O 대기 시간 동안 스레드가 블로킹되어 낭비

현재우리의 상황

• I/O 대기 : 95% 이상 (외부 API 응답대기) -> CPU-bound가 아닌 I/O bound작업 -> Platform Thread는 비효율적

  ---

  3. Virtural Thread 도입

Virtual Thread란?

• Java 21에서 정식 도입 (Project Loom)
• 경량 스레드: 1개당 수 KB 메모리
• 수백만 개 생성 가능
• I/O 대기 시 자동으로 다른 작업 수행 (Non-blocking)

제약사항

외부 기관 API 제약:

• 동시 호출 제한
• Rate Limit 초과 시: 429 에러

→ Virtual Thread로 10,000개 동시 호출하면 안 됨 → Rate Limiter 필수

4. 실제구현

4-1. Virtual Thread Executor 생성

@Configuration
public class VirtualThreadConfig {

    @Bean(name = "vehicleBatchExecutor")
    public ExecutorService vehicleBatchExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}

핵심: newVirtualThreadPerTaskExecutor()는 작업마다 새 Virtual Thread 생성 → 스레드 풀 크기 걱정 없음 4-2. Rate Limiter 적용

@Component
public class VehicleInfoBatchProcessor {

    private final RateLimiter rateLimiter;
    private final ExecutorService virtualThreadExecutor;

    public VehicleInfoBatchProcessor(
            ExecutorService executor,
            double rateLimiter) {
        this.virtualThreadExecutor = executor;
        // 초당 요청 설정
        this.rateLimiter = RateLimiter.create(rateLimiter);
    }

    public void processBatch(List<Loan> loans) {
        List<CompletableFuture<Void>> futures = loans.stream()
            .map(loan -> CompletableFuture.runAsync(() -> {
                rateLimiter.acquire(); // Rate Limit 대기
                processLoan(loan);
            }, virtualThreadExecutor))
            .toList();

        // 모든 작업 완료 대기
        CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]))
            .join();
    }

    private void processLoan(Loan loan) {
        try {
            VehicleInfo info = externalApiClient.getVehicleInfo(
                loan.getVehicleNumber()
            );
            loan.updateVehicleInfo(info);
            loanRepository.save(loan);

        } catch (Exception e) {
            log.error("Failed to process loan: {}", loan.getId(), e);
            // 실패 건은 별도 기록
            failureRepository.save(new FailedLoan(loan.getId(), e.getMessage()));
        }
    }

5. 결과 및 성능비교

처리시간비교

6. 실무 적용 시 주의사항

Virtual Thread가 만능은 아니다 1. CPU-bound 작업에는 효과 없음

나쁜 예: CPU 집약적 작업
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
for (int i = 0; i < 10000; i++) {
    executor.submit(() -> {
        // 복잡한 암호화 연산
        heavyCryptography();
    });
}
// → Platform Thread보다 느릴 수 있음

*Virtual Thread도 결국 Platform Thread * 위에서 실행됨 CPU 작업은 대기 시간이 없어서 Context Switching만 증가

2. Synchronized 블록 주의

주의: Virtual Thread에서 synchronized
public synchronized void updateCounter() {
    counter++;
}

synchronized는 Platform Thread를 Pinning(고정)시킴 → Virtual Thread의 장점 상실 해결책: ReentrantLock 사용

private final ReentrantLock lock = new ReentrantLock();

public void updateCounter() {
    lock.lock();
    try {
        counter++;
    } finally {
        lock.unlock();
    }
}

적용하기 좋은 케이스 1. 외부 API 호출이 많은 경우 2. DB I/O가 많은 경우

트러블 슈팅

1. OutOfMemoryError 원인:

Future를 모두 메모리에 보관
List<CompletableFuture<Void>> futures = loans.stream()
    .map(loan -> CompletableFuture.runAsync(...))
    .toList(); // 30,000개의 Future 객체

해결 : Chunk 단위 처리

개선: 1000개씩 나눠서 처리
int chunkSize = 1000;
for (int i = 0; i < loans.size(); i += chunkSize) {
    List<Loan> chunk = loans.subList(
        i, 
        Math.min(i + chunkSize, loans.size())
    );

    List<CompletableFuture<Void>> futures = chunk.stream()
        .map(loan -> CompletableFuture.runAsync(...))
        .toList();

    CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]))
        .join(); // 1000개 완료 후 다음 Chunk
}

결론

Virtual Thread를 써야 하는 경우

• I/O 대기 시간이 긴 작업 (외부 API, DB 조회)
• 동시 처리가 필요한 대량 작업

Virtual Thread를 쓰면 안 되는 경우

• CPU 집약적 연산 (암호화, 이미지 처리)
• 짧은 작업 (수 ms 이내)
• 레거시 코드에 ThreadLocal이 많은 경우

마지막으로

15시간 걸리던 배치를 30분으로 줄인 건 단순히 Virtual Thread를 적용했기 때문이 아닙니다. 문제의 본질을 파악하고 (I/O-bound) 적절한 도구를 선택하고 (Virtual Thread) 실무 제약사항을 고려한 (Rate Limiter, Chunk 처리) 덕분입니다. 새로운 기술을 도입할 때는 항상 "왜?"를 먼저 습관을 들이는게 중요한것 같습니다.

실무에서 외부 시스템과 통신하는 코드는 필연적으로 다양한 예외를 마주합니다.

하지만 종종 이런 예외를 아래와 같이 직접적으로 던지는 경우를 봅니다:

java
복사편집
try {
    // 외부 API 호출
} catch (IOException e) {
    throw e; 
}

이렇게 되면 무슨 문제가 생길까요?

🧱 문제점

• 도메인 계층이 외부 시스템의 예외 타입에 오염됨

  → IOException 같은 라이브러리/네트워크 예외가 서비스 레이어까지 흘러들어옴

• 예외 처리 일관성 붕괴

  → 같은 실패인데 어떤 API는 500, 어떤 API는 400으로 응답하거나, 로그 메시지도 제각각

• 장애 추적 어려움

  → 로그에서 API 호출 실패인지, 파싱 실패인지, 클라이언트 버그인지 분간이 안 됨

• 테스트와 시뮬레이션이 어려움

  → 예외를 모킹할 수 없고, 실제 API 서버에 의존

🛡 그래서, 에러 '격벽 처리'란?

격벽 처리 는 외부 예외를 시스템 내부에서 완전히 캡슐화하여,

내부 도메인 또는 클라이언트로 전파하지 않는 설계 패턴입니다.

java
복사편집
// 외부 API → HTTP/IO 예외 → APIException (표준화)
// 서비스 레이어 → APIException → CustomException (도메인 에러에 매핑)
// 컨트롤러 → ErrorHandler → 사용자에게 명확한 메시지 전달

이렇게 되면 "외부 API는 실패할 수 있다"는 전제를 시스템이 안전하게 감싸는 구조가 됩니다.

✅ 장점 요약

🧱 실제 예: 외부 API 처리

java
복사편집
try {
    String res = get(url, headers);
    return objectMapper.readValue(res, Custom.class);
} catch (APIException e) {
    throw new CustomException(CustomError.getCustomError(e), e.getResMsg());
}

이 구조 하나로 다음을 동시에 만족시킵니다:

• 외부 API 상태나 에러 포맷이 바뀌어도 서비스 레이어는 무관
• 내부 도메인은 도메인에러 같은 의미 있는 에러 코드만 보고 판단 가능
• HTTP 408, 504, 404 등 다양한 상황을 ErrorHandler에서 통일된 메시지로 반환 가능

1. 기존 문제점

case 이벤트성 상품 할인 쿠폰 이벤트 시 중복하여 쿠폰이 발생하는 경우

이러한 문제점이 발생했습니다, 그렇담 왜 이러한 중복 발급이 발생하는걸까요?

선착순 쿠폰 발급을 동시에 많은 사용자가 요청 시 쿠폰 수량을 줄이기전에 다른 트랜잭션이 읽을 경우 중복 발급이 발생되어집니다.

모색 방안

현재 프로젝트의 경우 분산환경에서 N개의 서버를 구동중에 있습니다.

낙관적락 비관적락

이러한 락을 처리하기 위해 보편적으로 많이 사용하는 낙관적락 비관적락이 있으나 현재 저의 상황에서는 맞지 않다 판단하여 적용하지 않았습니다.

1. 낙관적 락을 채택하지 않은 이유

• 낙관적 락은 version 필드를 활용하여 동시성을 제어하는데, 쿠폰 발급 요청이 동시다발적으로 들어오는 상황에서는 충돌이 빈번하게 발생하여 롤백을 직접 해주어야 하기에 성능이 저하되었고, 때문에 이를 채택하지 않았습니다.

2. 비관적 락을 채택하지 않은 이유

• 비관적 락은 하나의 트랜잭션이 특정 데이터(쿠폰)를 갱신하는 동안 다른 트랜잭션의 접근을 차단하는 방식입니다. 이런 경우 데이터베이스 락이 병목이 발생하여, 성능 저하가 발생하여 이를 채택하지 않았습니다.

그럼에도 불구하고 낙관적 락, 비관적 락은 많은 부하가 있지 않은 경우 훌륭한 선택지가 될 수 있다고 생각합니다.

Redisson 기반 Redis 분산락 적용

기존의 Lettuce 방식은 스핀락 기반으로 동작하여 Redis에 지속적으로 요청을 보내는 방식이었습니다. 이는 Redis 부하를 유발하는 단점이 있었기 때문에, Redisson의 Pub/Sub 기반 분산락을 적용하여 성능을 개선하였습니다.

Redisson 적용 장점:

• 불필요한 Redis 요청 감소: 락 대기 시 Pub/Sub 방식으로 이벤트를 수신하여, 스핀락 방식보다 효율적으로 관리 가능
• 데드락 방지: 락의 만료 시간을 설정하여 불필요한 리소스 점유 방지

분산 락을 적용하지 않은 이유

• 부하테스트 시 높은 동시 요청이 발생하면 TPS 감소 및 서버 부하 증가 문제가 발생하여 이를 채택하지 않았습니다.

여러 서버가 있는 분산 환경에서 분산락은 좋은 선택지가 될 수 있다 생각합니다.

Kafka 대기열 + Redis Sorted Set 적용

앞선 문제들을 해결하기위해 Kafka + Redis를 활용한 대기열을 도입하였습니다.

아키텍처

주요 방식

** 1. Kafka를 활용한 요청 대기열 구성 **

• 사용자가 쿠폰을 요청하면, Kafka Producer가 해당 요청을 메시지로 변환하여 대기열(Kafka 토픽)에 전송합니다.
• 이때, Kafka 브로커 개수, 파티션 수, ISR 등의 설정을 최적화하여 메시지가 빠르고 안정적으로 처리되도록 구성하며. (추후 이부분에 대한 게시글 작성하겠습니다.)
• 대기열 서버에서 순차적으로 요청을 처리하여 과부하를 방지합니다.

** 2. Redis Sorted Set을 활용한 쿠폰 발급 요청 정렬 **

• Redis sorted Set을 활용하면 중복 요청 방지 및 순서 보장이 가능합니다.
• Kafka에서 전달된 요청을 도착 시간 기준으로 Redis Sorted Set에 저장 합니다.

** 3. 쿠폰 발급 배치를 활용한 빠른 Insert 처리 **

• 배치 서버에서 Redis에 적재된 시간순으로 적재된 발급정보들을 읽어옵니다.(지정된 수 만큼)
• JDBC Bulk Insert를 활용하여 DB에 적재합니다.
• Redis에 저장된 정보를 삭제하며, 중복 발급 방지를 위한 TTL 설정이 포함된 정보를 Redis에 다시 적재하게 됩니다.

성능 비교

락 적용 X 기본

효과

• 쿠폰 초과 발급(동시성) 문제 해결 - Kafka 대기열과 Redis Sorted Set을 활용해 요청을 순차적으로 처리하면서 동시성 문제를 해결 하였습니다.
• 서버 부하 감소 - Kafka가 요청을 분산 처리하면서 서버의 부하를 효과적으로 분산할 수 있었습니다.

마지막으로

선착순 쿠폰 발급 시스템의 초과 발급 문제를 해결하기 위해 Redis 기반 분산락과 Kafka 대기열 시스템을 비교해 개발을 진행해 보았습니다.

최종적으로 Kafka와 Redis Sorted Set을 활용한 대기열 시스템이 높은 성능을 보이며, 초과 발급을 방지하면서도 빠른 응답성을 유지할 수 있었습니다.

선착순 쿠폰 발급뿐만 아니라 동시 요청이 많은 서비스(티켓팅, 한정판 판매 등) 에서도 활용할 수 있다 생각하며 오늘의 글은 여기 까지 작성하도록 하겠습니다.

개인 프로젝트로 진행하는 쇼핑몰 프로젝트에서 상품 랭킹 서비스 구현을 Redis의 Read Through + Write back 패턴을 활용하여 구현한 내용을 정리 해보자 📒

🧐기존 랭킹 구현 상태를 살펴보자

현재 프로젝트에서 사용자가 상품 조회요청을 보내면 Product-service에서 Rank-Service로 조회요청에 대한 이벤트를 발행하고 이를 Rank-service 쪽에서 Consume하여 조회수를 증가 시키고 있습니다!

🤷‍♂️ 대표적인 읽기 전략

Redis의 대표적인 읽기 전략

1. Look Aside 패턴
2. Read Through 패턴

Look Aside 패턴

• 반복적인 읽기가 많은 호출에 적합
• 캐시와 DB가 분리되어 가용 원하는 데이터만 구성하여 캐시에 저장
• 캐시와 DB가 분리되어 가용되기에 캐시 장애 대비 구성이 되어있다. Redis 다운시 DB에서 데이터를 읽어 사용
• Redis 다운시 DB에 부하 발생

Read Through 패턴

• 캐시에서만 읽어오는 전략
• Look Aside와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이
• 데이터 조회속도가 느림
• 데이터 조회를 캐시에 의지하기에, redis 다운시 서비스에 치명적일 수 있음.
• 캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어 날 수 있음

🤷‍♂️ Redis의 대표적인 쓰기 전략

** Redis의 대표적인 쓰기 전략**

1. Write Back 패턴
2. Write Through 패턴
3. Write Around 패턴

Write Back 패턴

• 캐시와 DB 동기화를 비동기로 하기 때문에 동기화 과정이 생략
• 데이터를 저장할때 DB로 바로 쿼리하지 않으며, 일정 주기 배치 작업을 통해 DB 반영
• 캐시에 모아 놨다가 DB에 쓰기 때문에 부하를 줄일 수 있다
• Wirte가 빈번하고 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
• 캐시에서 오류가 발생하면 데이터를 영구 소실함

Write Through 패턴

• DB, Cach 동시에 데이터를 저장하는 전략
• 데이터를 저장할때 캐시에 저장한 뒤 DB에 저장 (모아두는 방식이 아님)
• DB와 캐시 항상 동기화되어 캐시는 항상 최신의 상태로 유지
• 데이터 일관성을 유지할 수 있다
• 데이터 유실이 발생하면 안 되는 상황에 적합
• 자주 사용되지 않은 불필요한 리소스를 저장
• 매 요청 마다 Write를 두번 발생시키기에 빈번한 생성, 수정의 경우 성능 이슈가 발생

Write Around 패턴

• Write Though 보다 빠름
• 모든 데이터는 DB에 저장 (캐시를 저장하지 않음)

🤷‍♂️ 왜 랭킹 구현에 Write back + Read Through 패턴이 왜 적합 할까?

읽기 전략

1. DB 접근의 최소화 현재 쇼핑몰의 메인 페이지에서, 상단 헤더 부분에 상품 랭킹에 대한 정보 들을 계속 보여줄 예정이다, 그렇다면 트래픽이 상승할 경우 랭킹 DB에 대한 접근이 많아질 것이고, 이때 부하를 일으킬 것을 가정하였다

2. Cluster 구성 일단 Read Through 패턴은 Redis에게 데이터 동기화를 위임하기 때문에 Redis단일로 사용하게 된다면 Redis가 장애를 일으킨다면 상당히 치명적일 수 있다. 하지만 현재 프로젝트에서 Redis Cluster를 구성하여 사용할 것이 판단하여 Redis 장애에 대한 가용성을 높일 수 있을거라 생각되었다

쓰기 전략

1. DB 접근의 최소화 현재 kafka를 통해 상품 클릭시 product-service에서 이벤트를 발행하고 rank-service에서 이를 consume 하여 사용중이다 이때 많은 사용자가 있으며, 상품클릭에 대한 트래픽이 높다고 가정하고있다, 그렇기 때문에 이벤트 consume시 DB에 직접 write를 한다면 DB에 부하가 가해질 것으로 가정하였고, 이를 해결하기 위해 write-back 패턴을 도입 구체적으로 배치 작업 + jdbc bulk insert를 통해 쓰기작업을 이용하여 DB에 부하를 줄일 수 있을것으로 생각 되었다.

최종 결정 사유

위에 나열한 이유와 랭킹서비스가 서비스 전체를 보았을때 치명적인 오류를 일으키지 않을것으로 판단하여 선택하게 되었다!

개인 프로젝트로 진행하는 쇼핑몰 프로젝트에서 상품 랭킹 서비스 구현을 Redis의 sorted set을 이용해서 구현한 내용을 정리 해보자 📒

🧐기존 랭킹 구현 상태를 살펴보자

현재 프로젝트에서 사용자가 상품조회를 요청하게 되면 Product-Service 에서 Rank-Service로 조회요청에 대한 이벤트를 발행 하게 되고 이를 Rank-Service 쪽에선 Consume 하여 상품 ID을 통해 조회수를 증가시키고 있습니다!

🤷‍♂️ RDB를 직접 사용 하지 않고 Redis를 사용하는 이유는?

1. 속도 차이

랭킹 기능은 현재 사용중인 MySql DB에 저장된 데이터의 count 값을 증가 시켜 구현할 수 있겠으나, 만약 이 데이터 값이 많아 진다면 order by하여 값들을 계산하여 return 해주는 시간이 데이터가 늘어날수록 늘어날 것으로 판단 하였기 때문에 Redis를 선택하여 사용하였습니다.

🤔 spring cache가 아닌 Redis를 사용한 이유는?

일단 저의 프로젝트 구성은 MSA구성으로 분산환경에 맞춰 개발을 진행했기 때문에 이를 공통적으로 관리 할 수 있는 환경이 필요 했고 Redis로 선택하게 되었습니다.

2. write-back 패턴 도입

상품을 지속적으로 조회수가 많아지수록 Rank DB에 대한 부하가 심해질것 이며, 이를 해결 하기 위하여 도입하기로 하였으나 이번 주제랑은 다른 관계로 다른 포스팅에서 작성 하도록 하겠습니다!

랭킹 구현에 soted set이 왜 적합 할까?

로직 구현이 필요없다 sorted set은 score를 하나하나 비교하여 정렬해줄 필요가 없다 -> score 값을 비교하여 정렬하기 때문이다.

빠르게 sorted set 명령을 알아보자

*(1) rank 추가 *

$ ZADD <key> <score> <member>

(2) rank의 score 값 조회

$ ZSCORE <key> <member>

만약 없는 key값을 조회하려고 하면 (nil)으로 값을 반환한다.

일단 간단한 등록과 조회를 할 수 있는 명령어를 살펴보았습니다.

성능 비교를 해보자

1. JPQL을 사용한 순위 집계

 @Query("select r from RankingEntity r order by r.clickNum desc")
 List<RankingEntity> findWithPagingOrderByClickNum(Pageable pageable);

이 직접접인 DB call을 통하여 순위를 확인한 경우

541S의 성능을 보여 줬습니다. 하지만 만약 데이터가 계속적으로 많아질 경우 성능이 더 늦어질 것입니다.

2. redis sortedSet을 사용한 순위 집계

ZSetOperations zSetOps  = redisTemplate.opsForZSet();
Set<String> rangeRakingSet = zSetOps.reverseRange("CLICK_RANK",0,limit-1);

위와 같이 redis sortedSet을 활용하여 순위를 집계할 경우 11s의 성능을 보여주며 RDB에 직접 접근하는것 보다 빠르다는 것을 확인할 수 있었습니다!

그렇담 고려할점은 없을까?

Redis를 사용함에 있어 트래픽이 적을 경우는 오버헤드같은 경우를 고려하지 않아도 되겠지만 대용량 데이터를 사용할 시에는 이러한 오버헤드를 잘 고려해야한다고 합니다.

또한 Redis가 만약 죽어버린다면 데이터를 소실할 경우가 있습니다 이때에는 Redis의 백업 정책 혹은 cluster를 활용하여 이를 방지하여야 할것입니다!

이러한 것들은 추후 포스팅에서 다뤄볼 예정입니다!

그럼에도 Redis를 도입한 이유는?

일단 redis 모든 노드등의 문제가 생겨 순위 서비스가 만약 데이터를 잃는다고 하여도, 일단 순위에 대한 서비스 자체가 현재 진행하는 프로젝트의 서비스에서 크리티컬한 문제를 일으키지 않을 거라 판단 하였습니다. 이러할 경우 Look Aside 패턴을 사용하여 이전 데이터를 RDB에서 불러오는 전략을 세워볼 수 있을거라 판단했습니다. 이러한 읽기 전략이나 쓰기 전략은 추후에 모아서 글을 작성해 해보도록 하겠습니다!

일정 개수의 상수 값을 정의한 다음 그외의 값은 허용하지 않은 타입

그렇다면 이런 열거 타입을 왜 사용할까? 열거 타입 이전에 사용 했던 정수 열거 패턴을 살펴보며 이유를 알아보자!

정수 열거 패턴 단점

//정수 열거 패턴
public static final int APPLE_FUJI = 0;
public static final int APPLE_PIPPIN = 1;
public static final int APPLE_GRANNY_SMITH = 2;

public static final int ORANGE_NAVEL = 0;
public static final int ORANGE_TEMPLE = 1;
public static final int ORANGE_BLOOD = 2;

• 타입 안전을 보장할 방법이 없으며, 표현력 또한 좋지 않다.
• 평범한 상수를 나열이기 때문에 프로그램이 깨지기 쉽다.
• 정수 열거 그룹에 속한 모든 상수를 순회하는 방법도 마땅치 않고, 상수가 몇 개인지 알 수 없다.

열거 타입

열거 타입은 앞선 정수 열거 패턴의 단점을 말끔이 없애 준다.

/// 간단한 열거 타입
public enum Apple {FUJI, PIPPIN, GRANNY_SMITH}
public enum Orange {NAVEL, TEMPLE, BLOOD}

열거타입의 특징

• 상수 하나당 자신의 인스턴스를 하나씩 만들어 public static final 필드로 공개한다.
• 열거 타입 선언으로 만들어진 인스턴스는 딱 1개만 존재한다.

열거타입의 장점

• 타입의 안전성을 제공한다. ex) Apple 열거 타입 인수에 Orange를 넘길 수 없다.
• 같은 이름 상수 공존: 각자의 이름 공간이 있기 때문에
• 임의의 메서드나 필드를 추가할 수 있고 임의의 인터페이스를 구현하게 할 수 있다.

데이터와 메서드를 갖는 열거 타입

public enum Planet {
    MERCURY(3.302e+23, 2.439e6),
    VENUS  (4.869e+24, 6.052e6),
    EARTH  (5.975e+24, 6.378e6),
    MARS   (6.419e+23, 3.393e6),
    JUPITER(1.899e+27, 7.149e7),
    SATURN (5.685e+26, 6.027e7),
    URANUS (8.683e+25, 2.556e7),
    NEPTUNE(1.024e+26, 2.477e7);

    private final double mass;           // 질량(단위: 킬로그램)
    private final double radius;         // 반지름(단위: 미터)
    private final double surfaceGravity; // 표면중력(단위: m / s^2)

    // 중력상수(단위: m^3 / kg s^2)
    private static final double G = 6.67300E-11;

    // 생성자
    Planet(double mass, double radius) {
        this.mass = mass;
        this.radius = radius;
        surfaceGravity = G * mass / (radius * radius);
    }

    public double mass()           { return mass; }
    public double radius()         { return radius; }
    public double surfaceGravity() { return surfaceGravity; }

    public double surfaceWeight(double mass) {
        return mass * surfaceGravity;  // F = ma
    }
}

열거 타입 상수 각각을 특정 데이터와 연결지으려면 생성자에서 데이터를 받아 인스턴스 필드에 저장하면 된다.

• 열거타입은 불변이기에 모든 필드는 final이어야 한다.
• 필드를 public으로 선언해도 되지만, private으로 두고 별도의 public 접근 메서드를 두는 것이 낫다.

열거타입의 배열

public class WeightTable {
   public static void main(String[] args) {
      double earthWeight = Double.parseDouble(args[0]);
      double mass = earthWeight / Planet.EARTH.surfaceGravity();
      for (Planet p : Planet.values())
         System.out.printf("%s에서의 무게는 %f이다.%n",
                           p, p.surfaceWeight(mass));
   }
}

자신 안에 정의된 상수들의 값을 배열에 담아 반환하는 정적 메서드 값들은 선언된 순서로 저장된다.

상수별 메서드 구현

switch를 이용한 구현은 새로운 상수를 추가할 때마다 해당 case문도 추가해야해서 깨지기 쉽다.

** 상수별 메서드 구현 ** 열거 타입에 추상 메서드를 선언하고, 각 상수별 클래스 몸체(constant-specific class body)를 각 상수에 맞게 재정의하는 방법

import java.util.*;
import java.util.stream.Stream;
import static java.util.stream.Collectors.toMap;

public enum Operation {
    PLUS("+") {
        public double apply(double x, double y) { return x + y; }
    },
    MINUS("-") {
        public double apply(double x, double y) { return x - y; }
    },
    TIMES("*") {
        public double apply(double x, double y) { return x * y; }
    },
    DIVIDE("/") {
        public double apply(double x, double y) { return x / y; }
    };

    private final String symbol;

    Operation(String symbol) { this.symbol = symbol; }

    public abstract double apply(double x, double y);    
}

상수별 동작 혼합 : 전략 열거 타입 패턴

열거 타입 상수 일부가 같은 동작을 공유한다면 전략 열거 타입 패턴을 사용하자.

package effectivejava.chapter6.item34;

import static effectivejava.chapter6.item34.PayrollDay.PayType.*;

enum PayrollDay {
    MONDAY(WEEKDAY), TUESDAY(WEEKDAY), WEDNESDAY(WEEKDAY),
    THURSDAY(WEEKDAY), FRIDAY(WEEKDAY),
    SATURDAY(WEEKEND), SUNDAY(WEEKEND);

    private final PayType payType;

    PayrollDay(PayType payType) { this.payType = payType; }

    int pay(int minutesWorked, int payRate) {
        return payType.pay(minutesWorked, payRate);
    }

    enum PayType {
        WEEKDAY {
            int overtimePay(int minsWorked, int payRate) {
                return minsWorked <= MINS_PER_SHIFT ? 0 :
                        (minsWorked - MINS_PER_SHIFT) * payRate / 2;
            }
        },
        WEEKEND {
            int overtimePay(int minsWorked, int payRate) {
                return minsWorked * payRate / 2;
            }
        };

        abstract int overtimePay(int mins, int payRate);
        private static final int MINS_PER_SHIFT = 8 * 60;

        int pay(int minsWorked, int payRate) {
            int basePay = minsWorked * payRate;
            return basePay + overtimePay(minsWorked, payRate);
        }
    }

    public static void main(String[] args) {
        for (PayrollDay day : values())
            System.out.printf("%-10s%d%n", day, day.pay(8 * 60, 1));
    }
}

추가하려는 메서드가 의미상 열거타입에 속하는 경우 다음과 같이 전략 열거 타입 패턴을 사용한다.

그렇지 않은 경우에는 switch를 적용해서 간단하게 만든다.

열거타입을 언제 사용할까?

• 필요한 원소를 컴파일 타임에 다 알 수 있는 상수 집합이라면 항상 열거 타입을 사용하자

  • Ex) 태양계 행성, 한 주의 요일, 체스말

• 열거 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다.

  • Ex) 메뉴 아이템, 연산 코드, 명령줄 플래그

• 열거타입의 성능은 상수와 별반 다르지 않다

불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다.

특징

• 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 달라지지 않는다.

• 자바 플랫폼 라이브러리에도 String, BigInteger, BigDecimal가 여기 속한다.

그렇다면 왜 불변 클래스를 사용할까?

불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류의 여지도 적고 안전하다.

불변 클래스의 규칙

이제 클래스를 불변으로 만드는 다섯가지 규칙에 대해 알아보자.

1. 객체의 상태를 변경하는 메서드를 제공하지 않는다.
2. 클래스를 확장할 수 없도록 한다. (하위 클래스에서 객체의 상태를 변하게 만드는것을 방지하기 위해)
3. 모들 필드를 final로 선언한다. 이를 통해 설계자의 의도를 명확히 드러 낸다.
4. 모든 필드를 private으로 선언한다. 이를 통해 필드가 참조하는 가변 객체를 직접 수정하는 일을 방지한다.
5. 자신 외에는 내부 가변 컴포넌트에 접근할 수 없도록 한다.

불변 복소수 클래스

이러한 불변 클래스의 규칙을 통해 만들어진 예제를 보자

public final class Complex {
    private final double re;
    private final double im;

    public Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }

    public double realPart() {
        return re;
    }

    public double imaginaryPart() {
        return im;
    }

    public Complex plus(Complex complex) {
        return new Complex(re + complex.re, im + complex.im);
    }

    // ...

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Complex complex = (Complex) o;
        return Double.compare(complex.re, re) == 0 && Double.compare(complex.im, im) == 0;
    }

    @Override
    public int hashCode() {
        return Objects.hash(re, im);
    }
}

• plus 메서드는 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어서 반환한다.
• 이처럼 피연산자에 함수를 적용해 그 겨과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다.
• 절차적 혹은 명령형 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.

불변 클래스 장점

그렇다면 이런 불변 클래스를 사용함으로 써 가져오는 이점은 무엇일까?

• 불변 객체는 단순하다. 생성된 시점의 상태를 파괴될 때까지 간직한다.
• 불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다.
• 위와 비슷한 맥락이지만 어떤 스레도도 다른 스레드에 영향을 줄 수 없으니 불변 객체는 안심하고 공유할 수 있다. 이렇기 때문에 한번 만든 인스턴스는 재활용 하기를 권하며, 자주 쓰이는 값들은 상수로 제공 하는것이다.

  //예제
  public static final Complex ZERO = new Complex(0,0);
  public static final Complex One = new Complex(1,0);
  public static final Complex I = new Complex(0,1);

• 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있다. 이를 통해 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어 들며, 필요에 따라 캐시 기능을 나중에 덧붙일 수 있다.
• 불변 클래스는 어파치 원본과 같기 때문에, 방어적 복사가 필요 없다.
• 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.
• 불변 객체는 그 자체로 실패 원자성을 제공한다
  • 실패 원자성이란 메서드에서 예외가 발생한 후에도 그 객체는 여전히 (메서드 호출 전과 똑같은) 유효한 상태 여야하는 성질이다.

불변 클래스의 단점

앞서 불변 클래스의 장점을 보았을 때는 그럼 이러한 객체를 사용하지 않을 이유가 없자나! 라고 생각할 수 있다. 하지만 이러한 불변 클래스에도 단점이 존재 한다.

• 불변 클래스의 값이 다르면 반드시 독립된 객체로 만들어야 한다. 값의 가지수가 많다면 이를 만드는데 큰 비용이 들어 갈것이다.
• 이에 대처하는 방안은 두 가지이다. 첫 번째는 흔히 쓰일 다단계 연산(multistep operation)들을 예측하여 기본 기능으로 제공하는 방법이다.
• 클라이언트가 원하는 복잡한 연산들을 정확히 예측할 수 있다면 이러한 다단계 연산 속도를 높여주는 package-private인 가변 동반 클래스(companion class)만으로도 충분하다.
• 예측이 불가능하다면 가변 동반 클래스를 public으로 제공하는 게 최선이다. 대표적인 예로 StringBuilder, StringBuffer가 있다.

생성자를 대신 정적 팩터리를 사용한 불변 클래스

앞서 불변 클래서의 장단점을 알아 보았고, 불변 클래스를 만드는 방법을 알아볼텐데 그중 생성자를 대신 정적 팩터리를 사용한 불변 클래스 방법에 대해 알아보자

그전에 불변 클래스 생성 필요한 규칙인 클래스가 불변임을 보장하려면 자신을 상속하지 못하게 해야 하는점을 생각해보자.

• 이에 대한 가장 쉬운 방법은 final 클래스로 선언하는 것이다.
• 또는 생성자를 private로 만들고 정적 팩터리를 제공할 수도 있다(이 편이 더 유연하다).

public final class Complex {
    private final double re;
    private final double im;

    private Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }

    public static Complex valueOf(double re, double im) {
        return new Complex(re, im);
    }

    // ...
}

• 이 방식은 바깥에서 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 훨씬 유연하다.
• 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다. public이나 protected 생성자가 없으니 다른 패키지에서 이 클래스를 확장하는 게 불가능하기 때문이다.
• 정적 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이후에 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.
• 계산 비용이 큰 값의 경우, 나중에 (처음 쓰일 때) 계산하여 final이 아닌 필드에 캐시하여 사용함으로써 계산 비용을 절감할 수 있다. 불변 객체는 변하지 않기 때문에 가능하다.

정리

이런 내용들을 정리해 보자면,

• 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.

• 단순한 값 객체는 불변으로 만들도록 하자.

• 성능 때문에 어쩔 수 없다면 불변 클래스와 함께 가변 동반 클래스를 public 클래스로 제공하도록 하자.

• 모든 클래스를 불변으로 만들 수는 없다. 하지만 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이도록 하자.

  • 꼭 변경해야 하는 필드를 제외한 나머지 모두를 final로 선언하도록 하자. 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.

• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.

  • 확실한 이유가 없다면 생성자나 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공하면 안 된다.
  • 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 마찬가지다. 복잡성만 커지고 성능 이점은 거의 없다.

DB Replication 이란?

그렇담 이 Replication은 무엇인가?!

데이터베이스를 복제하는 행위

그렇담 왜 하나의 DB를 사용하면 되지만 여러개의 DB를 사용할까?

Case 1 DB의 이상으로 요청에대한 응답이 되지 않았을때 Case 2 요청 트래픽의 증가로 인한 트래픽의 부하 분산이 필요한 상황 일때 이때 스케일업을 통해 어느정도 보완이 가능하겠으나, 스케일업에는 분명 한계가 있습니다!

이러한 상황을 타개하기 위해서 DB Replication을 사용해야 합니다.

DB Replication의 구조

일단 원본 데이터를 가진 데이터베이스 서버를 소스서버 복제된 DB의 데이터를 가지고 있는 DB 서버를 레플리카 서버 라고 합니다.

소스 서버에서 변경이 일어나면 변경된 내용은 레플리카 서버에 동일하게 반영이 됩니다. 이런 구조를 소스-레플리카 구조라고 합니다!

그렇기 때문에 앞선 Case 1의 경우 레플리카 서버를 소스서버로 승격시켜 사용할 수 있습니다. Case2의 경우는 소스 서버를 쓰기 전용 DB, 레플리카 서버를 읽기 전용 DB로 사용해 부하를 해결할 수 있습니다.

복제는 어떻게 발생 하는가?

그렇담 이러한 레플리카에 데이터 복제는 어떻게 가능하게 하는지 알아보도록 합시다.

바이너리 로그 기반 복제

바이너리 로그란?

모든 변경사항이 로그 파일에 순서대로 기록되는 것을 의미합니다.

즉 소스서버에 변경이 발생되어 바이너리 로그 이벤트가 기록이 되면 이 이벤트는 레플리카 서버가 자신의 로컬 디스크에 저장한 이후 이벤트를 읽어 들여 레플리카DB 자기자신의 데이터 파일에 반영합니다.

좀더 자세히 알아볼까요?

일단 복제 쓰레드는 총 세 가지 쓰레드가 사용됩니다. 이벤트 순서 대로

1. 소스서버의 바이너리 로그에 이벤트가 발생되면 바이너리 로그 덤프 쓰레드가 이 이벤트를 읽어 레플리카 서버로 전송합니다.
2. 레플리카 서버의 I/O 쓰레드는 이 변경 이벤트를 자신의 로컬파일인 릴레이 로그에 저장합니다. (이때 아직 자신의 DB엔 변경이 일어나지 않습니다.)
3. 레플리카 서버의 DB 변경을 위해 SQL 쓰레드가 변경 내용을 데이터 파일에 저장합니다.

레플리카는 소스서버의 바이너리 로그 이벤트를 식별하여 반영할까?

이 방식에는 두 가지 방식이 있습니다.

1. 바이너리 로그 파일 위치 기반 복제

• 이 방식의 경우 소스서버 바이너리 로그의 로그 파일명과 오프셋을 이용해 식별합니다.
• ex) Binary-log.00002:110 이라는 로그가 있다고 한다면 Binary-log는 로그파일명이며 콜론뒤 110은 Offset입니다.
• 이러한 방식의 단점은 소스서버에만 유용한 식별 방법 이라는 단점이 있습니다.
• 즉 소스서버에 문제가 생겨 다른 레플리카 서버가 소스서버로 승격된 경우 다른 레플리카 서버들(복제에 참여하는)은 다시 이 바이너리 파일의 위치를 찾아야 하기 때문에 복구에 시간이 소요 됩니다.

즉 동일한 이벤트가 레플리카 서버에서도 동일한 파일명의 동일한 위치에 저장된다는 보장이 없습니다.

2. 글로벌 트랜잭션 아이디(GTID)

앞선 단점을 해결하기 위해 MySQL 5.6 버전 부터는 글로벌 트랜잭션 기반 복제를 기본 복제 방식으로 사용하고 있습니다.

그렇담 이 글로벌 트랜잭션 아이디는 무엇일까?

복제에 참여한 모든 데이터베이스들이 고유한 식별값을 가지며 이 값들은 모두 동일하기 때문에 동일한 이벤트에 대해서 동일한 글로벌 트랜잭션만 읽기만 하면 반영이 가능하게 됩니다.

복제 데이터 포맷

바이너리 로그 포맷

1. Statement 기반 방식

INSERT INTO member VALUES(1,'TESTNAME')

이러한 SQL문이 일어나면 이 SQL문이 바이너리 로그에 그대로 저장되는 방식을 Statement 기반 방식이라고 합니다.

• 장점: 으로는 여러 개의 데이터를 수정하는 쿼리여도 바이너리 로그에 SQL문 딱 하나만 저장되기 때문에 저장 공간에 대한 부담이 감소 되며, 빠른처리가 가능하게 됩니다.
• 단점 :하지만 실행하는 쿼리마다 결과값이 바꾸니는 경우 데이터 동기화 문제가 발생하며 트랜잭션 격리수준이 REPEATABLE-READ 이상에서만 사용이 가능하다는 단점이 있습니다.

일관되지 않은 데이터가 저장될 위험이 있습니다!

2. Row 기반 방식

앞선 Statement 기반의 단점을 보완하여 MySQL 5.7.7 버전 부터는 이 Row 기반 바이너리 로그 포맷을 기본으로 사용합니다.

이 방식은 변경 값 자체가 바이너리 로그에 그대로 저장되어 있는 형식을 말합니다.

• 장점 : 모든 트랜잭션 격리 수준에서 사용 가능 하다.
• 단점 : 데이터를 변경하는 SQL문이 많이 발생되면 바이너리 로그 파일의 크기가 너무 커질 수 있으며, SQL쿼리를 육안으로 확인하기 어렵습니다.

  그럼에도 불구하고 데이터를 일관되게 저장 하는 가장 안전한 방식 입니다.

  3. Mixed 기반 방식

  이 Mixed 방식은 사용자가 커스텀하여 사용이 가능합니다. 기본적인 쿼리는 Statement 포맷으로 저장하되 비확정적 쿼리 라면 Row 포맷으로 저장하는 방식을 사용할 수 있습니다.

복제 동기화 방식

그렇다면 복제가 잘 일어났는지 어떻게 확인할까?

1. 비동기 복제

소스 서버가 레플리카 서버에서 변경 이벤트가 정상적으로 전달 됐는지 확인하지 않는다.

자세히 알아보자면.

1. 데이터 변경 요청이 들어온다면 바이너리 로그의 이벤트를 먼저 작성한 뒤 바로 소스 서버 스토리지 엔진에 커밋을 하게 된다.
2. 그 이후 변경 이벤트를 레플리카 서버로 전송합니다.

이 방식은 변경 이벤트를 레플리카 서버로부터 소스 서버로 확인 이벤트를 보내지 않습니다. 그렇기 때문에 성능은 빠를 수 있으나 동기화는 보장하지 않습니다.

2. 반동기 복제

앞선 비동기 복제의 단점을 보완하여 MySQL 5.5 버전 부터는 반동기 복제 방식을 사용합니다.

소스 서버는 레플리카 서버가 소스 서버로부터 전달 받은 변경 이벤트를 릴레이 로그에 기록 후 응답을 보내면 그때 트랜잭션을 완전히 커밋한다.

자세히 알아보자면

1. 데이터 변경 요청이 소스 서버로 들어오면 바로 이벤트를 바이너리 로그에 기록후 레플리카 서버로 전송합니다.
2. 레플리카 서버는 이 변경 이벤트를 잘 받았다는 응답을 보내게 되며, 응답이 오고 난 이후 소스 서버는 변경 내역을 스토리지 엔진에 커밋합니다.

이때 레플리카 서버가 보내는 응답은 변경 이벤트를 잘 받았다는 응답일뿐 이벤트가 레플리카 서버에 적용되었다는 응답을 보내는 것은 아닙니다.

복제 구성 형태(복제 토폴리지)

그렇다면 소스 서버와 레플리카 서버를 구성 할까요?

1.싱글 레플리카

이는 소스 서버와 레플리카 서버를 한대씩 두는 방식이며, 레플리카 서버는 예비 서버 및 데이터 백업용으로 활용합니다.

2.멀티 레플리카

싱글 레플리카 방식에서 레플리카 서버를 한대 더 둔 멀티 레플리카 방식이 있으며 이때 레플리카 두 대를 사용하는데 한대는 쿼리 부하 분산용으로, 두 번째 레플리카 서버는 백업 용으로 사용할 수 있습니다.

3. 체인 복제

소스 서버에 연결된 레플리카 서버가 많다면 소스 서버의 복제부하가 커지게 됩니다. 이때 다른 레플리카 서버를 소스 서버로 활용하여 복제 부하를 분산시키는데 사용할 수 있습니다. 혹은 기존에 사용하던 서버를 업데이트 하거나 장비 교체할 때 사용할 수 있습니다.

4. 듀얼 소스 복제

싱글 레플리카를 두개 만들어 놓은 것이며 이는 두 서버 모두 쓰기가 가능한 형태입니다. 이방식은 트랜잭션이 충돌이 일어날 경우 복제 멈춤 현상이 일어나기 때문에 잘 사용되지 않습니다.

5. 멀티 소스 복제

하나의 레플리카 서버가 둘 이상의 소스서버를 가지며 이는 데이터를 분석 시 데이터를 모아 분석을 수행할 때 사용하게 됩니다.

장애복구

그렇다면 소스 서버에 장애가 난 경우엔 레플리카 서버를 활용하는 경우들은 살펴 보았습니다. 하지만 레플리카 서버에 문제가 생긴다면 어떻게 다시 동기화를 만들까?

1. 크레시 세이프

MySQL에선 크레시 세이프 복제 방식을 제공하고 있습니다.

1. 레플리카 서버는 I/O 쓰레드와 SQL 쓰레드를 이용하여 소스 서버에 바이너리 로그 이벤트 위치를 읽을 때와 트랜잭션 실행정보를 읽을 때 어디까지 읽었는지에 대한 포지션 정보를 로컬에 저장해 둡니다.
2. 레플리카 서버에 문제가 생겨 다시 재가동했을 시 그 정보를 기반으로 다시 소스서버에 동기화 과정을 거칩니다!

equals를 재정의한 클래스는 hashCode도 재정의 해야한다. 그렇지 않는다면 hashCode 일반 규약을 어기게 되어 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으키기 때문이다.

HashCode 규약

• equals비교에 사용되는 정보가 변경되지 않다면, 객체의 hashCode 메서드는 항상 같은 값을 반환한다.
• equals가 두 객체를 같다고 판단하면, 두 객체는 같은 hashCode를 반환한다.
• equals가 두 객체를 다르다고 판단하더라고 다른 hashCode를 반환할 필요는 없으나, 다른 값을 반환해야 해시 테이블의 성능이 좋다.

논리적으로 같은 객체는 같은 해시코드를 반환한다.

Map<PhoneNumber, String> map = new HashMap<>();
map.put(new PhoneNumber(010,1111,1111), new Person("테스트"));

이 코드에 map.get(new PhoneNumber(010,1111,1111))을 실행하면 테스트값이 아닌 null 값을 반환한다. 이유는 PhoneNumber클래스에 hashCode를 재정의 하지 않았기 때문에, 다른 해시코드를 반환하기 때문이다. hashMap은 해시코드가 다른 엔트리 끼리는 비교를 시도조차 하지 않도록 최적화 되어 있다.

좋은 해시코드를 작성하는 법은?

좋은 해시코드는 서로 다른 인스턴스 마다 다른 해시코드를 반환하는 것이 이상적인 해시 함수 이며, 32비트 정수 범위에 균일하게 분배되어야 한다.

1.int 변수인 result를 선언한 후 값을 c로 초기화한다.

• 이 때, c는 해당 객체의 첫번째 핵심 필드를 단계 2.1 방식으로 계산한 해시코드이다.
• 여기서 핵심 필드는 equals 비교에 사용되는 필드를 말한다.

2. 해당 객체의 나머지 핵심 필드인 f 각각에 대해 다음 작업을 수행한다.

• 해당 필드의 해시코드 c 를 계산한다.
  • 기본 타입 필드라면,Type.hashCode(f)를 수행한다
  • 참조 타입 필드면서, 이 클래스의 equals 메서드가 이 필드의 equals를 재귀적 호출하여 비교하면, 이 필드의 hashCode를 재귀적으로 호출한다.
  • 필드가 배열이라면, 핵심 원소 각각 별도 필드처럼 다룬다. 모든 원소가 핵심 원소라면 Arrays.hashCode를 사용한다.

주의할점

• equals 비교에 사용되지 않은 필드는 반드시 제외한다.
• 성능 향상을 위해 해시코드를 계산할 때 핵심 필드를 생랴하면 안 된다.
• 참조 타입 필드가 null일 경우 0을 사용한다.
• 31을 곱하는 이유는 홀수이면서 소수 이기 때문이다.

전형적인 hashCode 메서드

@Override
    public int hashCode() {
        int result = Integer.hashCode(areaCode);
        result = 31 * result + Integer.hashCode(prefix);
        result = 31 * result + Integer.hashCode(lineNum);
        return result;
    }

PhoneNumber 핵심 필드 3개를 이용해 간단한 계산만 수행하고, 이 과정에 비결정적 요소는 전혀 없다. -> 동치 이기 때문에 PhoneNumber 인스턴스는 서로 같은 해시코드를 가질 것이 확실하다.

핵심

equals를 재정의할 때는 hashCode를 반드시 재정의해야 하며, 그렇지 않으면 프로그램이 제대로 동작하지 않을것이며, 서로 다른 인스턴스라면 되도록 해시코드가 서로 다르게 구현해야한다.

영속성 컨텍스트는 엔티티를 영구 저장 하는 환경 이다. 영속성 컨텍스트는 애플리케이션과 DB 사이에서 객체를 보관하는 가상 DB 역할을 하며, 엔티티 매니저를 통해 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.

엔티티 생명주기

• 비영속(new/transient): 영속성 컨텍스와 전혀 관계 없는 상태

  //객체만 생성한 비영속 상태
  Member member = new Member();
  member.setId("member");
  member.setUsername("회원");

• 영속 상태: 영속성 컨텍스트에 저장된 상태

  //객체만 생성한 비영속 상태
  Member member = new Member();
  member.setId("member");
  member.setUsername(“회원”);
  EntityManager em = emf.createEntityManager();
  em.getTransaction().begin();
  //객체를 저장한 상태(영속)
  em.persist(member);

• 준영속 상태: 영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 더이상 관리하지 않으면 준영속 상태가 되며 em.datach()을 호출 하면 된다

em.persist(member);

이런 준영속 상태의 특징 으로는 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩등 영속성 컨텍스트가 제공하는 기능이 작동하지 않는다.

• 삭제 상태: 삭제된 상태

  em.remove(member);

영속성 컨텍스트 장점

1. 1차 캐시

• 영속성 내부에는 1차 캐시가 존재하며, 이는 영속 상태의 엔티티를 저장하기 때문에 엔티티 조회시 1차 캐시에 엔티티가 존재한다면 DB를 찾아보지 않는다.

2. 영속 엔티티의 동일성 보장

Member a = em.find(Member.class, "member");
Member b = em.find(Member.class, "member");

System.out.println(a==b) // true

1차 캐시로 반복 가능한 읽기 등급의 트랙잭션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공해 준다.

3. 트랜잭션을 지원하는 쓰기 지연

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
//엔티티 매니저는 데이터 변경시 트랜잭션을 시작.
transaction.begin(); // [트랜잭션] 시작

em.persist(memberA);
em.persist(memberB);
//여기까지 INSERT SQL을 데이터베이스에 보내지 않고 모아 둔다.

//커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋

em.persist()로 객체를 영속성 컨텍스트에 저장하여도 DB에 곧장 Insert 쿼리를 보내지 않는다. SQL 쿼리들을 모아둔 후 flush 될 때(영속성 컨텍스트의 변경내용을 DB에 반영할 시점) 모아둔 쿼리를 Insert 쿼리를 보낸다. 이를 쓰기 지연이라 한다. 이를 통하여 성능이 향상될 수 있다.

4. 변경 감지

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // [트랜잭션] 시작

// 영속 엔티티 조회
Member member = em.find(Member.class, "member");

// 영속 엔티티 데이터 수정
member.setName("hi");
member.setAge(10);

transaction.commit(); // [트랜잭션] 커밋

영속성 컨텍스트에서 엔티티를 조회해서 해당 엔티티를 수정한다 할 때, 조회한 엔티티를 다시 업데이트를 하지 않아도 영속성 컨텍스트내의 스냅샷과 엔티티를 비교해 변경된 엔티티가 있으면 update 쿼리를 자동 생성한다.이 Update 쿼리도 쓰기 지연이 가능하다.

5. 지연 로딩

지연로딩은 연관 관계 매핑되어 있는 엔티티를 조회 시 프록시 객체를 우선 반환하며, 실제 필요한 데이터를 쿼리를 날려 가져오는 기능이다.

플러시

플러시는 영속성 컨텍스트의 변경 내용을 DB에 반영한다. 영속성 컨텍스트의 엔티티를 지우는게 아니라 변경 내용을 DB에 동기화하는 것이다.

플러시의 흐름으로는

1. 변경 감지가 동작하여 스냅샷과 비교해서 수정된 엔티티를 찾는다.
2. 수정된 엔티티에 대해 수정 쿼리를 만들어 SQL 저장소에 등록한다.
3. 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송한다.

얼마전에 작성했던 try-with-resources의 대한 내용이 책에서도 나오는것을 보면 많이 사용되는 개념인것 같다. 앞서 　 try-with-resources 예외 처리 여기서 설명했지만 각설하고 다시 정리해보도록 하자

개요

자바의 InputStream, OutputStream, java.sql.Connection 등은 close 메서드를 통하여 자원을 닫아야 한다. 하지만 클라이언트가 놓치기 쉽고 이는 성능 문재로 이어진다. 안정망으로 finalizer를 사용한다만, 아이템 8의 내용처럼 그리 믿을만 하지 않다.

public static String firstLineOfFile(String path) throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return br.readLine();
    } finally {
        br.close();
    }
}

위 코드는 close 메서드를 이용해 자원을 해제주는 코드로 나쁘지 않아 보이지만 자원의 사용이 많아질 경우 코드가 지저분해지고 실수를 유발할 가능성이 높아진다.

public class Copy {
    static void copy(String src, String dst) throws IOException {
        InputStream in = new FileInputStream(src);
        try {
            OutputStream out = new FileOutputStream(dst);
            try {
                byte[] buf = new byte[BUFFER_SIZE];
                int n;
                while ((n = in.read(buf)) >= 0)
                    out.write(buf, 0, n);
            } finally {
                out.close();
            }
        } finally {
            in.close();
        }
    }
}

여기서 문제는 예외가 try 블록과 finally 블록 모두 발생할 수 있으나 마지막 예외가 모든 예외를 덮어 버리게 되고 이는 디버깅을 어렵게할 것이다.

try-with-resources 등장

앞선 문제들은 try-with-resources등장 이후 해결되었다.

    static String firstLineOfFile(String path) throws IOException {
        try (BufferedReader br = new BufferedReader(
                new FileReader(path))) { 
            return br.readLine();
        }
    }

이렇게 회수해야할 자원을 try 구문에 써주게 된다면 자원을 자동으로 닫아주고 앞선 덮여진 예외의 디버깅등 상당히 편리해 졌으며, 숨겨진 예외의 경우도 무시가 되지 않고 숨겨졌다는 메시지로 출력된다.

자바에서 두 가지 객체 소멸자인 finalizer과 cleaner를 제공한다. 하지만 이를 사용하는 것은 지양해야한다. 자바 9 에서 finalizer은 deprecated 되었고, clenaner가 대안으로 나왔으나 여전히 예측할 수 없고, 느리며, 불필요 하다.

예측 불가능성 문제

public class FinalizerTest {

    @Override
    protected void finalize() throws Throwable {
        System.out.println("Clean test");
    }

    public void test() {
        System.out.println("test");
    }
}
public class Main {

    public static void main(String[] args) throws InterruptedException {
        new Main().run();
        Thread.sleep(100);
    }

    private void run() {
        FinalizerTest finalizerTest = new FinalizerTest();
        finalizerTest.test();
    }
}

FinalizerTest의 인스턴스에 대한 GC(가비자 컬렉터)가 수행될때 "Clean test"라는 문자열을 출력되도록 finalize 메서드를 오버라이드 한 후 Main 클래스를 실행 해보자.

예상해 본다면 run 메서드가 종료되면 FinalizerTest의 인스턴스 참조가 존재하지 않기에 GC가 실행되어 0.1초 기다리는 사이에 "Clean test"가 출력되어야 한다.

하지만 실제 finalize 메서드는 호출되지 않는다.

자바 언어 명세는 어떤 스레드가 finalizer나 cleaner의 수행 시점뿐 아니라 수행 여부조차 보장하지 않는다.

그렇기에 상태를 영구적으로 수정하는 작업에서는 더욱이 finalizer나 cleaner의 사용을 지양하여야 한다.

사용지양의 이유

• 성능 문제

  • 간단한 AutoCloseable 객체를 생성하고 가비지 컬렉터가 수거시와 finalizer을 사용한 객체 생성 파괴를 살펴보면 무려 50배가 느리다. 이는 finalizer가 가비지 컬렉터의 효율을 떨러어뜨리기 때문이다.

• 보안 문제

  • finalizer은 생성자나 직렬화 과정에서 예외가 발생하면, 생성되다 만 객체에서 악의적인 하위 클래스의 finalizer가 수행될 수 있게 된다. 이는 절대 일어나설 안되는 일이다. 다른 객체 생성 방지로는 생성자에 예외를 던지면 되지만finalizer은 그것을 방해한다.

그렇담 언제 사용하는가?

1. 안정망 역할

cleaner나 finalizer가 즉시 호출되지 않을순 있지만, 클라이언트가 하지 않은 자원 회수를 늦게라도 해주는 것이 안전하다. 대표적으로 FileInputStrean, FileOupputStrea, ThreadPoolExecutor가 있다.

2. 네이티브 피어 정리

네이티브 객체는 일반적인 객체가 아니라서 GC가 그 존재를 모른다. 따라서 네이티브 피어가 들고 있는 리소스를 Cleaner나 Finalizer를 사용해서 해당 자원을 반납할 수도 있다.

하지만 이는 해당 자원이 중요하지 않거나, 성능상 영향이 크지 않다면 사용해야 한다.

C,C++ 와는 다르게 자바에서는 GC(가비지 컬렉터)을 통해 메모리를 회수해 가지만. 그렇다고 메모리 관리를 하지 않아도 된다고 오해해서는 절대 안된다

메모리 누수

public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        this.elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }
    public void push() {
        ensureCapacity();
        elements[size++] = e;
    }
    public Object pop() {
        if (size == 0) throw new EmptyStackException();
        return elements[--size];
    }
    // 공간이 부족할 시 2배로 공간을 확장한다.
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

간단한 스택을 구현한 코드이다. 특별한 문제는 없어 보이지만, 이스택을 사용하는 프로그램을 오래 실행하다 보면 가비지 컬렉션 활동과 메모리 사용량의 증가로 성능이 저하할것 이며, 심할 경우 OutOfMemoeryError을 일으킬 것이다.

그 이유는 pop 메서드를 통해 특정 객체를 꺼내 사용하여 메모리를 해제하는것이 아니라 push 메서드 사용시 그 위치에 덮어 씌우는 방식으로 프로그래밍 되어 있기 때문이다.

가비지 컬렉터의 경우 객체 참조를 살려두면 그 객체가 참조하는 모든 객체를 회수해가지 않는다. 그렇기 때문에 배열에서 참조 해제 시켜주지 않는다면 메모리 누수가 일어날 것이다.

참조 해제

그렇다면 이런 코드의 참조 해제 방법은 무엇이 있냐면

1. 다 쓴 참조에 null처리

public Object pop() {
    if (size == 0) throw new EmptyStackException();

    Object result = elements[--size];
    elements[size] = null;
    return result;
}

위처럼 다 쓴 참조를 null 처리를 함으로 써, 메모리 누수가 없는 코드를 완성할 수 있다. 그거 의외의 이점으로, 만약 null 처리한 참조를 실수로 사용하려 하면 프로그램은 즉시 NullPointerException을 발생시켜 종료 시킬 것이다.

하지만 이는 코드를 필요 이상으로 더럽힐 것이다. 그렇기에 null 처리하는 일은 예외적인 경우여야 한다.

2. 유효 범위 처리

다 쓴 참조 해제중 가장 좋은 방법은 참조를 담은 변수를 유효 범위 밖으로 밀어내는 것이다.

마무리

이외에도 캐시, 리스너, 콜백의 경우에도 메모리 누수를 발생시킬 것이다. 따라서 이런 메모리 사용시 꼭 사용 해제를 해주어야 한다.

메모리 누수는 수년간 시스템에 잠복하는 경우도 있다. 이런 누수는 철저한 코드 리뷰나 힙 프로파일러 같은 디버깅 도구를 동원하여 발견되기도 한다. 그렇기에 이런 예방법을 익혀두는 것이 중요할 것이다.

new String() 사용하는 경우

String a = new String("test");
String b = new String("test");
String c = new String("test");

문자열 a,b,c는 결국 동일한 "test"라는 문자열을 가지군다. 하지만 실행될때 마다 String 인스턴스를 새로 만들어 버린다. 이렇게 되면 메모리를 할당하기 때문에 낭비가 발생되어 버린다.

그렇기 때문에 문자열 리터럴을 사용하여 이러한 메모리 낭비를 줄여야 한다.

String a = "test";
String b = "test";
String c = "test";

String.matches()의 사용

public static boolean isRomanNumeral(String s) {
    return s.matches("^(?=.)M*(C[MD]|D?C{0,3})(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
}

이러한 String.matches()는 정규표현식으로 문자열 형태를 확인하는 가장 쉬운 방법이지만, 성능이 중요한 상황에선 반복하여 사용하기 어렵다. 왜냐하면 내부에서 만드는 정규 표현식용 Pattern 인스턴스는, 한 번 쓰고 버려지기에 가비지 컬렉션 대상이 되기 때문이다. 성능 개선을 하려면 불변 인스턴스를 클래스 초기화시 캐싱해두고 메서드 호출시 인스턴스를 재사용하면 된다.

public class RomanNumerals {

    private static final Pattern ROMAN = Pattern.compile(
        "^(?=.)M*(C[MD]|D?C{0,3})(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");

    public static boolean isRomanNumeral(String s) {
        return ROMAN.matcher(s).matches();
    }
}

개선시 속도도 빨라지고 static final 필드로 이름도 정하기 때문에 코드의 의미가 잘 드러난다.

주의사항

클래스가 초기화된 후 이 메서드를 사용하지 않는 다면 ROMAN 필드는 쓸데없이 최기호가 된것이다.

어댑터는 뒷단 객체에 위임하고, 자신은 제2의 인터페이스 역할을 해주는 객체이다. 어댑터는 뒷단 객체만 관리하면 되므로 객체 하나당 어댑터 하나씩만 만들어 주면된다.

예를 들어 Map 인터페이스의 KeySet 메서드는 Map 객체 안의 키 전부를 담은 Set뷰를 반환한다. 사용자는 KeySet을 호출할 때마다 새로운 Set 인스턴스를 반환한다 생각할 수 있지만. 가변 반환된 Set 인스턴스를 반환한다.

즉 반환된 객체 중 하나를 수정하면 모든 객체가 바뀐다. 모두 똑같은 Map 인스턴스를 대변하기 때문이다. 이러한 이유로 KeySet이 뷰 객체를 여러 개 만들어도 상관 없지만, 그럴 필요도 없고 이득도 없다.

Map<String, Integer> map = new HashMap<>();
map.put("A", 1);
map.put("B", 2);

// 두 개의 KeySet 뷰를 얻습니다.
Set<String> keySet1 = map.keySet();
Set<String> keySet2 = map.keySet();

// keySet1을 수정하면 실제 맵도 수정됩니다.
keySet1.add("C");

System.out.println(map); // 출력 결과: {A=1, B=2, C=null}

이런것 처럼 Set뷰는 실제 맵의 키를 복제 하지 않고, Map 인스턴스를 대변하는 Set 뷰 객체가 생성되기에 Map 자체가 수정되어 버린다. 이는 동일한 맵 인스턴스를 참조하기 때문이다.

오토 박싱

오토박싱은 기본 타입과 박싱된 기본 타입을 섞어 쓸 때 자동으로 상호 변환해 주는 기술이다. 하지만 오토박싱은 기본 타입과 그에 대응하는 박싱된 기본 타입의 구분을 흐리게 할뿐 완전히 없애주는 것이 아니다.

public static long sum() {
    Long sum = 0L;
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    return sum;
}

이 코드는 정확한 답을 내기는 하나, 성능적으로는 상당히 비효율적인 코드이다.

sum 타입은 Long타입이고, i는 long 타입이다. 반복문을 돌면서 sum에 더해질때 마다 새로운 Long 인스턴스를 만들게 되며 이는 불필요한 인스턴스가 늘어난게 되며 속도가 느려지게 된다.

박싱된 기본 타입 보다는 기본 타입을 사용하고, 의도 치 않은 오토박싱이 숨어 들지 않도록 하자.

오해하지 말아야 한다.

"객체 생성은 비싸니 피해야 한다"라고 오해하면 안된다. 특히 요즘 JVM은 작은 객체를 생성하고 회수하는 일이 크게 부담되지 않는다. 그렇기 때문에 명확성, 간결성, 기능을 위해 객체를 추가로 생성하는 것이라면 좋은것 이라고 할 수 있다. 그러므로, 데이터베이스 연결과 같은 생성 비용이 비싼 경우를 제외 하면, 커스텀 객체 풀을 만들지 않아야한다.

마지막으로 방어적 복사가 필요한 상황에서 객체를 재사용 했을때의 피해가, 필요 없는 객체를 반복 생성했을 때의 피해보다 훨씬 크다는 것을 기억하자. 반복 생성의 부작용은 코드 형태와 성능에만 영향을 주지만, 방어적 복사가 실패하면 버그와 보안 문제로 직행한다.

public class ImmutableClass {
    private List<String> items;

    public ImmutableClass(List<String> items) {
        // 외부에서 전달된 리스트를 복사하여 내부에 저장합니다.
        this.items = new ArrayList<>(items);
    }

    public List<String> getItems() {
        // 내부 리스트를 그대로 반환합니다.
        return items;
    }
}

public class Client {
    public static void main(String[] args) {
        List<String> originalList = new ArrayList<>();
        originalList.add("Item 1");
        originalList.add("Item 2");

        ImmutableClass immutableObj = new ImmutableClass(originalList);

        // 클라이언트가 내부 리스트에 직접 접근하여 수정하려고 시도합니다.
        List<String> internalList = immutableObj.getItems();
        internalList.add("Item 3");

        // 원래 의도대로 불변 객체인 immutableObj를 수정하려는 시도이지만, 내부 리스트도 변경됩니다.
        System.out.println(immutableObj.getItems()); // 출력 결과: [Item 1, Item 2, Item 3]
    }
}

클래스가 하나 이상의 자원에 의존하고, 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.이 자원들을 클래스가 직접 만들게 해서도 안 된다. 대신 필요한 자원을 생성자에 넘겨주자. 의존 객체 주입이라 하는 이 기법은 클래스의 유연성, 재사용성, 테스트 용이성을 개선해준다.

예제

정적 유틸리티를 잘못 사용한 예

public class SpellChecker {

    private static final Lexicon dictionary = new Lexicon();

    private SpellChecker() {
    }

    public static boolean isValid(String word) {
        ...
    }

    public static List<String> suggestions(String typo) {
      ....
    }
}

해당 유틸리티 클래스는 사전을 하나만 사용한다고 가정하고 이 있다. 하지만 실제에서는 사전이 언어별 따로 있고 특수 어휘용 사전을 따로 두는 경우도 있다.

싱글턴을 잘못 사용한 예

public class SpellChecker {

    private final Lexicon dictionary = new Lexicon();

    public static SpellChecker INSTANCE = new SpellChecker();

    private SpellChecker() {
    }

    public static boolean isValid(String word) {
        ...
    }

    public static List<String> suggestions(String typo) {
        ...
    }
}

싱글턴 방식에서도 마찬가지 사전을 하나만 사용한다고 가정하기에 앞선 단점이 발생한다.

해결책

final 한정자를 제거

public class SpellChecker {

    private Lexicon dictionary = new Lexicon();

    public static SpellChecker INSTANCE = new SpellChecker();

    private SpellChecker() {
    }

    public static void changeDictionary(Lexicon dictionary) {
        this.dictionary = dictionary;
    }

    public static boolean isValid(String word) {
        ...
    }

    public static List<String> suggestions(String typo) {
        ...
    }
}

dictionary 필드에서 final 한정자를 제거하고 다른 사전으로 교체하는 메서드를 추가하였다. 하지만 이방식은 오류를 내기 쉬우며 멀티스레드 환경에서는 사용할 수 없다.

의존 객체 주입 방식

public class SpellChecker {

    private final Lexicon dictionary;

    public SpellChecker(Lexicon dictionary) {
        this.dictionary = dictionary;
    }

    public static boolean isValid(String word) {
        ...
    }

    public static List<String> suggestions(String typo) {
        ...
    }
}

의존 객체 주입을 사용한 코드는 위에 예는 처럼 dictionary라는 하나의 자원만 사용하지만, 자원이 몇 개가되든 잘 작동한다. 또한 불변을 보장하여 여러 클라이언트가 의존 객체들을 공유할 수 있는 장점이 있다. 의존 객체 중비은 생성자, 정적 팩터리, 빌더 모두 똑같이 응용이 가능하다.

의존 객체 주입은 생성자에 자원 팩터리를 넘겨주는 방식도 종종 사용된다. 팩터리란 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어 주는 객체를 말한다. 이러한 방식을 팩터리 메서드 패턴이라고 한다.자바 8에서 ** Supplier< T >**가 완벽한 예시이다.

public static List<Test> create(Supplier<? extends Test> generator) {
    ...
}

일반적으로 한정적 와일드카드 타입을 사용하여 팩터리의 타입 매개 변수를 제한한다. 이 방식을 사용해 클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든 생성할 수 있는 팩터리를 넘길 수 있다.

의존 객체 주입은 유연성과 테스트 용이성을 개선해주지만, 의존성이 수천 개나 되는 큰 프로젝트에서는 코드가 상당히 방대해지고 어지러워 진다. 이런 경우 의존 객체 주입 프레임워크(Dagger, Guice, Spring)을 사용하여 이러한 문제를 해결할 수 있다.

정적 메서드와 정직 필드만을 담은 클래스를 만들고 싶을 때가 있다. 예를 들어 java.lang.Math, java.util.Arrays 처럼 기본 타입 값이나 배열 관련 메서드들을 모아 놓을 수 있다. 혹은 java.util.Collections처럼 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드를 모아놓을 수 있다.

이렇나 유틸리티 클래스는 인스턴스 변수나 메서드가 없어도 사용할 수 있다. 하지만 사용자는 생성자가 자동 생성된 것인지 구분할 수 없다.

이를 막기 위해 추상 클래스로 만드는 경우가 있는데 추상 클래스로는 인스턴스화를 막을 수 없다. 하위 클래스를 만들어 인스턴스화 하면 그만이기 때문이다.

public abstract class Parents {

    public static void talk(String message) {
        System.out.println(message);
    }
}

public class Child extends Parents {

    public Student() {
        super();
    }
}

그렇기 때문에 유틸리티 클래스의 인스턴스화를 막기 위해서는 생성자의 접근 제어자를 private으로 만들어주어야 한다.

public abstract class Parents {
    private Parents() {
        throw new AssertionError();
    }

    public static void talk(String message) {
        System.out.println(message);
    }
}

명시적 생성자가 private이니 클래스 바깥에스는 접근할 수 없다. 이러한 private 생성자는 직관적이지 않기에 적절한 주석을 다는 것이 좋다. 또한 private으로 선언 하면서 하위 클래스가 상위 클래스의 생성자에 접근할 길이 막히기 때문에 상속을 불가능하게 하는 효과도 있다.

싱글턴 이란?

싱글턴이란 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말한다. 싱글턴의 전형적인 예로는 함수와 같은 무상태 객체, 설계상 유일한 시스템 컴포넌트를 말한다. 하지만 싱글턴 클래스는 타입을 인터페이스로 정의하고 그것을 구현체로 정의한 것이 아니라면 테스트하기 어려워질 수 있다.

싱글턴 생성 방식

1. public static final 필드 방식

public class Elvis {

    public static final Elvis INSTANCE = new Elvis();

    private Elvis() {
        ...
    }

    public void leaveTheBuilding() {
        System.out.println("elvis");
    }
}

private 생성자는 public static final 필드인 Elvis.INSTANCE를 초기화할 때 딱 한번만 호출 된다. 예외는 단 한가지, 권한이 있는 클라이언트는 리플렉션 API인 AccessibleObject.setAccessible을 사용해 private 생성자를 호출할 수 있는데, 이렇나 공격을 방어하려면 생성자를 수정하여 두번째 객체가 생성되려 할 때 예외를 던져 막을 수 있다.

장점

• 해당 클래스가 싱글턴임이 API에 명백히 드러남
• 간결함

2. 정적 팩터리 방식

public class Elvis {

    private static final Elvis INSTANCE = new Elvis();

    private Elvis() {
        ...
    }

    public static Elvis getInstance() {
        return INSTANCE;
    }

    public void leaveTheBuilding() {
        System.out.println("elvis");
    }
}

Elvis.getInstance는 항상 같은 객체의 참조를 반환하므로 Elvis의 유일한 인스턴스임을 보장한다.

장점

• API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있다.
  - 스레드별 다른 인스턴스를 넘기게 하기
• 제네릭 싱글턴 팩터리 메서드로 변경할 수 있다.
• 정적 펙터리 메서드 참조를 공급자로 사용할 수 있다.
  - Elvis::getInstance를 대신해 Supplier < Elvis>로 사용할 수 있다.

3. 열거 타입 사용법

public enum Elvis {

    INSTANCE;

    public void leaveTheBuilding() {
        System.out.println("elvis");
    }
}

가장 바람직한 방식은 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 것이 가장 좋은 방법이다. public 필드 방식과 비슷하지만 간결하고, 직렬화 상황이나 리플렉션 공격에도 방어가 가능하다.

단, 만드려는 싱글턴이 Enum외의 클래스를 상속해야 한다면 이방법은 사용할 수 없다.

싱글턴 클래스를 직렬화할 때 주의할 것

첫 번째, 두 번째로 만든 싱글턴 클래스를 직렬화 하려면 단순히 Serializable을 구현하는 것 외, 인스턴스 필드를 일시적 이라고 선언하고, readResolve 메서드를 제공해야만 한다.

private Object readResolve throws ObjectStreamException {
    return INSTANCE;
}

정적 팩터리와 생성자에는 선택적 매개변수의 수가 많을 때 대응하기가 어렵다. 이럴 때 점증적 생성자 패턴을 사용할 수 있다.

public class NutritionFacts {

    private final int servingSize;

    private final int servings;

    private final int calories;

    private final int fat;

    private final int sodium;

    private final int carbohydrate;

    public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium, int carbohydrate) {
        this.servingSize = servingSize;
        this.servings = servings;
        this.calories = calories;
        this.fat = fat;
        this.sodium = sodium;
        this.carbohydrate = carbohydrate;
    }

    public NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0, 0, 0, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories) {
        this(servingSize, servings, calories, 0, 0, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories, int fat) {
        this(servingSize, servings, calories, fat, 0, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium) {
        this(servingSize, servings, calories, fat, sodium, 0);
    }
}

하지만 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기가 매우 어렵다.

자바 빈즈 패턴

public class NutritionFactsWithJavaBeansPattern {

    private int servingSize = -1; // 필수. 기본 값 없음.

    private int servings = -1; // 필수. 기본 값 없음.

    private int calories;

    private int fat;

    private int sodium;

    private int carbohydrate;

    public void setServingSize(int servingSize) {
        this.servingSize = servingSize;
    }

    public void setServings(int servings) {
        this.servings = servings;
    }

    public void setCalories(int calories) {
        this.calories = calories;
    }

    public void setFat(int fat) {
        this.fat = fat;
    }

    public void setSodium(int sodium) {
        this.sodium = sodium;
    }

    public void setCarbohydrate(int carbohydrate) {
        this.carbohydrate = carbohydrate;
    }
}

자바빈즈 패턴은 매개변수가 많더라도 인스턴스를 쉽게 만들 수 있다. 하지만 setter 메서드를 통한 반복적인 메서들 호출과, 객체가 온전히 완성되지 않았다면 일관성이 깨질 수 있다. 이는 클래스를 불변으로 만들 수 없는 문제가 생긴다.

빌더 패턴

점층적 생성자 패턴의 안전성과 자바 빈즈 패턴의 가독성을 겸비한 빌더 패턴을 주로 사용한다. 클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수 만으로 생성자를 호출해 빌더 객체를 얻는다. 이후 빌더 객체가 제공하는 세터 메서드들로 원하는 선택 매개변수를 설정하고, 매개변수가 없는 build() 메서드를 호출해 필요한 객체를 얻는다.

public class NutritionFactsWithBuilderPattern {

    private final int servingSize;

    private final int servings;

    private final int calories;

    private final int fat;

    private final int sodium;

    private final int carbohydrate;

    private NutritionFactsWithBuilderPattern(Builder builder) {
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }

    public static class Builder {

        private final int servingSize;

        private final int servings;

        private int calories;

        private int fat;

        private int sodium;

        private int carbohydrate;

        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

        public Builder calories(int val) {
            calories = val;
            return this;
        }

        public Builder fat(int val) {
            fat = val;
            return this;
        }

        public Builder sodium(int val) {
            sodium = val;
            return this;
        }

        public Builder carbohydrate(int val) {
            calories = val;
            return this;
        }

        public NutritionFactsWithBuilderPattern build() {
            return new NutritionFactsWithBuilderPattern(this);
        }
    }
}

NutritionFactsWithBuilderPattern 클래스는 불변하며, Builder의 Setter 메서들은 빌더 자신을 반환하기 때문에 연쇄적 호출이 가능하다. 이런 방식은 API 혹은 메서드 연쇄라고 한다.

NutritionFactsWithBuilderPattern nutritionFacts = 
    new NutritionFactsWithBuilderPattern.Builder(240, 8)
        .calories(100)
        .sodium(35)
        .build();

클러이언트는 빌더 패턴을 통해 코드를 읽기,쓰기 작업들을 편하기할 수 있다.

빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰기 좋다.

public abstract class Pizza {

    public enum Topping {
        HAM, MUSHROOM, ONION, PEPPER, SAUSAGE
    }

    final Set<Topping> toppings;

    Pizza(Builder<?> builder) {
        toppings = builder.toppings.clone();
    }

    abstract static class Builder<T extends Builder<T>> {

        private EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);

        public T addTopping(Topping topping) {
            toppings.add(topping);
            return self();
        }

        abstract Pizza build();

        protected abstract T self();
    }
}

Pizza.Bulder 클래스는 재귀적 타입 한정을 이용하는 제네릭 타입이다. 추상 메서드인 self를 더해 하위 클래스에서는 형변환하지 않고도 메서드를 연쇄를 지원할 수 있다. 하위 클래스에서는 이 추상 메서드의 반환값을 자기 자신을 주면 된다. Pizza를 상속받는 뉴욕 피자와 칼초네 피자를 보며 좀더 살펴보자

public class NyPizza extends Pizza {

    public enum Size {
        SMALL, MEDIUM, LARGE
    }

    private final Size size; // 필수 매개변수

    private NyPizza(Builder builder) {
        super(builder);
        size = builder.size;
    }

    public static class Builder extends Pizza.Builder<Builder> {

        private final Size size;

        public Builder(Size size) {
            this.size = size;
        }

        @Override
        NyPizza build() {
            return new NyPizza(this);
        }

        @Override
        protected Builder self() {
            return this;
        }
    }

}

public class CalzonePizza extends Pizza {

    private final boolean sauceInside; // 선택 매개변수

    private CalzonePizza(Builder builder) {
        super(builder);
        sauceInside = builder.sauceInside;
    }

    public static class Builder extends Pizza.Builder<Builder> {

        private boolean sauceInside = false;

        public Builder sauceInside() {
            sauceInside = true;
            return this;
        }

        @Override
        CalzonePizza build() {
            return new CalzonePizza(this);
        }

        @Override
        protected Builder self() {
            return this;
        }
    }
}

각 하위 클래스의 빌더가 정의한 build()를 통해 하위 클래스를 반환하고 있다. NYPizza.builder는 NyPizza를 반환하고, Calzone.Builder는 Calzone 피자를 반환하다는 것이다. 하위 메서드가 상위 클래스의 메서가 반환한 타입이 아닌, 그 하위 타입을 반환하는 기능을 공변 반환 타이핑이라고 한다. 이 기능 사용하면 클라이언트가 형변환을 할 필요가 없다.

NyPizza nyPizza = new NyPizza.Builder(Size.SMALL)
    .addTopping(Topping.SAUSAGE).addTopping(Topping.ONION).build();

CalzonePizza calzonePizza = new CalzonePizza.Builder()
    .addTopping(Topping.HAM).sauceInside().build();

클라이언트 입장에서 Pizza의 enum과 각 하위 클래스의 enum(열거형)을 혼용할 수 있 있다. 이러한 빌더 패턴은 매우 큰 유연성을 가져다 준다.

빌더 패턴 단점

1. 빌더 객체의 생성
2. 매개변수가 적을시 용이하다.
3. 코드의 장황함.

결론

생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하자.

프로젝트를 진행하면서 요약하자면 파일 다운로드 하는기능을 만들다가 오류가 발생했는데 디버깅 하기가 쉽지 않았다 그저 close()에서 오류가 발생했다고만 나오고 자세히 기술되어 나오지 않았기 때문이다. 대략적인 코드이다

  try  {
           File file = new File( "/test" );
           dataByte = new byte[(int) file.length()];
           fileInputStream = new FileInputStream(file);
           fileInputStream.read(dataByte);
        } catch (Exception e) {
           throw new UnknownException("Unknown Exception", e);
        } finally {
           fileInputStream.close();
        }

그래서 try-with-resources으로 바꾸었고 try-with-resources가 무엇인지 알아보자.

1. try-catch-finally란?

Java7 이전의 try-catch-finally

사용 후에 반납해주어야 하는 자운들은 Closable 인터페이스를 구현하고 있으며, 사용 후에 close 메소드를 호출해 주어야 했다. 앞선 코드에서는 파일을 다운 받는 경우로 예시를 들었었다. 문제는 이렇나 과정에서 여러가지 단점을 가지고 있다.

• 자원 반납에 의해 코드가 복잡해진다.
• 실수로 인한 자원반납 코드의 부재
• 에러로 인한 자원 반납하지 못하는 경우
• 디버깅의 어려움

Java7 이후 try-with-resources

Java는 이렇나 문제점을 해결하기 위해 자원을 자동 반납해주는 try-with-resources 문법을 추가했다. Java는 AutoCloseable 인터페이스를 구현하고 있는 자원에 대해 try-with-resources를 적용 가능하도록 만들었고, 이를 사용함으로써 코드의 유연함과 에러를 잡는 효과를 만들었다.

  try (FileInputStream fileInputStream = new FileInputStream(file)) {
             File file = new File( "/test" );
           dataByte = new byte[(int) file.length()];
           fileInputStream = new FileInputStream(file);
           fileInputStream.read(dataByte);
            }
        }

Closeable의 AutoCloseable 상속

close()를 따라가보면 기존의 Closeable에 부모 인터페이스로 AutoClosable을 추가한것을 볼 수 있다. 이는 기존 부모 인터페이스에 AutoClosable을 새롭게 추갛나 것이다. 보편적으로 먼저 만들어진 인터페이스를 자식 구현체에서 사용하는것이 일반적이다. 하지만 먼저 만들어진 Closable 인터페이스에 부모 AutoCloesable을 추가하면서 하위 호환성을 달성 시키며 변경 작업에 대한 수고를 덜었다. 만약 반대의 경우 Closeable을 부모로 만들고 진행하였다면 기존 상속받은 클래스들 모두 AutoClosable을 구현하도록 수정이 필요했을 것이다.

2. try-with-resources을 권장해야 하는 이유

에러 스택 트레이스의 누락

try-catch-finally를 이용하면 개요에서 설명한것 처럼 에러 스택 트레이스가 누락되는 경우가 발생할 수 있다. 이로인해 디버깅을 통한 오류 파악이 매우 어렵게 만든다. 예를 들어 AutoCloseable을 구현채를 만들어 보자

public class TestResource implements AutoCloseable {

    @Override
    public void close() throws RuntimeException{
        System.out.println("Test close");
        throw new Exception();
    }

    public void print() {
        System.out.println("print");
        throw new Exception();
    }
}

클래스를 살펴 보자면 print와 close 호출시 Exception을 발생시킨다. 이제 try-catch-finally와 try-with-resources로 테스트를 해보자

try-catch-finally로 구현

try-catch-finally로 자원을 반납하는 코드를 구현해보자

public void test() {
    TestResource testResource  = null;

    try {
        testResource = new TestResource();
        testResource.print();
    } finally {
       testResource.close();
    }
}

문제는 이코드를 실행하면 앞선 설명처럼 close 호출 시에 에러만 찍힌다는 것이다

try-with-resources로 구현

이번에는 try-with-resource로 구현해보자.

public void test() {
    try (TestResource testResource = new TestResource()) {
        testResource.print();
    }
}

이경우에는 print와 close 모두에 에러 트레이스가 남게 된다. 이런 에러 트레이스가 잘남는 다는것은 에러에대한 원인파악을 한층더 편하게 해준다. 또한 코드 자체도 finally로 close를 하지 않아도 자동으로 자원을 반납하기 때문에 close()를 실수로 호출하지 않아 생기는 문제도 미연에 방지할 수 있다.

정리하자면 다음과 같은 이유로 try-with-resources를 사용을 적극 권장한다.

• 코드의 간결함
• 번거로운 자원 반납 작업의 간소화
• 모든 에러에 대한 스택 트레이스를 남김으로써 디버깅의 간소화

이러한 이유들로 앞으로는 자원을 반납하는 경우를 만나면 try-with-resources를 적극 사용하자.

일반적으로 클래스의 인스턴스를 얻는 방법으로는 public 생성자다.

public class Product {
    private String name;

    private int price;

    private String description;

    private ProductStatus productStatus;

    public Product(String name, int price, String description, ProductStatus productStatus){
        this.name = name;
        this.price = price;
        this.description = description;
        this.productStatus = productStatus;
    }


}

public enum ProductStatus{
    WAITING,
    RELEASE,
    DISCONTINUE
}

일반적인 클래스에선 public 생성자만응로도 충분히 생성이 가능하지만, 생성자 외에 정적 팩터리 메서드를 제공하면 사용자 입장에서 의도한 대로 인스턴스를 만들기 쉬워지는 경우가 종종 있다.

정적 팩터리 메서드의 대표적인 예시는 Boolean의 valueOf() 메서드가 있다.

public static Boolean valueOf(boolean b){
    return b ? Boolean.TRUE : Boolean.FALSE;
}

메서드는 기본 타입인 boolean값을 받아와 Boolean 객체로 만들어 반환하고 있다.

정적 팩터리 메서드의 장점

이름을 가질 수 있다.

책 에서는 BinInteger(int, int, Random)과 정적 팩터리 메서드인 BigInteger.probablePrime중 어느 쪽이 '값이 소수인 BigInteger를 반환하다'는 의미인지 생각해 보라고 한다. 앞서 작성한 public 생성자 코드를 예로 예제를 만들어 보자면

만약 Product클래스의 메인 생성자인 (name, price, description, productStatus)만 보고 어떤 특성을 가진 Product인지 파악하기 어렵다.

또한, 하나의 시그니처로는 하나의 생성자를 만들 수 있는데, 정적 팩터리 메서드는 이름을 가질 수 있으므로 하나의 시그니처로 여러 개의 정적 팩터리 메서드를 만들어 인스턴스를 반환할 수 있다.

public class Product {
    private String name;

    private int price;

    private String description;

    private ProductStatus productStatus;

    public Product(String name, int price, String description, ProductStatus productStatus){
        this.name = name;
        this.price = price;
        this.description = description;
        this.productStatus = productStatus;
    }

    public static Product waitingMember(String name, int price, String description) {
        return new Product(name, price, description, ProductStatus.WAITING);
    }

    public static Product releaseMember(String name, int price, String description) {
        return new Product(name, price, description, ProductStatus.RELEASE);
    }

    public static Product discontinueMember(String name, int price, String description) {
        return new Product(name, price, description, ProductStatus.DISCONTINUE);
    }

}

public enum ProductStatus{
    WAITING,
    RELEASE,
    DISCONTINUE
}

위와 같은 생성자로 ProductStatus를 구분하는 것보단 같은 행위를 가진 여러개의 정적 팩터리 메서드를 만들면, 사용자 입장에선 혼동의 여지 없이 특정 상태의 Product 인스턴스를 생성할 수 있게 된다.

호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.

public static Boolean valueOf(boolean b){
    return b ? Boolean.TRUE : Boolean.FALSE;
}

Boolean의 valueOf() 메소드는 인스턴스를 미리 캐싱해뒀다가 반환해 주는 것을 알 수 있다. 이러한 생성 비용이 큰 객체가 자주 요청되는 상황이라면 성능을 상당히 높여줄 수 있고, 플라이웨이트 패턴도 이와 비슷한 기법으로 볼 수 있다.

반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.

  String[] strs = {"alpha", "beta", "charlie"};
  List<String> lst = Arrays.asList(strs);

해당 코드는 간단하게 문자열 배열을 list로 변환하는 코드이 이다 이런 Arrays유틸 클래스의 asList() 메서드를 사용해본 적이 있다면 해당 장점을 이해할 수 있을 것이다.

public static <T> List<T> asList(T... a) {
   return new ArrayList<>(a);
}

실제 asList 구현 코드를 확인하면 List의 하위 구현체인 ArrayList로 값을 래핑하여 반환하는데, 이때 사용자는 이러한 구현체까지 알 필요가 없다. 즉 반환 객체의 클래스를 자유롭게 선택할 수 있다는 유연성은 개발자가 구현체를 공개하지 않고 구현체를 반환할 수 있기에 API를 작게 유지할 수 있다.

입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.

반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없다. 이점은 파라미터의 값에 따랄 다른 하위 타입을 반환할 수 있도록 한다. 만약 어떤 값에 따라 ProductStatus를 반환하고 싶다면, 정적 팩터리를 만들고 그 안에 비교 로직을 세우면 될 것이다.

public enum ProductStatus{
    WAITING(0,30),
    RELEASE(31,60),
    DISCONTINUE(61,100);

    private final int min;
    private final int max;

    ProductStatus(int min,int max){
        this.min = min;
        this.max = max;
    }

    public static ProductStatus of(int num){
        return Arrays.stream(values())
                .filter(checkProductStatus(num))
                .findFirst()
                .orElseThrow(()-> new NoSuchElementException("해당 ProductStatus를 찾을 수 없습니다."))
    }

    private static Predicate<ProductStatus> checkProductStatus(int num){
        return ele -> ele.min <= num && ele.max >= num;
    }
}

정적 팩토리 메서드 단점

상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.

하지만 이 제약은 상속보다 컴포지션을 사용하도록 유도하고 불변 타입으로 만드려면 이 제약을 지켜야 하기에 오히려 장점으로 받아들일 수 도있다.

정적 팩터리 메서드는 프로그래머가 찾기 어렵다.

생성자 처럼 API 설명에 명확히 드러나지 않기에 사용자는 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야 한다. 그렇기 때문에 API 문서를 잘 써놓고 메서드 이름도 널리 알려진 규약을 사용하여 문제를 완화하여야 한다.

정적 팩터리 메서드 명명 방식

1. form : 매개변수를 하나 받아서 인스턴스 반환하는 형변환 메서드 ex) Date d = Date.from(instant)
2. of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환 집계 메서드 ex) Set faceCards = EnumSet.of(JACK, QUEEN, KING);
3. valueOf : from과 of의 더 자세한 버전 ex) BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);
4. instance 혹은 getInstance : instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다. ex) StackWalker luke = StackWalker.getInstance(options);
5. create 혹은 newInstance : 매개변수를 하나 받아서 인스턴스 반환하는 형변환 메서드 ex) Object newArray = Array.newInstance(classObject, arraylen);
6. getType : getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩토리 메소드를 정의할 때 쓴다. ex) FileStore fs = Files.getFileStore(path);
7. newType : newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩토리 메소드를 정의할 때 쓴다. ex) BufferedReader br = Files.newBufferedReader(path);
8. type :getType과 newType의 간결한 버전 ex) List litany = Collections.list(legacyLitany);