TIL

Chapter 11. 자바 언어의 성능 향상 기법

11.1 컬렉션 최적화

• 대부분 언어 라이브러리는 최소 두 가지 컨테이너를 제공한다.
  • 순차 컨테이너: 수치 인덱스로 표기한 특정 위치에 객체를 저장
  • 연관 컨테이너: 객체 자체를 이용해 컬렉션 내부에 저장할 위치를 결정
• 컨테이너에서 메서드가 정확히 작동하려면 객체가 호환성과 동등성 개념을 지니고 있어야 한다.
  • 코어 자바 컬렉션 API에서 모든 객체는 hashCode(), equals() 구현해야 한다.
• 참조형 필드는 힙에 레퍼런스로 저장된다.
  • 컨테이너에 저장되는 건 객체 자신이 아니라 객체를 가리키는 레퍼런스이기에 C/C++의 배열에서만큼의 성능을 얻을 순 없다.
• 자바는 서브시스템이 알아서 가비지 수집을 해주는 대신 저수준의 메모리 제어를 포기한다.
• 컬렉션 API는 타입별로 해당 컨테이너가 준수해야 할 작업을 구체적으로 명시한 인터페이스 모음

11.2 List 최적화

• 자바에서의 두 가지 리스트 기본 형태
  • ArrayList, LinkedList

11.2.1 ArrayList

• 고정 크기 배열에 기반한 리스트
  • 배열이 꽉 차면 더 큰 배열을 새로 할당해 기존 값을 복사
  • 성능을 신경쓰려면 크기 조정 작업 비용을 고려해야 함
• 기본 용량은 10이지만 초기 용량값을 생성자에 전달할 수도 있다.
  • new ArrayList<>(1000000);
• ensureCapacity() 메서드로 용량을 늘려 크기 조정 작업을 건너뛸 수 있다.

11.2.2 LinkedList

• 동적으로 증가하는 리스트
• 이중 연결 리스트이기에 add() 작업은 항상 O(1)이다.

11.2.3 ArrayList vs LinkedList

• 둘 중 어느 것을 쓸지는 데이터 접근/수정 패턴에 따라 다르다.
• 원소 추가 작업
  • 리스트 끝에 원소를 추가하는 작업은 두 리스트 모두 일정한 시간이 소요된다.
  • 특정 인덱스에 원소를 추가하는 경우 ArrayList는 다른 원소를 모두 한 칸씩 밀어야한다.
  • LinkedList는 특정 인덱스에 추가해도 레퍼런스만 변경하면 된다.
• 조회 작업
  • ArrayList는 랜덤 엑세스 하는 경우 모든 원소를 O(1)만에 가져올 수 있다.
  • LinkedList는 인덱스 카운트만큼 원소를 방문해야 한다.
• LinkedList 고유 기능이 필요한 경우가 아니고 랜덤 엑세스가 필요한 알고리즘에선 ArrayList를 권장
  • 가급적 크기를 미리 지정하여 중간에 다시 조정하는 일이 없도록 하는 것이 좋다.

11.3 Map 최적화

• 매핑이란 키와 연관된 값 사이의 관계를 뜻한다. (연관 배열이라고도 함)
• 자바는 java.util.Map<K, V> 인터페이스를 제공하며 키/값 모두 참조형이어야 한다.

11.3.1 HashMap

• HashMap 축소 버전 핵심 메서드

    public Object get(Object key) {
        // 편의상 널 키는 지원하지 않음
        if (key == null) return null;
      
        int hash = key.hashCode();
        int i = indexFor(hash, table.length);
        for (Entry e = table[i]; e != null; e = e.next) {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                return e.value;
        }
        return null;
    }
      
    private int indexFor(int h, int length) {
        return h & (length - 1);
    }
      
    static class Node implements Map.Entry {
        final int hash;
        final Object key;
        Object value;
        Node next;
      
        Node(int h, Object k, Object v, Entry n) {
            hash = h;
            key = k;
            value = v;
            next = n;
        }
    }
  

  • HashMap.Node 클래스는 java.util 패키지에서만 접근할 수 있다. (정적 클래스 사용하는 전형적인 유스케이스)

• HashMap 배치

  

  • 처음에 버킷 엔트리를 리스트에 저장
  • 값을 찾으려면 키 해시값을 계산하여 equals() 메서드로 리스트에서 키를 찾는다. (중복 허용 x)
