아이템61. 박싱된 기본 타입보다는 기본 타입을 사용하라.

[YuDeokRin]

item61. 박싱된 기본 타입보다는 기본 타입을 사용하라.

⚓️서론

자바의 데이터 타입은 크게 두 가지로 나눌 수 있다.

기본타입(Primitive Type) 과 참조타입(Reference Type) 이 있다.

기본타입에는 각각 대응하는 참조타입이 있는데, 그것을 박싱된 기본타입이라고 한다.

기본 타입	래퍼(박싱) 타입
byte	Byte
short	Short
int	Integer
long	Long
float	Float
double	Double
char	Character
boolean	Boolean

---

➡️오토 박싱(AutoBoxing)과 오토 언박싱(AutoUnBoxing)

// Integer -> int
Integer num = new Integer(10);
int i = num; // Auto UnBoxing

//int -> Integer 
int num2 = 10;
Integer j = 10; // Auto Boxing

JDK 1.5부터는 박싱과 언박싱이 필요한 상황에서 자바 컴파일러가 이를 자동으로 처리해준다.

그전에는 시대는.. 참 귀찮았다.

• intValue()메소드를 사용해서 UnBoxing

Integer num = new Integer(10); // Boxing
int n = num.intValue();        // Unboxing

• Integer.valueOf() 메소드를 사용해서 Boxing

int num2 = 10;
Integer j = Integer.valueOf(num2); // Boxing

그렇다면 기본 타입과 래퍼타입은 무슨 차이일까?

---

➡️기본타입(Primitive Type) VS 박싱된 기본타입(Wrapper Type)

• 두 개의 차이점은 크게 세 가지다.

1️⃣ 기본 타입은 값만 가지고 있다. 반면에 박싱된 기본타입은 값 + 식별성 속성 을 갖고 있다.

2️⃣ 기본 타입의 값은 언제나 유효하지만 박싱된 기본 타입은 유효하지 않는 값, Null을 가질 수 있다.

3️⃣ 기본 타입이 박싱된 기본 타입보다 시간과 메모리 사용면에서 더 효율적이다.  

📎참고 - Java Primitives versus Objects

위의 세 가지를 유의하지 않고 사용할 경우 문제가 발생할 수 있다.

➡️ 문제가 발생하는 경우

1️⃣잘못 구현된 비교자 예시

public class BrokenComparator {
    public static void main(String[] args) {
			Comparator<Integer> naturalOrder =
	     (i, j) -> (i < j) ? -1 : (i == j ? 0 : 1);

			int result = naturalOrder.compare(new Integer(42), new Integer(42));
      System.out.println(result); // 1 
   }
}

두 Integer 인스턴스의 값이 42로 같으므로 0을 출력해야 하지만, 실제로는 1을 출력한다.

❓출력은 1 이다. 왜? 0이 아니고 1일까?

🔡원인

• 첫번째 연산(i< j)에서 i와 j는 참조하는 오토박싱된 Integer 인스턴스는 기본 타입 값으로 변환된다. Integer → int : UnBoxing
• 첫번째 연산 → false , 두번째 연산(i == j) → false 발생한다.

🔡분석

• (i,j)의 타입이 Integer로 추론되기 떄문에 두번째 연산(i == j)이 진행될 때 동일성 검사가 진행되어 false가 발생한다.
• i와 j는 값은 같지만 서로 다른 객체이다.

⚠️따라서 박싱된 기본 타입에 == 연산자를 사용하면 다른 결과가 나올 수 있다.

위와 같은 문제를 고치려면..

지역변수 2개를 두어 각각 박싱된 Integer 매개변수의 값을 기본 타입 정수로 저장한 다음 모든 비교를 이 기본 타입 변수로 수행하면 된다. 이렇게 하면 오류의 원인인 식별성 검사는 이뤄지지 않는다.

Comparator<Integer> naturalOrder = (iBoxed, jBoxed) -> {
    int i = iBoxed, j = jBoxed; // 오토박싱
    return i < j ? -1 : (i == j ? 0 : 1);
};

2️⃣ NullPointerException 발생

public class Unbelievable {
    static Integer i;

    public static void main(String[] args) {
        if (i == 42) System.out.println("믿을 수 없군!");
    }
}

위 프로그램은 '믿을 수 없군!’ 을 출력하지 못하고 NullPointerException을 던진다.

❓‘믿을 수 없군!’이 아니라 왜 NullpointerException을 던지는 것일까?

🔡원인

• (i == 42)를 검사하는 과정에서 NullPointerException을 던진다.
• i가 리터럴 값인 42와 비교하는 과정에서 i는 Auto UnBoxing을 수행, 하지만 i가 null이기 떄문에 Auto Unboxing 과정 중에 NullPointerExceotion을 던진다.

기본 타입과 박싱된 기본 타입을 혼용한 연산에서는 박싱된 기본 타입의 박싱이 자동으로 풀린다.

