자바에는 기본 타입(primitive type)과 Wrapper 클래스가 존재한다.
값 비교
에는 equals
를 사용합니다. ==
는 인스턴스의 주소비교
에 사용박싱과 언박싱에 대한 개념을 먼저 살펴보자
기본 타입 데이터에 대응하는 Wrapper 클래스로 만드는 동작 (Primitive -> Wrapper)
// 박싱
int i = 10;
Integer num = new Integer(i);
int intData = 512;
// 명시적인 방식
Integer integerData = (Integer)intData;
int intData = 512;
// 묵시적인 방식
Integer integerData = intData;
Wrapper 클래스에서 기본 타입으로 변환 (Wrapper -> Primitive)
// 언박싱
Integer num = new Integer(10);
int i = num.intValue();
int intData = 512;
// 명시적인 언방식
int sum = (int)integerData + 100;
System.out.println(sum);
int intData = 512;
// 묵시적인 언방식
int sum = integerData + 100;
System.out.println(sum);
→ Java에서 아무리 기능적 편의성을 위하여 박싱과 언박싱 그리고 오토박싱을 제공하지만,
명백히 다른 타입 간의 형변환은 어플리케이션의 성능에 영향을 미칠 수 밖에 없다.
예제
public static void main(String[] args) {
long t = System.currentTimeMillis();
Long sum = 0L;
for (long i = 0; i < 1000000; i++) {
sum += i;
}
System.out.println("processing time: " + (System.currentTimeMillis() - t) + " ms") ;
}
// processing time: 21 ms
public static void main(String[] args) {
long t = System.currentTimeMillis();
long sum = 0L;
for (long i = 0; i < 1000000; i++) {
sum += i;
}
System.out.println("processing time: " + (System.currentTimeMillis() - t) + " ms") ;
}
// processing time: 4 ms
→ 총 100만번의 sum 연산을 통해 대략 5배의 결과차이를 보이는 것으로 확인했다.
100만건의 결과는 서비스 어플리케이션에서는 결코 작은 숫자는 아닐 것
→ 따라서 작성한 코드에 불필요한 auto casting이 반복적으로 이루어지고 있는지 확인하는 것은
대용량 서비스를 개발하는데 있어서 필수적으로 파악해야하는 요소임