[이펙티브 자바] Item6. 불필요한 객체 생성을 피하라.

item06. 불필요한 객체 생성을 피하라. 

❗️ 여기서 주의할 점은 그냥 객체 생성은 피하라! 가 아니라는 점이다. 

 

 

 

1) 문자열

public static void main(String[] args) {
    String hello = "hello";
    String hello2 = new String("hello"); // 이 방법은 권장하지 않음! -> 메모리를 많이 사용하는 단점
    String hello3 = "hello";

    System.out.println("hello == hello2 = " + (hello == hello2));
    System.out.println("hello == hello3 = " + (hello == hello3));
}

문자열을 사용할 때는 보통 첫번째, 세번째 방식처럼 문자열 리터럴을 사용해서 문자열을 만들 것이다.

근데 혹시나 new String()을 사용해서 문자열을 사용하는 사람이 있다면 바꿔야하는 방법이다. 

 

hello == hello3 비교해 보면 결과가 true가 나오는데 

왜냐하면 hello와 hello3은 사실상 동일한 객체이기 때문이다. 따라서 new String 으로 해서 굳이 새로 만들 필요가 없다!! 

(즉, hello == hell2의 결과는 false)

 

그러므로 new String("")을 사용하지 말고 문자열 리터럴을 사용해 기존에 동일한 문자열을 재사용하는 것이 좋다!! 

 

출처 https://www.digitalocean.com/community/tutorials/what-is-java-string-pool

같은 가상 머신 안에서는 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장된다. 

 

 

2) 정규식, Pattern

: 생성 비용이 비싼 객체이기 때문에 반복해서 생성하기 보다는 캐싱하여 재사용하는 것이 좋다. 

public class RomanNumerals {

    static boolean isRomanNumeralSlow(String s) {
        return s.matches("^(?=.)M*(C[MD]|D?C{0,3})(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
    }

    // 값 비싼 객체를 재사용해서 성능을 개선한다.
    private static final Pattern ROMAN = Pattern.compile("^(?=.)M*(C[MD]|D?C{0,3})(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");

    static boolean isRomanNumeralFast(String s) {
        return ROMAN.matcher(s).matches();
    }

    public static void main(String[] args) {
        boolean result = false;
        long start = System.nanoTime();
        for (int i = 0; i < 10; i++) {
            result = isRomanNumeralSlow("MCMLXXVI");
        }
        long end = System.nanoTime();
        System.out.println("(end - start) = " + (end - start));
        System.out.println("result = " + result);
    }
}

result의 결과를 isRomanNumeralSlow와 isRomanNumeralFast로 비교해보면 캐싱하여 재사용하는 방법이 훨씬 빠른 것을 확인할 수 있다. 

isRomanNumeralSlow()

isRomanNumberSlow()에서 matches()를 사용하는 것이 문제가 될 수 있다. 

String.matches는 정규표현식으로 문자열 형태를 확인하는 가장 쉬운 방법이지만, 성능이 중요한 상황에서는 반복해서 사용하기엔 적합하지 않다. 실행 결과 차이를 보기만 해도 반복해서 사용하니까 isRomanNumeralFas()보다 훨씬 느린 것을 확인할 수 있다. 

isRomanNumeralFast()

따라서 성능을 개선하려면 필요한 정규표현식을 표현하는 Pattern 인스턴스를 클래스 초기화 과정에서 직접 캐싱해두고 이제 isRomanNumeralFast() 메서드가 호출될 때 마다 이 인스턴스(ROMAN)를 재사용하도록 한다. 

 

 

🐥 Pattern

: 정규 표현식이 컴파일된 클래스. 정규 표현식에 대상 문자열을 검증하거나, 활용하기 위해 사용되는 클래스이다. 

 

 

 

3) 오토박싱 auto boxing

우선 오토박싱이란 기본타입 (primitive type) 을 그에 상응하는 박싱된 기본타입 Wapper type로 상호변환해주는 기술 

ex) int -> Integer 

언박싱은 반대로 박싱된 기본타입을 primitive type으로 변환해주는 기술 

ex) Integer -> int, Long -> long 

 

public class Sum {
    private static long sum() {
        long sum = 0L;
        for (long i = 0; i <= Integer.MAX_VALUE; i++) {
            sum += i; // sum이 Long인 경우 i 에서 오토박싱이 계속 일어나서 속도가 느리게 된다.
        }
        return sum;
    }

    public static void main(String[] args) {
        long start = System.nanoTime();
        long x = sum();
        long end = System.nanoTime();

        System.out.println(((end - start) / 1_000_000.) + "ms.");
        System.out.println("x = " + x);
    }
}

long sum이 아닌 Long sum이었을 경우에는 기본 타입(long i)과 박싱된 기본타입(Long sum)이 섞여있기 때문에 변환하는 과정에서 불필요한 객체 생성이 이루어져서 훨씬 속도가 느리게 된다. 

오토박싱이 일어난 경우

오토박싱이 일어나지 않은 경우

 

따라서 박싱된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의하자!! 

 

 

✏️ item06에서 핵심? 포인트는 우선 불필요한 객체 생성을 피하라! 인데 여기서 오해하면 안되는 것이 모든 객체 생성이 생성 비용이 비싸니까 피하라! 라고 하는 것이 아니라 위에서 제시한 3가지 경우(문자열 생성, 오토박싱, 정규식) 에는 불필요한 객체를 굳이 생성하지 말고 재사용하자~ 라는 것이다.