아이템 6. 불필요한 객체 생성을 피하라

[chikeem90]

• 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 나을 때가 많음.
• 재사용은 빠르고 세련됨.
• 특히 불변 객체는 언제든 재사용할 수 있음.

String s = new String("bikini");

• 이 문장은 실행될 때마다 String 인스턴스를 새로 만든다.

String s = "bikini";

• 이 코드는 새로운 인스턴스를 매번 만드는 대신 하나의 String 인스턴스를 사용함.
• 나아가 이 방식을 사용한다면 같은 가상 머신 안에서 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장됨.

• 생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있음.
• 불변 객체만이 아니라 가변 객체라 해도 사용 중에 변경되지 않을 것임을 안다면 재사용할 수 있음.

• 생성 비용이 아주 비싼 객체도 더러 있음.
• 이런 비싼 객체가 반복해서 필요할 경우에는 캐싱하여 재사용하는 방법이 권장됨.

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})$");
}

• String.matches는 정규표현식으로 문자열 형태를 확인하는 가장 쉬운 방법이지만, 성능이 중요한 상황에서 반복해 사용하기엔 적합하지 않음.
• 이 메서드가 내부에서 만드는 정규표현식용 Pattern 인스턴스는 한 번 쓰고 버려져서 곧바로 가비지 컬렉션 대상이 됨.
• Pattern 내부 구현 코드

public boolean matches(String regex) {
    return Pattern.matches(regex, this);
}

//
public static boolean matches(String regex, CharSequence input) {
    Pattern p = Pattern.compile(regex);
    Matcher m = p.matcher(input);
    return m.matches();
}

//
public static Pattern compile(String regex) {
    return new Pattern(regex, 0);
}

• 해당 문자열을 상태로 가지는 인스턴스를 매번 생성하기 때문에 인스턴스 생성 비용이 높음.
• 성능을 개선하기 위해서는 필요한 정규표현식을 표현하는 Pattern 인스턴스를 클래스 초기화 과정에서 직접 생성해 캐싱해두고, 나중에 isRomanNumeral 메서드가 호출될 때마다 이 인스턴스를 재사용하도록 해야 함.

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();
}

• 개선 전에서는 존재조차 몰랐던 Pattern 인스턴스를 static final 필드로 끄집어내고 이름을 지어주어 코드의 의미가 훨씬 잘 드러남.
• 개선된 isRomanNumeral 방식의 클래스가 초기화된 후 이 메서드를 한 번도 호출하지 않는다면 ROMAN 필드는 쓸데없이 초기화된 꼴임.
• isRomanNumeral 메서드가 처음 호출될 때 필드를 초기화하는 지연 초기화로 불필요한 초기화를 없앨 수 있지만, 권하지는 않음. ⇒ 지연 초기화는 코드는 복잡하게 만들지만, 성능은 크게 개선되지 않을 때가 많기 때문.

• 객체가 불변이라면 재사용해도 안전함이 명백함.
• 그러나 훨씬 덜 명확하거나, 심지어 직관에 반대되는 상황도 있음.
• 어댑터는 실제 작업은 뒷단 객체에 위임하고, 자신은 제2의 인터페이스 역할을 해주는 객체.
• 어댑터는 뒷단 객체만 관리하면 됨. 뒷단 객체 외에는 관리할 상태가 없으므로 뒷단 객체 하나당 어댑터 하나씩만 만들어지면 충분함.
• Map 인터페이스의 keySet 메서드의 경우 뒷단 객체는 Map이고 keySet을 뷰로 제공함.
• 매번 같은 인스턴스를 반환하며, keySet을 변경하게되면 그 뒷단 객체인 Map이 변경됨.

• 오토박싱은 프로그래머가 기본 타입과 박싱된 기본 타입을 섞어 쓸 때 자동으로 상호 변환해주는 기술.
• 오토박싱은 기본 타입과 그에 대응하는 박싱된 기본 타입의 구분을 흐려주지만, 완전히 없애주는 것은 아님.

private static long sum() {
	Long sum = 0L;
	for (long i = 0; i <= Integer.MAX_VALUE; i++) {
		sum += i;
	}
	return sum;
}

• sum 변수를 Long으로 선언해서 실제 sum 연산을 할 때 long 타입인 i가 매번 Long 타입으로 오토박싱되면서 Long 인스턴스가 2^31개나 생성됨.
• 박싱된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의하자.

[chikeem90]

나아가 이 방식을 사용한다면 같은 가상 머신 안에서 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장됨.

이거에 추가적으로 String을 concat할 때

String str = "hello";
str = str + "world";

