불필요한 객체 생성을 피하라
이번 Item의 경우, 제목 자체가 그렇게 난해하지는 않다.
똑같은 기능의 객체를 매번 생성하는 것보다 객체 하나를 생성하여 재사용하는 편이 좋을 때가 많다. 특히 불변 객체(item 17)는 언제든지 재사용할 수 있다.
객체 지향 방법론이란 자주 사용되는 것들을 객체(하나의 모듈)로 만들고,
언제든지 필요할 때 재사용 할 수 있게 하자는 것이 궁극적인 목표이다.
그런데 이때 객체 생성이 너무 빈번하고 불필요하게 이루어지면 문제가 될 수 있다.
여기서 우리는 불필요하다는 것의 의미를 파악해 볼 필요가 있다.
보통 우리가 클래스로부터 인스턴스를 생성하여 사용할 때,
인스턴스에 조그마한 변화를 줄 수가 있다.
예를 들어보면, A라는 클래스는 어떤 자동차 B를 나타내고 있다고 해자.
B라는 자동차를 생산할 때, 모두 다 A 클래스로부터 인스턴스화 도니다.
그런데 아주 단순하게, 그 모든 자동차의 번호판은 다르지 않겠는가?
그래서 A클래스로부터 인스턴스화는 시키되, 필요한 변화를 적용시키게 된다.
그런데 만약 위의 예시에서,
B라는 자동차는 고유한 식별 정도 조차도 없이 모든 정보가 다 같다면 어떨까?
어차피 인스턴스가 모두 같을텐데,
코드를 재사용 한다는 명목으로 매번 인스턴스를 생성하는 것이 더 낭비이지 않을까?
// 안좋은 예 - 호출될 때마다 인스턴스 새로 생성
String s = new String("bad example");위의 문장은 실행될 때마다 String 인스턴스를 새로 만들며, 이 문장이 반복문이나 빈번히 호출되는 메서드 안에 있다면, String 인스턴스가 수없이 많이 만들어 질 수 있다. 같은 문자열이 있어도 새로 인스턴스를 만드는 방식이다.
위의 예시는, bad example이라는 문장을 생성자한테 넘겨 새로운 String 객체를 만든다.
딱 봤을때 이게 왜? 어때서? 라고 생각할 수도 있지만,
이는 정말 쓸데없는 일이다.
//하나의 String 인스턴스 사용
String s = "good example";위의 경우 새로운 인스턴스를 매번 만드는 대신 하나의 인스턴스를 사용하며, 같은 가상 머신 안에서 똑같은 문자열 리터럴을 사용하는 경우 모든 코드가 같은 객체를 재사용함이 보장된다. 즉, 간단히 말하면 같은 문자열이 존재하면 같은 인스턴스를 사용하는 방식이다.
둘 모두 문자열을 생성해 변수에 저장하는 역할을 하지만 엄청난 차이가 있다.
첫 번째는 매번 객체를 생성하고 있지만 두 번째는 그렇지 않다.
그냥 문자열을 하나 만드는 건 똑같은데 매번 객체를 생성하는 것은 너무 낭비이다.
보통 생성자의 경우 당연스럽게도 호출될 때마다 객체를 생성하지만,
정적 팩토리 메서드의 경우 반환하는 값을 스스로 조절할 수 있다.
즉, 필요에 따라 기존의 객체를 반환함으로써 불필요한 객체 생성을 막을 수 있다.
StringBuilder 사용
문자열 연산이 자주 이루어지는 경우, 문장열 연결 연산자 '+'대신 StringBuilder를 사용하는 것이 성능 향상에 도움이 될 수 있다. 문자열 연결 연산자는 매번 새로운 문자열을 생성하는데, StringBuilder를 사용하면 기존의 문자열을 수정하므로 불필요한 객체 생성을 줄일 수 있다.
// 안좋은 예 - 매번 새로운 문자열을 생성
String result = "";
for (int i = 0; i < 10; i++) {
result += i;
}
StringBuilder resultBuilder = new StringBuilder();
for (int i = 0; i < 10; i++) {
resultBuilder.append(i);
}
String result = resultbuilder.toString();요즘은 컴퓨터 스펙이 너무나 좋아졌기 때문에,
웬만한 객체들을 마구잡이로 생성한다고 해도 그렇게 신경쓸 필요는 없다.
(항상 자원의 효율적인 사용을 추구하는 개발자가 아니라면)
하지만 문제는 생성 자체만으로 엄청난 소모비용이 드는 객체들이 있다는 것이다.
이런 객체의 경우 호출될 때마다 생성하는 것보다는,
기존에 만들어두었던 객체를 캐시(Reset) 하고 재사용 하는 것이 낫다.
여기까지 너무 이상적인 이야기지만,
사용하려는 객체가 생성 비용이 비싼 것인지 파악하는 것 자체가 힘들 수 있다.
정적 팩터리 메서드(item 1)를 제공하는 불변 클래스에서는 불필요한 객체 생성을 피할 수 있다.
// 생성자 - Java9에서 deprecated
public Boolean(String s) {
this(parseBoolean(s));
}
// 팩터리 메서드
public static Boolean valueOf(String s) {
return parseBoolean(s) ? TRUE : FALSE;
}생성자는 매번 새로운 객체를 생성하지만, 팩터리 메서드는 그렇지 않으므로, Boolean(String) 생성자 대신 Boolean.valueOf(String) 팩터리 메서드를 사용하는 것이 좋다.
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})$");
}isRomanNumeral()함수는 정규 표현식을 활용해 유효한 로마 숫자인지 확인하는 메서드이다. 하지만 이 방식은 String.matches 메서드를 사용한다는 문제점이 있다.
문제점
- 위에서 match 메서드는 내부적으로 Pattern 인스턴스를 생성한다.
- Pattern은 문자열에 대한 판별용으로만 잠시 사용되고 버려진다.
- Pattern은 생성비용이 매우 높다.
/**
* Tells whether or not this string matches the given <a
* href="../util/regex/Pattern.html#sum">regular expression</a>.
*
* <p> An invocation of this method of the form
* <i>str</i>{@code .matches(}<i>regex</i>{@code )} yields exactly the
* same result as the expression
*
* <blockquote>
* {@link java.util.regex.Pattern}.{@link java.util.regex.Pattern#matches(String,CharSequence)
* matches(<i>regex</i>, <i>str</i>)}
* </blockquote>
*
* @param regex
* the regular expression to which this string is to be matched
*
* @return {@code true} if, and only if, this string matches the
* given regular expression
*
* @throws PatternSyntaxException
* if the regular expression's syntax is invalid
*
* @see java.util.regex.Pattern
*
* @since 1.4
* @spec JSR-51
*/
public boolean matches(String regex) {
return Pattern.matches(regex, this);
}String.matches 메서드 내부에서 만드는 정규표현식용 Pattern 인스턴스는 한 번 쓰고 버려져 곧 바로 가비지 컬렉션 대상이 된다. Pattern은 입력 받은 정규 표현식에 해당하는 유한 상태 머신(finite state machine)을 만들어 인스턴스 생성 비용이 높다.
finite state machine 이란
상태를 기반으로 동작하는 개념의 방식으로, 상태를 기반으로 처리 되기 때문에 한 번에 한 개의 상태만 처리된다. 상태에 기반한 조건에 의해 처리되므로, 상태 값이 변경되면 상태에 대한 종료 및 다른 상태로의 변환을 처리한다.
이렇게 생성 비용이 많이 드는 객체가 반복해서 필요하다면, 캐싱하여 재상용하는 것을 권장한다.
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 인스턴스를 클래스 초기화 과정에서 직접 생성해 캐싱해두고, 나중에 isRomanNumeral 메서드 호출을 통해 이 인스턴스를 재사용하여 성능을 개선할 수 있다.
하지만, 클래스가 초기화된 후 이 메서드를 한번도 호출하지 않는다면, ROMAN 필드는 필요없이 초기화 된 것이다. lazy initialization(item 83) 으로 isRomanNumeral 메서드가 처음으로 호출될 때 필드를 초기화하도록 하여 불필요한 초기화를 없앨 수 있지만, 지연 초기화는 코드를 복잡하게 만드는데, 성능은 크게 개선되지 않을 때가 많으므로 권하지 않는다.(item 67)
Map 인터페이스의 keySet 메서드는 Map 객체 안의 모든 키 값을 담은 Set 뷰를 반환한다. keySet 호출시 새로운 Set 인스턴스가 만들어진다고 생각할 수 있지만, 사실은 매번 동일한 Set 인스턴스를 반환할 수도 있다.
반환된 Set 인스턴스가 일반적으로 가변이더라도 반환된 인스턴스들은 기능적으로 모두 동일하며, 반환된 객체 중 하나를 수정하면 모든 객체가 동일한 Map을 대변하기 때문에 모든 객체가 따라서 바뀐다. keySet 뷰 객체를 여러 개 생성해도 되지만, 그럴 필요는 없다.
오토 박싱(Auto Boxing)의 경우
또 다른 예로 auto boxing을 들 수 있다. auto boxing은 기본 타입과 박싱된 기본 타입을 섞어 쓸 때 자동으로 상호 변환해주는 기술이다.
오토 박싱은 기본 타입과 그에 대응하는 박싱된 기본 타입의 구분을 흐려주지만, 완전히 없애주는 것은 아니다.
오토박싱이란?
- 기본 타입(int 등)을 Wrapper 클래스의 객체 (Integer)로 변환하는 것.
- Wrapper 클래스란, 기본 타입 데이터를 객체로 취급해야 하는 경우에 객체로 포장해주는 것.
private static long sum() {
Long sum = 0L;
for (long i = 0; i < Integer.MAX_VALUE; i++) {
sum += i;
}
return sum;
}위 코드는 모든 정수의 총 합을 구하는 메서드로, int를 사용하지 않고 long을 사용하고 있다.
정확한 답을 낼 수는 있지만 제대로 구현하였을 때보다 성능상으로 훨씬 느려진다. sum변수를 long이 아닌 Long으로 선언하여 불필요한 인스턴스가 sum += i 연산이 이루어질 때마다 생성되는 것이다.
단순히 sum의 타입을 long으로만 변경해주어도 성능이 개선된다. 즉, 박싱된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의해야 한다.
실제로 상품의 가격을 계산할 때 의도치 않은 auto boxing이 흔히 발생한다. 가격 필드에 대한 타입으로 BigDecimal 내부 메서드는 기본타입을 사용하고 있다.
public BigDecimal(long val) {
this.intCompact = val;
this.intVal = (val == INFLATED) ? INFLATED_BIGINT : null;
this.scale = 0;
}
public long longValue() {
return (intCompact != INFLATED && scale == 0) ? intCompact : toBigInteger().longValue();
}이때 BigDecimal.longValue()로 연산을 하고 싶다면, 기본 타입을 사용해야하며, 그렇지 않다면 불필요한 인스턴스가 생성될 것이다.
프로그램의 명확성, 간결성, 기능을 위해 객체를 추가로 생성하는 것이라면 일반적으로 좋은 일이다. 불필요한 객체를 생성하는 것을 피하고자 객체 풀(pool)을 생성하는 것은 권장하지 않는다.
여기서 주의해야 할 것은,
객체 생성은 비싸니까 피해야 한다고 말하는 것이 아니다.
요새 나오는 JVM의 경우 성능이 좋기 때문에,
프로그램의 명확성, 간결성 기능을 위해서 객체를 생성하는 것은 오히려 좋다.
자체 객체 풀은 코드를 헷갈리게 만들며, 메모리 사용량을 늘리고 성능을 떨어뜨린다. JVM의 가비지 컬렉터는 상당히 최적화가 잘되어있어 직접 만든 객체풀보다 훨씬 빠른 경우가 많다. 방어적 복사가 필요한 상황에서 객체를 재사용했을 때의 피해가 필요 없는 객체를 반복 생성했을 때의 피해보다 훨씬 큰 것을 유의해야한다.
