Dev.Oh | Feed

Statement와 PreparedStatement

Fri, 04 Mar 2022 00:00:00 GMT

Statement

일반적인 쿼리(Statement)를 만들어 실행하면 쿼리 분석, 컴파일, 실행 단계를 거치게 된다.
그러다보니 매번 쿼리를 실행할 때마다 반복적으로 단계를 거치게 되어 성능이 떨어질 수 있다.
뿐만 아니라 애플리케이션에서 제공해주는 라이브러리(java는 jdbc)에서 Statement를 사용해서 쿼리를 작성할 경우 파라미터로 들어가는 곳에 "or 1 = 1" 과 같은 것을 삽입하여 모든 정보를 가져오거나 테이블을 통째로 날려버리는 등의 SQL Injection 공격에 취약해지게 된다.

PreparedStatement

이를 위해 데이터베이스에서 PreparedStatement를 제공해준다.
앞서 말한 쿼리 분석, 컴파일 과정을 거쳐 실행 계획을 미리 만들어두고 세션 내에서 같은 쿼리를 사용할 때마다 동일한 실행 계획을 이용할 수 있게 해준다.
또한 placeholder(? 문자)가 포함되어 있는 쿼리를 이용하면 placeholder에 값을 넣어줄 수 있는데 이렇게 되면 미리 실행 계획이 만들어져 있어 잘못된 값이 오면 무시되므로 SQL Injection을 예방할 수 있다.

prepare stmt1 from 'select * from test where id = ?';
set @a = '1';
execute stmt1 using @a;

그렇다면 MySQL에서 PreparedStatement는 어떨까?
특히 MySQL에서 jdbc 드라이버로 제공해주는 PreparedStatement 구현체를 보니까 재밌는 사실을 알 수 있었다.

Client PreparedStatement

MySQL은 4.1 버전부터 완전한 PreparedStatement를 지원하였기 때문에 그 전에는 Jdbc 드라이버를 통해 ClientPreparedStatement만 지원했다고 한다. 그렇기 때문에 PreparedStatement 흉내만 냈을 뿐이지 실제 MySQL에서 제공하는 PreparedStatement를 사용하는 것이 아니기에 매번 쿼리 분석, 컴파일, 실행 단계가 발생한다고 한다.
오잉? 그렇다면 SQL Injection은 어떻게 막지?
이는 따로 파라미터로 들어온 값에 특정 특수문자 같은게 존재하면 \를 추가해 escape 시켜서 보내준다.
그렇기에 SQL Injection을 막을 수 있다고 한다.

Server PreparedStatement

추가된 ServerPreparedStatement 객체는 실제 MySQL에서 제공하는 PreparedStatement를 사용할 수 있도록 해준다.
아래 메서드는 ServerPreparedStatement 생성자에 존재하는 serverPrepare라는 메서드인데 ServerPreparedQuery의 serverPrepare를 보면 Prepare 구문으로 만들도록 MySQL에 요청하는 걸 볼 수 있다.

그래서 실제 흐름은 Connection으로부터 PreparedStatement가 만들어질 때 MySQL에서 해당 쿼리를 이용해서 Prepare 구문을 만들고 이를 계속 사용하게 된다.
이러한 설정은 useServerPrepStmts 값에 따라 바꿀 수 있다고 한다.
userServerPrepStmts=false이면 ClientPreparedStatement, true이면 SeverPreparedStatement를 사용할 수 있다고 하는데 기존 코드와의 호환성을 위해 false가 default라고 한다.

실제로 userServerPrepStmts=false로 하면 ClientPreparedStatement를 사용해 MySQL에서 show global status; 를 입력해 보았을 때 Prepared_stmt_count(세션 상관없이 지금 운영중인 PreparedStatement 수)가 올라가있지 않은 반면 userServerPrepStmts=true로 하면 ServerPreparedStatement를 사용해 올라간 모습을 볼 수 있다.

그렇다면 우리 플젝에서도?

보고 또 보고 플젝에서는 jpa를 쓰는데 결국 jpa도 jdbc를 쓰기 때문에 혹시 MariaDB에서 제공해주는 PreparedStatement를 사용하지 않고 있는건가 라는 합리적 의심이 들기 시작했다. 테스트해본 결과 정말 사용하고 있지 않았고 userServerPrepStmts=true를 추가하니 사용된 모습을 볼 수 있었다.
그렇다면 앞으로 userServerPrepStmts=true를 추가하여 ServerPreparedStatement를 사용해야 할까?
그건 경우에 따라 다를 것 같다. 어차피 이 PreparedStatement라는게 해당 세션 내에서만 사용할 수 있고 같은 쿼리를 반복해서 사용하는 경우에 효과가 있는거라 (심지어 테스트해보니 더 느리다는 글도 있다) 적절하게 상황에 따라 테스트해보면서 사용하면 될 것 같다.

참고

[이펙티브 자바] 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

Wed, 09 Feb 2022 00:00:00 GMT

상속을 고려한 설계와 문서화란?

상속을 고려한 설계와 문서화란 정확히 무얼 뜻할까?

우선, 메서드를 재정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야 한다.
즉, 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기사용) 문서로 남겨야 한다.

더 넓게 말하면, 재정의 가능(public과 protected 메서드 중 final이 아닌 모든 메서드) 메서드를 호출할 수 있는 모든 상황을 문자로 남겨야 한다. 예를 들어 백그라운드 스레드나 정적 초기화 과정에서도 호출이 일어날 수 있따.

문서화의 예

API 문서의 메서드 설명 끝에서 종종 "Implementation Requirements"로 시작하는 절을 볼 수 있는데, 그 메서드의 내부 동작 방식을 설명하는 곳이다.
메서드 주석에 @implSpec 태그를 붙여주면 자바독 도구가 생성해준다. @implSpec 태그는 자바 8에서 처음 도입되어 자바 9부터 본격적으로 사용되기 시작했다.

java.util.AbstractCollection에서 발췌한 예이다.

클래스를 안전하게 상속할 수 있도록 하려면 (상속만 아니었다면 기술하지 않았어야 할) 내부 구현 방식을 설명해야만 한다.

내부 메커니즘을 문서로 남기는 것만이 상속을 위한 설계의 전부는 아니다.
효율적인 하위 클래스를 큰 어려움 없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드 형태로 공개해야 할 수도 있다.

java.util.AbstractList의 removeRange 메서드를 예로 살펴보자.

List 구현체 최종 사용자는 removeRange 메서드에 관심이 없다. 그럼에도 이 메서드를 제공한 이유는 단지 하위 클래스에서 부분리스트의 clear 메서드를 고성능으로 만들기 쉽게 하기 위해서다.

상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출해야 할지는 어떻게 결정할까?
심사숙고해서 잘 예측해본 다음, 실제 하위 클래스를 만들어 시험해보는 것이 최선이다. protected 메서드 하나하나가 내부 구현에 해당하므로 그 수는 가능한 한 적어야 한다. 한편으로는 너무 적게 노출해서 상속으로 얻는 이점마저 없애지 않도록 주의해야 한다.

상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 '유일'하다.
꼭 필요한 protected 멤버를 놓쳤다면 하위 클래스를 작성할 때 그 빈자리가 확연히 드러난다.
거꾸로, 하위 클래스를 여러 개 만들 때까지 전혀 쓰이지 않는 protected 멤버는 사실 private이었어야 할 가능성이 크다.
상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.

또한, 상속하려는 사람을 위해 덧붙인 설명은 단순히 그 클래스의 인스턴스만 만들어 사용할 프로그래머에게는 필요 없는 군더더기일 뿐이다.

주의할 점

상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다.
상위 클래스의 생성자가 하위 클래스 생성자보다 먼저 실행되므로 하위 클래스에서 재정의한 메서드가 하위 클래스의 생성자보다 먼저 호출된다. 이때 그 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면 의도대로 동작하지 않을 것이다.

// 재정의 가능 메서드를 호출하는 생성자 - 따라 하지 말 것! (115쪽)
public class Super {
    // 잘못된 예 - 생성자가 재정의 가능 메서드를 호출한다.
    public Super() {
        overrideMe();
    }

    public void overrideMe() {
    }
}

// 생성자에서 호출하는 메서드를 재정의했을 때의 문제를 보여준다. (126쪽)
public final class Sub extends Super {
    // 초기화되지 않은 final 필드. 생성자에서 초기화한다.
    private final Instant instant;

    Sub() {
        instant = Instant.now();
    }

    // 재정의 가능 메서드. 상위 클래스의 생성자가 호출한다.
    @Override
    public void overrideMe() {
        System.out.println(instant);
    }

    public static void main(String[] args) {
        Sub sub = new Sub();
        sub.overrideMe();
    }
}

이 프로그램이 instant를 두 번 출력하리라 기대했겠지만, 첫 번째는 null을 출력한다. 상위 클래스의 생성자는 하위 클래스의 생성자가 인스턴트 필드를 초기화하기도 전에 overrideMe를 호출하기 때문이다. 따라서 이 프로그램에서는 final 필드의 상태가 두 가지다. (정상이라면 단 하나뿐)
만약 overrideMe에서 instant 객체의 메서드를 호출하려 한다면 상위 클래스 생성자에서 NullPointerException이 발생하게 될 것이다.

private, final, static 메서드는 재정의가 불가능하니 생성자에서 안심하고 호출해도 된다.

Cloneable, Serializable

Cloneable과 Serializable 인터페이스는 상속용 설계의 어려움을 한층 더해준다.
둘 중 하나라도 구현한 클래스를 상속할 수 있게 설계하는 것은 일반적으로 좋지 않은 생각이다. 그 클래스를 확장하려는 프로그래머에게 엄청난 부담을 지우기 때문이다.

clone과 readObject 모두 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다.
readObject의 경우 하위 클래스의 상태가 미처 다 역질렬화되기 전에 재정의한 메서드부터 호출하게 된다. clone의 경우 하위 클래스의 clone 메서드가 복제본 상태를 (올바른 상태로) 수정하기 전에 재정의한 메서드를 호출한다.
어느 쪽이든 프로그램 오작동으로 이어질 것이다.

마지막으로 Serializable을 구현한 상속용 클래스가 readResolve나 writeReplace 메서드를 갖는다면 이 메서드들은 private이 아닌 protected로 선언해야 한다. private으로 선언한다면 하위 클래스에서 무시되기 때문이다.

그래서 결론은?

클래스를 상속용으로 설계하려면 엄청난 노력이 들고 그 클래스에 안기는 제약도 상당하다. 절대 가볍게 생각하고 정할 문제가 아니다.
추상 클래스나 인터페이스의 골격 구현처럼 상속을 허용하는 게 명백히 정당한 상황이 있고, 불변 클래스처럼 명백히 잘못된 상황이 있다.

그렇다면 그 외 일반적인 구체 클래스는 어떨까?
그대로 두면 위험하기에 해결하기 위한 가장 좋은 방법은 상속용으로 설계하지 않은 클래스는 상속을 금지하는 것이다.
상속을 금지하는 방법은 두 가지다.

클래스를 final로 선언
모든 생성자를 private or package-private으로 선언하고 public 정적 팩터리를 만들어주는 방법.

