java.lang.String.intern ()을 사용하는 것이 좋습니까?

Javadoc에 String.intern()대해서는 자세히 설명하지 않습니다. (간단히 말하면 : 문자열의 표준 표현을 반환하여 내부 문자열을 사용하여 비교할 수 있습니다 ==)

• 언제이 기능을 선호 String.equals()합니까?
• Javadoc에 언급되지 않은 부작용, 즉 JIT 컴파일러에 의한 최적화가 어느 정도 있습니까?
• 추가 용도가 String.intern()있습니까?

String.equals ()에 대해이 함수를 언제 사용합니까?

문자열을 참조로 비교할 수 있으므로 속도 가 필요할 때 (== 같음보다 빠름)

Javadoc에 언급되지 않은 부작용이 있습니까?

가장 큰 단점은 비교할 모든 문자열을 실제로 intern ()하도록해야한다는 점을 기억해야한다는 것입니다. 모든 문자열을 intern ()하는 것을 잊어 버리면 혼란스럽게 잘못된 결과를 얻을 수 있습니다. 또한 모든 사람을 위해 내부화되는 문자열에 의존하고 있음을 매우 명확하게 문서화하십시오.

문자열을 내부화하기로 결정한 경우 두 번째 단점은 intern () 메소드가 상대적으로 비싸다는 것입니다. 고유 한 문자열 풀을 관리해야하므로 문자열이 이미 내부화 된 경우에도 상당한 작업이 필요합니다. 따라서 코드 디자인에주의하십시오. 예를 들어 입력에 적절한 문자열을 모두 intern ()으로 설정하면 더 이상 걱정할 필요가 없습니다.

(JGuru에서)

세 번째 단점 (Java 7 이하 만 해당) : 인턴 된 문자열은 PermGen 공간에 있으며 대개 매우 작습니다. 충분한 여유 공간이있는 OutOfMemoryError가 발생할 수 있습니다.

(Michael Borgwardt 출신)

이것은 문자열 비교와 거의 관련이 없습니다. 문자열 인터 닝 은 응용 프로그램에 동일한 내용의 문자열이 많은 경우 메모리를 절약하기위한 것입니다. String.intern()응용 프로그램 을 사용 하면 장기적으로 하나의 인스턴스 만 갖게되고 부작용은 일반 문자열 비교 대신 빠른 참조 평등 비교를 수행 할 수 있다는 것입니다 (그러나 인턴 만 잊어 버리면 깨지기 쉽기 때문에 일반적으로 권장하지 않습니다) 단일 인스턴스).

String.intern()확실히 현대 JVM에서 가비지 수집됩니다.
다음은 GC 활동으로 인해 메모리가 부족하지 않습니다.

// java -cp . -Xmx128m UserOfIntern

public class UserOfIntern {
    public static void main(String[] args) {
        Random random = new Random();
        System.out.println(random.nextLong());
        while (true) {
            String s = String.valueOf(random.nextLong());
            s = s.intern();
        }
    }
}

비 GCed String.intern () 의 신화 에 대해 더 많은 정보를 참조하십시오 .

최근 Java 6, 7 및 8의 String.intern () 구현에 대한 기사를 작성했습니다. Java 6, 7 및 8-문자열 풀링의 String.intern .

Java의 문자열 풀링으로 현재 상황에 대한 충분한 정보가 포함되기를 바랍니다.

간단히 말해서 :

• String.intern()PermGen에 들어가기 때문에 Java 6에서는 피하십시오 .
• String.intern()Java 7 및 Java 8 선호 : 자체 오브젝트 풀을 롤링하는 것보다 4-5 배 적은 메모리 사용
• 반드시 조정하십시오 -XX:StringTableSize(기본값은 너무 작을 수 있습니다. 소수를 설정하십시오)

==로 문자열을 비교하는 것은 equals ()보다 훨씬 빠릅니다.

5 시간이 빠르지 만 일반적으로 문자열 비교는 응용 프로그램의 총 실행 시간의 작은 비율 만 나타 내기 때문에 전체 게인은 그보다 훨씬 작으며 최종 게인은 몇 퍼센트로 희석됩니다.

String.intern ()은 문자열을 힙에서 빼내어 PermGen에 넣습니다.

