DEV ℧ Developer Diary

[EffectiveJava] item32 - 제네릭과 가변인수를 함께 쓸 때는 신중해라

30 Apr 2023

먼저 가변인수 메서드에 대해 가볍게 정리를 하고 넘어가자

가변인수(varargs) 메서드란? 아래의 메소드와 같이 매개변수를 n개 이상으로 받는 메서드를 말한다.

public List<String> getStringList(String... words) {
    return Arrays.asList(words);
}

가변인수(varargs) 메서드와 제네릭은 같이 사용할때 주의할점이 있어, 신중하게 사용해야한다.
가변인수 메서드를 호출하면 가변인수를 담기위한 배열이 자동으로 하나 생성되는데, 내부로 감춰야할 이 배열이 클라이언트에 노출되는 문제가 생겼다.
그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생한다.

실체화 불가 타입은 런타임에는 컴파일타임보다 타입 관련 정보를 적게 담고있다. 그리고 거의 모든 제네릭과 매개변수화 타입은 실체화되지 않으므로, 메서드를 선언할 때 실체화 불가 타입으로 varargs 매개변수를 선언하면 컴파일러가 경고를 보낸다.

warning: [unchecked] Possible heap pollution from parameterized vararg type List<String>

가변인수 메서드의 오류

매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다. 이렇게 다른 타입 객체를 참조하는 상황에서는 컴파일러가 자동 생성한 형변환이 실패할 수 있으니, 제네릭 타입 시스템이 약속한 타입 안정성의 근간이 흔들려버린다.

다음 메소드로 예시를 한번 들어보자.

static void dangerous(List<String>... stringLists) {
    List<Integer> intList = List.of(42);
    Object[] objects = stringLists;
    objects[0] = intList;               /** 힙 오염 발생 */
    String s = stringLists[0].get(0);   /** ClassCastException */
}

이 메소드는 형변환이 보이지 않지만, 마지막 줄에 컴파일러가 생성한 (보이지 않는) 형변환이 숨겨 있기 때문에 인수를 건네 호출하면 ClassCastException이 발생한다.

이처럼 타입 안전성이 깨지니 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.

또 하나의 코드를 확인해보자.

아래의 코드는 바로 위의 코드의 가변인수 매개변수를 받지않고 메소드 내부에서 선언해 직접 사용하는 코드이다. 그런데 해당 코드는 위의 코드와달리 컴파일 에러가 발생한다.

static void dangerous(){
    List<String>[]stringLists=new List<String>[1];
    List<Integer> intList=List.of(42);
    Object[]objects=stringLists;
    objects[0]=intList;
    String s=stringLists[0].get(0);
}

왜 제네릭 배열을 직접 생성하는건 허용하지 않지만, 제네릭 varargs 매개변수를 받는 메서드를 선언할 수 있게한 이유는 무엇일까?

제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 메서드가 실무에서 매우 유용하기 때문이다.

자바 라이브러리도 Arrays.asList(T... a), Collections.addAll(Collection<? super T> c, T... elements) 와 같은 비슷한 메서드를 여럿 제공한다. 하지만 이 메서드들은 타입 안전하다.

@SafeVarargs

자바 7 이후 부터 @SafeVarargs 애너테이션이 추가되어 가변인수 메서드 작성자가 코드에서 발생하는 경고를 숨길 수 있게 되었다.

@SafeVarargs 애너테이션은 메서드 작성자가 그 메서드가 타입 안전함을 보장 하는 장치다. 그러므로 메서드가 안전한 게 확실하지 않다면 절대 @SafeVarargs 애너테이션을 달아서는 안된다.

그렇다면 메서드가 안전한지 어떻게 확신할 수 있을까?

가변인수 메서드를 호출할 때 varargs 매개변수를 담는 제네릭 배열이 생성되는것을 기억하자. 메서드가 이 배열에 아무것도 저장하지 않고(그 매개변수들을 덮어쓰지 않고) 그 배열의 참조가 밖으로 노출되지 않는다면(신뢰할 수 없는 코드가 배열에 접근할 수 없다면) 타입 안전하다.

정리하자면 이 varargs 매개변수 배열이 호출자로부터 그 메서드로 순수하게 인수들을 전달하는 일만 한다면 그 메서드는 안전하다.

잘못된 예시

하지만 저장을 하지않고 전달을 하는 상황에서도 타입 안전성을 깰 수 가 있다. 다음의 예시를 살펴보자.

다음의 코드는 가변인수로 넘어온 매개변수들을 배열로 담아 반환하는 제네릭 메서드이다. 얼핏보면 편리해보이지만, 보기와 달리 위험하다.

static <T> T[] toArray(T... args) {
    return args;
}

이 메서드가 반환하는 배열의 타입은 이 메서드에 인수를 넘기는 컴파일 타임에 결정되는데, 그 시점에는 컴파일러에게 충분한 정보가 주어지지 안아 타입을 잘못 판단할 수 있다.

