[Java] 참조변수, 메모리 주소, hash code, identity hash code

Java에서 참조변수는 단순히 객체의 주소값을 저장하고 있다고 생각하고 있었는데, 참조변수를 출력해보았을 때는 클래스명@16진수 해시코드로 출력되는 것을 확인하고 어떤 방식으로 참조변수가 객체의 주소값을 가지고 있는 것인지 궁금해졌다.

해당 글에서는 참조 변수가 객체를 어떻게 참조하는지, 그리고 참조 변수 출력 시 나타나는 해시코드와 실제 메모리 주소의 관계에 대해 알아보려고한다.

Java의 참조 변수

참조변수는 힙(Heap) 메모리에 저장된 객체의 주소를 저장하지만, 개발자에게 직접 주소값을 노출하지 않는다고 한다. 대신 toString() 메서드를 호출하면 클래스명@해시코드 형식의 문자열이 반환된다.

 

해시코드 vs 실제 주소

• Product@1302068a와 같은 해시코드는 객체의 메모리 주소를 의미하지 않는다.
• JVM은 객체 식별을 위해 이러한 identity hash code를 생성하며, 이 식별자는 객체의 생명주기 동안 유지되는 고유값이다.
• 실제 메모리 주소는 jvm의 메모리 최적화의 이유로 가비지 컬렉션(GC)에 의해 변경될 수 있지만, 여전히 동일한 identity hash code를 기준으로 객체를 식별 가능하다.

 

Product prod = new Product();

System.out.println(prod);
System.out.println(System.identityHashCode(prod));
System.out.println(Long.parseLong("5305068a", 16));

아래는 인스턴스 변수를 출력했을때의 결과와 identityHashCode 메서드를 호출했을 때 결과이다.

5305068a와 1392838282 로 값이 달라보여 다른 의미를 지니고 있는 줄 알았지만,

5305068a(16진수) 1392838282(10진수)로 동일한 identity hash code인 것을 확인할 수 있었다.

즉, hashCode 메서드를 별도로 오버라이드하여 로직을 수정하지 않는다면 두경우 모두 identity hash code를 의미한다.

 

추가적으로 개발자가 Java에서 클래스를 설계할 때 지켜야 하는 계약(contract)에 대해 간단히 정리해보겠다.

• 두 객체가 equals()에 의해 동등하다면, 두 객체의 hashCode() 반환값은 반드시 같아야 한다.
• 두 객체의 hashCode()가 같다고 해서 equals()에 의해 동등한 것은 아니다(해시 충돌 가능성).

이 계약을 지키지 않으면 HashMap, HashSet 등의 해시 기반 컬렉션에서 객체가 제대로 동작하지 않을 수 있다. 예를 들어, equals()가 같은데 hashCode()가 다르다면, HashMap에서는 동일한 객체를 다른 버킷에 저장하게 되어 검색 시 의도와 다른 결과가 발생할 것이다.

이것은 Java가 자동으로 고려해주는 것이 아니기 때문에, 클래스의 equals()를 오버라이드할 때는 항상 hashCode()도 함께 override 해주자.

 

해시 코드 생성 방식

우리가 일반적으로 사용하는 64bit JVM에서는 8byte 주소값으로 4byte 해시코드를 만들기 때문에 해시코드가 중복될 여지가 존재한다. 이러한 이유로 클래스의 인스턴스 변수 값으로 객체가 동일한지 판단하고 싶다면 equals 메서드와 hashCode 메서드도 올바르게 오버라이딩 해주어야한다.

 

실제 HotSpot JVM에서는 단순히 주소의 일부를 사용하는 것이 아니라, 초기 호출 시 스레드 로컬 PRNG나 기타 알고리즘(Marsaglia의 XOR-Shift 등)을 사용해 identity hash code를 생성하고, 이를 객체 헤더에 저장한다. 따라서 “메모리 주소에서 파생된다”고 표현했지만, 구현에 따라서는 완전히 난수에 기반한 방식일 수도 있다고 한다.

 

메모리 주소 vs 객체 참조

C/C++의 포인터는 메모리의 물리적 주소를 직접 저장하고 조작할 수 있지만

