고성능 시나리오에서 Java의 StringBuilder를 올바르게 사용하는 방법

고성능 시나리오에서 StringBuilder의 올바른 사용법

StringBuilder에 대해 대부분의 학생들은 문자열 접합을 위해 StringBuilder를 사용해야 하고, +도 사용하지 말고, StringBuffer도 사용하지 말아야 한다는 점만 기억하면 성능이 최고가 될 것입니다. 사실인가요? ? 정말?

일부 학생들은 세 가지 특별한 경험도 들었습니다.

1. Java 컴파일 및 최적화 후 +는 StringBuilder와 동일한 효과를 갖습니다.

2. StringBuilder는 스레드로부터 안전하지 않으므로 이를 위해 사용하는 것이 좋습니다. "보안" StringBuffer

3. 로그 정보 문자열을 직접 연결하지 말고 slf4j에 맡기세요.

1. 초기 길이는 네 번 언급할 만큼 중요합니다.

StringBuilder 내부에는 char[]가 있는데, 상수 추가()는 char[]를 지속적으로 채우는 과정입니다.

new StringBuilder()를 사용할 때 char[]의 기본 길이는 16입니다. 그러면 17번째 문자를 추가하려면 어떻게 해야 하나요?

System.arraycopy를 사용하여 이중 복사하고 용량을 확장하세요! ! ! !

이렇게 하면 배열 복사 비용이 발생하고, 둘째로 원본 char[]도 낭비되어 GC에 의해 손실됩니다. 상상할 수 있듯이 129자 문자열이 16, 32, 64, 128 네 번 복사되고 삭제되었으며, 고성능 시나리오에서 총 496자가 할당되었습니다. 견딜 수 없는.

그래서 초기값을 합리적으로 설정하는 것이 얼마나 중요한지.

근데 정말 견적을 잘 못내면 어쩌지? 결국 문자열이 16보다 큰 이상 조금 낭비되더라도 용량을 두 배로 늘리는 것보다 낫습니다.

2. Liferay의 StringBundler 클래스

Liferay의 StringBundler 클래스는 길이 설정에 대한 또 다른 아이디어를 제공합니다. 추가()할 때 char[]에 항목을 넣기 위해 서두르지 않고 먼저 String[]을 사용하여 모두 저장합니다. 마지막에 모든 문자열의 길이를 합산하여 합리적인 길이의 StringBuilder를 구성합니다.

3. 그러나 char[]의 두 배는 여전히 낭비됩니다.

마지막 단계 StringBuilder.toString()

// 복사본을 만들고 배열을 공유하지 마세요
새 String(value를 반환합니다. , 0, count);

String의 생성자는 System.arraycopy()를 사용하여 들어오는 char[]를 복사하여 안전성과 불변성을 보장합니다. 이렇게 스토리가 종료되면 StringBuilder의 char[]가 여전히 낭비됩니다. .

이러한 char[]를 낭비하지 않기 위해 Unsafe 등의 다양한 블랙 기술을 사용하여 생성자를 우회하고 String의 char[] 속성에 직접 값을 할당하는 방법도 있지만 이렇게 하는 사람은 거의 없습니다.

더 안정적인 또 다른 방법은 StringBuilder를 재사용하는 것입니다. 재사용은 이전 길이 설정 문제도 해결합니다. 처음에는 추정치가 정확하지 않더라도 몇 번 더 확장하면 충분하기 때문입니다.

4. StringBuilder 재사용

이 메서드는 JDK의 BigDecimal 클래스에서 제공됩니다(JDK 코드가 얼마나 중요한지 살펴봐도 좋습니다). SpringSide는 코드를 하나의 함수

public StringBuilder getStringBuilder()로 추출합니다. ) {
sb .setLength(0);
return sb;
}

StringBuilder.setLength() 함수는 카운트 포인터만 재설정하지만 char[]는 계속 재사용되며 toString()도 현재 포인터를 재설정합니다. count 포인터를 String 생성자에 매개변수로 전달하면 새 콘텐츠의 크기를 초과하는 이전 콘텐츠를 전달하는 것에 대해 걱정할 필요가 없습니다. StringBuilder가 완전히 재사용 가능하다는 것을 알 수 있습니다.

동시성 충돌을 방지하기 위해 이 홀더는 일반적으로 ThreadLocal로 설정됩니다. 표준 작성 방법은 BigDecimal 또는 StringBuilderHolder의 설명을 참조하세요.

5.+ 및 StringBuilder

String s = “hello ” + user.getName();

javac 컴파일 후 이 문장의 효과는 실제로 StringBuilder를 사용하는 것과 동일하지만 길이는 설정되지 않습니다.

String s = new StringBuilder().append(“hello”).append(user.getName());

하지만 다음과 같다면:

String s = “hello”;
// 다른 명령문 이후
s = s + user.getName();

모든 명령문은 새로운 StringBuilder를 생성합니다. 여기에는 두 개의 StringBuilder가 있으며 성능은 완전히 다릅니다. s+=i; 가 루프 본문에 있으면 훨씬 더 우스꽝스럽습니다.

R 대학에 따르면 열심히 일하는 JVM 엔지니어들은 실행 최적화 단계에서 +XX:+OptimizeStringConcat(JDK7u40 이후 기본적으로 열림)에 따라 인접한(제어문 없이) StringBuilder를 하나로 결합하기 위해 열심히 노력할 것입니다. .

따라서 안전을 위해 계속해서 StringBuilder를 사용하여 길이를 직접 설정하세요.

6. StringBuffer 및 StringBuilder

StringBuffer 및 StringBuilder는 모두 AbstractStringBuilder에서 상속됩니다. 유일한 차이점은 StringBuffer 함수에 동기화된 키워드가 있다는 것입니다.

StringBuffer가 "안전하다"고 말하는 학생들의 경우 실제로 여러 스레드가 차례로 StringBuffer를 추가하는 것을 본 적이 있습니까? ? ?

7. 로그 문자열은 항상 slf4j??

logger.info("Hello {}", user.getName());

출력 여부를 알 수 없는 로그의 경우 그대로 두세요. slf4j에 연결하면 실제로 출력이 필요할 때만 연결하여 비용을 절약할 수 있습니다.

하지만 출력해야 하는 로그의 경우 StringBuilder를 사용하여 직접 연결하는 것이 더 빠릅니다. slf4j의 구현을 보면 실제로는 상수 indexof("{}"), 상수 subString()일 뿐이며 지속적으로 StringBuilder를 사용하여 이를 조합하는 방법이 없습니다.

PS. slf4j의 StringBuilder는 원본 메시지 외에 50자를 예약합니다. 변수 매개 변수의 추가가 최대 50자를 초과하는 경우 여전히 복사하고 확장해야 하며... StringBuilder는 재사용되지 않습니다.

위 내용은 고성능 시나리오에서 Java의 StringBuilder를 올바르게 사용하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!