가끔 까먹는 비교 연산(IntegerCache, LongCache)

아.. 순간 동작 방식을 헤깔렸버렸다...ㅠㅠ;;

 

대략적인 흐름은 

Integer val1=3;

Integer val2=3;

 

val1==val2// true일지 false 일지....

 

위에 val1=3 는 오토 박싱으로 기존 primitive가 Integer로 박싱된다.

디컴파일러로 보면 

Integer val1=Integer.valueOf(3); 으로 코드가 바뀐다.

 

그런데 실수는.. 아래 비교 부분이다

 

비교연산자에서

if(obj1==obj2) , 는 당연히 ref 비교

 

if(obj1.equals(obj2)), 는 당연히 equals() 내부 구현을 따라가는 비교..

(대부분 안에 값 비교)

때문에 String 비교는 ==가 아닌 equals 비교를 해야 원하는 동작이 된다..

 

착각한 부분은 

1.

==가 ref 비교가 아니라 hash비교로....... 착각 했다..

(하긴 hash 비교면 String도 equals를 할께 아니라 == 하면 되는건데..)

 

 

2.

이전에 블로그에서 봤던 부분인데 Integer는 오토박싱시에 캐싱을 한다는것..

범위가 대략 127까지 였던것 같은데.. 

애매하게 알았으니 착각한게 당연한지도..

 

그래서! Integer코드를 열어봤다

Integer의 valueOf(int) 위의 경우에는 이 부분이 불릴것이고.. 캐시동작..

 

 

주석에는 아주아주 친절하게, 오토박싱하는 값(-128~127) 까지는 값을 캐싱 해두도록 되어있었다..

그렇다면 해시값은 물론이고 객체 값도 당연히 같게 되겠지..

아 그리고 아래 로직을 보면 꼭 최대값이 127이 아니고, Property, java.lang.Integer.IntegerCache.high 값에 의해 결정되는걸 확인할 수 있었다.

 

결국 다시한번 부족함을 느끼고 지식이 늘음에 감사하는걸로..

 

추가로!

Double에는 없었고

Long도 열어보니 캐싱을 하고 있다.. 대신에 여기는 무조건 -128~127까지만!

Long의 valueOf()

 

 

요약

1. 오토박싱

2. 비교 연산자

3. IntegerCache, LongCache

4. 언제나 코드는 까보자.

5. 기초를 잊지 말자.