[Java] Wrapper Class 의 캐싱에 대한 내용 정리

⚡개요

Wrapper Class에 대해서 기본적인 내용을 체크하던 도중에 객체를 비교하는 과정에서 추가적인 내용을 확인해서 내용을 정리해 놓으려고 한다.

 

⚡ Wrapper Class 생성 방법

기본적인 생성 방법

일반적으로 new 를 통한 객체를 생성하는 방법이 있다. 하지만 이 방법은 버전에 따라서 사용을 할 수 없도록 되어있다. 

심지어 사용할수 있는 버전에서 조차 "불필요한 박싱"이라는 문구가 발생한다.

 

java 9 version 이후 deprecated

일부 Wrapper Class에 대해서도 확인해 보았지만, 모두 동일한 것으로 파악되며, 대신 valueOf()를 사용하도록 권장하고 있다.

(해당 부분이 왜이렇게 바꼇는지는 밑에서 설명 하도록 하겠다.❗❗❗)

 

이 또한 불필요한 박싱이라는 경고가 뜨게 된다. 

 

여기까지는 대부분 알고 있는 내용이며 크게 설명하지는 않도록 하겠다. 

⚡ Wrapper Class 캐싱에 대해서

추가적으로 내용을 확인하던 도중 많은 블로그에서는 Wrapper Class는 == 비교 할수 없다고 나온다.

객체이기 때문에 값의 비교가 아닌 주소를 비교 하기때문에 당연하다고 생각했지만 한번 테스트를 해봤다.

결과는 둘다 true로 나온다.

이유가 뭘까 생각을 하면서 Long Class 내부를 보았다.

위에서 생성자를 통해서 생성하지 못하게 하고 valueOf()를 통해서 생성하는걸 권장하는지 이유가 나온다. ❗

해당 조건을 보게 되면, LongCache.cache 배열에 미리 저장해둔 객체를 리턴하는것으로 파악이 된다.

 

LogCache 클래스를 따라가보면 아래의 내용이 나온다.

Long Class 내부에 있던 Inner Class이다. 내용을 보면 미리 기본값(-128 ~ 127) 사이의 인스턴스를 미리 생성하고 캐싱 처리를 하고 있는 모습을 볼 수 있다. 미리 생성된 인스턴스가 캐싱에 저장이 되면서 해당 범위 내에 있는 경우 캐싱되어있는 인스턴스를 반환하고 범위 밖인 경우는 새로운 인스턴스를 생성해서 반환을 하고 있던 것이다.

추가적으로 다른 Wrapper Class도 확인 해보면 동일하게 캐싱처리가 되고 있는 부분을 확인할 수 있다.

 

Integer Cacheing

⚡ 생각

한편으로는 당연한 조치라고도 생각을 한다. Wrapper Class의 인스턴스를 매번 생성하면 메모리를 낭비할 수 있고, 이는 속도 저하가 발생하게 된다. 매번 인스턴스를 생성하는 것보다 캐싱된 인스턴스를 사용하게 되면 메모리 사용을 최적화할 수 있다. 아마 테스트를 해보지 않고 그냥 넘어 갔다면 캐싱처리에 대해서 모르고 지나갈뻔했다.

내부적으로 개발을 할때도 이 부분에 대해서 유의하면서 개발하면 성능 향상의 도움이 되고 지금처럼 대규모 데이터를 다룰 때 유용하게 사용될 거라고 생각한다.