Java 문자열 더하기 연산의 최적화

String을 +로 더하는 코드가 javac과 JDK 런타임에서 버전에 따라 어떻게 최적화되는지 정리합니다. JDK 1.4의 StringBuffer 치환, JDK 5의 StringBuilder 치환, JDK 9의 invokedynamic 도입, JDK 15의 대안 전략 제거, JDK 24의 hidden class 기반 구현까지의 변화를 JDK 25에서 확인한 바이트코드와 함께 설명합니다.

Table of Contents

컴파일 타임 상수식의 결합
변수가 섞인 결합의 StringBuffer·StringBuilder 치환
반복문 안에서 누적하는 문자열 결합
JDK 9부터 적용된 invokedynamic 방식
정리
참고 자료

String을 + 연산자로 더하는 코드는 컴파일러와 JVM이 최적화합니다. JDK의 javac은 JDK 1.4까지 StringBuffer를 쓰는 코드로, JDK 5부터 JDK 8까지는 StringBuilder를 쓰는 코드로 컴파일 시점에 변환했습니다. JDK 9부터는 기본적으로 invokedynamic 명령을 만들고, 실제 결합 코드는 실행 시점에 링크합니다. 어떤 경우에 자동으로 최적화되는지 알고 있으면 문자열 결합 코드를 더 융통성 있게 쓸 수 있습니다.

Java 언어 명세는 문자열 결합의 결과와 평가 순서를 규정하지만, 구체적인 구현 방식은 컴파일러의 재량에 맡깁니다. 따라서 이 글의 버전 구분은 JDK javac의 기본 바이트코드와 OpenJDK 런타임 구현을 기준으로 합니다. ^[1]

컴파일 타임 상수식의 결합

문자열 타입의 컴파일 타임 상수식은 컴파일 시점에 평가되어 하나의 문자열이 되고, 이 문자열은 String.intern()을 거친 것처럼 문자열 풀에 등록되어 공유됩니다. String.intern()은 같은 내용에 대한 문자열 풀(string pool)의 canonical reference(대표 참조)를 반환합니다. 내용이 같은 String 인스턴스가 힙에 여러 개 있어도 문자열 풀에는 내용별로 대표 인스턴스가 하나만 등록되는데, canonical reference는 그 대표 인스턴스를 가리키는 참조입니다. 그래서 내용이 같은 문자열을 intern하면 동일한 인스턴스를 참조하게 됩니다. 이는 힙에 존재하는 내용이 같은 모든 String 객체가 자동으로 문자열 풀에 합쳐진다는 뜻은 아닙니다. 문자열 리터럴뿐 아니라 primitive 리터럴과 상수 변수도 이런 상수식에 포함될 수 있습니다. ^[2] 예를 들어 아래의 두 선언은 같은 코드로 컴파일됩니다.

String str1 = "It's" + " a string" + "....";
String str2 = "It's a string....";

