이펙티브 자바, 쉽게 정리하기 - item 61. 박싱된 기본 타입보다는 기본 타입을 사용하라

이펙티브 자바, 쉽게 정리하기 - item 61. 박싱된 기본 타입보다는 기본 타입을 사용하라

기본 타입과 박싱된 기본 타입의 차이

• 기본 타입은 값만 가지고 있으나, 박싱된 기본 타입은 식별성(identity)이라는 속성도 갖는다.
• 기본 타입의 값은 언제나 유효하나, 박싱된 기본 타입은 null을 가질 수 있다.
• 기본 타입이 박싱된 기본 타입보다 메모리 면에서 우수하다.

문제가 생기는 코드 살펴보기

의도치않은 식별성 검사

public class Item61Test {
    Comparator<Integer> naturalOrder = (i, j) -> (i < j) ? -1 : (i == j ? 0 : 1);

    @Test
    public void naturalOrderTest() {
        int compare = naturalOrder.compare(new Integer(42), new Integer(42));
        System.out.println("compare = " + compare);
    }
}

• 분명 의도한대로라면 0(동일함) 이 나와야 하는데 결과가 1(다름) 이 나온다.
  • int 기본 타입을 상정하고 == 을 이용해 코드를 짰는데, 실제로는 Integer 라는 박싱된 기본 타입이 들어와버려서 객체끼리 == 연산을 수행한 것처럼 코드가 동작했다.
    • 객체끼리 == 연산을 수행하면, 같은 주소값에 있는 객체가 아니면 false 이기 때문에 1 이 나와버린다. 이를 객체 참조의 식별성 검사라고 한다.
    • 최소한 equals() 였다면 올바른 값이 나왔을 것이다.
    • 가장 이상적인 것은 Integer.compare() 를 사용하는 것이다.

기본 타입에서의 NullPointerException

static Integer i;

@Test
public void nullPointerException() {
    if(i == 42) {
        System.out.println("i = " + i);
    }
}

• 컴파일타임에 아무런 에러도 잡지 못한다.
• 실행시키는 순간 NullPointerException 을 던진다.
  • 내부적으로는 박싱 타입인 Integer 객체와 기본 타입 int 를 비교한 것이다.
• 해법은 i 를 애초에 기본타입인 int 로 선언했으면 된다.
  • 이 경우 자동으로 0으로 초기화되기 때문에 NullPointerException 은 날아오지 않는다.

의도치 않은 속도 저하

@Test
public void unintendedBoxing() {
    Long sum = 0L;
    for (long i = 0; i < Integer.MAX_VALUE; i++) {
        sum += i;
    }

    System.out.println("sum = " + sum);
}

• 실행결과 2.647초 가 걸린다.
• 속도 병목이 발생되는 부분은 실제 연산이 아닌 i 가 더해지고 그 이후에 계속 그 값이 Long 으로 박싱되는 부분이다.

개선 후

@Test
public void unintendedBoxing() {
    long sum = 0L;
    for (long i = 0; i < Integer.MAX_VALUE; i++) {
        sum += i;
    }

    System.out.println("sum = " + sum);
}

• 실행 결과 0.7초 로 소요시간이 많이 줄어든다.

박싱된 기본 타입을 쓰는 경우

• 컬렉션의 원소, 키, 값
  • 컬렉션은 원래는 기본 타입을 담을 수 없기 때문이다.
• 리플렉션을 통해 메서드를 호출할 때

핵심 정리

• 박싱된 기본 타입과 기본 타입 중 별 이유가 없으면 그냥 기본 타입을 쓰는 게 좋다.
• 기본 타입 사용 중 나타나는 오토박싱은 잠재적 위협을 만들 때가 있으니 주의하자.
  • NullPointerException, 필요 없는 객체 생성, 속도 이슈