하지만 이 조언은 다소 논란의 여지가 있다.
그동안 수많은 프로그래머가 일반적인 구체 클래스를 상속해 계측, 통지, 동기화, 기능 제약 등을 추가해왔을 테니 말이다.

핵심 기능을 정의한 인터페이스가 있고, 클래스가 그 인터페이스를 구현했다면 상속을 금지해도 개발하는데 아무런 어려움이 없을 것이다. (ex - Set, List, Map)
구체 클래스가 표준 인터페이스를 구현하지 않았는데 상속을 금지하면 사용하기 상당히 불편해진다.
그래서 이런 경우는 클래스 내부에서는 재정의 가능 메서드를 사용하지 않게 만들고 이 사실을 문서로 남겨야 한다.

핵심 정리

상속용 클래스는 클래스 내부에서 스스로를 어떻게 사용하는지(자기사용 패턴) 모두 문서로 남겨야 하며, 일단 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜야 한다.
- 그렇지 않으면 하위 클래스를 오동작하게 만들 수 있다.
다른 사람이 효율 좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공해야할 수도 있다.
- 이렇게 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하는 편이 낫다.
상속을 금지하려면 클래스를 final로 선언하거나 생성자 모두를 외부에서 접근할 수 없도록 만들면 된다.

검색 기능에 Spring Event 써보기

Sat, 05 Feb 2022 00:00:00 GMT

여느 때와 다름없이 공부를 하고 있던 중 프로젝트 에서 막혔던 부분이 생각났고 이를 어떻게 해결할 수 있을지 궁금해졌다.
이미 다 끝난 프로젝트긴하지만 갑자기 궁금해졌으므로 고민을 해보았고 그 과정과 찾은 해결책 중 하나를 포스팅해보려고 한다.
물론 적절한 해결책이라고 할 수 있을진 모르겠으나 한번 고민을 해보았다는거에 의미를 두기 위해..ㅎㅎ

어떤 상황이었는가?

기존에 문제집 검색 기능이 존재했다.
프로젝트를 진행하면서 인기 검색어 기능이 추가되었고 이를 위해 검색어가 몇번 사용되었는지를 저장해주어야 했다.
저장소로 redis를 사용하였고 이 부분을 담당했던 팀원이 멋지게 기능 구현을 해주었다.
이때 검색어로 조회 + 해당 검색어의 score 증가는 하나의 트랜잭션에서 이루어지는 것이 좋겠다 싶어 팀원이 다음과 같은 코드를 작성해주었다.

@Transactional(readOnly = true)
public List<WorkbookResponse> searchWorkbooks(WorkbookSearchParameter workbookSearchParameter,
                                              List<Long> tags,
                                              List<Long> users) {

    PageRequest pageRequest = workbookSearchParameter.toPageRequest();
    if (pageRequest.getPageNumber() == 0) {
        String searchKeywordValue = workbookSearchParameter.getSearchKeyword().getValue();
        searchRankService.increaseScore(searchKeywordValue);
    }
    Page<Workbook> page = workbookQueryRepository.searchAll(workbookSearchParameter, tags, users, pageRequest);
    List<Workbook> workbooks = page.toList();
    return WorkbookResponse.openedListOf(workbooks);
}

문제는 @Transactional(readOnly = true)에서 시작되었다. 당시에 성능 향상(자동으로 flush 하지 않음) 및 replication을 적용해 readOnly 속성에 따라 작업 분리 목적으로 readOnly = true를 설정해두었다. 당연 검색 기능 또한 read 작업이기에 readOnly = true로 설정해두었는데 score 증가 작업을 추가함에 따라 애매해진 것.
그런데 신기한건 readOnly = true여도 redis에서 write 작업은 잘 작동된다. 문제는 readOnly = true일 때 redis에서 score 증가 작업이 성공하고 에러가 발생한다면 rollback이 되지 않았다. 반면 readOnly = false로 바꾸면 에러가 발생해도 정상적으로 rollback이 되었다.

왜 그럴까? 에 대해 좀 찾아보았는데 정확한지는 모르겠으나 공식 문서 + 디버깅을 통한 뇌피셜은 다음과 같다.
우선 공식 문서의 내용이다.

Spring Data Redis distinguishes between read-only and write commands in an ongoing transaction. Read-only commands, such as KEYS, are piped to a fresh (non-thread-bound) RedisConnection to allow reads. Write commands are queued by RedisTemplate and applied upon commit.

간단하게 트랜잭션에서 read only 명령과 write 명령을 구분하며 write 명령은 queue에 쌓아두고 한꺼번에 실행하나 read only 명령은 바로 실행이 된다는 뜻이다.
근데 read only인지 write 명령인지 정하는 기준이 @Transactional에 readOnly 설정인듯 싶다.
실제로 readOnly = true로 두고 score 증가 명령을 실행하면 redis transaction 명령어를 실행해주는 곳을 통과하지 못한다.
이는 readOnly일 경우 위 작업을 해주는 곳과 별개로 명령이 실행된다고 볼 수 있다.
즉, 이로 인해 해당 명령이 실행되는 서비스 메서드에서 예외가 발생하더라도 rollback되지 않는 것!

반면 readOnly = false로 두고 score 증가 명령을 실행하면 이 곳을 통과하고 해당 서비스 메서드의 트랜잭션 상태에 따라 redis 명령이 실행된다. 이로 인해 rollback이 되어 score가 증가하지 않게 된다.

이야기가 길었지만 결론은 redis write 명령 transcation에 에러가 발생하면 rollback 하기 위해 @Transaction의 readOnly = true를 삭제하게 되었다.

@Transactional
public List<WorkbookResponse> searchWorkbooks(WorkbookSearchParameter workbookSearchParameter,
                                              List<Long> tags,
                                              List<Long> users) {

    PageRequest pageRequest = workbookSearchParameter.toPageRequest();
    if (pageRequest.getPageNumber() == 0) {
        String searchKeywordValue = workbookSearchParameter.getSearchKeyword().getValue();
        searchRankService.increaseScore(searchKeywordValue);
    }
    Page<Workbook> page = workbookQueryRepository.searchAll(workbookSearchParameter, tags, users, pageRequest);
    List<Workbook> workbooks = page.toList();
    return WorkbookResponse.openedListOf(workbooks);
}

하지만 이렇게 되면 write와 read 작업을 master, slave db로 나누었는데 read 작업 중 제일 많은 부분을 차지하게 될 검색 기능이 slave db를 타질 못한다.
당시 팀원들과 어떻게 하면 검색 조회는 readOnly = true로 score 증가는 readOnly = false로 나눌 수 있을까에 대해 고민해보았지만 마땅한 해결책이 없었고 더 좋은 해결책이 나오기 전까지 위 방법을 사용하기로 하였다.

다른 방법은 없을까?

프로젝트가 끝난지 한참이 지나긴 했지만 갑자기 생각이 나 고민을 해보고 싶었다.
우선 살펴보니 위 코드는 다음과 같은 아쉬운 점이 있었다.

score 증가 작업이 조회 작업보다 먼저 있음. (로직 흐름상 조회 후 증가가 맞음)
검색 작업이 slave db를 이용하지 못함.
read 작업인데 서로 연관이 없는 write 작업이 같이 있음.
score 증가하다가 에러가 발생하면 검색 기능이 되질 않는데 과연 score 증가하는 작업이 검색 기능을 막아버릴 정도로 중요한가 싶음. (score 증가하다 에러 발생해도 검색은 영향을 받지 않아야하지 않을까..?)

따라서 두 작업을 나누는게 좋을 것 같다고 생각했고 어떻게 나누는게 좋을지 고민해보았다.

SearchController에서 score 증가, 검색 조회 순으로 두 개의 서비스 메서드를 호출하도록 수정 -> 1, 2, 3을 만족하나 4를 만족시킬 수 없다고 생각.
SearchService의 searchWorkbooks 메서드를 readOnly = true로 수정하고 SearchRankServce의 increaseScore 메서드의 transaction 전파 레벨을 REQUIRES_NEW로 설정 -> 1, 2, 3을 만족하나 4를 충족시키지 않고 잘못하다가 검색은 실패하는데 score는 증가될 수 있다고 생각.
AOP는? 가능하지 않을까 싶긴했지만 여기서만 사용되기에 공통 관심사는 아니라고 생각했고 쪼끔 부담스러운 작업이 아닐까 생각..
event는? 검색 조회 작업이 끝나고 transaction이 commit이 되어야지만 event listener에 의해서 score 증가 작업이 실행된다면 1, 2, 3을 만족시키는데다 찾아보니 @TransactionalEventListener를 사용하면 event listener에서 에러가 발생해도 event publisher에서의 작업은 그대로 진행이 된다는데..? 그럼 4도 만족시킬 수 있지 않을까 해서 이것을 적용시켜보기로 했다.

물론 이렇게 event를 발행해서 사용하는게 적합한 방법일까 싶지만 (필자는 아직까지 event에 대해 잘 알지 못한다..) 이런 방법으로도 해결할 수 있겠구나 싶은 생각으로 적용해볼 것이다.

Spring Events

Spring에서는 이벤트 프로그래밍을 위한 몇가지 인터페이스를 제공한다.
기본적으로 이벤트 게시자(Event Publisher)가 이벤트를 발행하고 이러한 이벤트를 이벤트 리스너(Event Listener)가 소비하는 흐름으로 진행된다.

Event는 ApplicationEvent를 확장해서 사용하지만 Spirng FrameWork 4.2 버전부터 확장하지 않아도 사용 가능하다. (POJO)
Event Publisher는 ApplicationEventPublisher에 이벤트를 발행한다. ApplicationEventPublisher는 ApplicationContext가 상속받고 있기 때문에 따로 빈으로 등록하지 않아도 의존성 주입을 할 수 있다.
Event Listener는 ApplicationListener 인터페이스를 구현하여 이벤트를 받지만 4.2 버전부터 @EventListener나 @TransactionalEventListener를 통해 이벤트를 받을 수 있다.

@TransactionalEventListener

이렇게 이벤트를 발행하도록 만들게 되면 두 서비스간의 결합도가 낮아지게 된다.
더이상 SearchServcie에서 SearchRankService를 의존하지 않아도 되며 read 작업, write 작업도 분리가 된다.
또한 read 작업과 write 작업을 독립적으로 분리(에러 전파가 안됨)할 수 있도록 @TransactionalEventListener를 사용할 수 있다.
@TransactionalEventListener를 사용하면 TransactionPhase에 따른 이벤트 처리가 가능하다.
phase는 4개가 있으며 다음과 같다. 참고로 phase를 설정하지 않으면 트랜잭션이 성공적으로 완료되었을 때 이벤트가 실행된다.

AFTER_COMMIT (default): 트랜잭션이 성공했을 때 실행
AFTER_ROLLBACK: 트랜잭션이 롤백되었을 때 실행
AFTER_COMPLETION: 트랜잭션이 완료되었을 때 실행
BEFORE_COMMIT: 트랜잭션이 커밋되기 전에 실행

조회가 성공하면 검색어 score를 증가해주면 되었기에 AFTER_COMMIT으로 설정해주었다.

적용 코드

