[Java] 문자열 - String pool과 String concatenation

우테코에서 문자열 관련 수업을 듣다가, 이것저것 궁금해서 찾아봤는데 블로그 글로 작성하면 좋을 것 같아서 이렇게 작성한다 🤗

의식의 흐름대로 궁금한 점들을 찾아본 거여서 상당히 두서가 없을 것 같다 🥲

---

 

✔️ String과 String pool

String은 문자열을 저장하고 처리하는 클래스이다. 불변 클래스이기 때문에, 한 번 생성되면 변경이 불가능하다. 또한, final 클래스로 되어 있기 때문에 상속이 불가능하다.

UTF-16 인코딩을 활용하여, 인코딩된 문자열을 저장하기 때문에 각 문자를 2바이트 (=16비트) 유니코드 문자로 표현한다.

public String(int[] codePoints, int offset, int count) {
        checkBoundsOffCount(offset, count, codePoints.length);
        if (count == 0) {
        this.value = "".value;
        this.coder = "".coder;
        return;
        }
        if (COMPACT_STRINGS) {
        byte[] val = StringLatin1.toBytes(codePoints, offset, count);
        if (val != null) {
        this.coder = LATIN1;
        this.value = val;
        return;
        }
        }
        this.coder = UTF16;
        this.value = StringUTF16.toBytes(codePoints, offset, count);
        }

(내부 구현체를 보면, 아래에서 this.coder = UTF16으로 설정해둔 것을 볼 수 있다.)

 

문자열을 처리하기 위해, 'String'은 정말 많이 사용되는 클래스이다. 그렇기 때문에, 항상 객체를 생성해서 사용하기에는 어쩌면 낭비일 수 있다. 이를 최적화하기 위해서 자바에서는 내부적으로 'String pool'을 활용하여 중복된 문자열을 공유하게 된다.

 

여기서, String pool이란 무엇일까? JVM에서 String 객체를 메모리에서 관리하기 위한 일종의 '저장소'이다. String pool에 대해서 알아보기 전에, 먼저 String을 생성하는 방법에 대해 생각해봐야 한다.

 

String을 생성하기 위해서는, new, 혹은 리터럴을 사용하여 생성할 수 있다.

String hello = new String("hello"); // new 사용하기
        String hi = "Hi"; // 리터럴 사용하기

 

둘은 무슨 차이가 있을까? 사실 new를 통해서 생성하는 건 거의 본 적이 없다. (권장하지도 않는다.)

먼저, 'new'를 통해 생성한 String 객체는 heap 영역에 저장되고, 리터럴로 생성한 객체는 'String pool'에 저장된다.

그림으로 보면 다음과 같다.

new 연산자를 활용하면 새로운 객체를 생성하여 'heap' 영역에 저장하게 되며, 리터럴을 사용하면 String pool에 예쁘게 쌓이는 것을 볼 수 있다. 이때, 가장 중요한 것은 동일한 문자열이 한 번 더 들어왔을 경우이다. String pool은 Heap 내부에 존재하며, JVM 이 시작될 때 생성되고, 클래스 파일이 로드될 때 초기화된다. 그렇기 때문에 프로그램이 실행될 때마다 새로운 String pool이 생성되는 것이 아닌, JVM이 시작될 때 한 번 생성되고 그 이후로는 계속해서 재사용된다는 특징이 있다.

 

String hello = new String("hello");
        String hello2 = new String("hello");

        String hi = "Hi";
        String hi2 = "Hi";

이와 같이 문자열이 존재할 때, 위의 구조는 어떻게 변하게 될까?

new를 통해서 생성하게 되면, 이미 존재하는 값이더라도 무조건 힙에 새로운 공간을 할당하게 되지만, 리터럴을 활용하게 되면 이미 존재하는 값이 있을 때 해당 값을 가리키도록 한다는 것이다. 즉, 서로 공유하는 상태가 된다. 참고로, 내부적으로 String pool은 HashMap을 사용하여 구현하고 있기 때문에 (당연히 ConcurrentHashMap이다. 동시성 보장!) 

String hello = new String("hello");
        String hello2 = new String("hello");

        String hi = "Hi";
        String hi2 = "Hi";

        System.out.println(hello == hello2); // false
        System.out.println(hello.equals(hello2)); // true

        System.out.println(hi == hi2); // true
        System.out.println(hi.equals(hi2)); // true

실제로 비교 연산을 해보면, 객체를 비교하는 ==의 경우 hello와 hello2에 대해 false를 반환하고, hi와 hi2에 대해서 true를 반환하는 것을 볼 수 있다. 

 