Java에서 실제 메모리 주소를 직접 확인하는 것은 원칙적으로 불가능하다. 이는 JVM이 메모리 관리를 추상화하고 물리적 주소 접근을 차단하기 때문이다.

특수한 방법(ex: sun.misc.Unsafe 클래스)으로 접근 시도를 할 수 있다는 정보도 있었지만 권장되지 않는다고한다.

JVM은 가비지 컬렉션(GC)을 통해 사용하지 않는 객체를 자동으로 정리하기 때문에 개발자가 직접 메모리를 할당하거나 해제할 필요가 없다.

추상화된 메모리 관리는 개발자가 복잡한 메모리 관리 세부 사항에 신경 쓰지 않고도 코드를 작성하고 유지보수할 수 있게 해준다.

따라서 Java 개발에서는 메모리 주소보다 객체의 논리적 상태와 관계 관리에 집중하는 것이 바람직하다.

 

 

 일반적으로 “참조 변수는 객체의 주소값을 저장한다”라는 설명은 개발자가 이해하기 쉽게 단순화한 표현이다. 실제로는 JVM 내부에서 참조 변수는 객체를 찾기 위한 “핸들(handle)” 혹은 “포인터” 역할을 하며, 물리적 메모리 주소와는 추상화된 관계를 가진다. 특히, GC가 객체를 이동시킬 때 참조 변수는 자동으로 새 위치를 가리키도록 업데이트되므로, 실제 물리적 주소는 변할 수 있지만 객체의 identity는 유지된다. 이를 간략한 프로세스로 정리하면 아래와 같다.

객체 이동과 참조값 갱신 프로세스

가비지 컬렉션 중 객체가 이동될 때, JVM은 다음과 같은 단계를 수행한다.

1. 객체를 새로운 메모리 위치로 복사
2. 새 위치에 기반하여 32비트 참조값을 다시 계산
3. 모든 관련 참조값을 새 위치를 가리키도록 업데이트(모든 참조를 새 참조값으로 갱신)
4. 이전 메모리 공간을 해제

JVM은 위와 같은 과정을 통해 참조를 올바르게 업데이트하여 효율적인 메모리 관리를 수행하면서도 프로그래밍에서 의미론적 일관성을 유지한다.

 

== 연산자

등가 연산자(==)는 메모리 구조 내에서 비교 대상이 어디(Heap, Stack)에 위치하고 있는지, 어떤 방식으로 저장되어 있는지에 따라 다르게 동작한다.

기본형 데이터 타입에서의 등가 연산자(==)

기본형 데이터 타입(Primitive Type)에 대해 등가 연산자(==)를 사용할 때, JVM은 해당 변수에 저장된 실제 값을 직접 비교한다. 기본형 데이터 타입은 Stack 영역에 직접 값이 저장되기 때문에, 등가 연산자는 이 Stack에 있는 값들을 비교하게 된다.

 

참조형 데이터 타입에서의 등가 연산자(==)

참조형 데이터 타입(Reference Type)에 대해 등가 연산자(==)를 사용할 경우, JVM은 변수가 가리키는 객체의 메모리 주소(참조값)를 비교한다. 참조 변수는 Stack 영역에 저장되지만, 실제 객체는 Heap 영역에 생성되기 때문에 Stack에 저장된 참조값(32비트 또는 64비트 정수 형태)이 같은지를 비교하는 것이다.

 

 

"==" 연산자가 비교하는 값은 JVM 내부에서 각 객체를 가리키는 "참조 값"(메모리상의 주소 또는 압축 포인터)이다.
OpenJDK 64비트 JVM에서는 힙이 작을 경우 'compressed oops'가 활성화되어 64비트 참조값이 32비트로 압축(메모리 오버헤드 줄이기 위함)되어 저장된다. 이 압축된 참조 값이 "==" 연산자에 의해 비교된다.
즉, 두 변수에 저장된 참조 값(메모리 주소 또는 압축된 값)이 같다면 "==" 비교 결과는 true가 된다.

 

 