• 자바 최근 버전에서 기존 indexFor() 메서드를 키 객체의 hashCode() 메서드를 사용하는 코드로 교체
  • 마스크를 적용해 상위 비트 아랫쪽 해시 부분에 분산시키도록 변경
  • 즉 해시값을 계산할 때 상위 비트를 무조건 반영하도록 설계한 것인데 이로 인해 인덱스 계산 시 상위 비트가 누락되는 것을 방지
• HashMap 생성자에 전달하는 두 매개변수는 성능에 큰 영향을 미친다.
  • initialCapacity: 현재 생성된 버킷 개 수(디폴트 16)
  • loadFactor: 버킷 용량 자동 증가시키는 한계치 (디폴트 2배)
  • 용량을 2배 늘리고 저장된 데이터를 재배치한 다음 해시를 다시 계산하는 과정을 재해시라고 한다.
• HashMap의 get(), put()은 일정 시간이 소요되지만 순회를 하면 비용이 증가할 수 있다.
• 트리화 또한 성능에 영향을 준다.
  • 버킷 원소를 LinkedList로 구현하면 리스트를 훑어보는 작업이 커질수록 비용이 더 든다.
  • 최신 HashMap은 한 버킷에 TREEIFY_THRESHOLD 값만큼 키/값 쌍이 모이면 버킷을 TreeNode로 비꾸어 마치 TreeMap처럼 동작한다.
  • TreeNode는 리스트 노드에 비해 2배 더 공간을 차지하기에 처음부터 쓰지는 않는다.
• LinkedHashMap
  • HashMap의 서브클래스로 이중 연결 리스트를 사용해 원소의 삽입 순서를 관리한다.
  • 기본 관리 모드는 삽입 순서이지만 엑세스 순서 모드로 변경 가능하다.
  • 순서가 중요한 코드에서 많이 사용되지만 TreeMap처럼 비용이 많이 들지 않는다.

11.3.2 TreeMap

• TreeMap은 레드-블랙 트래를 구현한 Map

  레드-블랙 트리: 기본 이진 트리 구조에 메타데이터를 부가(노드 컬러링)해서 트리 균형이 치우치는 현상을 방지한 트리

• TreeMap은 다양한 키가 필요할 때 아주 유용하다.
  • 서브맵에 신속히 접근 가능
  • 데이터를 분할하는 용도로도 쓰인다.
• TreeMap이 제공하는 get(), put(), containsKey(), remove() 메서드는 log(n) 작업 성능을 보장
• 스트림이나 람다로 Map 일부를 처리해야할 때 TreeMap을 쓰는편이 바람직하다.

11.3.3 MultiMap은 없어요

• 자바는 MultiMap(하나의 키에 여러 값을 묶은 맵) 구현체를 제공하지 않는다.
• 쓸 일이 드물다.
• 대부분 Map<K, List<V>> 형태로도 충분하다.

11.4 Set 최적화

• 자바엔 세 종류 Set이 존재하며 고려해야할 사항은 Map과 비슷하다.
  • 실제로 HashSet은 HashMap으로 구현되어 있다.
• Set은 중복을 허용하지 않기에 Map의 키 원소와 같다.
  • HashSet의 add() 메서드가 내부적으로는 HashMap의 키에 대응되고, 값은 PRESENT라는 더미 객체로 구성
  • 더미 객체는 처음 한 번 만들어 참조하기에 오버헤드는 무시할 정도
• HashSet의 삽입/삭제, contains 작업의 복잡도는 O(1)
  • 순서는 유지하지 않는다.
• 순회 비용은 initialCapacity, loadFactor에 따라 달라진다.
• TreeSet 역시 TreeMap을 활용
  • 삽입/삭제 복잡도는 log(n)이며 원소 순서 유지

11.5 도메인 객체

• 도메인 객체는 애플리케이션에 유의미한 비즈니스 컨셉트를 나타낸 코드
  • ex) Order, OrderItem, DeliverySchedule 등
• 도메인 객체는 대부분 타입 간에 연관되어 있다.
  • ex) 하나의 Order에는 여러 OrderItem 인스턴스가 매핑됨
• jamp -histo 명령이나 VisualVM 같은 GUI 툴을 통해 자바 힙 상태를 살펴볼 수 있는데 도메인 객체 메모리 누수 현상을 효과적으로 진단할 수 있다.
• 도메인 객체는 메모리 누수 같은 버그를 찾는 과정에서 쉽게 눈에 띈다.
  • 일차적인 비즈니스 관심사를 나타내고 어느정도 유일한 상태값을 지니기 때문