---

✔️ String pool은 어디에 저장되었을까?

Java6 이전 버전까지 문자열은 PermGen(Permanent Generation) 영역에 위치했었다. PermGen 영역은 클래스나 메타 데이터, String pool 같이 고정적으로 생성되는 객체들이 저장되는 영역이다. 즉, JVM이 실행되더라도 변하지 않는 메타데이터들을 저장하는 공간이라고 보면 된다. 내부적으로 PermGen의 초기 사이즈인 PermSize와 최대 사이즈인 MaxPermSize를 조절할 수 있으며, 일반적으로 고정된 크기로 할당되었기 때문에 OOM (Out Of Memory)이 발생할 수 있었다. 또한, GC는 Full GC만 수행하였기 때문에 애플리케이션의 성능적으로도 그렇게 좋지 않았다.

 

자바의 GC (Garbage Collector)에 대해서 간략하게 짚고 넘어가보자.

Young Generation에서는 새롭게 생성된 객체들이 저장되고, Old Generation에서는 Young generation에서 살아남은 객체들이 저장된다. (Young에서 Eden은 객체가 생성되자마자 저장되는 곳이고, Survivor는 한 번 Minor GC를 겪은 객체들이 저장되는 곳이다.) Old에서만 GC가 일어나는 것을 Major GC, Young에서만 일어나는 것을 Minor GC라고 한다.  Full GC의 경우 두 영역 모두에 대해서 사용되지 않는 객체들에 대해 해제하는 작업이 들어가기 때문에 성능에 지장을 줄 수 있다. 

 

그러나, Java8부터는 PermGen 영역이 Metaspace 영역으로 대체되었으며, 기존에 Heap에서 관리되던 PermGen 영역과 달리 Native Memory에 할당된다. Native Memory 영역은 JVM 외부에서 할당되고 관리되기 때문에, JVM이 실행되고 있는 OS의 메모리 영역을 사용하며, GC에 의해 관리되지 않는다는 특징이 존재한다. Heap에 저장되지 않기 때문에 GC가 관리하지 않지만, Heap에 저장되지 않음으로서 용량에 대한 제한이 없다는 것이 특징이다. (물론 OS의 메모리에는 국한되어 있다 🥲)

 

즉, Metaspace에서는 클래스 로딩 시 PermGen 영역과 달리 동적으로 메모리를 할당할 수 있으며, 기본적으로 시스템의 메모리 크기에 따라서 동적으로 할당되지만 -XX:MetaspaceSize와 -XX:MaxMetaspaceSize 옵션을 통해서 수동으로 조절도 가능하다. 그러나, String pool의 경우 permGen이 아닌 Heap으로 이동했으며, Heap에서 관리되기 때문에 GC가 수행된다.

 

 

💬 metaspace 영역 vs method 영역

개인적으로 공부할 때 궁금해서 찾아본 내용이다. JVM에서 메서드 영역 (다른 곳에서 클래스 영역, 혹은 스태틱 영역이라고도 하는 것 같다. 이름이 참 다양하다)은 클래스 파일의 바이트 코드가 로드되는 곳으로, 이전의 PermGen에서 관리되던 것들을 이곳에서 관리하게 되었다. 이때 좀 혼란이 왔었는데, '그러면 metaspace 영역와 method 영역은 동일한 것인가?'라는 의문이 들었다.

 

찾아본 결과, Java8 이전까지는 서로 같은 개념이었으나 PermGem 영역에 위치해 있던 영역이 native area로 이동하면서 'metaspace'라는 이름으로 변경되었다. (이전까지는 permGen에서 메타데이터를 전부 관리하였음) Java8 이후부터는 클래스의 메타 데이터 일부를 native에, 일부는 heap에 저장하면서 native memory에 저장되는 부분을 'metaspace', heap 영역에 저장되는 부분을 'class metadata' 영역이라고 (JDK 내부에서 'klass metadata'라고 하는 것 같다) 하면서 약간은 다른 개념으로 사용한다고 한다. 

 

아무튼... JVM의 구조는 다음과 같은데,  heap과 native memory 부분을 제대로 생각하지 못해서 착오가 일어났던 것 같다.

- Method area: JVM의 클래스 정보를 저장한다. 클래스마다 별도로 생성되며, 클래스 로더가 클래스 파일을 읽어와서 클래스 정보를 저장한다. 클래스 이름, 메서드 변수와 이름, 타입, 접근 제어자들이 저장된다. = java8 이전에는 permGen area. 이후에는 metaspace라고 생각해도 좋을 것 같다.

