반응형
이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다.
아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라
가변인수 메서드와 제네릭은 잘 어우러지지 않는다.
가변인수(varargs)
- 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해주는데, 구현 방식에 허점이 존재함
- 가변인수 메서드를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어지는데 내부로 감춰야 했을 이 배열을 클라이언트에 노출하는 문제가 발생한다.
- 그 결과 varaargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생함
실체화 불가 타입
- 실체화 불가 타입은 런타임 시, 컴파일 할 떄보다 타입 관련 정보를 적게 담고 있다.
- 거의 모든 제네릭과 매개변수화 타입은 실체화 불가 타입이다.
- 메서드를 선언할 때 실체화 불가 타입으로 varargs 매개변수를 선언하면 컴파일러가 경고를 일으킨다.
- 가변인수 메서드를 호출할 때도 varargs 매개변수가 실체화 불가 타입으로 추론되면, 그 호출에 대해서도 경고를 발생시킨다.
warning: [unchecked] Possible heap pollution from
parameterized vararg type List<String>
- 매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다.
- 이렇게 다른 타입 객체를 참조하는 상황에서는 컴파일러가 자동 생성한 형변환이 실패할 수 있으니, 제네릭 타입 시스템이 약속한 타입 안전성의 근간이 흔들린다.
ex1) 제네릭과 varags를 혼용한 소스(타입 안정성이 깨짐)
static void danferous(List<String>... stringLists) {
List<Integer> intList = List.of(42);
Object[] objects = stringLists;
objects[0] = intList; // 힙 오염 발생
String s = stringLists[0].get(0); // ClassCastException
}
- 이 메서드에서는 형변환하는 곳이 보이지 않는데도 인수를 건네 호출하면 ClassCastException이 발생한다.
- 마지막 줄에 컴파일러가 생성한 보이지않는 형변환이 숨어있기 때문
- 이처럼 타입 안정성이 깨지니 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.
@SafeVarargs Annotation
- 자바 7 전에는 제네릭 가변인수 메서드의 작성자가 호출자 쪽에서 발생하는 경고에 대해서 해줄 수 있는 일이 없었고, @SuppressWarnings(”unchecked”) 어노테이션을 달아 경고를 숨겨왔다. → 이 작업은 지루한 작업이고, 가독성을 떨어뜨리며 진짜 문제를 알려주는 경고마저 숨기는 결과를 초래할 수 있다.
- 자바 7 이상 부터는 @SafeVarargs 어노테이션이 추가되어 제네릭 가변인수 메서드 작성자가 클라이언트 측에서 발생하는 경고를 숨길 수 있다.
- @SafeVarargs : 메서드 작성자가 그 메서드가 타입 안전함을 보장하는 장치
- 메서드가 안전한 게 확실하지 않다면 절대 @SafeVarargs 어노테이션을 사용하면 안된다.
메서드가 안전한 지 확인하는 방법
- 가변인수 메서드를 호출할 때 varargs 매개변수를 담는 제네릭 배열이 만들어진다
- 메서드가 이 배열에 아무것도 저장하지 않고(그 매개변수들을 덮어쓰지 않고) 그 배열의 참조가 밖으로 노출되지 않는다면(신뢰할 수 없는 코드가 배열에 접근할 수 없다면) 타입 안전하다.
- 즉, 이 varargs 매개변수 배열이 호출자로부터 그 메서드로 순수하게 인수들을 전달하는 일만 한다면 그 메서드는 안전하다.
- 이 때, varargs 매개변수 배열에 아무것도 저장하지 않고도 타입 안정성을 깰수도 있으니 주의해야한다.
ex 2) 자신의 제네릭 매개변수 배열의 참조를 노출하는 코드(안전하지 않음)
static <T> T[] toArray(T... args) {
return args;
}
- 이 메서드가 반환하는 배열의 타입은 이 메서드에 인수를 넘기는 컴파일타임에 결정되는데, 그 시점에는 컴파일러에게 충분한 정보가 주어지지 않아 타입을 잘못 판단 할 수 있다.
- 그 결과, 자신의 varargs 매개변수 배열을 그대로 반환하면 힙 오염을 이 메서드를 호출한 쪽의 콜스택으로까지 전이하는 결과를 야기할 수 있다.
ex 3) T타입 인수 3개를 받아 그 중 무작위로 골라 담은 배열을 반환하는 메서드
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(a, b);
case 2: return toArray(a, b);
}
throw new AssertionError(); // 도달할 수 없다.
}
- 이 메서드는 제네릭 가변인수를 받는 toArray 메서드를 호출하는 부분을 뺴면 위험하지 않고 경고를 발생시키지도 않는다.
- 컴파일러는 toArray에 넘길 T인스턴스 2개를 담을 varargs 매개변수 배열을 만드는 코드를 생성한다.
- 이 코드가 만드는 배열의 타입은 Object[]인데, pickTwo에 어떤 타입의 객체를 넘기더라도 담을 수 있는 가장 구체적은 타입이기 때문이다.
- toArray 메서드가 돌려준 이 배열이 그대로 pickTwo를 호출한 클라이언트까지 전달된다. 즉, pickTwo는 항상 Object[] 타입 배열을 반환한다.
ex 4) pickTwo를 사용하는 main 메서드
public static void main(String[] args) {
String[] attributes = pickTwo("좋은", "빠른", "저렴한");
}
- 문제 없는 메서드기에 별다른 경고 없이 컴파일 되지만 실행 시, ClassCastException이 발생된다.
- PickTwo의 반환값을 attributes에 저장하기 위해 String[]로 형변환하는 코드를 컴파일러가 자동 생성하기 때문이다. (Object[]는 String[]의 하위 타입이 아니므로 이 형변환은 실패함)
- 이렇게, 제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다.
- 단, 예외가 2개 있다.
- @SafeVarargs로 제대로 어노테이션 된 또라느 varargs 메서드에 넘기는 건 안전하다.
- 이 배열 내용의 일부 함수를 호출만 하는 (varargs를 받지 않는) 일반 메서드에 넘기는 것도 안전하다.
ex 5) 제네릭 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;
}
- flatten 메서드는 임의 개수의 리스트를 인수로 받아, 받은 순서대로 그 안의 모든 원소를 하나의 리스트로 옮겨 담아 반환한다.
- 이 메서드에는 @SafeVarargs 어노테이션이 달려있으니 선언하는 쪽과 사용하는 쪽 모두에서 경고를 발생시키지 않는다.
- 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에 @SafeVarargs 어노테이션을 달자
varargs 매개변수를 List 매개변수로 바꿔보기
ex 6) 제네릭 varargs 매개변수를 List로 대체한 코드 (타입 안전함)
@SafeVarargs
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;
}
- @SafeVarargs 어노테이션이 유일한 정답은 아니다.
- 정적 팩터리 메서드인 List.of를 활용하면 다음 코드와 같이 이 메서드에 임의 개수의 인스턴스를 넘길 수 있다.
- List.of에도 @SafeVarargs 어노테이션이 달려있어 이와 같이 사용이 가능하다.
정리
- 가변인수와 제네릭은 잘 어울리지 않는다.
- 가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하고, 배열과 제네릭의 타입 규칙이 서로 다르기 때문이다.
- 제네릭 varargs 매개변수는 타입 안전하지 않지만 허용된다.
- 메서드에 제네릭 (혹은 매개변수화된) varargs 매개변수를 사용하자고 한다면, 먼저 그 메서드가 타입 안전한 지 확인한 다음 @SafeVarargs 어노테이션을 사용하자
반응형
'BE > Java' 카테고리의 다른 글
[Effective Java] 34. int 상수 대신 열거 타입을 사용하라 (0) | 2022.10.21 |
---|---|
[Effective Java] 33. 타입 안전 이종 컨테이너를 고려하라 (0) | 2022.10.19 |
[Effective Java] 아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라 (1) | 2022.10.18 |
[Effective Java] 아이템 30. 이왕이면 제네릭 메서드로 만들라 (1) | 2022.10.13 |
[Effective Java] 아이템 29. 이왕이면 제네릭 타입으로 만들라 (0) | 2022.10.12 |