위의 해법은 i를 int로 선언해주면 된다. 너무 간단하다..

3️⃣ Auto Boxing과 Auto UnBoxing으로 인한 성능 저하

public class App {
    public static void main(String[] args) {
        Long sum =0L;
        for (long i = 0; i <= Integer.MAX_VALUE; i++) {
            sum += i;
        }
        System.out.println(sum);
    }
}

위 코드는 엄청 느리게 결과를 출력한다.

❓ 왜 엄청나게 느리게 출력하는 걸까?

🔡원인

• 우선 위에 코드에서 sum은 박싱된 기본타입(Long)으로 선언되어 있다.
• sum += i; 이 진행되는 코드에서 sum이 long타입으로 Auto UnBoxing이 되고 sum + i 연산이 진행되고 Long타입으로 Auto Boxing된다.
• 이렇게 반복을 하다보면 매우 성능이 느려진다.

---

➡️박싱된 기본 타입은 언제 써야 하는가?

1️⃣ 컬렉션의 원소, 키 , 값으로 쓴다.

• 컬렉션은 기본 타입을 담을 수 없으므로 어쩔 수 없이 박싱된 기본 타입을 써야만 한다.

• 제네릭(Generics) 타입을 이용하는 경우에도 박싱된 기본타입을 사용한다.

  • 제네릭 타입에서는 int, double과 같은 기본타입을 지원하지 않기 때문이다.

• 리플렉션(Reflection)을 통해 메서드를 호출할 때에도 박싱된 기본타입을 사용한다.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✅핵심 정리

• 오토 박싱이 박싱된 기본 타입을 사용할 때의 번거로움을 줄여주지만, 위와 같이 세 가지의 위험은 없애주지 않는다.

• 두 박싱된 기본 타입을 ==연산자로 비교한다면 식별성 비교가 이뤄지므로 예상했던 결과와 다르게 나온다.

• 같은 연산에서 기본타입과 박싱된 기본 타입을 혼용하면 언박싱이 이뤄지며, 언박싱 과정에서 NullPoinerException을 던질 수 있다.

• 기본 타입을 박싱하는 작업은 필요 없는 객체를 생성하는 부작용을 초래할 수 있다.

[JoisFe]

코틀린은 기본 타입이 없다고해요 ->기본 타입의 문제점이 발생하지 않는 장점이 있습니다.
하지만 위에서 @YuDeokRin 님께서 설명해주신 대로 성능에 대한 걱정이 있었는데 알아보니
코틀린은 컴파일러가 어느 정도 최적화를 해주기 때문에 성능이 괜찮다고 합니다.

• 코틀린은 기본 타입에 null을 저장하거나 제네릭에 사용하지만 않는다면 래퍼 클래스가 아닌 원시 타입을 쓰게끔 자바 바이트코드가 생성되어 성능이 괜찮음

[corock]

정리해주신 글 잘 읽었습니다~

저는 웹 백엔드 개발을 할 때 path 에 논리(true / false) 타입 또는 정수 타입이 필요하면 원시 타입과 래퍼 클래스 중 스펙을 고민하곤 합니다.

예를 들면, JpaRepository 내 추상 메서드 중 Boolean 반환 타입인 추상 메서드의 값을 바탕으로 후속 작업을 해야 할 때,
원시 타입이면 조건문을 간소화할 수 있지만, 래퍼 클래스는 Boolean.TRUE 또는 Boolean.FALSE 등을 활용해서 비교해야 하는 것처럼요.

아니면 path variable 에 포함된 정수 타입은 null 이 들어오지 않는다는 것이 정책상 명확하다면, 굳이 원시 타입을 안 쓸 이유가 있는가? 처럼요.
여러분들의 의견은 어떤지 궁금합니다.

[JoisFe]

몇몇 사람들은 true, false 경우 래퍼 클래스 비추하더라구요. (true or false 둘 중 하나가 명확한 경우!)

[Irisation23]

래퍼 클래스가 확장성이 좋지 않을까요?

왜냐하면 단순히 리터럴 값만 주고받는 경우는 확실히 원시타입이 좋아보이나,
차후에 래퍼 클래스로 사용할 수 있는 메서드가 있을거라는 생각이 듭니다.

저도 Boolean은 원시타입 추천합니다.

[JoisFe]

엔터프라이즈 급의 대규모 데이터를 처리해야하는 경우 성능에 영향이 조금 있을 수 있다고 하네요...

[chikeem90]

아까 추가로 좀 얘기드렸던 건 아래의 경우에는 wrapper class로 처리되는게 명확할 거 같긴 해요
db에서 count를 조회하는 로직이 있는데 db 서버 장애로 exception 발생한다 했을 때 count를 0으로 반환한다,,? 그때는 명시적으로 null로 반환해서 뭔가 문제가 있는 걸 인지할 수 있지 않을까? 그런 케이스에 쓰일 수는 있을 거 같네요.