java.lang.Object.hashcode() 값은 실제 메모리 주소와 어떤 연관이 있나요?

Question

다른 일을 하다가 다시 도전해 보려고 자바책피고 공부중인데 검색해도 너무 아리송해서 질문 올립니다.

자바의정석에서 "hashCode메서드를 오버라이딩하지 않는다면 Object클래스에 정의된대로 모든 객체가 서로 다른 해시코드값을 가질 것이다"라고 적혀있습니다.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. ( javadoc hashcode() 설명중)

위 표현을 통해 "그럼 참조변수의 참조값은 실제 메모리 주소와 1:1 매핑하겠네" 라고 이해를 했습니다.

그런데 64bit JVM의 실제 메모리 주소는 해시코드 리턴값인 INT값의 범위를 넘어가니까 또 아닌거 같더라구요.

아리송한 상태로 코드도 짜봤는데 해쉬코드값의 중복수가 100만개당 232개, 1000만개당 23279개 이런식으로 뜨더라구요.

아래는 제가 짠 코드입니다.

코드가 잘못됐을 수도 있고 제가 잘못 이해한 부분이 있을 수도 있어서 자세히 말씀드렸습니다.

java.lang.Object.hashcode() 값과 실제 메모리 주소는 어떤 연관이 있는지 설명해주시면 정말 감사하겠습니다.

질문 읽어주셔서 감사합니다. 새해 복 많이 받으세요 ㅎㅎ

J.H.Lee · Accepted Answer

메모리 주소와 관련은 없어 보입니다. 해시코드는 단순히 JVM 내부적으로 객체 간 구별을 위한 고유의 정수값이라고 알고 있습니다(공식 문서를 보면 hashtable의 성능 이점도 있다고 하네요). 다만, 모든 객체가 서로 다른 해시값을 가지는 것은 아니고 위의 프로그램처럼 객체가 서로 달라도 같은 해시값을 가지는 경우가 있다고 하네요.. 반면 두 객체가 (equals 메소드를 통해)서로 같다면, 두 객체의 hashcode() 메소드는 반드시 같은 해시값을 도출합니다.

아래는 공식문서에서 참고한 내용입니다.

If two objects are equal according to the equals method, then calling the hashCode method on each of the two objects must produce the same integer result.
It is not required that if two objects are unequal according to the equals method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.

스택오버플로우에도 비슷한 질문이 있습니다: java - Does hashcode number represent the memory address? - Stack Overflow

벼랑끝에서올라오는중 · Answer

Object class에서 쓰이는 hashcode와 동일성을 판별하기 위한 주소값 hashcode가 다른 것으로 알고 있습니다. 주소값(자바에는 포인터가 없어 실제로는 주소값은 아니고 주소값 대용 hashcode라고 합니다)은 System.identityHashCode()로 찍어보면 나옵니다.

System.idenetityHashCode()와 Object class의 hashcode()를 override해서 찍어보는 hashcode() 값이 실제로 서로 다릅니다. 저는 이걸 잘못된 이해일지도 모르겠지만 동등성용(equality. 값 비교) hashcode와 동일성용(identity. 주소 비교) hashcode로 구분해서 보고 있습니다.

저도 이제 막 국비 수료한 사람이라 자세하게 아는 것은 아니니 더 검색해보시면 좋을 것 같아요. 고수 분들이 답변주시면 더더욱 좋을 것 같습니다

adduci · Answer

hashCode 는 참조값이 아닙니다

그냥 해시 알고리즘에 사용될때 적절히 오버라이딩하도록 유도하는 메소드입니다

애초에 자바가 포인터를 채택하지 않은 이유가 메모리 관리를 개발자 대신 가상머신이 하게 하기 위함인데 참조값을 노출하는게 말이 안되죠

윗분이 언급한 identityHashCode 도 마찬가지 이구요

Object 의 hashCode 는 해시값 생성에 대한 기준이 없으니 그냥 적절한 해시값을 리턴하도록 만들어 놓은거고, 그렇기 때문에 오버라이딩을 권장하는겁니다

사과맛오렌지 · Answer

만약 hashcode값이 메모리 주소라면, 같은 객체의 hashcode값이 시시때때로 변하거나, 같은 hashcode를 갖는 다른 두 객체가 생길 수 있는 문제가 있겠지요.

다음을 참고해보시는 게 좋을 것 같습니다.

https://stackoverflow.com/questions/49172698/default-hashcode-implementation-for-java-objects/49175508#49175508

System.idenetityHashCode의 경우, 코드가 여기 있습니다.

https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjava/System.c#L55

JNIEXPORT jint JNICALL
Java_java_lang_System_identityHashCode(JNIEnv *env, jobject this, jobject x)
{
    return JVM_IHashCode(env, x);
}

아마 Object.hashcode도 JVM_IHashCode 함수를 호출하는 것 같습니다, 이상하게도 Object.c를 보면

#include "jni.h"
#include "jni_util.h"
#include "jvm.h"

#include "java_lang_Object.h"