• 자바 힙에 관한 기본적인 사실
  • 가장 흔히 할당되는 자료 구조는 스트링, char 배열, byte 배열, 자바 컬렉션 타입의 인스턴스
  • jamp에서 누수되는 데이터는 비정상적으로 비대한 데이터셋으로 나타난다.
  • 즉 메모리 점유량과 인스턴스 개수 모두 보통 코어 JDK에 있는 자료 구조가 상위권을 형성하는 것이 보통
  • 만약 애플리케이션에 속한 도메인 객체가 jamp 결과치의 상위 30% 안에 든다면 메모리 누수의 신호
• 메모리 누수를 일으키는 도메인 객체의 또 다른 특징은 ‘전체 세대 효과’
  • 특정 타입 객체가 수집되지 않을 경우 테뉴어드 세대까지 살아남을 것이다.
  • 세대 카운트별(자료형별) 바이트 히스토그램을 찍어보면 누수 가능성이 있는 도메인 객체가 전 세대에 걸쳐 분포한다.
• 도메인 객체 메모리 누수 대처 방법
  • 도메인 객체에 대응되는 데이터셋 크기를 살피고 그 수치가 온당한지 살핀다.
  • 작업 세트에 존재하는 도메인 객체 수가 예상 범위 내에 들어 있는지 확인한다.
  • 알맞은 작업 세트가 배정되도록 해야 한다.
• 도메인 객체 역시 부유 가비지를 일으키는 또 다른 원인이 될 가능성이 농후하다.

누수를 일으키는 도메인 객체는 종종 GC 마킹 시간을 증가시키는 주범이다. 단명 객체가 긴 전체 객체 체인에 걸쳐 살아남기 때문

11.6 종료화 안 하기

• 자바 finalize() 메서드는 자동으로 리소스를 관리하려고 만든 장치
• 객체가 지닌 리소스를 자동으로 없애는 일은 프로그래머가 아닌 플랫폼의 몫

11.6.1 무용담: 정리하는 걸 깜빡하다.

• close() 호출은 정말 깜빡 잊고 놓치기 쉽다.
  • 특히 라이브러리를 사용할 때
• 리소스를 제 때 닫지 않으면 리소스가 소진되고 서버 지연이나 장애가 발생할 수 있다.

11.6.2 왜 종료화로 문제를 해결하지 않을까

• Object의 Finalize() 메서드는 자바 태동기부터 존재했다.
  • 런타임 내부 깊숙한 곳에 있는 어셈블리 코드에 기반해 객체를 미리 등록하고 특별한 GC 작업을 수행

어떤 객체가 더 이상 자신을 참조하지 않는다고 가비지 수집기가 판단하면 그 객체에 있는 finalize() 메서드를 호출한다. 서브 클래스는 finalize() 메서드를 오버라이드해서 시스템 리소스를 처분하는 등 기타 정리 작업을 수행한다.

• 종료화 가능 개별 객체는 Object 생성자 바디에서 성공 반환되는 시점에 해당 객체를 등록하는 식으로 JVM에 구현돼 있다.
  • 핫스팟 인터프리터에 등록하는 코드가 존재
• 가비지 수집 중 즉시 회수되지 않고 종료화 대상으로 등록된 객체는 다음과 같이 수명이 연장된다.
  1. 종료화 가능 객체는 큐로 이동
  2. 애플리케이션 스레드 재시작 후 별도의 종료화 스레드가 큐를 비우고 각 객체마다 Finalize() 실행
  3. 종료되면 객체는 다음 사이클에 진자 수집될 준비를 마친다.
• Finalize() 문제점
  • 종료화 가능 객체는 적어도 한 번의 GC 사이클은 더 보존되기에 테뉴어드 세대 객체인 경우 상당히 긴 시간 동안 회수되지 않을 수 있다.
  • 종료화 스레드 실행 도중 예외가 발생하면 유저 애플리케이션 코드 내부엔 아무런 컨텍스트가 없기에 예외는 무시된다.
  • 종료화에 블로킹 작업이 있을지 모르니 JVM이 스레드를 하나 더 만들어 Finalize()를 실행해야 한다. (스레드 생성 오버헤드 감수)
  • 가비지 수집은 정해진 시간에 실행되는 법이 없으므로 종료화를 자동으로 리소스를 관리한다는 것 자체가 무리 (리소스 고갈의 위험)