내부화 된 문자열은 다른 저장 영역 ( 영구 생성)에 저장됩니다. 영구 생성 은 클래스, 메소드 및 기타 내부 JVM 오브젝트와 같이 사용자가 아닌 오브젝트를 위해 예약 된 JVM 영역입니다. 이 영역의 크기는 제한되어 있으며 힙보다 훨씬 소중합니다. 이 영역이 힙보다 작기 때문에 모든 공간을 사용하고 OutOfMemoryException을 얻을 가능성이 높습니다.

String.intern () 문자열은 가비지 수집됩니다

새로운 버전의 JVM에서는 객체에 의해 참조되지 않을 때 내부화 된 문자열도 가비지 수집됩니다.

위의 3 가지 점을 염두에두면 String intern ()이 문자열 비교를 많이 할 때 소수의 상황에서만 유용 할 수 있다는 것을 공제 할 수 있지만 정확히 무엇을 모르는 경우 내부 문자열을 사용하지 않는 것이 좋습니다 하고있다 ...

String.equals ()에 대해이 함수를 언제 사용합니까?

그들이 다른 일을한다고해서 아마 결코 그렇지 않을 것입니다.

성능상의 이유로 문자열을 참조 평등에 대해 비교할 수 있도록 문자열을 인턴하는 것은 사용자 입력에서 오는 문자열 또는 IO가 인바운드되지 않는 한동안 문자열에 대한 참조를 보유하는 경우에만 유용합니다.

즉, 응용 프로그램에서 외부 소스에서 입력을 받아 의미 론적 가치가있는 객체로 식별자를 처리하지만 객체는 원시 데이터와 구별 할 수없는 유형을 가지며 프로그래머가 어떻게 해야하는지에 대한 규칙이 다릅니다. 그걸 써.

UserId유형이 java.lang.String사용자 ID 인 경우 참조 시맨틱으로 유형 을 오버로드하는 것보다 인터 인 된 유형 (스레드 안전 일반 인터 닝 메커니즘을 작성하는 것이 용이함)을 작성하는 것이 훨씬 항상 낫 습니다 .

이렇게하면 특정 문자열이 억류되었는지 여부를 혼동하지 않고 개방형 열거 형에 필요한 추가 동작을 캡슐화 할 수 있습니다.

어떤 이점도 인식하지 못하고 있다면 equals () 자체가 내부적으로 intern ()을 사용한다고 생각할 것입니다.

파열 인턴 () 신화

Daniel Brückner가 절대적으로 옳습니다. 문자열 인터 닝은 메모리를 절약하기위한 것입니다 (힙). Google 시스템에는 현재 특정 데이터를 보유하기위한 거대한 해시 맵이 있습니다. 시스템이 확장됨에 따라 해시 맵은 메모리에서 힙을 만들 수있을만큼 커질 것입니다 (테스트 한대로). 모든 중복 된 문자열을 해시 맵의 모든 객체에 삽입함으로써 상당한 양의 힙 공간을 절약 할 수 있습니다.

또한 Java 7에서 인턴 문자열은 더 이상 PermGen에 살지 않고 대신 힙입니다. 따라서 크기에 대해 걱정할 필요가 없으며 가비지 수집이 가능합니다.

JDK 7에서 인턴 된 문자열은 더 이상 Java 힙의 영구 생성에 할당되지 않지만 대신 애플리케이션이 작성한 다른 오브젝트와 함께 Java 힙의 주요 부분 (젊고 오래된 세대)에 할당됩니다. . 이 변경으로 인해 기본 Java 힙에 더 많은 데이터가 상주하고 영구 생성의 데이터가 줄어들어 힙 크기를 조정해야 할 수 있습니다. 대부분의 응용 프로그램은 이러한 변경으로 인해 힙 사용량에서 상대적으로 작은 차이 만 볼 수 있지만 많은 클래스를로드하거나 String.intern () 메서드를 많이 사용하는 큰 응용 프로그램은 더 큰 차이를 보게됩니다.

Javadoc에 언급되지 않은 부작용, 즉 JIT 컴파일러에 의한 최적화가 어느 정도 있습니까?

JIT 수준에 대해서는 잘 모르지만 문자열 풀에 대한 직접적인 바이트 코드 지원이 있습니다.이 문자열 은 전용 CONSTANT_String_info구조체로 마술과 효율적으로 구현됩니다 (일반적인 표현이 다른 대부분의 객체와 달리).

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

상수 문자열의 표현은 바이트 코드에서 매우 마술입니다.