Event Publisher

@Service
@Transactional(readOnly = true)
public class SearchService {

    private static final int SIZE_LIMIT = 10;

    private final WorkbookSearchRepository workbookSearchRepository;
    private final TagSearchRepository tagSearchRepository;
    private final ApplicationEventPublisher applicationEventPublisher;

    public SearchService(WorkbookSearchRepository workbookSearchRepository,
                         TagSearchRepository tagSearchRepository,
                         ApplicationEventPublisher applicationEventPublisher) {
        this.workbookSearchRepository = workbookSearchRepository;
        this.tagSearchRepository = tagSearchRepository;
        this.applicationEventPublisher = applicationEventPublisher;
    }

    public List<WorkbookResponse> searchWorkbooks(WorkbookSearchParameter workbookSearchParameter,
                                                  List<Long> tags,
                                                  List<Long> users) {
        PageRequest pageRequest = workbookSearchParameter.toPageRequest();
        Page<Workbook> page = workbookSearchRepository.searchAll(workbookSearchParameter, tags, users, pageRequest);
        List<Workbook> workbooks = page.toList();
        applicationEventPublisher.publishEvent(new SearchRankEvent(
                pageRequest.getPageNumber(),
                workbookSearchParameter.getSearchKeyword().getValue()));
        return WorkbookResponse.openedListOf(workbooks);
    }
}

SearchService에 ApplicationEventPublisher를 의존하고 주입받게 하였다.
조회 작업 후 이벤트를 만들어서 발행하도록 하였다.

Event

public class SearchRankEvent {
    private final int pageNumber;
    private final String keyWord;

    public SearchRankEvent(int pageNumber, String keyWord) {
        this.pageNumber = pageNumber;
        this.keyWord = keyWord;
    }

    public int getPageNumber() {
        return pageNumber;
    }

    public String getKeyWord() {
        return keyWord;
    }
}

EventListener

@Component
public class SearchRankEventHandler {

    private final SearchRankService searchRankService;
    
    public SearchRankEventHandler(SearchRankService searchRankService) {
        this.searchRankService = searchRankService;
    }

    @TransactionalEventListener
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void increaseScore(SearchRankEvent event) {
        if (event.getPageNumber() == 0) {
            searchRankService.increaseScore(event.getKeyWord());
        }
    }
}

따로 EventListener를 만들고 이벤트를 받아 실행해주도록 하였다.
여기서 주의해야할 점이 전파 레벨인데 @TransactionalEventListener를 설정했더라도 이미 commit된 트랜잭션에 참여하고 있기에 재 commit이 불가능하다. redis에 score를 증가시키기 위해선 commit이 필요하므로 publisher와 listener의 트랜잭션을 완전히 분리시켜주기 위해 전파 레벨을 REQUIRES_NEW로 설정해주어야 한다.
위 코드처럼 listener에 설정해주어도 되고 SearchRankService의 increaseScore 메서드에서 설정해주어도 된다.

테스트

@Test
@DisplayName("문제집을 검색하고 score가 증가한다.")
void searchWorkbooks() {
    // given
    String keyword = "java";
    WorkbookSearchParameter searchParameter = WorkbookSearchParameterUtils.builder()
            .searchKeyword(keyword).build();

    // when
    searchService.searchWorkbooks(searchParameter, Collections.emptyList(), Collections.emptyList());

    // then
    assertThat(searchScoreRepository.score(keyword)).isEqualTo(1.0);
}

테스트 결과 이벤트도 잘 동작하며 조회시 slave db도 제대로 타게 된다.

public List<WorkbookResponse> searchWorkbooks(WorkbookSearchParameter workbookSearchParameter,
                                                  List<Long> tags,
                                                  List<Long> users) {
    PageRequest pageRequest = workbookSearchParameter.toPageRequest();
    Page<Workbook> page = workbookSearchRepository.searchAll(workbookSearchParameter, tags, users, pageRequest);
    List<Workbook> workbooks = page.toList();
    applicationEventPublisher.publishEvent(new SearchRankEvent(
            pageRequest.getPageNumber(),
            workbookSearchParameter.getSearchKeyword().getValue()));
    throw new IllegalArgumentException();
}

@Test
@DisplayName("문제집 검색하고 score 증가 후 에러 발생하면 rollback 한다.")
void searchWorkbooksWithSearchException() {
    // given
    String keyword = "java";
    WorkbookSearchParameter searchParameter = WorkbookSearchParameterUtils.builder()
    .searchKeyword(keyword).build();

    // when, then
    assertThatThrownBy(() -> searchService.searchWorkbooks(searchParameter, Collections.emptyList(), Collections.emptyList()))
    .isInstanceOf(IllegalArgumentException.class);
    assertThat(searchScoreRepository.score(keyword)).isNull();
}

@TransactionalEventListener
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void increaseScore(SearchRankEvent event) {
    if (event.getPageNumber() == 0) {
        searchRankService.increaseScore(event.getKeyWord());
    }
    throw new IllegalArgumentException();
}

@Test
@DisplayName("문제집 검색하고 score 증가시 에러 발생하면 score는 rollback하지만 검색은 정상으로 된다.")
void searchWorkbooksWithScoreException() {
    // given
    String keyword = "java";
    WorkbookSearchParameter searchParameter = WorkbookSearchParameterUtils.builder()
    .searchKeyword(keyword).build();
    
    // when
    searchService.searchWorkbooks(searchParameter, Collections.emptyList(), Collections.emptyList());
    
    // then
    assertThat(searchScoreRepository.score(keyword)).isNull();
}

또한 위와 같이
조회 성공 -> 증가 성공 -> 예외 발생한 경우엔 검색 기능 예외 발생 및 정상적으로 rollback되며
조회 성공 -> 증가 실패한 경우에 증가에 대한 트랜잭션은 rollback되고 검색 기능은 정상적으로 작동된다.

마무리

원하는대로 구현을 할 수 있게 되어 좋았지만 반드시 이게 정답은 아닐 것이다.
우선 분리를 해서 좋으나 전체적인 로직 파악이 한번에 되진 않는다.
이벤트 로직까지 코드를 봐야 알 수 있으니까..ㅎㅎ
그리고 이벤트 로직에서 예외가 발생했을 때는 어떻게 관리를 해야할지 생각해봐야겠다.
정상적으로 검색 기능은 작동하나 예외가 발생하고 있는지도 모를 수 있으니까..
마지막으로 SearchRankService가 사라지는 대신에 ApplicationEventPublisher를 의존하니 이벤트를 만들고 등록하는 로직이 서비스 로직에 추가된거 같아 이거도 다른 곳으로 이동할 수 없을까 생각했었는데 관련 글 이 있었다.
이벤트 만들고 등록하는 로직을 AOP로 분리하는 것이었는데 이렇게 분리하면 후에 이벤트가 필요한 곳에 재사용 가능하니 좋은 방법이지 않을까 싶었다.

참고

[Java] Garbage Collection이란?

Mon, 24 Jan 2022 00:00:00 GMT

Garbage Collection이 무엇일까?

Garbage Collection(이하, GC)은 메모리 관리 기법 중의 하나로, 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요없게 된 영역을 해제하는 기능이다.
많은 현대 언어들이 GC 기법을 사용한다고 하는데 C와 C++은 수동 메모리 관리를 가정하고 설계되었기에 기본으로 제공해주지는 않지만 라이브러리를 통해 사용할 수 있다고 한다. (필자는 C 언어를 접해본 적이 단한번도 없다..ㅎㅎ)
Java, Javascript, Python 등의 언어에서는 GC가 내장되어 있어 자동으로 메모리 관리를 해주고 있으며 이 글에서는 Java, 즉 JVM이 제공해주는 GC에 대해 알아보도록 한다.

Garbage Collection 알고리즘

https://asfirstalways.tistory.com/159

먼저 GC에서 사용되는 알고리즘을 먼저 알아보도록 하자.
그 전에 Garbage Collector(GC를 하는 주체)에서는 Heap 영역에 있는 어떤 객체를 Garbage로 보고 메모리를 해제하는 걸까?
기본적으로 객체를 Reachable과 Unreachable의 상태로 구분하는데 구분 방법으로 Root Set과의 관계로 판단한다.
Root Set과 관계가 있어 유효한 참조가 있다면 Reachable 객체, 그렇지 않다면 Unreachable 객체가 되는 것이다.
여기서 말한 Root Set이란

Stack (Java 메서드 실행 시에 사용하는 지역변수와 파라미터들에 의한 참조),
Native Stack (JNI, Java Native Interface에 의해 생성된 객체에 대한 참조),
Method 영역의 정적 변수에 의한 참조.

를 뜻한다.
참고로 사용자 코드에서 객체의 rechability를 조절하여 GC에 관여할 수 있도록 다양한 Reference 객체를 제공해주는데 이는 네이버 아티클 을 참고하도록 하자. (아직까진 이해 안가는 부분이 있지만 GC, 특히 Reference에 대해 다룬 좋은 글이다)

아무튼 GC 알고리즘은 기본적으로 Garbage를 식별하고 이를 메모리에서 해제하는 흐름으로 진행된다.
알고리즘 종류로 여러 종류가 있는데 대표적인 두 가지 알고리즘으로 Reference Counting과 Mark And Sweep이 있다.

Reference Counting

https://rebelsky.cs.grinnell.edu/Courses/CS302/99S/Presentations/GC/

Reference Counting은 힙 영역에 생성된 객체마다 Reference Count라는 별도의 숫자를 가지고 있다고 생각하면 된다.
Reference Count는 몇 가지 방법으로 해당 객체에 접근할 수 있는지(참조 되고 있는 갯수)를 뜻하는데 해당 객체에 접근할 수 있는 방법이 하나도 없다면 즉, Reference Count가 0이 되면 GC를 수행한다. Reference Count가 0이 되면 즉시 메모리에서 해제된다는 장점이 있지만 객체 간의 순환 참조가 존재하고 있는 상태에서 Root Set으로부터 참조가 끊겨도 Reference Count는 0이 되지 않으므로 사용하지 않는 메모리 영역이 해제되지 못해 Memory Leak이 발생하는 단점이 있다.

Mark And Sweep

https://rebelsky.cs.grinnell.edu/Courses/CS302/99S/Presentations/GC/

Reference Counting의 단점을 해결하기 위해 나온 알고리즘으로 Root Set을 통해 참조 관계를 추적하는 매우 기본적인 알고리즘이다.
원래는 조금 더 복잡하겠지만 기본적인 흐름만 살펴보자면 이러하다.
우선 Mark 단계와 Sweep 단계로 나뉜다.
Mark에서 Root Set으로부터 그래프 순회를 통해 연결된 객체를 찾아내어 Garbage 대상이 아닌 객체에 Marking을 진행하게 된다.
이 작업이 끝나면 바로 Garbage 대상들을 지우는 작업인 Sweep이 진행되고 이후 Marking 되었던 정보를 초기화한다.

