JLS
이 개념을 JLS에서 "인터 닝"이라고합니다.
JLS 7 3.10.5의 관련 구절 :
또한 문자열 리터럴은 항상 String 클래스의 동일한 인스턴스를 나타냅니다. String.intern 메소드를 사용하여 고유 한 인스턴스를 공유하기 위해 문자열 리터럴 또는보다 일반적으로 상수 표현식 (§15.28)의 값인 문자열이 "인터 닝"되기 때문입니다.
예 3.10.5-1. 문자열 리터럴
편집 단위 (§7.3)로 구성된 프로그램 :
package testPackage;
class Test {
public static void main(String[] args) {
String hello = "Hello", lo = "lo";
System.out.print((hello == "Hello") + " ");
System.out.print((Other.hello == hello) + " ");
System.out.print((other.Other.hello == hello) + " ");
System.out.print((hello == ("Hel"+"lo")) + " ");
System.out.print((hello == ("Hel"+lo)) + " ");
System.out.println(hello == ("Hel"+lo).intern());
}
}
class Other { static String hello = "Hello"; }
그리고 컴파일 단위 :
package other;
public class Other { public static String hello = "Hello"; }
출력을 생성합니다.
true true true true false true
JVMS
JVMS 7 5.1 말한다 :
문자열 리터럴은 String 클래스의 인스턴스에 대한 참조이며 클래스 또는 인터페이스의 이진 표현에서 CONSTANT_String_info 구조 (§4.4.3)에서 파생됩니다. CONSTANT_String_info 구조는 문자열 리터럴을 구성하는 일련의 유니 코드 코드 포인트를 제공합니다.
Java 프로그래밍 언어를 사용하려면 동일한 문자열 리터럴 (즉, 동일한 코드 포인트 시퀀스를 포함하는 리터럴)이 동일한 String 클래스 인스턴스 (JLS §3.10.5)를 참조해야합니다. 또한 String.intern 메소드가 문자열에서 호출되면 결과는 해당 문자열이 리터럴로 표시 될 때 리턴되는 동일한 클래스 인스턴스에 대한 참조입니다. 따라서 다음 표현식은 true 값을 가져야합니다.
("a" + "b" + "c").intern() == "abc"
문자열 리터럴을 도출하기 위해 Java Virtual Machine은 CONSTANT_String_info 구조에서 제공하는 코드 포인트 시퀀스를 검사합니다.
CONSTANT_String_info 구조에서 제공 한 것과 동일한 유니 코드 코드 포인트 시퀀스를 포함하는 String 클래스의 인스턴스에서 String.intern 메소드를 이전에 호출 한 경우 문자열 리터럴 파생 결과는 동일한 클래스의 클래스 인스턴스에 대한 참조입니다.
그렇지 않으면 CONSTANT_String_info 구조에 의해 제공된 일련의 유니 코드 코드 포인트를 포함하는 String 클래스의 새 인스턴스가 작성됩니다. 해당 클래스 인스턴스에 대한 참조는 문자열 리터럴 파생의 결과입니다. 마지막으로, 새로운 String 인스턴스의 인턴 메소드가 호출됩니다.
바이트 코드
OpenJDK 7의 바이트 코드 구현을 살펴 보는 것도 유익합니다.
디 컴파일하면 :
public class StringPool {
public static void main(String[] args) {
String a = "abc";
String b = "abc";
String c = new String("abc");
System.out.println(a);
System.out.println(b);
System.out.println(a == c);
}
}
우리는 상수 수영장에 있습니다.
#2 = String #32 // abc
[...]
#32 = Utf8 abc
그리고 main:
0: ldc #2 // String abc
2: astore_1
3: ldc #2 // String abc
5: astore_2
6: new #3 // class java/lang/String
9: dup
10: ldc #2 // String abc
12: invokespecial #4 // Method java/lang/String."<init>":(Ljava/lang/String;)V
15: astore_3
16: getstatic #5 // Field java/lang/System.out:Ljava/io/PrintStream;
19: aload_1
20: invokevirtual #6 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
23: getstatic #5 // Field java/lang/System.out:Ljava/io/PrintStream;
26: aload_2
27: invokevirtual #6 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
30: getstatic #5 // Field java/lang/System.out:Ljava/io/PrintStream;
33: aload_1
34: aload_3
35: if_acmpne 42
38: iconst_1
39: goto 43
42: iconst_0
43: invokevirtual #7 // Method java/io/PrintStream.println:(Z)V
참고 사항 :
0및 3: 동일한 ldc #2상수로드 (리터럴)12: 새로운 문자열 인스턴스가 생성됩니다 ( #2인수로)35: a와 c일반 객체로 비교if_acmpne
상수 문자열의 표현은 바이트 코드에서 매우 마술입니다.
위의 JVMS 인용문은 Utf8이 가리키는 경우마다 동일한 인스턴스가에 의해로드된다고 말합니다 ldc.
필드에 대해 비슷한 테스트를 수행했으며
static final String s = "abc"ConstantValue 속성을 통해 상수 테이블을 가리킴- 최종이 아닌 필드에는 해당 속성이 없지만 다음으로 초기화 할 수 있습니다.
ldc
결론 : 문자열 풀에 대한 직접적인 바이트 코드 지원이 있으며 메모리 표현이 효율적입니다.
보너스 : 직접 바이트 코드를 지원하지 않는 Integer pool 과 비교하십시오 (예 : CONSTANT_String_info아날로그 없음 ).