• 그것은 전용 갖는다 CONSTANT_String_info의 일반 오브젝트와 달리 구조 (예를 new String)
• 구조체 는 데이터를 포함 하는 CONSTANT_Utf8_info 구조체를 가리 킵니다 . 이것이 문자열을 나타내는 데 필요한 유일한 데이터입니다.

위의 JVMS 인용문은 Utf8이 가리키는 경우마다 동일한 인스턴스가에 의해로드된다고 말합니다 ldc.

필드에 대해 비슷한 테스트를 수행했으며

• static final String s = "abc"ConstantValue 속성을 통해 상수 테이블을 가리킴
• 최종이 아닌 필드에는 해당 속성이 없지만 다음으로 초기화 할 수 있습니다. ldc

보너스 : 직접 바이트 코드를 지원하지 않는 Integer 풀 과 비교하십시오 (예 : CONSTANT_String_info아날로그 없음 ).

문자열을 여러 번 비교할 때 equals-comparison이 병목 현상이있는 경우에만 intern과 ==-comparison을 검사합니다. intern ()이 자유롭지 않기 때문에 적은 수의 비교에는 도움이되지 않습니다. 적극적으로 문자열을 삽입하면 intern () 호출이 점점 느려집니다.

subString()소스 문자열에 비해 결과가 작고 개체 수명이 길 때 사용하면 메모리 누수가 발생할 수 있습니다 .

일반적인 해결책은 사용하는 new String( s.subString(...))것이지만 잠재력의 결과를 저장 subString(...)하고 호출자를 제어 할 수없는 클래스가있는 intern()경우 생성자에 전달 된 String 인수 를 저장하는 것을 고려할 수 있습니다 . 이것은 잠재적 인 큰 버퍼를 해제합니다.

문자열 인터 닝은 equals()메서드가 equals()시작될 때 개체가 동일한 지 확인 하기 위해 메서드를 빠르게 확인하기 때문에 메서드가 자주 호출되는 경우에 유용합니다 .

if (this == anObject) {
    return true;
}

이것은 Collection다른 코드를 통해 검색 할 때 일반적으로 발생 하지만 다른 코드에서도 문자열 평등 검사를 수행 할 수 있습니다.

인터 닝에 비용이 들지만, 일부 코드의 마이크로 벤치 마크를 수행했으며 인터 닝 프로세스가 런타임을 10 배 증가시킵니다.

코드에서 문자열이 자동으로 코드 될 때 코드 외부에 저장된 키를 읽을 때 일반적으로 코드를 작성하는 것이 가장 좋습니다. 이것은 일반적으로 첫 번째 사용자 페널티를 방지하기 위해 응용 프로그램의 초기화 단계에서 발생합니다.

키 조회를 수행하는 데 사용할 수있는 사용자 입력을 처리 할 때 수행 할 수있는 또 다른 위치입니다. 이것은 일반적으로 요청 프로세서에서 발생합니다. 내부 문자열은 전달되어야합니다.

그 외에도, 코드의 나머지 부분에서 인턴을하는 것은 별다른 의미가 없으므로 일반적으로 아무런 이점이 없습니다.

나는 유지 보수 번거 로움이 가치가 없다고 투표합니다.

대부분의 경우 코드가 하위 문자열로 많은 작업을 수행하지 않는 한 필요하지 않고 성능상의 이점이 없습니다. 이 경우 String 클래스는 원래 문자열과 오프셋을 사용하여 메모리를 절약합니다. 코드에서 하위 문자열을 많이 사용하면 메모리 요구 사항이 폭발적으로 증가 할 것으로 생각됩니다.

http://kohlerm.blogspot.co.uk/2009/01/is-javalangstringintern-really-evil.html

에 따르면 이전에 객체 를 비교 하는 String.equals()데 사용 "=="하는 주장String

http://www.codeinstructions.com/2009/01/busting-javalangstringintern-myths.html

문자열의 길이와 내용을 비교합니다.

(판매 카탈로그의 제품 코드 문자열은 길이가 모두 동일합니다.-BIC0417은 자전거 타는 사람의 안전 헬멧이며, TIG0003은 라이브 성인 남성 호랑이입니다. 그 중 하나를 주문하려면 모든 종류의 라이센스가 필요할 것입니다. 안전 헬멧을 동시에 주문하는 것이 좋습니다.)