이렇게 Mark And Sweep만 진행된 상태에서는 메모리 파편화 현상이 발생하는데 이로 인해 메모리 공간이 낭비되어 OutOfMemory가 발생할 수 있다.
이를 위해 공간을 정리하고 살아남은 객체들을 연속된 메모리 공간에 적재하는 Compact 과정이 거쳐질 수도 있는데 이러한 알고리즘을 Mark Sweep Compact 알고리즘이라고 한다. Java는 기본적으로 Mark And Sweep (선택적으로 Compact) 알고리즘을 사용한다.
참고로 위 사진은 Mark Sweep Compact 알고리즘이다.

Garbage Collection 동작 방식

사용되는 알고리즘을 알아봤으니 동작 방식을 알아보자.
GC가 진행되는 곳은 Heap 영역인데 Heap을 자세하게 보면 다음과 같이 나누어져있다.

https://code-factory.tistory.com/48

위와 같이 Heap은 Young Generation과 Old Generation으로 나뉜다.
이때 Young Generation은 Eden과 두 개의 Survivor 영역(Survivor0,1)로 나뉜다.

새로 객체가 생성되면 Young Generation의 Eden에 위치하게 된다.
Eden 영역이 꽉 차면 Minor GC가 발생하게 되어 참조되지 않은 객체는 메모리에서 해제되고, 살아남은 객체는 Survivor 영역 중 한 군데로 이동하게 된다. 이때 살아남은 객체는 age bit가 1 증가하게 된다.
이후 Eden 영역이 꽉 차서 Minor GC가 발동할 때마다 Survivor 영역에 있던 객체들은 다른 Survivor 영역으로 이동한다.
age bit가 일정 수준을 넘어가게 되면 오랫동안 참조될 객체라고 판단하여 Old Generation으로 넘겨주고 이를 Promotion이라고 부른다.
Old Generation도 꽉 차게 되면 Major GC가 발생하게 된다.

왜 Young Generation과 Old Generation으로 나누었을까?

그 이유는 다음과 같다.

대부분의 할당된 객체는 오랫동안 참조되지 않으며 금방 Garbage 대상이 된다.
오래된 객체에서 젊은 객체로의 참조는 거의 없다.

이러한 이유를 바탕으로 Young과 Old Generation 두 영역으로 나누어 효율적으로 처리하도록 만든 것이다. (아무래도 GC도 하나의 비용이다 보니..ㅎㅎ)

Garbage Collector 종류

JVM은 다양한 Garbage Collector를 제공한다. Java 7, 8은 Parallel GC가 default고 9, 10, 11은 G1 GC가 default다.
Java 11부터는 실험적으로 Z GC를 사용할 수 있다고 한다.
종류에 대한 특징은 간단하게 살펴보도록 하자.

Stop The World?

종류를 알아보기 앞서 Stop The World라는 용어를 알고 가야한다.
Stop The World는 GC를 수행하기 위해 JVM이 애플리케이션 실행을 멈추는 것을 의미한다.
애플리케이션 실행을 멈추는 것이다보니 당연히 이 시간이 길어지면 성능이 떨어지게 된다.
GC는 계속해서 이 Stop The World 시간을 최소화하기 위해 발전해왔다.

Serial Garbage Collector

하나의 스레드로 GC를 실행한다. (Mark Sweep Compaction)
Stop The World 시간이 길다.
싱글 스레드 환경 및 Heap이 매우 작을 때 사용한다.

Parallel Garbage Collector

여러 개의 스레드로 GC를 실행한다. (Mark Sweep Compaction)
Serial GC보다 Stop The World 시간이 줄어들게 된다.
멀티 코어 환경에서 사용한다.

CMS(Concurrent Mark Sweep) Garbage Collector

Stop The World 시간을 최소화하기 위해 고안되었다.
GC 작업을 애플리케이션과 동시에 실행한다.
메모리와 CPU를 많이 사용하고 Compaction이 기본적으로 제공되지 않음.
G1 GC 등장에 따라 Deprecated 되었다.

G1(Garbage First) Garbage Collector

큰 Heap 메모리에서 짧은 GC 시간을 보장하는데 목적을 둔다.
Heap을 특정한 크기의 Region으로 나누어서 사용한다.
- 각 Region의 상태에 따라 역할(Eden, Survivor, Old)이 동적으로 부여된다.
런타임에 G1 GC가 필요에 따라 영역별 Region 개수를 튜닝하여 Stop The World 시간을 최소화한다.

Z Garbage Collector

확장 가능하고 낮은 지연율을 가진 GC이다.
아래의 목표를 충족하기 위해 나오게 되었다.
- 정지 시간이 최대 10ms를 초과하지 않음
- Heap의 크기가 증가하더라도 정지 시간이 증가하지 않음
- 8MB ~ 16TB에 이르는 다양한 범위의 Heap 처리 가능
ZPages라는 Region으로 나누어 사용한다.

Z GC의 작동 원리는 찾아보아도 아직까진 잘 이해가 가지 않기에 추후에 더 많이 찾아보아야 할 것 같다..ㅠㅠ
벤치마킹 결과 큰 메모리에서 G1 GC 보다 훨씬 좋은 성능을 보였는데 아직까진 JVM default GC가 아니기에 이런 GC가 있다 정도로 알고 넘어가야겠다.

번외 - Permanent Generation, Metaspace

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=kbh3983&logNo=220967456151

GC에 대해 공부하다 보니 JVM의 Method 영역에 대해 헷갈리는 부분이 생기게 되었다.
동작 방식을 설명하면서 Heap을 나누게 되는데 여러 사진에서 Permanent Generation이 등장하게 된다.
이는 Java 7까지 존재하던 영역으로서 Heap 영역의 일부라고 하는데 Method 영역이 이 Perm Gen에 속해있다고 한다.
엥..? 그렇다면 Method 영역이 Heap 영역에 속한다는건가?
실제로도 Perm Gen에 있는 정보를 보면 class, method meta 정보, constant pool이 존재한다고 적혀있었다. 이를 보고 여태 내가 잘못 알고 있었나 하는 생각을 들게 하였다.
하지만 찾아보니 이러한 StackOverFlow 글 을 있었고 읽어보니 Perm Gen은 Heap 영역으로 인용하고 있지만 (Generations 설명을 위해) Heap 영역이 아니라는 답변이 있어 넘어가기로 했다.
게다가 Java 8버전부터 Perm Gen이 사라지고 Metaspace가 추가되면서 (Metaspace는 확실하게 Heap 영역이 아니다) 더이상 찾아볼 필요는 없다고 생각했다.

여기서 흥미로운 점은 Perm Gen에 존재했던 string, static object의 위치인데 7 버전까지 Perm Gen에 존재하면서 GC의 관리 대상에 속하지 않았다고 한다.
기본적으로 Perm Gen은 고정된 메모리 용량을 사용하고 있는데다 속해있던 string object, static object가 GC에 의해 해제되지 않다보니 OOM이 발생하는 문제가 생겼다고 한다.
이를 해결하기 위해 8부터는 Perm Gen이 삭제되고 Metaspace가 추가되면서 class, method meta 정보들은 Metaspace에 저장되고 string, static object는 Heap 영역에 저장되면서 GC의 대상이 되었다고 한다. 참고로 object만 Heap 영역으로 이동되었고 reference는 여전히 Metatspace에 관리되기에 참조를 잃은 object만 GC의 대상이 되는 것이다.

마무리

GC와 더불어 JVM에 대해서도 다시 한번 공부하게 된 좋은 시간이었다고 생각한다.
과연 언젠가는 GC를 튜닝해보는 날도 오지 않을까..?
물론 그 전에 코드 단에서 성능을 해결하도록 노력해야겠지만..ㅎㅎ

참고

ThreadLocal과 Request Scope

Wed, 12 Jan 2022 00:00:00 GMT

ThreadLocal?

김영한님의 스프링 고급편 을 들으면 ThreadLocal에 대한 내용이 나온다.
ThreadLocal이 나오게 된 이유는 다음과 같다.

@Slf4j
public class FieldLogTrace implements LogTrace {

    private static final String START_PREFIX = "-->";
    private static final String COMPLETE_PREFIX = "<--";
    private static final String EX_PREFIX = "<X-";

    private TraceId traceIdHolder; //traceId 동기화, 동시성 이슈 발생

    @Override
    public TraceStatus begin(String message) {
        syncTraceId();
        TraceId traceId = traceIdHolder;
        Long startTimeMs = System.currentTimeMillis();
        log.info("[{}] {}{}", traceId.getId(), addSpace(START_PREFIX,
                traceId.getLevel()), message);
        return new TraceStatus(traceId, startTimeMs, message);
    }

    private void syncTraceId() {
        if (traceIdHolder == null) {
            traceIdHolder = new TraceId();
        } else {
            traceIdHolder = traceIdHolder.createNextId();
        }
    }
    
    // ...
}

LogTrace를 사용해 원하는 부분에 로그를 출력할 수 있게 만들었다.
이때 FieldLogTrace 내부에 있는 TraceId에 의해서 로그 id, 출력 depth가 결정된다.

그런데 상태가 변하는 값이다 보니 싱글 스레드에서는 문제 없으나 요청이 많이 발생하는 멀티 스레드 환경에서는 다음과 같이 원치않는 로그가 찍히게 된다.

이를 위해 스레드마다 고유한 값을 가지기 위해 등장하는 것이 ThreadLocal이다. ThreadLocal은 동일한 스레드에서만 접근할 수 있는 특별한 저장소를 뜻한다.
내부를 살펴보게 되면 ThreadLocalMap이 존재하게 되는데 이 Map을 각 스레드가 가지고 있게 된다. 그래서 set을 하게 될 때 이 Map에 현재 ThreadLocal을 key로 두고 입력받은 값을 value로 저장하는 것이다.

ThreadLocal로 변경한 코드는 다음과 같다.

@Slf4j
public class ThreadLocalLogTrace implements LogTrace {

    private static final String START_PREFIX = "-->";
    private static final String COMPLETE_PREFIX = "<--";
    private static final String EX_PREFIX = "<X-";
    
    private ThreadLocal<TraceId> traceIdHolder = new ThreadLocal<>();


    @Override
    public TraceStatus begin(String message) {
        syncTraceId();
        TraceId traceId = traceIdHolder.get();
        Long startTimeMs = System.currentTimeMillis();
        log.info("[{}] {}{}", traceId.getId(), addSpace(START_PREFIX,
                traceId.getLevel()), message);
        return new TraceStatus(traceId, startTimeMs, message);
    }

    private void syncTraceId() {
        TraceId traceId = traceIdHolder.get();
        if (traceId == null) {
            traceIdHolder.set(new TraceId());
        } else {
            traceIdHolder.set(traceId.createNextId());
        }
    }
    
    // ...
}

그리고 로그를 출력해보면 다수의 요청이 오더라도 원하는 결과값이 나오는 것을 확인할 수 있다.

Request Scope?

그런데 생각해보니 이 LogTrace는 Spring 빈으로 등록해서 사용한다. 그리고 변경할 수 있는 상태 값을 가지며 요청마다 이용된다. 그렇다면 빈 스코프를 request로 설정하여 동일한 요청에서만 생성하고 소멸시키면 동일하게 문제를 해결할 수 있지 않을까?

@Configuration
public class LogTraceConfig {