JVM에서 압축 포인터(compressed oops)는 64비트 메모리 주소를 일정 기준(베이스와 시프트 값)에 따라 32비트 정수로 압축한 값이다. 압축결과로 나온 값은 여전히 각 객체를 유일하게 식별할 수 있도록 설계되어 있다. 이 압축값은 필요 시 복원되어 실제 주소로 변환되지만, identity hash code와는 별개로 관리된다. 즉, 압축 포인터 사용은 객체 식별(identity hash code)과는 직접적인 연관이 없다.

 

 

Compressed OOPs는 약 32GB까지의 힙 크기에서만 효과적으로 작동한다. (실제로는 널 페이지(null page)와 정렬 요구 사항으로 인해 이 한계는 32GB보다는 약간 낮다고 함)

애플리케이션이 매우 큰 힙(2^32개 이상의 객체가 동시에 존재할 정도의 크기)을 필요로 한다면, JVM은 자동으로 Compressed OOPs를 비활성화하고 전체 64비트 참조를 사용하게 되는데, 이렇게 되면 32비트로 압축했던 이점이 사라지기 때문에 Compressed OOPs의 메모리 효율성을 활용하기 위해선 힙 크기를 32GB 이하로 유지하는 것이 권장된다.

 

 

System.identityHashCode()는 객체의 메모리 주소에 기반해 계산되고 객체의 수명 동안 해당 identityHashCode 값은 변하지 않도록 JVM에 의해 관리된다. indentityHashCode값은 32비트 정수로 반환되므로 이론적으로 충돌(동일한 해시값)이 발생할 수 있다.

그러나 이 값은 실제 메모리 주소 자체가 아니라, 메모리 주소를 기반으로 한 해시 함수의 결과값이다.

따라서 System.identityHashCode()의 32비트 정수 표현은 Compressed OOPs와 같은 포인터 압축 기술과는 별개의 개념이다. 

 

"==" 연산자는 내부적으로 메모리상의 주소(참조 값)를 비교하기 때문에, 두 객체가 같은 System.identityHashCode() 값을 가진다고 하더라도, 메모리 주소가 다르면 "==" 연산자는 false를 반환한다.
즉, 객체의 == 연산은 System.identityHashCode()가 아니라, JVM 내부에서 관리하는 참조(메모리 주소) 비교를 통해 이루어진다.

 

 

 

 

정리 

Java의 참조 변수는 물리적인 메모리 주소가 아닌 . 참조 변수를 출력했을 때 나타나는 해시코드는 실제 메모리 주소가 아닌 객체의 고유 식별자로, JVM의 가비지 컬렉션 과정에서 객체가 이동하더라도 변하지 않는다.

64비트 JVM에서는 메모리 효율성을 위해 참조값을 32비트로 압축하는 기술(Compressed OOPs)이 사용되며, == 연산자는 이러한 내부 참조값을 비교한다.

System.identityHashCode()는 객체의 메모리 주소에서 파생된 값(단순하게 표현하면)이지만 직접적인 메모리 주소는 아니다.

Java의 메모리 관리 시스템은 개발자가 복잡한 메모리 관리 세부사항에 신경 쓰지 않고도 안전하게 프로그래밍할 수 있도록 설계되었기 때문에 Java 개발에서는 메모리 주소보다 객체의 논리적 상태와 관계에 집중하는 것이 중요하다.

 

 

참고 자료:

https://codingdog.tistory.com/entry/java-hashCode-vs-identityHashcode-%EC%9D%B4-%EB%91%98%EC%9D%80-%EB%AC%B4%EC%97%87%EC%9D%B4-%EB%8B%A4%EB%A5%BC%EA%B9%8C%EC%9A%94

java hashCode vs identityHashcode : 이 둘은 무엇이 다를까요?

https://stackoverflow.com/questions/1382026/how-is-the-operator-implemented-in-java

How is the == operator implemented in Java?

https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode

Compact Identity Hashcode - Compact Identity Hashcode - OpenJDK Wiki

https://users.elis.ugent.be/~leeckhou/papers/ecoop07.pdf

https://alidg.me/blog/2020/7/15/hash-code

On Generating Identity Hash Codes

https://www.baeldung.com/java-equals-hashcode-contracts