따라서 문자열을 intern()버전으로 교체하면 이점이 있지만, equals()프로그래밍에서 "=="를 사용하지 않고 안전 및 가독성 및 표준 준수를 얻을 수 있습니다. 그리고 제가 말하고자하는 것은 사실이라면 그것이 사실인지에 달려 있습니다.

그러나 String.equals()사용하기 전에 다른 객체가 아닌 문자열을 전달했는지 테스트 "=="합니까? 말할 수있는 자격은 없지만 압도적으로 대부분의 이러한 equals()작업은 String to String이므로 테스트는 거의 항상 통과 되기 때문에 추측하지 않습니다 . 실제로 "=="를 우선 순위로 지정 String.equals()하면 문자열을 동일한 실제 객체와 자주 비교한다는 확신이 있습니다.

다음 줄이 "false"의 결과를 만들어 낸 것에 대해 아무도 놀라지 않기를 바랍니다.

    Integer i = 1;
    System.out.println("1".equals(i));

그러나 두 번째 줄로 변경 i하면 i.toString()물론 true입니다.

당신이 인턴에서 이익을 위해 희망 할 수 개최지 포함 Set하고 Map, 분명히. 내부 문자열에 해시 코드가 캐시되기를 바랍니다 ... 그것이 요구 사항이라고 생각합니다. 그리고 저는 백만 달러를 벌 수있는 아이디어를 포기하지 않았기를 바랍니다. :-)

메모리의 경우 문자열의 볼륨이 크거나 프로그램 코드에서 사용하는 메모리를 매우 작게 만드는 것이 중요한 한계라는 것도 분명합니다. -distinct- 문자열의 볼륨이 매우 큰 경우 전용 데이터베이스 프로그램 코드를 사용하여 관리하고 별도의 데이터베이스 서버를 고려해야합니다. 마찬가지로, 문자열 자체를 전혀 저장하지 않도록하여 작은 프로그램 (10000 개의 인스턴스에서 동시에 실행해야 함)을 개선 할 수있는 경우.

새 문자열을 만든 다음 intern()대체를 위해 바로 버리는 것이 낭비 적이지만, 중복 문자열을 유지하는 것 외에는 명확한 대안이 없습니다. 따라서 실제로 실행 비용은 인턴 풀에서 문자열을 검색 한 다음 가비지 수집기가 원본을 처리하도록 허용하는 비용입니다. 그리고 문자열 리터럴 인 경우 어쨌든 이미 인턴으로 제공됩니다.

intern()일부 String 및 해당 객체 참조가 intern()풀에 이미 존재하는지 여부를 감지하기 위해 악성 프로그램 코드에 의해 악용 될 수 있는지 궁금합니다. 따라서 Java 세션의 다른 곳에 존재하면 알 수 없습니다. 그러나 프로그램 코드가 이미 신뢰할 수있는 방식으로 사용되는 경우에만 가능합니다. 여전히 ATM PIN 번호를 저장하고 기억하기 위해 프로그램에 포함하는 타사 라이브러리에 대해 고려해야 할 사항입니다!

인턴을 사용하는 진짜 이유는 위의 것이 아닙니다. 메모리 부족 오류가 발생하면 사용할 수 있습니다. 일반적인 프로그램에서 많은 문자열은 다른 큰 문자열의 String.substring ()입니다 [100K xml 파일에서 사용자 이름을 가져 오는 것을 고려하십시오). 자바 구현은 하위 문자열이 원래 문자열에 대한 참조와 거대한 문자열의 시작 + 끝을 보유한다는 것입니다. (뒤에있는 생각은 같은 큰 줄을 재사용하는 것입니다)

1000 개의 큰 파일을 저장하면 1000 개의 짧은 이름 만 저장하면 1000 개의 파일 전체를 메모리에 보관할 수 있습니다! 솔루션 :이 시나리오에서는 smallsubstring.intern ()을 사용하십시오.

메모리를 절약하기 위해 인턴을 사용하고 있으며 많은 양의 문자열 데이터를 메모리에 보유하고 intern ()을 사용하여 이동하면 엄청난 양의 메모리가 절약됩니다. 불행히도 메모리를 많이 사용하지는 않지만 사용하는 메모리는 힙이 아닌 PermGen 메모리에 저장되며 고객에게 이러한 유형의 메모리 할당을 늘리는 방법을 설명하기가 어렵습니다.