    @Bean
    @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
    public LogTrace logTrace() {
        return new ThreadLocalLogTrace();
    }
}

ThreadLocal로 되어있던 필드를 원래대로 수정하고 Config 클래스의 @Bean을 다음과 같이 설정했다. 이때 LogTrace를 필드에 두고 사용하기 때문에 proxymode 설정을 해주어야 한다. 그 이유는 런타임때 의존관계를 맺어주게 되는데 스코프를 request로 설정했기에 맺어주는 시점에서 LogTrace가 존재하지 않아 에러가 터지기 때문이다.

그리하여 proxymode를 TARGET_CLASS로 설정하여 프록시 객체를 삽입해주도록 한다.

그리고나서 로그를 출력해보면 다음과 같이 제대로 동작하는 모습을 볼 수 있다.

무엇을 사용하는게 좋을까?

그렇다면 실제로 이런 상황이 생길 때 ThreadLocal을 써주는게 좋을까 빈 스코프를 request로 설정하는 것이 좋을까?
혹시나 관련 글이 있을까 해서 검색을 했더니 역시나 존재 했다. 스택오버플로우 에도 있었다.
찾아보니 목적에 따라 다를 것 같다.
request 안에서 여러 개의 스레드가 필요한 환경에서 사용하거나 성능을 좀 더 중요시하면 ThreadLocal, 관리 포인트를 줄이고 깔끔한 코드를 원한다면 Request Scope를 사용하는 것이 좋아보인다.
개인적으로는 위와 같은 상황이 생기면 Request Scope를 사용할 것 같다. (물론 실제로 로깅을 위해서라면 AOP를 만들겠지만..) 물론 둘 다 실제로 써본 적이 없어서 아직까지 제대로 감이 오진 않는당..ㅎㅎ;;

번외

ThreadLocal의 주의사항으로 저장된 값은 반드시 remove()를 통해 제거해라고 적혀있다.
제거하지 않으면 한번 스레드가 사용되고 그 후에 동일한 스레드를 사용하게 될 경우 ThreadLocal의 남아있는 값 때문에 예상치 못한 오류가 발생할 수 있기 때문이다.
물론 위에서 말했듯 스레드에 존재하는 ThreadLocalMap에 저장하기 때문에 당연히 그렇겠다 생각이 들지만 한번 테스트 해보도록 하자.

public class ThreadLocalTest {

    @Test
    void threadLocalTest() {
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for (int i = 1; i <= 100; i++) {
            int now = i;
            executorService.execute(() -> {
                Item item = new Item();
                // item.remove();
                System.out.println(item.getItem());
                item.setItem(String.valueOf(now));
            });
        }
    }

    private static class Item {

        private static ThreadLocal<String> threadLocal = new ThreadLocal<>();

        private String getItem() {
            return threadLocal.get();
        }

        private void setItem(String item) {
            threadLocal.set(item);
        }

        private void remove() {
            threadLocal.remove();
        }
    }
}

약간 억지스러운 테스트인거 같지만 대충 스레드풀 사이즈를 10으로 잡고 100번 스레드를 실행시키도록 했다.
그리고 ThreadLocal에서 먼저 값을 꺼내어 출력하고 set을 하였다.
이렇게 테스트하면 어떻게 될까?
예상대로라면 10개만 null이 출력되고 나머지는 숫자가 세팅되어 출력될 것이다.

예상한 결과대로 출력되었다.
참고로 remove() 주석을 풀고 실행시키면 세팅된 값이 제거되므로 전부 null로 출력되는 것을 볼 수 있었다.

참고

스프링 코어 고급편, 김영한님 강의
https://hwannny.tistory.com/95

[이펙티브 자바] 18. 상속보다는 컴포지션을 사용하라

Sun, 09 Jan 2022 00:00:00 GMT

상속

상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다.

일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일은 위험하다.
여기서의 '상속'은 (클래스가 다른 클래스를 확장하는) 구현 상속을 말한다.
(클래스가 인터페이스를 구현하거나 인터페이스가 다른 인터페이스를 확장하는) 인터페이스 상속과는 무관하다.

메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 즉, 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 이러한 이유로 상위 클래스 설계자가 확장을 충분히 고려하고 문서화도 제대로 해두지 않으면 하위 클래스는 상위 클래스 변화에 발맞춰 수정돼야만 한다.

상속 예시

// 코드 18-1 잘못된 예 - 상속을 잘못 사용했다! (114쪽)
public class InstrumentedHashSet<E> extends HashSet<E> {
    // 추가된 원소의 수
    private int addCount = 0;

    public InstrumentedHashSet() {
    }

    public InstrumentedHashSet(int initCap, float loadFactor) {
        super(initCap, loadFactor);
    }

    @Override public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

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

    public int getAddCount() {
        return addCount;
    }

    public static void main(String[] args) {
        InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
        s.addAll(List.of("틱", "탁탁", "펑"));
        System.out.println(s.getAddCount());
    }
}

구체적인 예로 위와 같은 HashSet을 사용하는 프로그램이 있다. main 메서드에서와 같이 원소 3개를 더하고 getAddCount 메서드를 호출하면 3이 아닌 6을 반환한다.
그 이유는 HashSet의 addAll은 각 원소를 add 메서드를 호출해 추가하는데, 이때 불리는 add는 InstrumentedHashSet에서 재정의 한 메서드다. 따라서 addCount에 값이 중복해서 더해져, 최종값이 6으로 늘어난 것이다.

해결 방법은?

1 - 재정의하지 않기

이 경우 하위 클래스에서 addAll 메서드를 재정의하지 않으면 문제를 고칠 수 있다. 하지만 당장은 제대로 동작할지 모르나, HashSet의 addAll이 add 메서드를 이용해 구현했음을 가정한 해법이라는 한계를 지닌다. 이처럼 자신의 다른 부분을 사용하는 '자기사용(self-use)' 여부는 해당 클래스의 내부 구현 방식에 해당하며, 자바 플랫폼 전반적인 정책인지, 그래서 다음 릴리스에서도 유지될지는 알 수 없다. 따라서 이런 가정에 기댄 InstrumentHashSet도 깨지기 쉽다.

2 - 다른 방법으로 재정의

addAll 메서드를 주어진 컬렉션을 순회하여 원소 하나당 add 메서드를 한 번만 호출하도록 재정의할 수도 있다. 하지만 상위 클래스의 메서드 동작을 다시 구현하는 것이 어렵고, 시간도 더 들고, 자칫 오류를 내거나 성능을 떨어뜨릴 수도 있다. 또한 하위 클래스에서는 접근할 수 없는 private 필드를 써야 하는 상황이라면 이 방식으로는 구현 자체가 불가능하다.

하위 클래스가 깨지기 쉬운 이유는 더 있다. 다음 릴리스에서 상위 클래스에 새로운 메서드를 추가한다면 어떨까? 보안 때문에 컬렉션에 추가된 모든 원소가 특정 조건을 만족해야만 하는 프로그램을 생각해보자. 컬렉션을 상속하여 원소를 추가하는 모든 메서드를 재정의해 필요한 조건을 먼저 검사하게끔 하면 될 것 같다. 하지만 이 방식이 통하는 것은 상위 클래스에 또 다른 원소 추가 메서드가 만들어지기 전까지다. 다음 릴리스에서 우려한 일이 생기면 하위 클래스에서 재정의하지 못한 그 새로운 메서드를 사용해 '허용되지 않은' 원소를 추가할 수 있게 된다. 실제로 Hashtable, Vector를 컬렉션 프레임워크에 포함시키자 관련 보안 구멍들을 수정해야 하는 사태가 벌어졌다.

3 - 새로운 메서드 추가하기

메서드를 재정의하는 대신 새로운 메서드를 추가하면?
다음 릴리스에서 상위 클래스에 새 메서드가 추가됐는데, 운 없게도 하필 하위 클래스에 추가한 메서드와 시그니처가 같고 반환 타입은 다르다면 컴파일조차 되지 않는다. 반환 타입마저 같다면 재정의한 꼴이니 앞의 문제와 똑같은 상황에 부닥친다. 또한 상위 클래스 메서드가 요구하는 규약을 만족하지 못할 가능성이 크다.

더 좋은 방법은 없을까..? - 컴포지션

다행히 이상의 문제를 모두 피해 가는 묘안이 있다. 기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하자. 기존 클래스가 새로운 클래스의 구성요소로 쓰인다는 뜻에서 이러한 설계를 컴포지션(구성)이라 한다.
새 클래스의 인스턴스 메서드들은 기존 클래스의 대응하는 메서드를 호출해 그 결과를 반환한다. 이 방식을 전달(forwarding)이라 하며, 새 클래스의 메서드들을 전달 메서드(forwarding method)라 부른다. 그 결과 새로운 클래스는 기존 클래스의 내부 구현 방식의 영향에 벗어나며, 심지어 기존 클래스에 새로운 메서드가 추가되더라도 전혀 영향을 받지 않는다.

컴포지션 예시

// 코드 18-2 래퍼 클래스 - 상속 대신 컴포지션을 사용했다. (117-118쪽)
public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        super(s);
    }

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

    public static void main(String[] args) {
        InstrumentedSet<String> s = new InstrumentedSet<>(new HashSet<>());
        s.addAll(List.of("틱", "탁탁", "펑"));
        System.out.println(s.getAddCount());
    }
}

// 코드 18-3 재사용할 수 있는 전달 클래스 (118쪽)
public class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;
    public ForwardingSet(Set<E> s) { this.s = s; }

    public void clear()               { s.clear();            }
    public boolean contains(Object o) { return s.contains(o); }
    public boolean isEmpty()          { return s.isEmpty();   }
    public int size()                 { return s.size();      }
    public Iterator<E> iterator()     { return s.iterator();  }
    public boolean add(E e)           { return s.add(e);      }
    public boolean remove(Object o)   { return s.remove(o);   }
    public boolean containsAll(Collection<?> c)
                                   { return s.containsAll(c); }
    public boolean addAll(Collection<? extends E> c)
                                   { return s.addAll(c);      }
    public boolean removeAll(Collection<?> c)
                                   { return s.removeAll(c);   }
    public boolean retainAll(Collection<?> c)
                                   { return s.retainAll(c);   }
    public Object[] toArray()          { return s.toArray();  }
    public <T> T[] toArray(T[] a)      { return s.toArray(a); }
    @Override public boolean equals(Object o)
                                       { return s.equals(o);  }
    @Override public int hashCode()    { return s.hashCode(); }
    @Override public String toString() { return s.toString(); }
}

InstrumentedSet은 HashSet의 모든 기능을 정의한 Set 인터페이스를 활용해 설계되어 견고하고 아주 유연하다. 구체적으로 Set 인터페이스를 구현했고, Set의 인스턴스를 인수로 받는 생성자를 하나 제공한다. 위와 같은 컴포지션 방식은 한 번만 구현해두면 어떠한 Set 구현체라도 계측할 수 있으며, 기존 생성자들과도 함께 사용할 수 있다.

