2. String 이용하기

자바의 장점 : 모든 라이브러리 구현을 직접 확인하고 점검할 수 있다는 것

-> String  객체를 확인해 보니 char타입의 배열 !!!

 

String 은 객체지만 원시타입처럼 취급되어 String 리터럴을 생성할 때 new 키워드를 이용할 필요가 없다.

ex) String helloString2 = "Hello World";

 

"String 클래스에서는 String 객체의 값을 변경하는 것처럼 보이는모든 메서드가 실제로는 String 인스턴스를 반환."

-> 즉 String 값은 절대 안 변함!

(String 말고도, integer, Double, Character, BigInteger....)

따라서, 

substring, replace, split 같은 메서드를 사용하면 변경된  String 객체의 새 복사본이 반환되는 것

 

결국, 인스턴스로 표현되는 값은 절대 변경할 수 없다.

 

이러한 String의 특징은 스래드에 안전하다는 점이 있다.

불변객체는 많은 동시 스레드에 사용할 수 있으며, 각 스레드는 그 값들이 절대 변하지 않을 거라는 걸 확신할 수 있기에 

잠금이나 복잡한 스레드 조절이 필요 없다.

 

이때 JVM은 뭘할까?

 

1) 클래스가 JVM에 로드 -> 모든 리터럴이 상수 풀에 위치

2) String 리터럴의 모든 반복은 풀 안의 같은 상수를 참조해서 이루어짐 => 이를 String 인터닝

 

인터닝이 JVM이 모든 클래스를 참조할 수 있게 도와주기 때문에 클래스는 절대 변하면 안된다

 

String 인턴 풀은 intern 메서드를 이용해서 모든 String 인스턴스를 이 풀에 추가.

-> 대량의 데이터가 읽혀질 때 인터닝하며 JVM의 메모리 내부에는 하나의 유일한 인스턴스만 존재

 

이런 intern 메서드는 해제에 사용할 수 없다.

String은 힙영역에 저장되어 있지 않으면 -> PermGen 영역에 있음.

 

즉, 수백만 개의 대상이 있는 상수 풀이 있다면 intern 메서드를 많이 사용.

 

String 상수 풀은 플라이웨이트 패턴을 구현한 것.

 

cf. JUnit의 Assert.assertSame()이 동일성 확인을 수행하지만 assertTrue 메서드에서 == 연산을 이용해 확인하는 것이 더 명확해짐.