- Native Method Stack: 메서드 영역을 사용할 때, Java Native Interface를 사용해서 호출되는 코드가 저장되는 영역이다. (그냥 이름이 메서드 영역이랑 비슷해서 적어둠)

 

이야기가 길어졌다. 아무튼, String pool의 경우 heap으로 옮겨졌기 때문에 GC가 관리할 수 있었으며, 크기가 고정되었던 permGen에서는 데이터가 많아졌을 때 OOM이 발생할 수 있었으나, GC 관리로 인해서 더 많은 데이터를 보관할 수 있게 되었다!

 

---

✔️ 문자열 연결하기 - String concatenation 

String은 앞서 말한 것처럼 불변하다. 그래서 String과 String을 더하게 되면, 새로운 String 객체를 생성하게 된다. String을 더하게 되면 메모리 할당과 해제가 계속 발생하게 되며 낭비가 될 수 있기에, 보통 문자열을 더할 때 내부적으로 StringBuilder를 사용한다. StringBuilder를 사용하게 되면 기존 데이터에 계속 데이터를 더하는 방식이기 때문에 속도가 더 빨라지게 된다.

 

우선, 직접 StringBuilder를 통해서 문자열을 더해보자. 

StringBuilder str1 = new StringBuilder("hi");
        str1.append(" java");

바이트 코드를 보면 다음과 같다.