다른 Set 인스턴스를 감싸고(wrap) 있다는 뜻에서 InstrumentSet 같은 클래스를 래퍼 클래스라 하며, 다른 Set에 계측 기능을 덧씌운다는 뜻에서 데코레이터 패턴(Decorator patten)이라고 한다. 컴포지션과 전달의 조합은 넓은 의미로 위임(delegation)이라고 부른다. 단, 엄밀히 따지면 래퍼 객체가 내부 객체에 자기 자신의 참조를 넘기는 경우만 위임에 해당한다.

래퍼 클래스는 단점이 거의 없다. 한 가지, 래퍼 클래스가 콜백(callback) 프레임워크와는 어울리지 않는다는 점만 주의하면 된다. 콜백 프레임워크에서는 자기 자신의 참조를 다른 객체에 넘겨서 다음 호출(콜백) 때 사용하도록 한다. 내부 객체는 자신을 감싸고 있는 래퍼의 존재를 모르니 대신 자신(this)의 참조를 넘기고, 콜백 때는 래퍼가 아닌 내부 객체를 호출하게 된다. 이를 SELF 문제라고 한다.

그렇다면 상속은 언제..?

상속은 반드시 하위 클래스가 상위 클래스의 '진짜' 하위 타입인 상황에서만 쓰여야 한다. 즉, 클래스 B가 클래스 A와 is-a 관계일 때만 클래스 A를 상속해야 한다.

자바에서 상속을 잘못 사용한 예시

자바 플랫폼 라이브러리에서도 이 원칙을 명백히 위반한 클래스들을 찾아볼 수 있다. 예를 들어, 스택은 벡터가 아니므로 Stack은 Vector를 확장해서는 안 됐다. 마찬가지로, 속성 목록도 해시테이블이 아니므로 Properties도 Hashtable을 확장해서는 안 됐다. 두 사례 모두 컴포지션을 사용했다면 더 좋았을 것이다.

컴포지션을 써야 할 상황에서 상속을 사용하는 건 내부 구현을 불필요하게 노출하는 꼴이다. 그 결과 API가 내부 구현에 묶이고 그 클래스의 성능도 영원히 제한된다. 더 심각한 문제는 클라이언트가 노출된 내부에 직접 접근할 수 있다는 점이다. 예컨대 Properties의 인스턴인 p가 있을 때, p.getProperty(key)와 p.get(key)는 결과가 다를 수 있다. 전자가 Properties의 기본 동작인 데 반해, 후자는 Hashtable로부터 물려받은 메서드이기 때문이다.

가장 심각한 문제는 클라이언트에서 상위 클래스를 직접 수정하여 하위 클래스의 불변식을 해칠 수 있다는 사실이다. 예컨대 Properties는 키와 값으로 문자열만 허용하도록 설계하려 했으나, 상위 클래스인 Hashtable의 메서드를 직접 호출하면 이 불변식을 깨버릴 수 있다. 불변식이 한번 깨지면 다른 Properties API는 더 이상 사용할 수 없다.

컴포지션 대신 상속을 사용하기로 결정하기 전에 마지막으로 자문해야 할 질문을 소개한다.
확장하려는 클래스의 API에 아무런 결함이 없는가?
결함이 있다면, 이 결함이 여러분 클래스의 API까지 전파돼도 괜찮은가?
컴포지션으로는 이런 결함을 숨기는 새로운 API를 설계할 수 있지만, 상속은 상위 클래스의 API를 '그 결함까지도' 그대로 승계한다.

핵심 정리

상속은 강력하지만 캡슐화를 해친다는 문제가 있다.
상속은 상위 클래스와 하위 클래스가 순수한 is-a 관계일 때만 써야 한다.
- 하위 클래스의 패키지가 상위 클래스와 다르고, 확장을 고려해 설계되지 않았다면 여전히 문제될 수 있다.
상속의 취약점을 피하려면 상속 대신 컴포지션과 전달을 사용하자.
- 특히 래퍼 클래스로 구현할 적당한 인터페이스 가있다면 더욱 그렇다. 래퍼 클래스는 하위클래스보다 견고하고 강력하다.

[이펙티브 자바] 17. 변경 가능성을 최소화하라

Thu, 30 Dec 2021 00:00:00 GMT

불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다.
불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다.

자바 플랫폼 라이브러리에도 다양한 불변 클래스가 있다.
String, 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal이 여기 속한다.

불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.
클래스를 불변으로 만들려면 다음 다섯 가지 규칙을 따르면 된다.

객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.
클래스를 확장할 수 없도록 한다.
모든 필드를 final로 선언한다.
모든 필드는 private으로 선언한다.
자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

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

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

    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 c) {
        return new Complex(re + c.re, im + c.im);
    }

    public Complex minus(Complex c) {
        return new Complex(re - c.re, im - c.im);
    }

    public Complex times(Complex c) {
        return new Complex(re * c.re - im * c.im,
                re * c.im + im * c.re);
    }

    public Complex dividedBy(Complex c) {
        double tmp = c.re * c.re + c.im * c.im;
        return new Complex((re * c.re + im * c.im) / tmp,
                (im * c.re - re * c.im) / tmp);
    }

    @Override public boolean equals(Object o) {
        if (o == this)
            return true;
        if (!(o instanceof Complex))
            return false;
        Complex c = (Complex) o;

        // == 대신 compare를 사용하는 이유는 63쪽을 확인하라.
        return Double.compare(c.re, re) == 0
                && Double.compare(c.im, im) == 0;
    }
    @Override public int hashCode() {
        return 31 * Double.hashCode(re) + Double.hashCode(im);
    }

    @Override public String toString() {
        return "(" + re + " + " + im + "i)";
    }
}

이 사칙연산 메서드들이 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어 반환하는 모습에 주목하자.
이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다.

이와 달리, 절차적 혹은 명령형 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.

함수형 프로그래밍에 익숙하지 않다면 조금 부자연스러워 보일 수도 있지만, 이 방식으로 프로그래밍하면 코드에서 불변이 되는 영역의 비율이 높아지는 장점을 누릴 수 있다.
불변 객체는 단순하다. 불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다.

모든 생성자가 클래스 불변식(class invariant)을 보장한다면 그 클래스를 사용하는 프로그래머가 다른 노력을 들이지 않더라도 영원히 불변으로 남는다.
반면 가변 객체는 임의의 복잡한 상태에 놓일 수 있다. 변경자 메서드가 일으키는 상태 전이를 정밀하게 문서로 남겨놓지 않은 가변 클래스는 믿고 사용하기 어려울 수도 있다.

불변 객체 장점

불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다.
불변 객체에 대해서는 그 어떤 스레드도 다른 스레드에 영향을 줄 수 없으니 불변 객체는 안심하고 공유할 수 있다.
따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권한다. 가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것이다.

불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있다. 박싱된 기본 타입 클래스 전부와 BigInteger가 여기 속한다.
이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.
새로운 클래스를 설계할 때 public 생성자 대신 정적 팩터리르 만들어두면, 클라이언트를 수정하지 않고도 필요에 따라 캐시 기능을 덧붙일 수 있다.

불변 객체를 자유롭게 공유할 수 있다는 점은 방어적 복사도 필요 없다는 결론으로 자연스럽게 이어진다. 아무리 복사해봐야 원본과 똑같으니 복사 자체가 의미 없다. 그러니 불변 클래스는 clone 메서드나 복사 생성자를 제공하지 않는 게 좋다.

불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.
ex) BigInteger 클래스 내부에는 부호인 int 변수, 크기인 int 배열이 있다. negate 메서드는 크기가 같고 부호만 반대인 새로운 BigInteger를 생성하는데, 이때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 된다. 그 결과 새로 만든 BigInteger 인스턴스도 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.

객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다. 값이 바꾸지 않는 구성요소들로 이뤄진 객체라면 그 구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월하기 때문이다.

불변 객체는 그 자체로 실패 원자성을 제공한다.

불변 객체 단점

불변 클래스에도 단점은 있다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 것이다.
값의 가짓수가 많다면 이들을 모두 만드는 데 큰 비용을 처리해야 한다.
원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제가 더 불거진다.
이 문제에 대처하는 방법은 두 가지다.

흔히 쓰일 다단계 연산들을 예측하여 기본 기능으로 제공하는 방법.

다단계 연산을 기본으로 제공한다면 더 이상 각 단계마다 객체를 생성하지 않아도 된다.
- ex) BigInteger는 모듈러 지수 같은 다단계 연산 속도를 높여주는 가변 동반 클래스를 package-private으로 두고 있다.

클라이언트들이 원하는 복잡한 연산들을 정확히 예측할 수 있다면 package-private의 가변 동반 클래스만으로 충분하다. 그렇지 않다면 이 클래스를 public으로 제공하는게 최선이다. ex) String 클래스. String의 가변 동반 클래스는 StringBuilder(와 StringBuffer)

불변 클래스를 만드는 또 다른 설계 방법

클래스가 불변임을 보장하려면 자신을 상속하지 못하게 해야 함.
자신을 상속하지 못하게 하는 가장 쉬운 방법은 final 클래스로 선언하는 것이지만, 더 유연한 방법이 있다.
모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 방법이다.

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

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

    // 코드 17-2 정적 팩터리(private 생성자와 함께 사용해야 한다.) (110-111쪽)
    public static Complex valueOf(double re, double im) {
        return new Complex(re, im);
    }
}

외부에서 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 이 방식이 훨씬 유연하다.
패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다.
public이나 protected 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는 게 불가능하기 때문이다.
정적 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이에 더해 다음 릴리스에서 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.

불변 클래스의 규칙 목록에 따르면 모든 필드가 final이고 어떤 메서드도 그 객체를 수정할 수 없어야 한다. 사실 이 규칙은 조금 과한 감이 있어서, 성능을 위해 다음처럼 살짝 완화할 수 있다.
"어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다"
어떤 불변 클래스는 계산 비용이 큰 값을 나중에 계산하여 final이 아닌 필드에 캐시해놓기도 한다.

정리

getter가 있다고 해서 무조건 setter를 만들지는 말자.
- 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
- 불변 클래스는 장점이 많으며, 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐이다.
PhoneNumber와 Complex 같은 단순한 값 객체는 항상 불변으로 만들자.
- String과 BigInteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 고심해야 한다.
- 성능 때문에 어쩔 수 없다면 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자.
불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
- 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
- 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안 된다.
- 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안 된다. 복잡성만 커지고 성능 이점은 거의 없다.

[Java] Java Collection Framework를 알아보자 - 1. Collection Interface

Thu, 30 Dec 2021 00:00:00 GMT

Java를 사용하면 짱짱 많이 쓰게 되는 List, Set, Map.

List는 순서를 보장하고 Set은 순서는 보장하지 않지만 중복을 허용하지 않고 Map은 key, value 쌍으로 이루어져 있고...

요런 기본적인 부분은 알고 있지만 Collection Framework에 대해 조금 더 구체적으로 공부하고 싶어서 찾아서 정리해보았다.

JCF(Java Collections Framework)란?

자료구조(data structure)란 컴퓨터 과학에서 효율적인 접근 및 수정을 가능케 하는 자료의 조직, 관리, 저장을 의미한다. 즉, 데이터 값의 모임, 또는 데이터 간의 관계, 그리고 데이터에 적용할 수 있는 함수나 명령을 의미한다. 프로그래밍 언어는 이러한 자료구조를 제공해주는데 Java에서 제공해주는 자료구조가 바로 JCF(Java Collections Freamework)인 것이다.