• 자바 9부터 Object.Finalize()는 디프리케이트 됐다.

11.6.3 try-with-resources

• 자바 7 이전까진 개발자가 책임지고 리소스를 닫아야 했다.

    public void readFirstLineOld(File file) throws IOException {
        BufferReader reader = null;
        try {
            reader = new BufferedReader(new FileReader(file));
            // ...
        } finally {
            if (reader != null) {
                reader.close();
            }
        }
    }
  

  • 닫아야할 리소스가 여러개가 되면 엄청 코드가 복잡해진다.

• 자바 7부터 try-with-resources 생성자를 통해 AutoCloseable 인터페이스를 구현한 객체를 자동으로 닫을 수 있다.

    public void readFirstLineNew(File file) throws IOException {
        try (BufferedReader reader = new BufferedReader(new FileReader(file))) {
            String firstLine = reader.readLine();
            // ...
        }
    }
  

  • 클래스를 해제/정리하는 방법을 일일이 코드로 기술할 필요가 없다.
  • 견고하고 캡슐화된 버그 없는 코드의 완성

• 런타임 GC에 의존하는 종료화와 달리 try-with-resources는 순수한 컴파일 타임 기능이다.

  • 상당히 큰 바이트코드로 변환되기에 JIT 컴파일러가 인라이닝하는 과정에 좋지 않을 수도 있다.

11.7 메서드 핸들

• 자바 7에 등장한 invokedynamic 명령어 덕분에 호출부에서 실행할 메서드를 유연하게 결정할 수 있게 되었다.
  • 어느 메서드를 호출할지 런타임 전까지 결정되지 않는다.
  • 호출부가 인터프리터에 이르면 특수한 보조 메서드(부트스트랩 메서드, BSM)가 호출되고 BSM이 실제 메서드를 가리키는 객체를 반환
  • 가장 단순한 경우 호출부를 처음 만난 시점에 한 번만 룩업 작업을 한다. (복잡한 경우엔 호출부가 무효화되어 다시 룩업하는 경우도 있음)
• 메서드 핸들이란 invokedynamic 호출부에 의해 호출되는 메서드를 나타낸 객체

• 자바 7부터 일부 클래스, 패키지(MethodHandle)가 추가되어 실행 가능한 메서드의 레퍼런스를 직접 반영할 수 있게 됐다.

    MethodType mt = MethodType.methodType(int.class);
    MethodHandles.Lookup l = MethodHandles.lookup();
    MethodHandle mh = l.FindVirtual(String.class, "hashCode", mt);
      
    String reveiver = "b";
    int ret = (int) mh.invoke(receiver);
    System.out.println(ret);
  

  • 메서드 핸들을 룩업하는 것과 호출하는 부분이 나누어져 있다.
  • 실제 시스템에선 이 두 부분이 코드 위치 측면에서 멀리 분리되어 있을 수도 있다.
  • 메서드 핸들은 불변 객체라 캐시하기가 쉽다.
• 클래스가 처음 로딩되면 VM은 바이트코드를 전수 검사하여 엑세스 권한을 검사한다.
  • 한 번 로딩된 클래스는 성능 상 두 번 다시 검사하지 않는다.
  • 이 틈새를 리플렉션 코드가 파고들어 엑세스 권한을 위반할 수도 있다.
• 메서드 핸들 API는 룩업 컨텍스트 방식으로 접근한다.
  • MethodHandles.lookup() 메서드로 컨텍스트 객체를 생성
  • 반환된 불변 객체엔 컨텍스트를 생성한 시점에 엑세스 가능한 메서드 및 필드를 기록한 상태 정보가 있다.
  • 컨텍스트 객체는 바로 사용해도 되고 저장했다가 나중에 써도 된다.
• 컨텍스트 객체는 유연하여 클래스의 프라이빗 메서드를 선택적으로 엑세스할 수도 있다.
  • 룩업 객체를 캐시하고 엑세스를 필터링하는 방법을 사용
  • 리플렉션은 setAccessible()말고는 방법이 없어 자바의 안전한 접근 제어 체계에 허점을 노출시킨다.
  • 룩업 컨텍스트에선 리플렉션과 달리 개발자가 엑세스 체크 로직을 없애거나 해제할 수 없다.

대부분 개발자에게 메서드 핸들이란 코어 리플렉션과 기능은 비슷하나 최대한 정적 타입을 안전하게 지키는 요즘 방식의 리플렉션이라고 생각하면 된다.