이런 식으로 하게되면 매번 새로운 String 인스턴스를 생성하기 때문에 불필요하게 힙메모리를 차지하게 될 수 있음. (물론 GC 될테지만,,)
그래서 문자열 변경이 많을 때는 StringBuffer나 StringBuilder 사용 권장.
StringBuffer나 StringBuilder는 내부적으로 char array를 가지고 있어서 그 array에 계속 문자를 담아두는 형태로 동작함.
기본적으로 할당하는 char array size가 정해져있으므로 (문자열 변경이 잦지 않은 경우 비용이 더 클 수 있음) 문자열 변경이 자주 있을 때 사용하는 것이 좋음.
StringBuffer는 StringBuilder와 달리 thread-safe하므로 각 상황에 맞게 적절히 사용하는 것이 필요함.

[YuDeokRin]

Syncronized 는 여러 쓰레드에서 하나의 객체에 있는 인스턴스 변수를 동시에 처리할 때 발생할 수 있는 문제를 해결하기 위해서 필요한 것이라고 알고 있습니다. 즉, 인스턴스 변수가 선언되어 있다고 하더라도, 변수가 선언되어 있는 객체를 다른 쓰레드에서 고유할 일이 전혀 없다면 syncronized 를 사용할 이유가 없다고 생각합니다.

StringBuffer는 쓰레드에 안전, StringBuilder는 쓰레드에 안전하지 않다고 알고 있습니다.

따라서

StringBuffer는 하나의 문자열 객체를 여러 쓰레드에서 공유해야 하는 경우에만 사용하고, StringBuilder는 여러 쓰레드에서 공유할 일이 없을 때 사용하면된다고 알고 있습니다.

[chikeem90]

StringBuffer는 하나의 문자열 객체를 여러 쓰레드에서 공유해야 하는 경우에만 사용하고, StringBuilder는 여러 쓰레드에서 공유할 일이 없을 때 사용하면된다고 알고 있습니다.

👍

[chikeem90]

만약 맞다면 Syncronized 를 사용 하면서 성능을 챙길 수 있는 방법은 있는지에 대해 궁금합니다. 🙏🏻

@JoisFe 님
덕린님이 코멘트 남겨주신 것처럼 우선 여러 쓰레드에서 공유하는 상황에서만 사용해야하고,,
synchronized 키워드도 어디에 적용하냐에 따라 성능이 차이가 날 수 있거든요
https://steady-coding.tistory.com/556
이 블로그 보시면,, (좀 저도 읽고 정리해서 공유하려고 했는데,, ㅠ) 인스턴스 전체 단위로 걸기보다는 메서드 단위 synchronized를 건다거나 정말 thread-safe 해야하는 로직만 synchorinized 로 감싼다거나 해서 성능 저하를 최소화할 수 있을 거 같습니다.

cc. @YuDeokRin

[chikeem90]

https://tecoble.techcourse.co.kr/post/2021-11-26-hashmap-hashtable-concurrenthashmap/
HashTable <> ConcurrentHashMap 비교한 거 참고해도 좋을 거 같아요.

[corock]

StringBuffer는 StringBuilder와 달리 thread-safe하므로 각 상황에 맞게 적절히 사용하는 것이 필요함.

문자열 조작 시 어느 시점에 연산자로부터 StringBuilder(StringBuffer) 로 넘어갈 것인지에 대해 고민한 적이 있습니다.
IntelliJ IDE 를 이용하는 경우 CheckStyle 확장을 사용하면 전환 기준에 대한 warning highlighting 을 제공하니 활용하는 것도 좋을 듯합니다.

[chikeem90]

Map 인터페이스의 keySet 메서드의 경우 뒷단 객체는 Map이고 keySet을 뷰로 제공함.
매번 같은 인스턴스를 반환하며, keySet을 변경하게되면 그 뒷단 객체인 Map이 변경됨.

keySet()의 결과는 Map에 있는 key를 set의 형태로 변환해서 반환하는 것임.
그래서 매번 동일한 인스턴스를 반환함.

[JoisFe]

String str = "abc"

String str2 = new String("abc");

위 방식이 아래 방식과 다르게 이 코드는 새로운 인스턴스를 매번 만드는 대신 하나의 String 인스턴스를 사용하는 이유에 대해서 찾아보니 String Constant Pool 이라는 저장 공간에 String 객체를 저장하기 때문이라고 알게 되었습니다.

(reference : https://starkying.tistory.com/entry/what-is-java-string-pool)

String Constant Pool은 Heap 영역에 존재하지만 new가 아닌 literal로 문자열을 생성한 경우 이미 해당 문자열이 String Pool에 존재한다면 재활용 하기 때문에 하나의 인스턴스를 사용하게 됩니다.


만약 new로 생성시 동일한 문자열이 존재하든 말든 Heap 메모리 영역(String Pool이 아닌) 곳에 새로운 인스턴스를 만들게 됨으로써 비효율적인 작업이 계속 되게 됩니다.

이번 아이템을 통해 단순히 편하다는 이유로 문자열을 literal로 생성하는 습관이 있었지만 해당 방식이 어떠한 장점이 있고 이러한 장점이 되는 이유에 대해 알게 되었습니다.


정리 감사합니다.