JCF를 더 알아보기 전에 도입이 되었던 배경에 대해 이야기 해보자.

JCF는 JDK 1.2버전에 도입되었는데 그 이전에도 물론 Vector, HashTable, Properties와 같은 클래스들이 존재했다. 문제는 이러한 클래스들에는 공통 인터페이스가 없었다. 그래서 모든 클래스들의 주요 목적은 동일하지만 구현은 독립적으로 정의되었으며 서로 상관 관계가 없었다. 즉, 추가, 삭제하는 메서드들 등이 동일한 목적으로 사용되더라도 이름이 다 달랐다. 그러다보니 사용자 입장에서 모든 클래스들에 있는 다양한 메서드, 구문 및 생성자를 모두 기억하는 것은 매우 어려웠다.

그래서 Java 개발자는 이러한 문제를 처리하기 위해 공통 인터페이스를 마련하기로 결정하고 JDK 1.2에서 Collections Framework를 도입된 것이다!

지금의 Vector와 HashTable은 모두 Collections Framework를 준수하도록 수정되었기에 버전을 돌리지 않는 이상 옛날 코드는 보기 힘들다ㅎㅎ;

JCF의 장점

JCF로 인한 장점은 무엇일까?

Oracle 문서 를 보면 다음과 같은 내용이 적혀있다.

자료구조와 알고리즘을 제공하여 프로그래밍 노력을 줄여주므로 직접 작성할 필요가 없다.
자료구조와 알고리즘의 고성능 구현을 제공하여 성능을 향상시킨다.
컬렉션을 주고받는 공통 언어를 설정하여 관련 없는 api간의 상호 운용성을 제공한다.
api를 배우는데 필요한 노력을 줄여준다.
api를 디자인하고 구현하는데 필요한 노력을 줄여준다.
소프트웨어 재사용을 촉진한다.

상호 운용성, 재사용.. 객체지향의 특징을 최대한 살리려고 한게 느껴진다..

특히 공식 문서에 “Design Goals” 항목을 보게되면 어떤 목표를 가지고 설계했는지를 알 수 있는데 ‘핵심 인터페이스의 메서드 수를 작게 유지하기 위해’라는 문장이 적혀있다. 이는 SOLID 중 ISP를 지켜 만들었다고 해석될 수 있을 것 같다.

왜 Library가 아니고 Framework일까..?

Framework과 Library의 차이점을 알고 나서부터 Java Collections Framework는 왜 Framework라고 부를까? 에 대한 의문이 있었다.

제어를 개발자가 해주고 원하는 시점에 가져다 쓰는 것이면 라이브러리, 제어가 역전되어 전체적인 흐름을 스스로 가지고 있으면 프레임워크로 알고 있는데 그렇다면 JCF는 개발자가 필요에 따라 가져다 쓰는 것이니 라이브러리가 아닌가? 라고 생각했다.

검색을 해보니 실제로 이렇게 생각한 글 이 몇 개 있었다. 이 글에서는 기술적으로 말하면 JCF는 라이브러리처럼 작동하지만 공통 통합 아키텍처, 다른 API와의 통합 및 재사용성과 같은 프레임워크의 특징으로 인해 프레임워크라 부른다고 적혀있다. 라이브러리라기에는 규모가 방대하며 특정한 뼈대에 맞게 사용을 해야한다는 특징때문에 프레임워크라 부르는건가 생각하고 넘어가기로 했다.

Collection Interface

List

List Interface는 선형 자료구조로 순서가 있는 데이터 목록을 이용할 수 있도록 만든 인터페이스이다. 이 인터페이스의 사용자는 목록에서 각 요소가 삽입되는 위치를 정밀하게 제어할 수 있다. 즉, 배열에서 사용하듯 인덱스를 이용해 데이터의 접근이 가능하다는 뜻이다. 또한 데이터의 중복을 허용한다.

List Interface의 구현체는 다음과 있다.

ArrayList
- 특징
  
  ArrayList의 내부를 살펴보게 되면 Object[] 라는 배열로 이루어져 있다.
  
  배열의 크기는 default가 10이고 add 메서드를 통해 데이터가 삽입될 때 배열이 꽉 차면 Arrays.copyOf를 통해 새롭게 배열을 생성하게 된다. 이때 배열의 증가되는 크기는 기존 용량 + 기존 용량/ 2 (우측 쉬프트 연산자) 가 된다.
- 시간 복잡도
  
  ArrayList는 중간 인덱스에서 삽입, 삭제가 일어난다면 뒤에 있는 요소들을 전부 옮겨주는 작업을 해주어야 한다. 그러다보니 최악의 경우 시간 복잡도는 O(N)이다.
  
  조회의 경우 인덱스를 알고 있어 이를 통해 데이터 주소를 구할 수 있으므로 O(1)이 된다.

LinkedList
- 특징
  
  LinkedList는 데이터(item)와 주소(prev, next)로 이루어진 클래스를 만들어 서로 연결하는 방식이다. 이 클래스를 Node라고 하는데 각 노드에는 이전 노드, 다음 노드 객체를 필드로 가지고 있다.
- 시간 복잡도
  
  LinkedList의 삽입, 삭제는 각 노드의 참조만 변경시켜주면 되므로 O(1)이다. 여담이지만 중간에 삽입이나 삭제하면 데이터를 찾기까지 O(N)이 걸리므로 삽입, 삭제도 최악에는 O(N) 아냐? 라고 생각했는데 조회하는 건 별도의 작업으로 간주한단다 ㅎㅎ
  
  조회는 위에서 말한 것처럼 해당 데이터를 찾기위해 연결된 노드를 계속 방문해야 하므로 O(N)이다.

Vector (+ Vector를 상속받은 Stack)
- Vector 특징
  
  Vector는 1.2 버전 이전의 컬렉션 클래스다. 간단하게 말하면 1.2 이전의 ArrayList라고 할 수 있겠다. JCF가 도입되면서 기존의 호환성을 위해 남겨두었고 List Interface를 구현하도록 되어있다. 그렇다면 지금도 쓸 수 있다는 뜻인데 왜 Vector를 거의 본 적이 없는걸까?
  
  그 이유는 동기화 보장에 있다. Vector를 보게되면 멀티 스레드 환경에서 동기화를 보장하기 위해 synchronized 키워드가 메서드 이곳저곳 있는 것을 볼 수 있다. 이는 멀티 스레드에서는 안전할 지라도 싱글 스레드 환경에서는 성능이 떨어지기 때문에 ArrayList를 많이 사용하는 것이다.
  
  그렇다면 멀티 스레드 환경에서는 정말 Vector를 쓸까..? 그건 또 아닌 것 같다. 앞서 말했듯 Vector는 메서드 이곳저곳에 synchronized가 있는데 거의 모든 메서드라고 봐도 무방할 정도로 많이 있다. 그래서 오버헤드도 많이 발생하기 때문에 Collections.synchronizedList()를 사용해 동기화 보장을 해주는 것이 좋다.
```
List<String> list = Collections.synchronizedList(new ArrayList<>());
```
  그런데 조금 더 자세히 살펴보니 Vector의 메서드는 메서드 레벨에 synchronized 키워드가 있고 SynchronizedList에는 메서드 안에 synchronized 블록이 있는 것을 볼 수 있다. 무슨 차이가 있는지 후에 멀티 스레드를 좀 더 공부하면서 정리해봐야겠다.
- Stack 특징
  
  Stack은 흔히 알고 있는 LIFO 특징을 가진 자료구조다. 문제는 Vector를 상속해서 구현했기에 Vector의 단점을 모두 가지고 있다. 그래서 자바에서 친절하게 Stack이 아닌 Deque를 사용해라고 문서에 적혀있다.

Set

Set Interface는 중복 요소가 없고 입력 순서대로의 저장 순서를 보장하지 않는 데이터 집합을 이용할 수 있도록 만든 인터페이스이다.

Set Interface의 구현체는 다음과 같다.

HashSet
- 특징
  
  HashSet은 중복 요소가 없고 입력 순서를 보장하지 않는 컬렉션 클래스다.
  재밌게도 내부를 보게 되면 HashMap이 존재하고 HashSet의 생성자에서 HashMap을 생성해준다. 그리고 데이터를 삽입하는 add 메서드를 보면 아래와 같이 map에다가 저장하는 모습을 볼 수 있다. (여기서 PRESENT는 더미 데이터다.)
  즉, HashSet은 내부적으로 HashMap을 이용하여 데이터를 key에다가 삽입, 삭제, 조회한다. 이러한 key를 기반으로 hashCode와 버킷 수를 이용해 인덱스를 만들기 때문에 중복을 허용하지 않을 수 있는 것이다. 더 자세한 내용은 HashMap때 다루겠다!
- 시간복잡도
  
  HashSet은 따로 조회 메서드가 없는 대신에 Iterator를 이용해 데이터를 순회할 수 있다.
  삽입, 삭제의 경우 기본적으로 hashCode를 통해 key에 해당하는 인덱스로 접근하기에 O(1)이지만 최악의 경우 O(N)이 걸린다.
  이 최악의 경우는 Java에서 해시 충돌이 발생했을 때 어떤 방법을 사용하여 해결했는지와 관련있는데 마찬가지로 자세한 내용은 HashMap때 다루겠다..ㅎㅎ;;

LinkedHashSet
- 특징
  
  LinkedHashSet은 이름에서 알 수 있듯이 기존의 HashSet에 Link가 추가되어 순서를 보장할 수 있게 된다.
  즉, 중복은 허용하지 않으면서 순서를 보장하고 싶을 때 사용할 수 있는 컬렉션 클래스다.
  내부를 보게 되면 HashSet의 기능을 거의 다 가지면서 (HashSet을 상속하고 있음) 생성할 때 LinkedHashMap을 만들어서 사용한다.

TreeSet
- 특징
  
  TreeSet은 HashSet과 같이 중복 요소가 없고 입력 순서를 보장하지 않는 컬렉션 클래스다.
  단, HashSet과 달리 지정한 정렬 방법대로 순서를 정렬하여 저장한다.
  마찬가지로 내부를 보게 되면 TreeMap을 사용하는 모습을 볼 수 있다. TreeMap의 경우 정렬을 위해 Red-Black Tree를 사용하고 있다고 하며 Red-Black Tree에 대한 내용은 이 블로그 에서 자세하게 확인할 수 있다.

참고

[이펙티브 자바] 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

Tue, 28 Dec 2021 11:00:00 GMT

이따금 인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려 할 때가 있다.

clsaa Point {
    public double x;
    public double y;
}

이런 클래스는 데이터 필드에 접근할 수 있으니 캡슐화의 이점을 제공하지 못한다.
API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다.

철저한 객체 지향 프로그래머는 이런 클래스를 상당히 싫어해서 필드들을 모두 private으로 바꾸고 public 접근자(getter)를 추가한다.

class Point {
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public double getX() { return x; }
    public double getY() { return y; }

    public void setX(double x) { this.x = x; }
    public void setY(double y) { this.y = y; }
}