구체적인 예시를 살펴보자. 다음의 예시는 위의 toArray 메서드를 이용해 전달받은 세개의 매개변수중 두개를 랜덤으로 배열에 담아 반환하는 메서드이다. 하지만 다음의 메서드는 toArray 메서드를 호출한다는 점만 빼면 위험하지 않고 경고도 내지 않는다.

static <T> T[] pickTwo(T a, T b, T c) {
    switch(ThreadLocalRandom.current().nextInt(3)) {
        case 0: return toArray(a, b);
        case 1: return toArray(b, c);
        case 2: return toArray(a, c);
    }
}

위의 코드가 만드는 배열의 타입은 Object[] 인데, picTwo에 어떤 타입의 객체를 넘기더라도 담을 수 있는 가장 구체적인 타입이기 때문이다. 또한 toArray 메서드가 돌려준 이배열이 그대로 pickTwo를 호출한 클라이언트까지 전달된다.

즉, pickTwo는 항상 Object[] 타입 배열을 반환한다.

여기까지는 무슨 문제가 있냐고 생각될것이다. 이제 진짜 문제가 되는 코드를 살펴보자.

아래의 코드는 아무런 문제가 없는 메서드이니 별다른 경고 없이 컴파일 된다. 하지만 실행을 할 경우 ClassCastException이 발생힌다.

public static void main(String[] args) {
    String[] attributes = pickTwo("좋은", "빠른", "저렴한");
}

따로 형변환하는 코드를 작성하지 않았는데 왜 해당 에러가 발생할까?

pickTwo의 반환값을 attributes에 저장하기 위해 String[]로 형변환하는 코드를 컴파일러가 자동으로 생성하기 때문이다. Object[]는 String[]의 하위타입이 아니므로 이 형변환은 실패한다.

이 예시는 제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다는 점을 다시한번 상기시킨다.

단 예외가 두가지 있다.

첫번째로는 @SafeVarargs로 제대로 애노테이트된 또다른 varargs 메서드를 넘기는건 안전하다. 두번째로는 그저 이 배열 내용의 일부 함수를 호출만하는 일반 메서드에 넘기는 것도 안전하다.

올바른 예시

그럼 한번 varargs 매개변수를 안전하게 사용하는 예시를 살펴보자.

@SafeVarargs
static <T> List<T> flatten(List<? extends T>... lists) {
    List<T> result = new ArrayList<>();
    for (List<? extends T> list : lists)
        result.addAll(list);
    return result
}

@SafeVarargs 애너테이션을 사용해야 할 때를 정하는 규칙은 간단하다. 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에 @SafeVarargs를 달면 된다.

이 말은 안전하지 않은 varargs 메서드는 절대 작성해서는 안된다는 뜻이다.

다음과 같은 규칙을 어긴다면 당장 수정해주도록 하자.

  • varargs 매개변수 배열에 아무것도 저장하지 않는다.
  • 그 배열(혹은 복제본)을 신뢰할 수 없는 코드에 노출하지 않는다.

@SafeVarargs 애너테이션은 재정의 할 수 없는 메서드에만 달아야한다. 재정의한 메서드도 안전할 지는 보장할 수 없기 때문이다.

그외 방법은?

@SafeVarargs 애너테이션만 유일한 정답은 아니다. varargs 매개변수를 List 매개변수로 바꿀 수도 있다. 이 방식을 앞서의 flatten 메서드에 적용하면 다음처럼 된다.

static <T> List<T> flatten(List<List<? extends T>> lists) {
    List<T> result = new ArrayList<>();
    for (List<? extends T> list : lists)
        result.addAll(list);
    return result
  }

정적 팩토리 메서드인 List.of를 활용하면 varargs 매개변수와 같이 임의 개수의 인수를 넘길 수 있다. 이렇게 사용하는게 가능한 이유는 List.of에도 @SafeVarargs이 달려 있기 때문이다.

audience = flatten(List.of(friends, romans, countrymen));

이와 같은 방식은 코드가 살짝 지저분해지고, 속도가 조금 느려질 수는 있지만, @SafeVarargs 애너테이션을 직접 달지 않아도 되며, 컴파일러가 이 메서드의 타입 안정성을 검증할 수 있다는 데 있다.

만약 이러한 방식을 이용해 위의 잘못된 예시를 수정한다면 아래와 같이 작성할 수 이다.

public static void main(String[] args) {
    List<String> attributes = pickTwo("좋은", "빠른", "저렴한");
}


static <T> List<T> pickTwo(T a, T b, T c) {
    switch(ThreadLocalRandom.current().nextInt(3)) {
        case 0: return List.of(a, b);
        case 1: return List.of(b, c);
        case 2: return List.of(a, c);
    }
}

Related posts