이 규칙은 이 글에서 다루는 모든 JDK 버전에서 같습니다. 뒤에서 소개할 JDK 25의 바이트코드에서도 두 변수가 상수 풀의 같은 항목(ldc #7)을 읽는 것을 확인할 수 있습니다. 두 변수는 문자열 풀의 같은 인스턴스를 참조하므로 equals() 메서드뿐 아니라 str1 == str2 비교도 true가 됩니다. 반면 비상수 결합식의 결과는 새 String으로 만들어지고 자동으로 intern되지 않으므로, 내용이 같은 리터럴이나 별도로 만들어진 문자열과 ==로 비교하면 false가 됩니다.

변수가 섞인 결합의 StringBuffer·StringBuilder 치환

상수와 String 변수를 섞어서 더하는 연산을 JDK 8까지의 javac으로 컴파일하면 StringBuffer나 StringBuilder의 append(), toString() 메서드를 호출하는 코드로 변환됩니다. JDK 1.4의 javac도 StringBuffer를 사용하는 방식이었습니다. 같은 시기의 Java ME 문서인 CLDC 1.1의 StringBuffer javadoc에는 당시 컴파일러의 변환 방식이 아래와 같이 설명되어 있습니다.

String buffers are used by the compiler to implement the binary string concatenation operator. For example, the code: x = "a" + 4 + "c" is compiled to the equivalent of: x = new StringBuffer().append("a").append(4).append("c").toString() which creates a new string buffer (initially empty), appends the string representation of each operand to the string buffer in turn, and then converts the contents of the string buffer to a string. Overall, this avoids creating many temporary strings.

JDK 5부터 JDK 8까지의 javac은 StringBuffer 대신, 동기화를 하지 않아서 단일 스레드에서 일반적으로 더 빠른 StringBuilder로 변환합니다. 이를 바이트코드나 역컴파일 결과로 확인할 수 있습니다. 원래의 소스가 아래와 같을 때

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 += "1111";
for (int i=0;i<10;i++){
    str2 = str2 + "1111";
    str2 += "1111";
}

JDK 5 이상 JDK 8 이하의 javac으로 컴파일한 후 역컴파일하면 다음과 같은 결과가 나옵니다.

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

Note	역컴파일 도구의 옵션에 따라서는 원래의 소스와 비슷하게 복원해서 `+` 연산이 그대로 보일 수도 있습니다. cfr이라는 디컴파일러가 그런 경우입니다. `javap -c` 명령으로 바이트코드를 확인하는 것이 정확합니다.

반복문 안에서 누적하는 문자열 결합

위의 역컴파일 결과에서 주목할 부분은 반복문입니다. 바이트코드에는 반복 주기마다 새로운 StringBuilder를 만들고, toString()을 호출해서 다음 반복에 넘길 String을 만드는 코드가 들어 있습니다. HotSpot JIT가 이 임시 StringBuilder의 실제 힙 할당을 제거할 수 있으므로, 바이트코드의 new 횟수가 항상 실제 객체 할당 횟수와 같지는 않습니다. 그러나 매번 더 길어진 이전 결과를 새 결과에 복사해야 한다는 문제는 남습니다.

따라서 성능이 중요한 반복문에서 문자열을 많이 누적할 때는 + 대신 하나의 StringBuilder를 직접 쓰는 편이 좋습니다. 고정된 길이의 문자열을 반복해서 붙인다면 + 방식의 누적 복사량은 반복 횟수에 대해 제곱으로 증가하지만, StringBuilder는 내부 버퍼를 재사용합니다. 반복 횟수가 작다면 가독성과 실제 측정 결과를 함께 고려할 수 있습니다. ^[3]

StringBuilder sb = new StringBuilder(str2);
for (int i = 0; i < 10; i++) {
    sb.append("1111");
}
str2 = sb.toString();

두 방식의 차이를 JDK 25(Temurin 25+36)에서 간단히 측정해 보았습니다. 4글자 문자열을 n회 누적하는 코드를 JIT 워밍업 후 여러 번 실행해서 가장 짧은 시간을 기록한 결과입니다. 측정에 쓴 코드는 examples/string-concat에 있습니다. ^[4]

반복 횟수 + 결합 StringBuilder 직접 사용 배율

반복 횟수	`+` 결합	`StringBuilder` 직접 사용	배율
100	0.008ms	0.001ms	약 10배
1,000	0.53ms	0.009ms	약 56배
10,000	10.6ms	0.023ms	약 471배
100,000	1,485ms	0.22ms	약 6,667배

100

0.008ms

0.001ms

약 10배

1,000

0.53ms

0.009ms

약 56배

10,000

10.6ms

0.023ms

약 471배

100,000

1,485ms

0.22ms

약 6,667배

반복 횟수가 늘수록 + 결합 시간은 급격히 증가합니다. 측정값은 JIT와 GC의 영향을 받지만, 누적 복사량이 반복 횟수에 대해 제곱으로 증가한다는 앞의 설명과 일치하는 경향을 보입니다. 반복 횟수가 100회 정도라면 어느 방식이든 절대 시간은 무시할 만한 수준입니다.

JDK 9부터 적용된 invokedynamic 방식

JDK 9부터는 JEP 280: Indify String Concatenation으로 javac의 기본 변환 방식이 완전히 달라졌습니다. 컴파일러가 StringBuilder 호출 코드를 만들어 넣는 대신 invokedynamic 호출 지점을 남기고, 실제 결합 메서드는 실행 시점에 연결합니다.

invokedynamic의 동작 구조

invokedynamic은 호출할 메서드를 실행 시점에 결정하는 바이트코드 명령입니다. invokevirtual이나 invokestatic 같은 다른 호출 명령은 호출 대상이 클래스 파일에 고정되어 있지만, invokedynamic은 호출 지점(call site)을 어떤 메서드에 연결할지를 실행 시점의 Java 코드에 위임합니다. JVM에서 동적 언어를 지원하기 위해 JSR 292로 JDK 7에 추가되었고, JDK 8의 람다 표현식 구현에도 쓰입니다.

이 연결을 담당하는 코드가 bootstrap 메서드입니다. 클래스 파일에는 invokedynamic 호출 지점마다 사용할 bootstrap 메서드가 기록됩니다. JVM은 호출 지점을 처음 실행하기 전에 bootstrap 메서드를 호출해 링크하고, bootstrap 메서드는 실제 실행할 메서드를 가리키는 CallSite를 만들어 반환합니다. 여러 스레드가 같은 호출 지점을 동시에 최초 실행하면 bootstrap 메서드가 병행 호출될 수 있지만, JVM은 그중 하나의 결과만 호출 지점에 설치합니다. 문자열 결합에서는 StringConcatFactory.makeConcatWithConstants()가 bootstrap 메서드이고, 이 메서드가 결합 코드를 만들어 CallSite에 담아 돌려줍니다.

MethodHandle은 java.lang.invoke 패키지에 있는, 실행할 대상을 가리키는 참조입니다. 메서드뿐 아니라 생성자 호출이나 필드 접근도 가리킬 수 있고, 인수와 반환 타입을 나타내는 MethodType을 가집니다. 리플렉션의 Method와 쓰임새는 비슷하지만, 접근 권한을 MethodHandle을 만드는 시점에 한 번만 확인하고 invokeExact() 같은 메서드로 바로 호출한다는 점이 다릅니다. 또한 MethodHandles.filterArguments()`나 `MethodHandles.foldArguments() 같은 메서드로 여러 MethodHandle을 엮어 새로운 MethodHandle을 만들 수 있습니다. 뒤에서 볼 문자열 결합 전략 중 일부가 이 조합 기능으로 결합 코드를 구성합니다.

CallSite는 같은 패키지의 객체로, 실행할 메서드를 가리키는 MethodHandle 하나를 target이라는 속성으로 참조합니다. CallSite.getTarget() 메서드가 현재 target인 MethodHandle을 돌려줍니다. JVM은 bootstrap 메서드가 반환한 CallSite를 호출 지점에 연결해 두는데, 이를 링크라고 합니다. 링크된 뒤의 invokedynamic 실행은 그 시점의 target MethodHandle을 호출하는 것과 같습니다. MutableCallSite처럼 실행 중에 target을 다른 MethodHandle로 바꿀 수 있는 구현도 있지만, 문자열 결합에는 target이 바뀌지 않는 ConstantCallSite가 쓰입니다. 그래서 한 번 링크된 뒤에는 일반 메서드 호출처럼 동작하고 JIT 컴파일러의 인라인 최적화 대상도 됩니다.

JDK 25에서 확인한 invokedynamic 바이트코드

JDK 25에서 아래의 소스를 컴파일해서 확인해 보았습니다.

StringTest.java의 인스턴스 메서드 본문

String str0 = "It's a string....";
String str1 = "It's" + " a string" + "....";
String str2 = str0 + str1 + "1111";
for (int i = 0; i < 10; i++) {
    str2 = str2 + "1111";
}

javap -c StringTest 명령으로 바이트코드를 보면 StringBuilder 호출 대신 invokedynamic 명령이 나옵니다.

javap -c StringTest 출력 중 해당 메서드 (JDK 25로 컴파일)

 0: ldc           #7    // String It's a string....
 2: astore_1
 3: ldc           #7    // String It's a string....
 5: astore_2
 6: aload_1
 7: aload_2
 8: invokedynamic #9,  0  // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
13: astore_3
14: iconst_0
15: istore        4
17: iload         4
19: bipush        10
21: if_icmpge     37
24: aload_3
25: invokedynamic #13,  0 // InvokeDynamic #1:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
30: astore_3
31: iinc          4, 1
34: goto          17
37: return

같은 소스를 javac --release 8 옵션으로 컴파일하면 앞 절에서 역컴파일로 보았던 것과 같은 StringBuilder 호출 코드가 나옵니다.

이 방식의 장점은 결합 전략이 컴파일된 클래스 파일이 아니라 JDK 런타임에 있다는 점입니다. 한 번 컴파일한 클래스도 실행하는 JDK를 올리면, 같은 호출 지점과 recipe에 대해 새 런타임의 결합 전략을 재컴파일 없이 적용받을 수 있습니다. 자세한 배경은 JDK 9/JEP 280: String Concatenations Will Never Be the Same에 설명되어 있습니다.

StringConcatFactory 결합 전략의 변화

JDK 9의 StringConcatFactory에는 6가지 결합 전략이 있었고, java.lang.invoke.stringConcat 시스템 프로퍼티로 선택할 수 있었습니다. 전략 이름에서 BC는 실행 시점의 바이트코드 생성을, MH는 MethodHandle 조합을, SB는 StringBuilder 사용을, SIZED는 버퍼 초기 용량 추정을, SIZED_EXACT는 정확한 용량 계산을 뜻합니다.

전략 설명

전략	설명
`BC_SB`	`StringBuilder`를 호출하는 바이트코드를 가진 클래스를 실행 시점에 생성합니다. JDK 8까지의 `javac`이 컴파일 시점에 만들던 코드와 같은 형태입니다.
`BC_SB_SIZED`	`BC_SB`와 같지만 `StringBuilder`의 초기 용량을 추정값으로 지정해서 내부 버퍼의 확장을 줄입니다.
`BC_SB_SIZED_EXACT`	인수들의 길이를 미리 계산해서 `StringBuilder`의 초기 용량을 정확한 값으로 지정합니다.
`MH_SB_SIZED`	바이트코드 생성 대신 `MethodHandle` 조합으로 `StringBuilder` 호출을 구성합니다. 초기 용량은 추정값입니다.
`MH_SB_SIZED_EXACT`	`MH_SB_SIZED`와 같은 방식이지만 초기 용량을 정확하게 계산합니다.
`MH_INLINE_SIZED_EXACT`	기본 전략입니다. `StringBuilder`를 거치지 않고 최종 길이의 `byte` 배열을 직접 만들어 인수들을 그 배열에 바로 씁니다.

BC_SB

StringBuilder를 호출하는 바이트코드를 가진 클래스를 실행 시점에 생성합니다. JDK 8까지의 javac이 컴파일 시점에 만들던 코드와 같은 형태입니다.

BC_SB_SIZED

BC_SB와 같지만 StringBuilder의 초기 용량을 추정값으로 지정해서 내부 버퍼의 확장을 줄입니다.

BC_SB_SIZED_EXACT

인수들의 길이를 미리 계산해서 StringBuilder의 초기 용량을 정확한 값으로 지정합니다.

MH_SB_SIZED

바이트코드 생성 대신 MethodHandle 조합으로 StringBuilder 호출을 구성합니다. 초기 용량은 추정값입니다.

MH_SB_SIZED_EXACT

MH_SB_SIZED와 같은 방식이지만 초기 용량을 정확하게 계산합니다.

MH_INLINE_SIZED_EXACT

기본 전략입니다. StringBuilder를 거치지 않고 최종 길이의 byte 배열을 직접 만들어 인수들을 그 배열에 바로 씁니다.

기본 전략인 MH_INLINE_SIZED_EXACT는 다 채운 byte 배열로 추가 복사 없이 String을 생성하므로, 임시 객체와 복사가 가장 적습니다. StringConcatFactory.java의 generateMHInlineCopy() 메서드가 그 구현입니다. 두 참조 값을 더하는 단순한 형태에는 StringConcatHelper.java의 simpleConcat() 같은 특수 경로도 사용됩니다.

기본 전략 외의 나머지 5가지 선택 전략과 java.lang.invoke.stringConcat 프로퍼티는 JDK-8245455로 JDK 15에서 제거되었습니다. 이 글에서는 simpleConcat() 같은 특수한 형태 전용의 빠른 경로를 제외하고, 대부분의 결합이 기본으로 타는 경로를 일반 결합 경로라고 부르겠습니다. JDK 15부터 JDK 22까지의 일반 결합 경로는 MH_INLINE_SIZED_EXACT에서 이어진 inline-copy MethodHandle 방식입니다. 여러 MethodHandle을 조합해서, 정확한 최종 길이의 byte 배열을 만들고 각 인수를 중간 버퍼 없이 그 배열에 바로 복사해 넣는(inline copy) 결합 메서드를 구성합니다.

JDK 23에서는 JDK-8327247로 인수 개수가 기본 임계값 20을 넘는 결합에 StringBuilder 호출 바이트코드를 생성하는 경로가 추가되었습니다. 큰 MethodHandle 표현식 트리가 JIT 컴파일 자원을 과도하게 쓰는 문제를 피하기 위한 변경입니다.

JDK 24에서는 JDK-8336856으로 주된 일반 결합 경로가 인수 형태(shape)별 hidden class를 생성하는 방식으로 다시 바뀌었습니다.

hidden class는 JEP 371: Hidden Classes로 JDK 15에 추가된 특수한 클래스입니다. Lookup.defineHiddenClass() 메서드로 정의하며, 클래스 이름으로 찾을 수 없고 참조가 사라지면 개별적으로 언로드될 수 있어서, 프레임워크나 JDK가 실행 시점에 만들어 내는 코드에 적합합니다. JDK 25 구현에서 hidden class 캐시의 키가 되는 인수 형태는 동적 인수의 개수와 정규화된 타입으로 이루어진 MethodType입니다. 참조 타입은 Object로, byte와 short는 int로 정규화됩니다. 상수의 내용과 배치는 캐시 키에 포함되지 않고 호출 지점마다 별도의 String[]에 저장됩니다. 따라서 앞의 바이트코드에서 str0 + str1 + "1111"의 호출 지점은 (String, String) → String 시그니처를 가지지만 캐시에서는 (Object, Object) → String 형태를 사용하고, 반복문 안 str2 + "1111"의 호출 지점은 (Object) → String 형태를 사용하므로 서로 다른 형태입니다. 인수 형태별 hidden class 방식은 생성한 결합 클래스를 캐시에 두고 같은 형태의 다른 호출 지점에서 재사용할 수 있습니다. 캐시는 soft reference를 사용하므로 캐시된 클래스가 회수되면 같은 형태의 클래스를 다시 만들 수도 있습니다. 깊게 중첩된 MethodHandle 트리 대신 JIT 컴파일러가 다루기 쉬운 평범한 바이트코드가 만들어지므로, 링크와 초기 구동(warmup) 비용이 줄어듭니다.

JDK 25의 StringConcatFactory는 먼저 단순 결합용 빠른 경로를 확인하고, 그 밖의 결합은 기본적으로 InlineHiddenClassStrategy로 처리합니다. 이 전략은 동적 인수가 하나인 경우 미리 구현된 전용 핸들러를 사용하고, 그 밖의 일반적인 결합에는 인수 형태별 hidden class를 사용합니다. 결합 코드는 최종 크기의 byte 배열을 채우고 그 배열로 String을 만듭니다. JDK 25의 StringConcatFactory.java에서 이를 확인할 수 있습니다.

한편 위의 바이트코드에서 보듯이 반복문 안의 invokedynamic 명령은 반복 주기마다 이미 링크된 결합 메서드를 호출하여 새로운 결과 String을 만듭니다. StringConcatFactory의 bootstrap 메서드가 매번 다시 실행되는 것은 아닙니다. 컴파일러나 런타임이 누적용 StringBuilder 하나를 반복문 밖에 만들어 주지는 않으므로, 많은 문자열을 누적하는 반복문에서 직접 StringBuilder를 쓰라는 결론은 JDK 9 이후에도 같습니다.

정리

JDK 버전 + 결합 연산의 처리 방식

JDK 버전	`+` 결합 연산의 처리 방식
JDK 1.4까지	`javac`이 컴파일 시점에 `StringBuffer`의 `append()`, `toString()` 호출로 변환
JDK 5 ~ 8	`javac`이 컴파일 시점에 동기화를 하지 않는 `StringBuilder` 호출로 변환
JDK 9 ~ 14	`javac`이 `invokedynamic` 호출 지점을 생성. 첫 링크 시 `StringConcatFactory`가 결합 메서드를 연결하며 6가지 전략 중 선택 가능
JDK 15 ~ 22	대안 전략을 제거하고 inline-copy MethodHandle 방식을 일반 결합 경로로 사용
JDK 23	인수가 많은 결합에는 `StringBuilder` 호출 바이트코드를 생성하는 경로 사용
JDK 24 ~ 25	단순 결합용 빠른 경로, 단일 인수 전용 구현과 정규화된 인수 형태별 hidden class 기반의 일반 결합 경로 사용

JDK 1.4까지

javac이 컴파일 시점에 StringBuffer의 append(), toString() 호출로 변환

JDK 5 ~ 8

javac이 컴파일 시점에 동기화를 하지 않는 StringBuilder 호출로 변환

JDK 9 ~ 14

javac이 invokedynamic 호출 지점을 생성. 첫 링크 시 StringConcatFactory가 결합 메서드를 연결하며 6가지 전략 중 선택 가능

JDK 15 ~ 22

대안 전략을 제거하고 inline-copy MethodHandle 방식을 일반 결합 경로로 사용

JDK 23

인수가 많은 결합에는 StringBuilder 호출 바이트코드를 생성하는 경로 사용

JDK 24 ~ 25

단순 결합용 빠른 경로, 단일 인수 전용 구현과 정규화된 인수 형태별 hidden class 기반의 일반 결합 경로 사용

문자열 타입의 컴파일 타임 상수식이 하나의 상수로 합쳐지는 동작은 모든 버전에서 같습니다. 반복문 밖에서 문자열 한두 개를 더하는 코드는 javac과 JDK 런타임이 최적화할 수 있으므로 가독성이 좋은 + 연산을 그대로 쓰면 됩니다. 반면 컴파일러나 런타임이 반복문을 누적용 StringBuilder 하나로 자동 변환하지는 않습니다. 성능이 중요한 반복문에서 많은 문자열을 누적한다면 StringBuilder를 직접 쓰는 편이 좋습니다.

참고 자료

1. JLS 15.18.1은 컴파일러가 StringBuffer나 그와 비슷한 기법을 사용할 수 있다고 설명합니다.

2. 컴파일 타임 상수식의 정확한 범위는 JLS 15.29를 참고합니다.

3. 성능 테스트 사례는 String concatenation with Java 8을 참고합니다.

4. JMH를 쓰지 않은 System.nanoTime() 기반의 단순 측정이라 미세한 수치는 부정확할 수 있지만, 수백 배 이상의 차이라 결론에는 영향이 없습니다.