패키지 바깥에서 접근할 수 있는 클래스라면 접근자를 제공함으로써 클래스 내부 표현 방식을 언제든 바꿀 수 있는 유연성을 얻을 수 있다.
public 클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생겨날 것이므로 내부 표현 방식을 마음대로 바꿀 수 없게 된다.

package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출한다 해도 하등의 문제가 없다.
이 방식은 클래스 선언 면에서나 이를 사용하는 클라이언트 코드 면에서나 접근자 방식보다 훨씬 깔끔하다.
클라이언트 코드가 이 클래스 내부 표현에 묶이기는 하나, 클라이언트도 어차피 이 클래스를 포함하는 패키지 안에서만 동작하는 코드일 뿐이다.
따라서 패키지 바깥 코드는 전혀 손대지 않고도 데이터 표현 방식을 바꿀 수 있다. private 중첩 클래스의 경우라면 수정 범위가 더 좁아져서 이 클래스를 포함하는 외부 클래스까지로 제한된다.

자바 플랫폼 라이브러리에도 public 클래스의 필드를 직접 노출하지 말라는 규칙을 어기는 사례가 종종 있다.
대표적인 예가 java.awt.package 패키지의 Point와 Dimension.

내부를 노출한 Dimension 클래스의 심각한 성능 문제는 오늘날까지도 해결되지 못했다.

public final class Time {
    private static final int HOURS_PER_DAY    = 24;
    private static final int MINUTES_PER_HOUR = 60;

    public final int hour;
    public final int minute;

    public Time(int hour, int minute) {
        if (hour < 0 || hour >= HOURS_PER_DAY)
            throw new IllegalArgumentException("Hour: " + hour);
        if (minute < 0 || minute >= MINUTES_PER_HOUR)
            throw new IllegalArgumentException("Min: " + minute);
        this.hour = hour;
        this.minute = minute;
    }

    // 나머지 코드 생략
}

public 클래스의 필드가 불변이라면 직접 노출할 때의 단점이 조금은 줄어들지만, 여전히 결코 좋은 생각이 아니다.
API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없단느 단점은 여전하다. 단, 불변식은 보장할 수 있게 된다.

핵심 정리

public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다.
- 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다.
- 하지만 package-private 클래스나 private 중첩 클래스에서는 종종 (불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다.

[이펙티브 자바] 15. 클래스와 멤버의 접근 권한을 최소화하라

Tue, 28 Dec 2021 07:38:00 GMT

잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다.
오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다.

정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다.

정보 은닉의 장점

시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.
시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적기 때문이다.
정보 은닉 자체가 성능을 높여주지는 않지만, 성능 최적화에 도움을 준다. 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정한 다음 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화할 수 있기 때문.
소프트웨어 재사용성을 높인다. 외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않는 낯선 환경에서도 유용하게 쓰일 가능성이 크기 때문.
큰 시스템을 제작하는 난이도를 낮춰준다. 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문.

자바에서의 정보 은닉

자바는 정보 은닉을 위한 다양한 장치를 제공하는데 그중 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)을 명시한다.
각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자로 정해지는데 이를 제대로 활용하는 것이 정보 은닉의 핵심.

기본 원칙은 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
즉, 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다.

톱레벨 클래스와 인터페이스 부여할 수 있는 접근 수준은 package-private(default)과 public 두 가지다.
public으로 선언하면 공개 API가 되며, package-private으로 선언하면 해당 패키지 안에서만 이용할 수 있다.
패키지 외부에서 쓸 이유가 없다면 package-private으로 선언하자. 그러면 API가 아닌 내부 구현이 되어 언제든 수정할 수 있다.
즉, 클라이언트에 아무런 피해 없이 다음 릴리스에서 수정, 교체, 제거할 수 있다.
반면, public으로 선언한다면 API가 되므로 하위 호환을 위해 영원히 관리해줘야만 한다.

한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시켜보자.
톱레벨로 두면 같은 패키지의 모든 클래스가 접근할 수 있지만, private static으로 중첩시키면 바깥 클래스 하나에서만 접근할 수 있다.
물론 이보다 더 중요한 일은 public일 필요가 없는 클래스의 접근 수준을 package-private 톱레벨 클래스로 좁히는 일이다.

접근 수준 네 가지

멤버(필드, 메서드, 중첩 클래스, 중첩 인터페이스)에 부여할 수 있는 접근 수준은 네 가지다.

private: 멤버를 선언한 톱레벨 클래스에서만 접근할 수 있다.
package-private: 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 접근 제한자를 명시하지 않았을 때 적용되는 패키지 접근 수준. (단, 인터페이스의 멤버는 기본적으로 public이 적용된다.)
protected: package-private의 접근 범위를 포함하며, 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다. (제약이 조금 따른다.)
public: 모든 곳에서 접근할 수 있다.

클래스의 공개 API를 세심히 설계한 후, 그 외의 모든 멤버는 private으로 만들자.
그런 다음 오직 같은 패키지의 다른 클래스가 접근해야 하는 멤버에 한하여 (private 제한자를 제거해) package-private으로 풀어주자.
권한을 풀어주는 일을 자주 하게 된다면 여러분 시스템에서 컴포넌트를 더 분해해야 하는 것은 아닌지 다시 고민해보자.
private과 package-private 멤버는 모두 해당 클래스의 구현에 해당하므로 보통은 공개 API에 영향을 주지 않는다. 단, Serializable을 구현한 클래스에서는 그 필드들도 의도치 않게 공개 API가 될 수도 있다.

public 클래스에서는 멤버의 접근 수준을 package-private에서 protected로 바꾸는 순간 그 멤버에 접근할 수 있는 대상 범위가 엄청나게 넓어진다.
public 클래스의 protected 멤버는 공개 API이므로 영원히 지원돼야 한다. 또한 내부 동작 방식을 API 문서에 적어 사용자에게 공개해야 할 수도 있다. 따라서 protected 멤버의 수는 적을수록 좋다.

멤버 접근성을 좁히지 못하게 방해하는 제약이 하나 있다.

상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래에서보다 좁게 설정할 수 없다는 것.

이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 한다는 규칙(리스코프 치환 원칙)을 지키기 위해 필요하다. 이 규칙을 어기면 하위 클래스를 컴파일할 때 컴파일 오류가 난다.

테스트에서 접근 범위

테스트 목적으로 클래스, 인터페이스, 멤버의 접근 범위를 넓히려 할 때가 있다. 적당한 수준까지도 넓혀도 괜찮다.
예를 들어, public 클래스의 private 멤버를 package-private까지 풀어주는 것은 허용할 수 있지만, 그 이상은 안 된다.

즉, 테스트만을 위해 클래스, 인터페이스, 멤버를 공개 API로 만들어서는 안 된다.

public 클래스의 public 필드

public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.
필드가 가변 객체를 참조하거나, final이 아닌 인스턴스 필드를 public으로 선언하면 그 필드에 담을 수 있는 값을 제한할 힘을 잃게 된다. 그 필드와 관련된 모든 것은 불변식을 보장할 수 없게 된다는 뜻이다.
여기에 더해, 필드가 수정될 때 (락 획득 같은) 다른 작업을 할 수 없게 되므로 public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다.

정적 필드에서도 마찬가지이나, 상수라면 public static final 필드로 공개해도 좋다.
관례상 이런 상수의 이름은 대문자 알파벳으로 쓰며, 각 단어 사이에 밑줄(_)을 넣는다.
이런 필드는 반드시 기본 타입 값이나 불변 객체를 잠조해야 한다. 가변 객체를 참조한다면 final이 아닌 필드에 적용되는 모든 불이익이 그대로 적용된다.

길이가 0이 아닌 배열은 모두 변경 가능하니 주의하자.
따라서 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안 된다.

// 보안 허점이 숨어 있다.
public static final Thing[] VALUES = {...};

이런 필드나 접근자를 제공한다면 클라이언트에서 그 배열의 내용을 수정할 수 있게 된다.

해결책은 두 가지다.

private static final Thing[] PRIVATE_VALUES = {...};
public static final List<Thing> VALUES = 
    Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

첫 번째 방법은 public 배열을 private으로 만들고 public 불변 리스트를 추가하는 것.

private static final Thing[] PRIVATE_VALUES = {...};
public static final Thing[] values() {
    return PRIVATE_VALUES.clone();
}

두 번째는 배열을 private으로 만들고 그 복사본을 반환하는 public 메서드를 추가하는 방법(방어적 복사).

모듈 시스템에서의 두 가지 암묵적 접근 수준

자바 9에서는 모듈 시스템이라는 개념이 도입되면서 두 가지 암묵적 접근 수준이 추가되었다.

패키지가 클래스들의 묶음이듯, 모듈은 패키지들의 묶음이다.
모듈은 자신에 속하는 패키지 중 공개(export)할 것들을 (관례상 module-info.java 파일에) 선언한다.
protected 혹은 public 멤버라도 해당 패키지를 공개하지 않았다면 모듈 외부에서는 접근할 수 없다.

모듈 시스템을 활용하면 클래스를 외부에 공개하지 않으면서도 같은 모듈을 이루는 패키지에서는 자유롭게 공유할 수 있다.

두 가지 암묵적 접근 수준은 이 숨겨진 패키지 안에 있는 public 클래스의 public 혹은 protected 멤버와 관련이 있음. 암묵적 접근 수준들은 각각 public 수준과 protected 수준과 같으나, 그 효과가 모듈 내부로 한정되는 변종인 것.

모듈에 적용되는 새로운 두 접근 수준은 상당히 주의해서 사용해야 한다.
모듈의 JAR 파일을 자신의 모듈 경로가 아닌 애플리케이션의 클래스패스(classpath)에 두면 그 모듈 안의 모든 패키지는 마치 모듈이 없는 것처럼 행동한다.
즉, 모듈이 공개했는지 여부와 상관없이 public 클래스가 선언한 모든 public 혹은 protected 멤버를 모듈 밖에서도 접근할 수 있게 된다.

새로 등장한 이 접근 수준을 적극 활용한 대표적인 예가 바로 JDK 자체다.
자바 라이브러리에서 공개하지 않은 패키지들은 해당 모듈 밖에서는 절대 접근할 수 없다.

모듈은 여러 면에서 자바 프로그래밍에 영향을 준다.
모듈의 장점을 제대로 누리려면 해야 할 일이 많다.
먼저 패키지들을 모듈 단위로 묶고, 모듈 선언에 패키지들의 모든 의존성을 명시한다. 그런 다음 소스 트리를 재배치하고, 모듈 안으로부터 (모듈 시스템을 적용하지 않는) 일반 패키지로의 모든 접근에 특별한 조치를 취해야 한다.
JDK 외에도 모듈 개념이 널리 받아들여질지 예측하기는 아직 이른 감이 있다.
꼭 필요한 경우가 아니라면 당분간은 사용하지 않는 게 좋을 것 같다.

핵심 정리

프로그램 요소의 접근성은 가능한 한 최소한으로 하라.
꼭 필요한 것만 골라 최소한의 public API를 설계하자.
- 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야 한다.
public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안 된다.
- public static final 필드가 참조하는 객체가 불변인지 확인하라.