StringBuffer와 StringBulider

2021.07.27 - [기본 지식/CS 기본지식] - 자바의 String과 Constant Pool

자바의 String과 Constant Pool

자바에서 문자열을 다루는 방법은 String, StringBuffer, StringBuilder가 있다.

사실 연산이 많지 않을 때에는 3개중 아무거나 사용해도 큰 차이는 없지만, 연산 횟수가 많아지거나 멀티쓰레드, Race Condition등의 상황이 발생한다면 각 문자열 클래스의 용도를 잘 알고 사용해야 한다.

 

# String

S가장 큰 특징은 String은 상수. 즉 불변(immutable)하다는 것이다.

String str = "hello"; // String str = new String("hello");
str = str + " world"; // [ hello world ]

코드상에서는 마치 문자열을 '편집' 한 것처럼 보이겠지만, JVM 내부에서는 아래와 같은 동작이 일어난다. 즉 문자열을 조작(추가, 수정, 삭제)한다면 Heap 메모리를 낭비하고 GC의 작업을 추가시켜 앱의 성능을 하락시킨다.

* 엥? new로 생성한게 아닌 문자열은 Heap이 아니라 정적 상수로 관리되는거 아니에요?

Java8부터는 상수 풀도 Heap메모리에 위치하게 된다. 즉 GC의 대상이다. 또한 메모리적인 측면뿐 아니라 문자열 조작 성능이 구리다는 단점도 있다는걸 잊지말자.

 

---

# StringBuffer와 StringBuilder

String과 다르게 가변성(mutable)을 가져 문자열 조작(추가, 수정, 삭제) 성능이 좋다. 그렇다면 기존의 String을 전부 StringBuffer로 바꾸면 되는거 아닐까?

 

String은 단순히 상수문자열만 가지고 있으면 되지만, StringBuffer, Builder는 버퍼의 크기를 조작하고 다양한 추가 메서드를 제공하는 만큼 내부 동작이 더 복잡하다. 즉 조작할 필요가 없는 모든 String을 StringBuffer으로 처리하는건 성능에 좋지않은 방법이다.

StringBuffer sb= new StringBuffer("hello");
sb.append(" world");

 

---

@ String의 스레드 안정성

String의 경우 값이 불변하기에 여러 쓰레드가 동시에 접근, 사용하더라도 동일한 결과값을 반환한다. 하지만 StringBuilder의  str.append() 연산처럼 문자열이 불변하지 않고 길이가 변할 수 있는 경우 여러 쓰레드가 접근 했을 때 어떤 문제점이 있을까?

스트링 값을 사용함에 있어 DB의 트랜잭션 처리, 즉 동기화를 해주지 않으면 정말 다양한 문제가 생길 수 있다. 예를 들어 [쓰레드1]이 문자열을 편집하고 있는 도중에 [쓰레드2]가 접근한다면 편집되다가 말은 이상한 값을 가져가거나, 혹은 동시에 접근한 [쓰레드2]가 [쓰레드1]의 작업 결과를 무시하고 덮어씌우는 등 정말 심각한 오류를 낼 수 있다.

 

---

@ StringBuffer vs StringBuilder, 차이점

가장 큰 차이점은 동기화의 유무이다. 이름에서 알 수 있듯이 StringBuffer는 멀티쓰레드 환경에서 사용을 위해 만들었다.

• String:  문자열 연산이 적고 멀티쓰레드 환경일 경우 (값이 변하지 않아 안전하다.)
• StringBuffer:  문자열 연산이 많고 멀티쓰레드 환경일 경우 (값이 변하지만, thread-safe를 보장한다.)
• StringBuilder:  문자열 연산이 많고 단일쓰레드이거나 동기화를 고려하지 않아도 되는 경우

 StringBuffer의 경우 자바의 synchronized 키워드를 이용해 멀티스레드의 동기화, thread-safe를 보장한다.

// StringBuilder.append()
@Override
    public StringBuilder append(String str) {
        super.append(str);
        return this;
    }

// StringBuffer.append()
  @Override
  public synchronized StringBuffer append(String str) {
      toStringCache = null;
      super.append(str);
      return this;
  }

 

다만 동기화를 보장하는 작업은 성능을 크게 하락시킨다. 즉 StringBuffer의 사용은 멀티쓰레드, 단일쓰레드 여부와 상관없이 '동기화' 기능의 추가 때문에 성능이 하락된다. 그래서 동기화가 필요없는 단일 쓰레드에서 사용해라고 만든 StringBuilder를 따로 제공하는 것이다.

 

참고로 대용량 문자열 조작 작업을 처리하는데 StrinBuilder가 1초 걸렸다고 가정하면,

• 멀티스레드 동기화를 보장하는 StringBuffer는 2초
• 그냥 조작할 때마다 객체를 생성하는 String은 2400초(40분)정도 걸린다.

상황에 따라 다르겠지만 실제 테스트 해보면 비슷한 결과를 볼 수 있다. 그래서 JDK1.5부터는 컴파일 시점에서 String 덧셈이 StringBuilder로 자동 치환된다.

 

---

# Java 컴파일러의 String 최적화

실제로 String과 StringBuffer는 장단점이 있었기에 관련된 논의가 많았다. 그래서 JDK1.5 이후 컴파일러는 String 처리에 있어 다음과 같은 바이트코드 변환 전 최적화를 보장한다.

• 한줄에서 상수 String의 덧셈은 아예 한 문자열로 바꿔서 컴파일한다.
• Java 1.5 이후의 String 덧셈 연산은 전부 StringBuilder로 치환된다.
• 즉 한줄에서 상수와 다른 String 클래스를 더하는건 StringBuilder.append() .toString() 메서드로 바꾼다.

실제로 JDK 1.5버전 이후로는 개발자가 String만 사용하더라도 컴파일 단계에서 적절하게 StringBuffer로 변환해준다.

//기존 자바코드
public static void main(String args[]) {
    String str0 = "It's a string....";
    String str1 = "It's a string....";
    String str2 = "It's a string...." + str0 + "000";
    str2 = str0 + str1 + "1111";
    str2 = str2 + "1111";
    str2 = str2 + "1111";
    for (int i = 0; i < 10; i++) {
        str2 = str2 + "1111";
        str2 = str2 + "1111";
    }

}

// jdk1.5 컴파일러가 최적화 시킨 코드.
public static void main(String args[]) {
    String str0 = "It's a string....";
    String str1 = "It's a string....";
    String str2 = (new StringBuilder("It's a string....")).append(str0).append("000").toString();
    str2 = (new StringBuilder(String.valueOf(str0))).append(str1).append("1111").toString();
    str2 = (new StringBuilder(String.valueOf(str2))).append("1111").toString();
    str2 = (new StringBuilder(String.valueOf(str2))).append("1111").toString();
    for (int i = 0; i < 10; i++) {
        str2 = (new StringBuilder(String.valueOf(str2))).append("1111").toString();
        str2 = (new StringBuilder(String.valueOf(str2))).append("1111").toString();
    }
}