Java에서 String, StringBuffer, StringBuilder 클래스의 성능 상세 분석
API를 보면 String, StringBuffer, StringBuilder는 모두 CharSequence 인터페이스를 실현했다. 문자열과 관련이 있지만 처리 메커니즘은 다르다.
String 클래스 사용 장면: 문자열이 자주 변하지 않는 장면에서 String 클래스를 사용할 수 있습니다. 예를 들어 상수의 성명, 소량의 변수 연산 등입니다.
StringBuffer 클래스를 사용하는 장면: 문자열 연산(결합, 교체, 삭제 등)이 빈번하고 다중 스레드 환경에서 실행될 때 XML 해석, HTTP 매개 변수 해석, 봉인 등 StringBuffer를 사용할 수 있습니다.
StringBuilder 클래스를 사용하는 장면: 문자열 연산(예를 들어 조립, 교체, 삭제 등)이 빈번하고 단일 라인에서 실행되는 환경에서 SQL 문장의 조립, JSON 봉인 등 StringBuilder를 사용할 수 있습니다.
3. 분석
간단하게 말하면 String 유형과 String Buffer 유형의 주요 성능 차이는 String이 변할 수 없는 대상이기 때문에 String 유형을 변경할 때마다 새로운 String 대상을 생성한 다음에 바늘을 새로운 String 대상으로 가리키는 것과 같다.따라서 내용을 자주 바꾸는 문자열은 String을 사용하지 않는 것이 좋다. 왜냐하면 매번 대상을 생성할 때마다 시스템 성능에 영향을 미치기 때문이다. 특히 메모리에 인용이 없는 대상이 많으면 JVM의 GC가 작업을 시작하기 때문에 그 속도는 상당히 느릴 것이다.
StringBuffer 클래스를 사용하면 결과가 달라집니다. 매번 결과는 StringBuffer 대상 자체를 조작하는 것이지 새로운 대상을 생성하고 대상 인용을 바꾸는 것이 아닙니다.따라서 일반적인 상황에서 StringBuffer, 특히 문자열 대상이 자주 바뀌는 경우를 추천합니다.특정한 상황에서 String 대상의 문자열 결합은 JVM에 의해 StringBuffer 대상의 결합으로 해석되기 때문에 이런 때 String 대상의 속도는 StringBuffer 대상보다 느리지 않다. 특히 다음과 같은 문자열 대상 생성에서 String 효율은 StringBuffer보다 훨씬 빠르다.
String S1 = “This is only a" + “ simple" + “ test";
StringBuffer Sb = new StringBuilder(“This is only a").append(“ simple").append(“ test");
String S1 = “This is only a" + “ simple" + “test";
String S1 = “This is only a simple test";
String S2 = "This is only a";
String S3 = "simple";
String S4 = "test";
String S1 = S2 +S3 + S4;
4. JVM의 최적화된 처리
정말 위의 성능 대가가 있을까요? 문자열 연결이 이렇게 자주 사용되는데 특별한 처리 최적화가 없습니까? 답은 있습니다. 이 최적화는 JVM에서 컴파일됩니다.java가bytecode에 도착했을 때.
Java 프로그램을 실행하려면 컴파일할 때와 실행할 때 두 시기를 거쳐야 한다.컴파일할 때 Java JVM(Compiler)은 자바 파일을 바이트 코드로 변환합니다.런타임 시 JVM(JVM)이 컴파일을 실행할 때 생성된 바이트 코드입니다.이러한 두 시기를 통해 자바는 이른바 컴파일링을 하고 곳곳에서 운행했다.
우리는 컴파일러가 어떤 최적화를 했는지 실험해 보자. 우리는 성능 대가가 발생할 수 있는 코드를 제조한다.
public class Concatenation {
public static void main(String[] args) {
String userName = "Andy";
String age = "24";
String job = "Developer";
String info = userName + age + job;
System.out.println(info);
}
}
javac Concatenation.java
17:22:04-androidyue~/workspace_adt/strings/src$ javap -c Concatenation
Compiled from "Concatenation.java"
public class Concatenation {
public Concatenation();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: ldc #2 // String Andy
2: astore_1
3: ldc #3 // String 24
5: astore_2
6: ldc #4 // String Developer
8: astore_3
9: new #5 // class java/lang/StringBuilder
12: dup
13: invokespecial #6 // Method java/lang/StringBuilder."<init>":()V
16: aload_1
17: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
20: aload_2
21: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
24: aload_3
25: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
28: invokevirtual #8 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
31: astore 4
33: getstatic #9 // Field java/lang/System.out:Ljava/io/PrintStream;
36: aload 4
38: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
41: return
}
5. JVM만으로 최적화?
JVM이 최적화를 도와줬으니 JVM의 최적화만으로도 충분하지 않겠습니까? 물론 아닙니다.
다음은 최적화되지 않은 성능이 낮은 코드를 보겠습니다.
public void implicitUseStringBuilder(String[] values) {
String result = "";
for (int i = 0 ; i < values.length; i ++) {
result += values[i];
}
System.out.println(result);
}
public void implicitUseStringBuilder(java.lang.String[]);
Code:
0: ldc #11 // String
2: astore_2
3: iconst_0
4: istore_3
5: iload_3
6: aload_1
7: arraylength
8: if_icmpge 38
11: new #5 // class java/lang/StringBuilder
14: dup
15: invokespecial #6 // Method java/lang/StringBuilder."<init>":()V
18: aload_2
19: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
22: aload_1
23: iload_3
24: aaload
25: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
28: invokevirtual #8 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
31: astore_2
32: iinc 3, 1
35: goto 5
38: getstatic #9 // Field java/lang/System.out:Ljava/io/PrintStream;
41: aload_2
42: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
45: return
조금만 최적화하면 순간적으로 압박을 증가시킵니다.
public void explicitUseStringBuider(String[] values) {
StringBuilder result = new StringBuilder();
for (int i = 0; i < values.length; i ++) {
result.append(values[i]);
}
}
public void explicitUseStringBuider(java.lang.String[]);
Code:
0: new #5 // class java/lang/StringBuilder
3: dup
4: invokespecial #6 // Method java/lang/StringBuilder."<init>":()V
7: astore_2
8: iconst_0
9: istore_3
10: iload_3
11: aload_1
12: arraylength
13: if_icmpge 30
16: aload_2
17: aload_1
18: iload_3
19: aaload
20: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
23: pop
24: iinc 3, 1
27: goto 10
30: return
전반적으로 말하자면, 우리는 순환체에서 스텔스나 현식으로 StringBuilder를 만드는 것을 최대한 피해야 한다.그래서 코드를 어떻게 컴파일하고 내부에서 어떻게 실행하는지 아는 사람들은 코드의 등급이 비교적 높다.
결론
대부분의 경우 StringBuffer > String
Java.lang. StringBuffer는 스레드가 안전한 가변 문자 시퀀스입니다.String과 유사한 문자열 버퍼이지만 수정할 수 없습니다.임의의 시간에 특정한 문자 서열을 포함하지만, 어떤 방법으로 호출하면 이 서열의 길이와 내용을 바꿀 수 있다.프로그램에서 문자열 버퍼를 다중 스레드에 안전하게 사용할 수 있습니다.그리고 필요할 때 이 방법들을 동기화할 수 있기 때문에 임의의 특정한 실례상의 모든 조작은 마치 직렬 순서로 발생하는 것 같다. 이 순서는 관련된 모든 라인에서 진행되는 방법과 호출 순서가 일치한다.
StringBuffer의 주요 동작은 append와 insert 방법입니다. 이 방법을 다시 불러와서 임의의 형식의 데이터를 받아들일 수 있습니다.모든 방법은 주어진 데이터를 문자열로 효과적으로 변환한 다음 문자열의 문자를 문자열 버퍼에 추가하거나 삽입할 수 있습니다.append 방법은 항상 이 문자를 버퍼의 끝에 추가합니다.insert 방법은 지정한 점에 문자를 추가합니다.
예를 들어 z가 현재 내용이 "start"문자열 버퍼 대상을 인용한다면, 이 방법은 z.append ("le") 를 호출하면 문자열 버퍼에 "startle"(누적) 을 포함합니다.z.insert (4, "le") 는 문자열 버퍼를 "starlet"을 포함하도록 변경합니다.
대부분의 경우 StringBuilder > StringBuffer
java.lang. StringBuilder의 가변 문자 시퀀스는 JAVA 5.0에 추가되었습니다.이 유형은 StringBuffer와 호환되는 API를 제공하지만 동기화를 보장하지 않기 때문에 장면을 사용하는 것은 단일 루트입니다.이 클래스는 문자열 버퍼가 한 라인에서 사용될 때 사용되는 StringBuffer의 간단한 교체로 설계되었습니다.가능하다면, 이 종류를 우선적으로 사용하는 것을 권장합니다. 왜냐하면 대부분의 실현에서 StringBuffer보다 빠르기 때문입니다.양자의 사용 방법은 기본적으로 같다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
JPA + QueryDSL 계층형 댓글, 대댓글 구현(2)이번엔 전편에 이어서 계층형 댓글, 대댓글을 다시 리팩토링해볼 예정이다. 이전 게시글에서는 계층형 댓글, 대댓글을 구현은 되었지만 N+1 문제가 있었다. 이번에는 그 N+1 문제를 해결해 볼 것이다. 위의 로직은 이...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
