포스터에서 말한 것과 관련하여, 스트링 스플라이싱은 상수 풀에서만 공유 객체를 생성하므로, 구체적으로 무엇을 의미하는지 이해가 안 되지만, 이런 방식으로 쓸데없는 객체가 많이 생성되는 이유는 설명할 수 있기를 바랍니다. 도움이 될 것입니다. 원본 포스터가 도움이 되었습니다.
답변은 다음과 같습니다.
먼저 위 그림을 보세요. JDK의 String 클래스는 최종 클래스이고, String 문자를 저장하는 데 사용되는 값도 최종입니다!
즉, 문자열 개체의 값은 생성된 후에는 수정할 수 없습니다. 따라서 각 루프에서 생성된 문자열은 새 String 객체여야 합니다. 하지만 위의 코드는 생각보다 더 많은 객체를 생성합니다! 부탁드립니다계속해서 사진을 감상해주세요!
---------아름다운 구분선---------- -------
두 번째 사진의 빨간색 상자는 첫 번째 사진의 빨간색 상자에 있는 디컴파일된 코드입니다. 그림에서 볼 수 있습니다: a+=a는 다음 작업을 수행합니다.
String.valueOf(a)를 호출합니다. 이 단계에서는 a도 문자열이므로 새 객체가 생성되지 않습니다.
new StringBulid(첫 번째 개체는 실제로 문자열 a임), 이 단계에서는 Stringbuild 개체를 생성합니다.
.append(문자열 추가)
.toString(), 이 단계에서는 Stringbuild의 toString 메서드를 호출합니다.
Stringbuild의 toString() 소스코드를 살펴보겠습니다
으아아아
앗! 또 다른 String 객체가 생성되는 이유는 무엇입니까?
여기서 a+=a 구문 분석이 완료되었으므로 루프 내의 모든 문자열 추가 작업은 실제로 최소한 하나의 StringBuild 객체와 하나의 String 객체를 생성합니다!
String은 불변 객체이므로 String 유형이 변경될 때마다 실제로는 새로운 String 객체를 생성한 다음 새 String 객체에 포인터를 가리키는 것과 동일하므로 내용을 자주 변경하는 문자열이 가장 많습니다. String을 사용하지 않는 것이 가장 좋습니다. 왜냐하면 객체가 생성될 때마다 시스템 성능에 영향을 미치기 때문입니다. 특히 메모리에 참조되지 않은 객체가 너무 많으면 JVM의 GC가 작동하기 시작하고 속도가 확실히 향상됩니다. 꽤 느립니다.
... jdk1.8 이후에만 StringBuild를 여러 문자열 연결에 사용할 수 있습니다. . 이전 버전은 이렇지 않아요! ~~ 지난번에 0 0 기사를 읽었는데 틀린 내용인지 모르겠습니다. 1.8 이전에는 String을 여러 번 수정하려면 StringBuffer 또는 StringBuilder를 사용해야 했습니다. 1.8에서는 구문 설탕을 활성화하고 이 영역을 수정하여 StringBuilder를 명시적으로 호출하지 않고도 높은 효율성을 누릴 수 있습니다.
그리고 문자열의 경우 상수 풀에서만 공유 객체를 생성합니다.
으아악
여기서 만든 물건은 모두 쓸모없는 물건이 아닌가? 최종 결과 외에도 GC 재활용에도 시간이 걸립니다.
문자열은 char[]의 최종 수정이므로 매번 새 객체를 생성해야 합니다. StringBuilder가 매우 효율적인 이유는 일반적으로 작업을 추가하여 배열이 동적으로 확장되기 때문입니다. 용량이 가득 차면 새로운 더 큰 char[]를 추가하고 이전 데이터를 추가하기 전에 복사합니다. 요약하면 stringbuilder는 개체 생성을 줄이고 매번 새 개체를 생성할 필요가 없습니다. 전문가에게 조언을 구해보세요! ~! ~! ~
포스터에서 말한 것과 관련하여, 스트링 스플라이싱은 상수 풀에서만 공유 객체를 생성하므로, 구체적으로 무엇을 의미하는지 이해가 안 되지만, 이런 방식으로 쓸데없는 객체가 많이 생성되는 이유는 설명할 수 있기를 바랍니다. 도움이 될 것입니다. 원본 포스터가 도움이 되었습니다.
답변은 다음과 같습니다.
먼저 위 그림을 보세요. JDK의 String 클래스는 최종 클래스이고, String 문자를 저장하는 데 사용되는 값도 최종입니다!
즉, 문자열 개체의 값은 생성된 후에는 수정할 수 없습니다. 따라서 각 루프에서 생성된 문자열은 새 String 객체여야 합니다. 하지만 위의 코드는 생각보다 더 많은 객체를 생성합니다! 부탁드립니다계속해서 사진을 감상해주세요!
---------아름다운 구분선---------- -------
두 번째 사진의 빨간색 상자는 첫 번째 사진의 빨간색 상자에 있는 디컴파일된 코드입니다. 그림에서 볼 수 있습니다:
a+=a는 다음 작업을 수행합니다.
String.valueOf(a)를 호출합니다. 이 단계에서는 a도 문자열이므로 새 객체가 생성되지 않습니다.
new StringBulid(첫 번째 개체는 실제로 문자열 a임), 이 단계에서는 Stringbuild 개체를 생성합니다.
.append(문자열 추가)
.toString(), 이 단계에서는 Stringbuild의 toString 메서드를 호출합니다.
Stringbuild의 toString() 소스코드를 살펴보겠습니다
으아아아앗! 또 다른 String 객체가 생성되는 이유는 무엇입니까?
여기서 a+=a 구문 분석이 완료되었으므로 루프 내의 모든 문자열 추가 작업은 실제로 최소한 하나의 StringBuild 객체와 하나의 String 객체를 생성합니다!
String은 불변 객체이므로 String 유형이 변경될 때마다 실제로는 새로운 String 객체를 생성한 다음 새 String 객체에 포인터를 가리키는 것과 동일하므로 내용을 자주 변경하는 문자열이 가장 많습니다. String을 사용하지 않는 것이 가장 좋습니다. 왜냐하면 객체가 생성될 때마다 시스템 성능에 영향을 미치기 때문입니다. 특히 메모리에 참조되지 않은 객체가 너무 많으면 JVM의 GC가 작동하기 시작하고 속도가 확실히 향상됩니다. 꽤 느립니다.
자주 수정되는 변수는 StringBuffer를 사용하는 것이 좋습니다~
... jdk1.8 이후에만 StringBuild를 여러 문자열 연결에 사용할 수 있습니다. . 이전 버전은 이렇지 않아요! ~~
지난번에 0 0 기사를 읽었는데 틀린 내용인지 모르겠습니다.
1.8 이전에는 String을 여러 번 수정하려면 StringBuffer 또는 StringBuilder를 사용해야 했습니다.
1.8에서는 구문 설탕을 활성화하고 이 영역을 수정하여 StringBuilder를 명시적으로 호출하지 않고도 높은 효율성을 누릴 수 있습니다.
그리고 문자열의 경우 상수 풀에서만 공유 객체를 생성합니다.
으아악여기서 만든 물건은 모두 쓸모없는 물건이 아닌가? 최종 결과 외에도 GC 재활용에도 시간이 걸립니다.
문자열은 char[]의 최종 수정이므로 매번 새 객체를 생성해야 합니다.
StringBuilder가 매우 효율적인 이유는 일반적으로 작업을 추가하여 배열이 동적으로 확장되기 때문입니다. 용량이 가득 차면 새로운 더 큰 char[]를 추가하고 이전 데이터를 추가하기 전에 복사합니다. 요약하면 stringbuilder는 개체 생성을 줄이고 매번 새 개체를 생성할 필요가 없습니다. 전문가에게 조언을 구해보세요! ~! ~! ~