L0
        LINENUMBER 5 L0
        NEW java/lang/StringBuilder
        DUP
        LDC "hi"
        INVOKESPECIAL java/lang/StringBuilder.<init> (Ljava/lang/String;)V
        ASTORE 1
        L1
        LINENUMBER 6 L1
        ALOAD 1
        LDC " java"
        INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
        POP
        L2
        LINENUMBER 7 L2
        RETURN
        L3
        LOCALVARIABLE args [Ljava/lang/String; L0 L3 0
        LOCALVARIABLE str1 Ljava/lang/StringBuilder; L1 L3 1
        MAXSTACK = 3
        MAXLOCALS = 2

 

크게 볼 것은 없고, invokespecial을 통해서 StringBuilder를 호출했다는 점과, L0에서 저장한 1번 인덱스의 hi를 L1에서 로드하여, invokevirtual을 통해 append를 호출하여 인자로 전달했다는 점이다. (pop은 stringbuilder에서 append한 이후 반환된 결과값을 사용하지 않아서 스택에서 제거한 것이다.) 

 

그렇다면, + 연산자를 사용해서 진행하면 어떻게 될까?

 

Java 9 이전에서는 문자열 연결에 +을 사용하면, 컴파일러는 StringBuilder 클래스를 사용한 코드로 변환을 진행해주었다. +을 사용한 문자열 연결은 내부적으로 StringBuilder 객체를 생성하고, append를 통해 문자열을 계속해서 추가해주어 toString()을 통해 해당 문자열을 반환하는 형태로 진행했었다. 물론, 더 이전 버전 (JDK 1.4)에서는 +가 계속 남아있었다. (직접 확인하고 싶었으나, 더 낮은 버전을 다운받지를 못했다... 🥲 다른 분이 작성한 게시글 참고!) 

 

 

그러나, Java 9 이후부터는 (JEP 280) InvokeDynamic을 호출하는 식으로 변경되었다! invokeDynamic이란, methodHandle을 호출할 때 사용되는 기술로, 동적으로 메서드 호출을 처리한다. 호출할 메서드가 동적으로 결정될 때 유용하며, 컴파일러에서 정적으로 결정될 수 없기 때문에 런타임에서 호출 대상을 결정하고, 해당 메서드를 호출하게 된다. 또한! Java 8 이후부터 도입된 람다식이 invokeDynamic을 활용하여 구현되었으며, 함수형 인터페이스 처리도 더 유용하게 해준다. (람다식이 호출되면, invokedynamic을 통해 해당 람다식을 처리할 메서드를 동적으로 연결하는 식으로 구현되어 있다 💦)

 

String hi = "hi";
        String java = " java";
        String hello = hi + java;

아무튼, 위 코드의 바이트 코드를 살펴보면 다음과 같이 나온다. 

 L0
        LINENUMBER 5 L0
        LDC "hi"
        ASTORE 1
        L1
        LINENUMBER 6 L1
        LDC " java"
        ASTORE 2
        L2
        LINENUMBER 8 L2
        ALOAD 1
        ALOAD 2
        INVOKEDYNAMIC makeConcatWithConstants(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; [
        // handle kind 0x6 : INVOKESTATIC
        java/lang/invoke/StringConcatFactory.makeConcatWithConstants(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
        // arguments:
        "\u0001\u0001"
        ]
        ASTORE 3
        L3
        LINENUMBER 9 L3
        RETURN
        L4
        LOCALVARIABLE args [Ljava/lang/String; L0 L4 0
        LOCALVARIABLE hi Ljava/lang/String; L1 L4 1
        LOCALVARIABLE java Ljava/lang/String; L2 L4 2
        LOCALVARIABLE hello Ljava/lang/String; L3 L4 3
        MAXSTACK = 2
        MAXLOCALS = 4

 

바이트 코드를 조금씩 살펴보자.

 

 L0
        LINENUMBER 5 L0
        LDC "hi"
        ASTORE 1

LineNumber는 코드에서 몇 번째 줄에 위치했는지 말하는 것이다.  LDC는 어떤 문자열을 로드했는지 나타내며, 여기서는 "hi"라는 문자열을 로드하여 ASTORE를 통해 스택에 있는 가장 위에 있는 값을 로컬 변수 배열의 인덱스 1번에 저장하였다.

즉, L0과 L1에서는 "hi"와 " java"라는 문자열을 각각의 변수에게 할당했다고 보면 된다.

 

L2
        LINENUMBER 8 L2
        ALOAD 1
        ALOAD 2
        INVOKEDYNAMIC makeConcatWithConstants(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; [
        // handle kind 0x6 : INVOKESTATIC
        java/lang/invoke/StringConcatFactory.makeConcatWithConstants(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
        // arguments:
        "\u0001\u0001"
        ]
        ASTORE 3

이후, L2를 보면 1, 2번의 변수를 ALOAD를 통해 각 변수의 값을 스택에 넣고, INVOKEDYNAMIC을 통해 'makeConcatWithConstants'메서드를 호출한 것을 확인할 수 있다. 해당 메서드를 통해서 +을 통해 값을 연결하는 것과 동일한 작업을 진행하고, 리턴받았다고 생각하면 된다. 또한, 인자로 전달되는 상수값들을 넘겨주는데, 여기서 사용되는 "\u0001\u0001"의 경우 String pool에 저장되어 있는 값을 사용한 것이다. 그리고, 받은 값을 3번 인덱스에 넣어주었다.

 

 

L4
        LOCALVARIABLE args [Ljava/lang/String; L0 L4 0
        LOCALVARIABLE hi Ljava/lang/String; L1 L4 1
        LOCALVARIABLE java Ljava/lang/String; L2 L4 2
        LOCALVARIABLE hello Ljava/lang/String; L3 L4 3
        MAXSTACK = 2
        MAXLOCALS = 4

이후, LOCALVARIABLE을 통해 변수 이름과, 해당 변수의 유효 범위를 나타내게 되며, 마지막에 보면 'hello'라는 변수에 3번 인덱스의 값 = 즉, concat을 진행한 값을 할당해주는 것을 확인할 수 있다. maxstack은 사용되었던 스택의 최대 크기를, maxlocals는 사용되었던 로컬 변수의 최대 개수를 의미한다.

 

 

아무튼, invokeDynamic을 활용한 덕분에 컴파일러는 StringBuilder를 사용할 필요없이 동적으로 메서드를 주입받아서 처리할 수 있게 되었다. StringBuilder에서 append()는 내부 문자열 버퍼 (char[])를 생성하며 문자열을 저장하는 구조이기 때문에 결국 메모리 소비가 발생하는데 (StringBuilder의 초기 사이즈는 16으로 고정이라, 문자열 길이가 길어지면 계속 복사 작업이 일어나서 비효율적이다), 이러한 측면에서 메모리 사용량을 줄일 수 있으며, 바이트 코드의 변경이 필요하지 않기 때문에 더 효율적으로 실행할 수 있다는 점이 장점이다. (바이트코드의 최적화 측면에서 좋은 것 같다!)

-> 이 부분은 이팩티브 자바 글을 정리할 때 다시 한 번 언급하겠다 😎

 

---

String에 대해 작성하려고 했으나, 자꾸 모르는 개념이 생겨서 많이 헤맨 느낌이다 ;ㅅ;

수업 때 어렵다고 느꼈던 걸 최대한 쉽게 풀었는데 다른분들이 봐도 이해가 됐으면 좋겠다.

앞으로도 파이팅... 💪