JNIEXPORT jclass JNICALL
Java_java_lang_Object_getClass(JNIEnv *env, jobject this)
{
    if (this == NULL) {
        JNU_ThrowNullPointerException(env, NULL);
        return 0;
    } else {
        return (*env)->GetObjectClass(env, this);
    }
}

hashCode 메소드에 대응하는 함수는 찾아볼 수가 없네요... 더 이상한 건 hashCode함수가 있지 않을까 싶어 보이는 java_lang_Object.h헤더는 아예 JDK 소스 내에 존재조차 하지 않습니다...

빌드 시에 동적으로 만들어지는 파일인지... 잘 모르겠네요.

우선 JVM_IHashCode를 찾기 위해 열심히 뒤져 보면...

https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvm.cpp#L614

JVM_ENTRY(jint, JVM_IHashCode(JNIEnv* env, jobject handle))
  // as implemented in the classic virtual machine; return 0 if object is NULL
  return handle == NULL ? 0 : ObjectSynchronizer::FastHashCode (THREAD, JNIHandles::resolve_non_null(handle)) ;
JVM_END

객체가 NULL이라면 0을 반환하게 되어 있습니다. 객체가 실존한다면 FastHashCode함수로 떠넘겨 버리네요.

FastHashCode함수의 코드는 여기 있습니다.

https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/synchronizer.cpp#L859

      hash = mark.hash();
      if (hash != 0) {                     // if it has a hash, just return it
        return hash;
      }
      hash = get_next_hash(current, obj);  // get a new hash
      temp = mark.copy_set_hash(hash);     // merge the hash into header
                                           // try to install the hash

객체 헤더에 해쉬값이 이미 저장되어 있다면, 그 값을 쓰고, 없다면 get_next_hash를 호출해 새 값을 만든 후 헤더에 해쉬값을 저장해줍니다.

get_next_hash 함수는 FastHashCode함수 바로 위에 구현되어 있습니다.

// hashCode() generation :
//
// Possibilities:
// * MD5Digest of {obj,stw_random}
// * CRC32 of {obj,stw_random} or any linear-feedback shift register function.
// * A DES- or AES-style SBox[] mechanism
// * One of the Phi-based schemes, such as:
//   2654435761 = 2^32 * Phi (golden ratio)
//   HashCodeValue = ((uintptr_t(obj) >> 3) * 2654435761) ^ GVars.stw_random ;
// * A variation of Marsaglia's shift-xor RNG scheme.
// * (obj ^ stw_random) is appealing, but can result
//   in undesirable regularity in the hashCode values of adjacent objects
//   (objects allocated back-to-back, in particular).  This could potentially
//   result in hashtable collisions and reduced hashtable efficiency.
//   There are simple ways to "diffuse" the middle address bits over the
//   generated hashCode values:

static inline intptr_t get_next_hash(Thread* current, oop obj) {
  intptr_t value = 0;
  if (hashCode == 0) {
    // This form uses global Park-Miller RNG.
    // On MP system we'll have lots of RW access to a global, so the
    // mechanism induces lots of coherency traffic.
    value = os::random();
  } else if (hashCode == 1) {
    // This variation has the property of being stable (idempotent)
    // between STW operations.  This can be useful in some of the 1-0
    // synchronization schemes.
    intptr_t addr_bits = cast_from_oop(obj) >> 3;
    value = addr_bits ^ (addr_bits >> 5) ^ GVars.stw_random;
  } else if (hashCode == 2) {
    value = 1;            // for sensitivity testing
  } else if (hashCode == 3) {
    value = ++GVars.hc_sequence;
  } else if (hashCode == 4) {
    value = cast_from_oop(obj);
  } else {
    // Marsaglia's xor-shift scheme with thread-specific state
    // This is probably the best overall implementation -- we'll
    // likely make this the default in future releases.
    unsigned t = current->_hashStateX;
    t ^= (t << 11);
    current->_hashStateX = current->_hashStateY;
    current->_hashStateY = current->_hashStateZ;
    current->_hashStateZ = current->_hashStateW;
    unsigned v = current->_hashStateW;
    v = (v ^ (v >> 19)) ^ (t ^ (t >> 8));
    current->_hashStateW = v;
    value = v;
  }

해시를 만드는 여러 가지 방법이 있고, hashCode 변수 값에 따라 하나 지정해서 사용하는 방식입니다.

그럼 저 hashCode 변수는 어디서 무슨 값으로 저장되냐...

https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L737

5번이 디폴트로 되어 있는 것을 확인할 수 있습니다.

"Marsaglia's xor-shift scheme with thread-specific state", 즉 쓰레드 state와 비트 연산을 이용해서 계산한다고 이해할 수 있을 듯 합니다...

찾아보면 적어도 JDK8부터 저 5번이 디폴트였으니, JVM 자체를 커스텀으로 빌드하거나 하는 게 아니라면 저 방법이라고 생각하면 되겠네요.

참고한 자료 : https://stackoverflow.com/questions/60735601/understanding-how-javas-object-hashcode-can-be-related-to-memory-address-with

java.lang.Object.hashcode() 값은 실제 메모리 주소와 어떤 연관이 있나요?

4개의 답변

Q&A 목록