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

Dayon·2024년 5월 8일

Java 책스터디

이펙티브 자바

목록 보기

3/4

책 소개

[ 이펙티브 자바 3/E ] https://www.yes24.com/Product/Goods/65551284

item6 : 불필요한 객체 생성을 피하라

똑같은 기능의 객체를 매번 생성하기보다 객체 하나를 재사용하는 편이 나을 때가 많다.

String s = new String("bikini);  // (1) 따라 하지 말 것 ! 

String s = "bikini";  // (2)

(1)의 문장은 실행될 때마다 String 인스턴스를 새로 만든다. → 쓸모 없는 행위
문장이 반복문이나 빈번히 호출되는 메서드 안에 있다면 쓸데없는 String 인스턴스가 수백만개 만들어질 수 있다.
(2) 코드는 새로운 인스턴스를 매번 만드는 대신, 하나의 String 인스턴스를 사용한다. 같은 가상 머신(JVM) 안에서 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장된다.

생성자 대신 정적 팩터리 매서드 를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있다.

예) Boolean(String) 생성자 보다 Boolean.valueOf(String) 팩터리 메서드를 사용하는 것이 좋다.

Boolean true1 = new Boolean("true");
Boolean true2 = new Boolean("true");
System.out.println(true1 == true2); // false, 서로 다른 객체

new Boolean("true")는 true1과 true2가 각각 새로운 Boolean 객체를 참조하게 한다.

Boolean true1 = Boolean.valueOf("true");
Boolean true2 = Boolean.valueOf("true");
System.out.println(true1 == true2); // true, 같은 객체 재사용

Boolean.valueOf("true")는 필요에 따라 기존 객체를 재사용한다.

생성 비용이 비싼 객체

생성 비용이 비싼 객체가 반복해서 필요하다면 캐싱하여 사용하는 것이 좋지만, 객체가 비싼 객체인지 매번 확인 할수 없다.

정규 표현식을 활용한 예제

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

→ **String.matches** 메서드는 정규표현식으로 문자열 형태를 확인하는 가장 쉬운 방법이지만, 성능이 중요한 상황에서 반복해서 사용하기엔 적합하지 않는다.

이 메서드가 내부에서 만드는 Pattern 인스턴스는 한번 쓰고 버려져 바로 가비지 컬렉션 대상이 된다.
java.util.rege.Pattern 클래스는 정규식을 기반으로 문자열에 대한 검증을 수행한다.
Pattern은 입력받은 정규표현식에 해당하는 유한상태 머신(finite state machine)을 만들기 때문에 인스턴스 생성비용이 높다.
( → 유한상태머신을 쉽게 말하면 장치나 모델이 가질 수 있는 유한개의 상태를 정의하고, 조건에 맞는 이벤트가 발생되면 해당 상태로 변경되는 방식으로 동작하는 것을 유한상태머신이라 한다.)

성능 개선하기

정규표현식을 표현하는 (불변인) Pattern 인스턴스를 클래스 초기화 과정에서 직접 생성해 캐싱해두고, 나중에 isRomanNumeral 메서드가 호출될때 마다 재사용한다.

public class RomanNumerals {
	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 isRomanNumeral(String s) {
		return ROMAN.matcher(s).matches();
	}
}

위와 같은 개선을 통해 성능이 좋아지고, 코드가 더 명확해졌다.

Pattern 인스턴스를 static final 필드로 끄집어내고, 이름을 지어주어 코드의 의미가 잘 드러난다.

but!

만약 개선된 방식의 클래스가 초기화된 후 이 메서드를 한 번도 호출하지 않는다면, ROMAN 필드는 쓸데없이 초기화 된 꼴이다.
isRomanNumeral 메서드가 처음 호출될 때 필드를 초기화하는 지연초기화(Lazy initialization)로 불필요한 초기화를 없앨수도 있지만, 지연 초기화는 코드를 복잡하게 만드는데, 성능은 크게 개선되지 않을 때가 많아 추천하지 않는다.

객체가 불변이라도?

객체가 불변이라면 재사용해도 안전함이 명백하다.
하지만, 반대되는 상황을 생각해보자 ⇒ 어뎁터
어댑터는 실제 작업은 뒷단 객체에 위임하고, 자신은 제2의 인스턴스 역할을 해주는 객체다. 어댑터는 뒷단 객체만 관리하면 된다. 즉, 뒷단 객체 외에는 관리할 상태가 없으므로 뒷단 객체 하나당 어댑터 하나씩만 만들면 충분하다.

Adapter Pattern

Adaptee 를 감싸고, Target Interface 만을 클라이언트에게 드러낸다.

Target Interface 를 구현하여 클라이언트가 예상하는 인터페이스가 되도록 Adaptee 의 인터페이스를 간접적으로 변경한다.

Adaptee 가 기대하는 방식으로 클라이언트의 요청을 간접적으로 변경한다.

호환되지 않는 우리의 인터페이스와 Adaptee 를 함께 사용할 수 있다.

오토박싱(auto boxing)으로 인한 성능 저하

프로그래머가 기본 타입(primitive)과 박싱된 기본 타입을 섞어 쓸 때 자동으로 상호 변환해주는 기술
기본 타입과 그에 대응하는 박싱된 기본 타입의 구분을 흐릿하게 해주지만, 완전히 없애주진 못한다
모든 양의 정수의 총합을 구하는 메서드

private static long sum() {
    **Long** sum = 0L;  // 박싱된 타입 (Long)
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;  // 오토박싱 발생
    }
    return sum;
}