따라서 메모리 소비를 줄이기 위해 intern ()에 대한 대안이 있습니까? (== 대 성능상의 이점은 문제가되지 않습니다)

주요 유스 케이스 시나리오는 입력 스트림을 통해 또는 JDBC ResultSet에서 데이터 스트림을 읽고 전체에 걸쳐 반복되는 무수한 작은 문자열이있는 경우입니다.

다음은 문자열 및 기타 불변을 내부화하는 데 사용할 메커니즘의 종류와 구현 예를 제어하는 ​​약간의 요령입니다.

/**
 * Extends the notion of String.intern() to different mechanisms and
 * different types. For example, an implementation can use an
 * LRUCache<T,?>, or a WeakHashMap.
 */
public interface Internalizer<T> {
    public T get(T obj);
}
public static class LRUInternalizer<T> implements Internalizer<T> {
    private final LRUCache<T, T> cache;
    public LRUInternalizer(int size) {
        cache = new LRUCache<T, T>(size) {
            private static final long serialVersionUID = 1L;
            @Override
            protected T retrieve(T key) {
                return key;
            }
        };
    }
    @Override
    public T get(T obj) {
        return cache.get(obj);
    }
}
public class PermGenInternalizer implements Internalizer<String> {
    @Override
    public String get(String obj) {
        return obj.intern();
    }
}

스트림 또는 ResultSet에서 필드를 읽을 때 자주 사용합니다. 참고 : LRUCache에 기반한 간단한 캐시입니다 LinkedHashMap<K,V>. retrieve()모든 캐시 미스에 대해 사용자 제공 메소드를 자동으로 호출합니다 .

이것을 사용하는 방법은 LRUInternalizer읽기 (또는 읽기) 전에 하나를 생성 하여 String 및 기타 작은 불변의 객체를 내재화 한 다음 해제하는 것입니다. 예를 들면 다음과 같습니다.

Internalizer<String> internalizer = new LRUInternalizer(2048);
// ... get some object "input" that stream fields
for (String s : input.nextField()) {
    s = internalizer.get(s);
    // store s...
}

관련 이름으로 연결되는 약 36000 코드의 내용을 캐시하기 위해 사용하고 있습니다. 많은 코드가 동일한 문자열을 가리 키기 때문에 캐시에서 문자열을 인턴합니다.

캐시에서 문자열을 인턴함으로써 동일한 문자열을 가리키는 코드가 실제로 동일한 메모리를 가리 키도록하여 RAM 공간을 절약합니다.

내부 문자열이 실제로 가비지 수집 된 경우 전혀 작동하지 않습니다. 이것은 기본적으로 인턴의 목적을 무효화합니다. 캐시의 각 문자열에 대한 참조를 보유하고 있기 때문에 가비지 수집되지 않습니다.

문자열을 인턴하는 비용은 단일 문자열 A.equals (B) 비교에서 절약되는 시간보다 훨씬 큽니다. 변경되지 않은 동일한 문자열 변수를 반복적으로 사용하는 경우에만 성능상의 이유로 사용하십시오. 예를 들어, 안정적인 문자열 목록을 정기적으로 반복하여 동일한 문자열 필드에 입력 된 일부 맵을 업데이트하면 비용을 절약 할 수 있습니다.

코드의 특정 부분을 최적화 할 때 문자열 인턴을 사용하여 성능을 조정하는 것이 좋습니다.

또한 String은 변경할 수 없으며 다음과 같은 바보 같은 실수를하지 않습니다.

String a = SOME_RANDOM_VALUE
a.intern()

할 것을 기억하십시오

String a = SOME_RANDOM_VALUE.intern()

가비지 수집 된 String.intern의 무제한 교체를 찾고 있다면 다음이 잘 작동합니다.

private static WeakHashMap<String, WeakReference<String>> internStrings = new WeakHashMap<>();
public static String internalize(String k) {
    synchronized (internStrings) {
        WeakReference<String> weakReference = internStrings.get(k);
        String v = weakReference != null ? weakReference.get() : null;
        if (v == null) {
            v = k;
            internStrings.put(v, new WeakReference<String>(v));
        }
        return v;
    }
}

물론, 얼마나 많은 다른 문자열이 있을지 대략적으로 추정 할 수 있다면 String.intern ()을 -XX : StringTableSize = highEnoughValue 와 함께 사용 하십시오 .