2. GetHashCode
객체 값에 대한 HashCode를 반환해주는 Method입니다. 근데 이 Method가 반환해 주는 Hashcode는 그닥 쓸모가 없다고 합니다. 각 객체마다 유일한 Hashcode를 보장해 주어야 하지만 그렇지 못하기 때문입니다.
암튼 디자이너는 어떠한 객체라도 HashTable에 담길 수 있다면 여러모로 편리할 것이라고 판단해서 모든 Object를 상속하는 객체는 이 Method를 통해 Int32형태의 hashcode를 얻을 수 있도록 설계했다고 합니다.
하지만 결국 이 Method로 유일한 hashcode를 제대로 반환해 줄 수 있도록 사용하기 위해서는 override를 통해 재작성하여 사용해야 합니다. 그래서 CLR via C# 에서는 Object의 Method로 정의되어 있을 것이 아니라 interface로 정의해 놓는게 맞는게 아닌가 라고 말합니다.
그런데 이 GetHashCode를 재정의해서 사용하기 위해서는 기억해야 할 점이 있습니다. 지난 번에 공부했던 Object의 Method인 Equals()를 재정의 한다면 이 GetHashCode()도 재정의를 해 주어야 한다는 점입니다. 만약 Equals()만 재정의 한다면 컴파일시 warning을 발생합니다.
Animal이라는 Class에서 Equals()만 재정의 했더니 위와 같은 경고 메시지를 발생하는 것을 볼 수 있습니다. 이유는 두 객체가 같다면 (Equals()의 값이 true라면) 두 객체의 hashcode도 같을 것이라는 가정을 System.Collections.HashTable 타입과 System.Collections.Generic.Dictionary 타입이 하고 있기 때문입니다.
결국 객체의 동질성을 판단하는 Equals()의 알고리즘에 의해 두 객체가 같다고 판명이 난다면 GetHashCode()를 구하는 알고리즘도 Equals()을 판단하는 알고리즘과 연관되어 같은 값을 반환할 수 있도록 구현해 주어야 합니다.
GetHashCode()는 객체가 속한 AppDomain수준에서 유일할 수 있는 ID를 숫자로 반환하게 되어 있으며 이 값은 객체의 일생동안 바뀌지 않는 것이 보장되지만 이 객체가 가비지 수집기에 의해 수집되면 수집된 객체 hashcode를 의미하는 ID가 다른 새로운 객체에 재활용될 수 있다고 하네요. 그래서 유일한 값을 보장 못한다고 말하는데 그렇다면 AppDomain 수준에서 객체의 유일한 값을 보장해주는 HashCode를 반환해주는 Method가 CLR에 없을까요?
아니 있습니다. System.Runtime.ComplierServices 네임 스페이스에 있는 RuntimeHelpers 클래스의 정적 Method인 GetHashCode 메서드를 제공하고 있습니다. 객체가 Object의 GetHashCode 메서드를 재정의했다고 하더라도 해당 Object를 RuntimeHelpers.GetHashCode() 메소드의 인자로 제공하면 유일한 값을 보장받을 수 있는 ID를 제공해 줍니다.
아 그럼 Object의 GetHashCode()를 쓸게 아니라 저 RuntimeHelpers.GetHashCode()를 쓰면 되겠구나.
하면 되겠죠.
그런데 이 GethashCode()가 VS2010에 포함되어 있는 4.0X 버전의 mscorlib.dll 에서 구현하고 있는 것과 이전 버전에서 구현하고 있는 것이 좀 틀립니다.
우선 기존의 CLR의 mscorlib.dll에서 제공하고 있는 GetHashCode()의 내부를 살펴보도록 하겠습니다.
내부에서 Object.InternalGetHashCode()라는 Method를 호출하고 있네요. 저 함수를 들어가 보면
위와 같은 코드를 볼 수 있습니다. 함수 선언을 보면 internalcall이라는게 붙어 있는데 이것은 unmanaged코드가 불리는 것이라고 생각하면 됩니다. CLR의 관리되는 코드가 아니라 nativecode의 영역에서 구현되어 있다는 말이지요.
그래서 실제 GetHashCode는 다음과 같이 구현이 되어 있다고 합니다.
Hashcode 소스이지만 이 소스만 읽어서는 어떤 알고리즘으로 hashcode를 생성하는 건지 정확히 파악하기가 어렵군요. :)
암튼 이런식으로 GetHashCode()가 구현되어 있었습니다.
그런데 4.0 버전에서의 구현은 다음과 같습니다.
어라 어디서 많이 보던 함수를 호출 하고 있군요. 아까 앞에서 살펴본 AppDomain상에서 객체마다 유일한 ID를 제공하는 것을 보장해준다고 하는 System.Runtime.CompilerServices.RuntimeHelpers::GetHashCode(object)를 호출하고 있습니다!
System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode()는 역시 unmanaged code를 invoke하게 되어 있는 것 같습니다. 내부 구현 코드를 찾아볼 수 있으면 좋을텐데 찾기가 힘드네요;
결국 내부 코드 구현으로 봤을 때 .NET 4.0기반의 CLR에서는 Object.GethashCode()를 사용하는 것과 System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode()를 사용하는 건 동일합니다.
GetHashCode()를 재정의 할 때 고려해야 할 점을 생각해 볼까요.
1. 무엇보다 잘 분포된 난수를 생성할 수 있는 그러니까 같은 Application 환경에서 유일한 값을 보장할 수 있는 알고리즘을 사용해야 합니다.
2. 정의하는 알고리즘 상에서 상위 클래스의 GetHashCode() 를 호출해서 자신의 Hashcode에 값을 반영하는 경우가 있겠지만 기본적으로 제공하는 Object의 GetHashCode()는 가능하면 사용하지 말아야 합니다. 빠른 성능을 고려해서 만든 알고리즘이 아니기 때문입니다.
3. 알고리즘은 적어도 하나의 인스턴스 필드는 이용해야 합니다. 미리 정의되어 있는 정적 값만을 이용하면 안된다는 말이겠지요.
4. 사용되는 필드는 불변의 속성을 가져야 합니다. 즉 필드값은 한번 생성되면 그 객체가 소멸될 때까지는 절대 값이 바뀌어서는 안됩니다.
5. 객체가 같은 값을 지니고 있다면 HashCode도 같은 값을 반환해야 합니다.
그리고 이 GetHashCode()를 사용할 떄의 주의점도 있습니다. 절대로 이 메소드를 통해 연산한 결과를 저장하여 사용하지 말아야 한다는 점인데 예를 들어 설명하자면 어떤 사이트에서 회원 정보를 받을 때 암호를 GetHashCode()를 이용해서 만들어진 hashcode를 DB에 저장해선 안된다는 것입니다.
지금까지 알아본것 처럼 CLR이 업데이트 되면서 내부 구현이 바뀌게 된다거나, 사용자가 직접 재정의한 GetHashCode()의 알고리즘이 변경된다면 저 DB에 저장된 hashcode는 모두 쓰레기가 되어 버리게 될 테니까요.
객체 값에 대한 HashCode를 반환해주는 Method입니다. 근데 이 Method가 반환해 주는 Hashcode는 그닥 쓸모가 없다고 합니다. 각 객체마다 유일한 Hashcode를 보장해 주어야 하지만 그렇지 못하기 때문입니다.
암튼 디자이너는 어떠한 객체라도 HashTable에 담길 수 있다면 여러모로 편리할 것이라고 판단해서 모든 Object를 상속하는 객체는 이 Method를 통해 Int32형태의 hashcode를 얻을 수 있도록 설계했다고 합니다.
하지만 결국 이 Method로 유일한 hashcode를 제대로 반환해 줄 수 있도록 사용하기 위해서는 override를 통해 재작성하여 사용해야 합니다. 그래서 CLR via C# 에서는 Object의 Method로 정의되어 있을 것이 아니라 interface로 정의해 놓는게 맞는게 아닌가 라고 말합니다.
그런데 이 GetHashCode를 재정의해서 사용하기 위해서는 기억해야 할 점이 있습니다. 지난 번에 공부했던 Object의 Method인 Equals()를 재정의 한다면 이 GetHashCode()도 재정의를 해 주어야 한다는 점입니다. 만약 Equals()만 재정의 한다면 컴파일시 warning을 발생합니다.
------ Build started: Project: Test04, Configuration: Debug x86 ------
C:\Documents and Settings\XPMUser\my documents\visual studio 2010\Projects\TestSolution\Test04\Program.cs(8,11): warning CS0659: 'Test04.Animal' overrides Object.Equals(object o) but does not override Object.GetHashCode()
C:\Documents and Settings\XPMUser\my documents\visual studio 2010\Projects\TestSolution\Test04\Program.cs(8,11): warning CS0659: 'Test04.Animal' overrides Object.Equals(object o) but does not override Object.GetHashCode()
Animal이라는 Class에서 Equals()만 재정의 했더니 위와 같은 경고 메시지를 발생하는 것을 볼 수 있습니다. 이유는 두 객체가 같다면 (Equals()의 값이 true라면) 두 객체의 hashcode도 같을 것이라는 가정을 System.Collections.HashTable 타입과 System.Collections.Generic.Dictionary 타입이 하고 있기 때문입니다.
결국 객체의 동질성을 판단하는 Equals()의 알고리즘에 의해 두 객체가 같다고 판명이 난다면 GetHashCode()를 구하는 알고리즘도 Equals()을 판단하는 알고리즘과 연관되어 같은 값을 반환할 수 있도록 구현해 주어야 합니다.
GetHashCode()는 객체가 속한 AppDomain수준에서 유일할 수 있는 ID를 숫자로 반환하게 되어 있으며 이 값은 객체의 일생동안 바뀌지 않는 것이 보장되지만 이 객체가 가비지 수집기에 의해 수집되면 수집된 객체 hashcode를 의미하는 ID가 다른 새로운 객체에 재활용될 수 있다고 하네요. 그래서 유일한 값을 보장 못한다고 말하는데 그렇다면 AppDomain 수준에서 객체의 유일한 값을 보장해주는 HashCode를 반환해주는 Method가 CLR에 없을까요?
아니 있습니다. System.Runtime.ComplierServices 네임 스페이스에 있는 RuntimeHelpers 클래스의 정적 Method인 GetHashCode 메서드를 제공하고 있습니다. 객체가 Object의 GetHashCode 메서드를 재정의했다고 하더라도 해당 Object를 RuntimeHelpers.GetHashCode() 메소드의 인자로 제공하면 유일한 값을 보장받을 수 있는 ID를 제공해 줍니다.
아 그럼 Object의 GetHashCode()를 쓸게 아니라 저 RuntimeHelpers.GetHashCode()를 쓰면 되겠구나.
하면 되겠죠.
그런데 이 GethashCode()가 VS2010에 포함되어 있는 4.0X 버전의 mscorlib.dll 에서 구현하고 있는 것과 이전 버전에서 구현하고 있는 것이 좀 틀립니다.
우선 기존의 CLR의 mscorlib.dll에서 제공하고 있는 GetHashCode()의 내부를 살펴보도록 하겠습니다.
내부에서 Object.InternalGetHashCode()라는 Method를 호출하고 있네요. 저 함수를 들어가 보면
위와 같은 코드를 볼 수 있습니다. 함수 선언을 보면 internalcall이라는게 붙어 있는데 이것은 unmanaged코드가 불리는 것이라고 생각하면 됩니다. CLR의 관리되는 코드가 아니라 nativecode의 영역에서 구현되어 있다는 말이지요.
그래서 실제 GetHashCode는 다음과 같이 구현이 되어 있다고 합니다.
FCIMPL1(INT32, ObjectNative::GetHashCode, Object* obj) {
CONTRACTL
{
THROWS;
DISABLED(GC_NOTRIGGER);
INJECT_FAULT(FCThrow(kOutOfMemoryException););
MODE_COOPERATIVE;
SO_TOLERANT;
}
CONTRACTL_END;
VALIDATEOBJECTREF(obj);
DWORD idx = 0;
if (obj == 0)
return 0;
OBJECTREF objRef(obj);
HELPER_METHOD_FRAME_BEGIN_RET_1(objRef);
idx = GetHashCodeEx(OBJECTREFToObject(objRef));
HELPER_METHOD_FRAME_END();
return idx;
}
FCIMPLEND
INT32 ObjectNative::GetHashCodeEx(Object *objRef)
{
CONTRACTL
{
MODE_COOPERATIVE;
THROWS;
GC_NOTRIGGER;
SO_TOLERANT;
}
CONTRACTL_END
VALIDATEOBJECTREF(objRef);
DWORD iter = 0;
while (true)
{
DWORD bits = objRef->GetHeader()->GetBits();
if (bits & BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX)
{
if (bits & BIT_SBLK_IS_HASHCODE)
{
return bits & MASK_HASHCODE;
}
else
{
SyncBlock *psb = objRef->GetSyncBlock();
DWORD hashCode = psb->GetHashCode();
if (hashCode != 0)
return hashCode;
hashCode = Object::ComputeHashCode();
return psb->SetHashCode(hashCode);
}
}
else
{
if ((bits & (SBLK_MASK_LOCK_THREADID |
if (objRef->GetHeader()->SetBits(newBits, bits) == bits)
return hashCode;
}
}
}
}
CONTRACTL
{
THROWS;
DISABLED(GC_NOTRIGGER);
INJECT_FAULT(FCThrow(kOutOfMemoryException););
MODE_COOPERATIVE;
SO_TOLERANT;
}
CONTRACTL_END;
VALIDATEOBJECTREF(obj);
DWORD idx = 0;
if (obj == 0)
return 0;
OBJECTREF objRef(obj);
HELPER_METHOD_FRAME_BEGIN_RET_1(objRef);
idx = GetHashCodeEx(OBJECTREFToObject(objRef));
HELPER_METHOD_FRAME_END();
return idx;
}
FCIMPLEND
INT32 ObjectNative::GetHashCodeEx(Object *objRef)
{
CONTRACTL
{
MODE_COOPERATIVE;
THROWS;
GC_NOTRIGGER;
SO_TOLERANT;
}
CONTRACTL_END
VALIDATEOBJECTREF(objRef);
DWORD iter = 0;
while (true)
{
DWORD bits = objRef->GetHeader()->GetBits();
if (bits & BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX)
{
if (bits & BIT_SBLK_IS_HASHCODE)
{
return bits & MASK_HASHCODE;
}
else
{
SyncBlock *psb = objRef->GetSyncBlock();
DWORD hashCode = psb->GetHashCode();
if (hashCode != 0)
return hashCode;
hashCode = Object::ComputeHashCode();
return psb->SetHashCode(hashCode);
}
}
else
{
if ((bits & (SBLK_MASK_LOCK_THREADID |
(SBLK_MASK_APPDOMAININDEX << SBLK_APPDOMAIN_SHIFT))) != 0)
{
objRef->GetSyncBlock();
}
else
{
if (bits & BIT_SBLK_SPIN_LOCK)
{
iter++;
if ((iter % 1024) != 0 && g_SystemInfo.dwNumberOfProcessors > 1)
{
YieldProcessor();
}
else
{
__SwitchToThread(0);
}
continue;
}
DWORD hashCode = Object::ComputeHashCode();
DWORD newBits = bits | BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX |
objRef->GetSyncBlock();
}
else
{
if (bits & BIT_SBLK_SPIN_LOCK)
{
iter++;
if ((iter % 1024) != 0 && g_SystemInfo.dwNumberOfProcessors > 1)
{
YieldProcessor();
}
else
{
__SwitchToThread(0);
}
continue;
}
DWORD hashCode = Object::ComputeHashCode();
DWORD newBits = bits | BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX |
BIT_SBLK_IS_HASHCODE | hashCode;
if (objRef->GetHeader()->SetBits(newBits, bits) == bits)
return hashCode;
}
}
}
}
Hashcode 소스이지만 이 소스만 읽어서는 어떤 알고리즘으로 hashcode를 생성하는 건지 정확히 파악하기가 어렵군요. :)
암튼 이런식으로 GetHashCode()가 구현되어 있었습니다.
그런데 4.0 버전에서의 구현은 다음과 같습니다.
어라 어디서 많이 보던 함수를 호출 하고 있군요. 아까 앞에서 살펴본 AppDomain상에서 객체마다 유일한 ID를 제공하는 것을 보장해준다고 하는 System.Runtime.CompilerServices.RuntimeHelpers::GetHashCode(object)를 호출하고 있습니다!
System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode()는 역시 unmanaged code를 invoke하게 되어 있는 것 같습니다. 내부 구현 코드를 찾아볼 수 있으면 좋을텐데 찾기가 힘드네요;
결국 내부 코드 구현으로 봤을 때 .NET 4.0기반의 CLR에서는 Object.GethashCode()를 사용하는 것과 System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode()를 사용하는 건 동일합니다.
GetHashCode()를 재정의 할 때 고려해야 할 점을 생각해 볼까요.
1. 무엇보다 잘 분포된 난수를 생성할 수 있는 그러니까 같은 Application 환경에서 유일한 값을 보장할 수 있는 알고리즘을 사용해야 합니다.
2. 정의하는 알고리즘 상에서 상위 클래스의 GetHashCode() 를 호출해서 자신의 Hashcode에 값을 반영하는 경우가 있겠지만 기본적으로 제공하는 Object의 GetHashCode()는 가능하면 사용하지 말아야 합니다. 빠른 성능을 고려해서 만든 알고리즘이 아니기 때문입니다.
3. 알고리즘은 적어도 하나의 인스턴스 필드는 이용해야 합니다. 미리 정의되어 있는 정적 값만을 이용하면 안된다는 말이겠지요.
4. 사용되는 필드는 불변의 속성을 가져야 합니다. 즉 필드값은 한번 생성되면 그 객체가 소멸될 때까지는 절대 값이 바뀌어서는 안됩니다.
5. 객체가 같은 값을 지니고 있다면 HashCode도 같은 값을 반환해야 합니다.
그리고 이 GetHashCode()를 사용할 떄의 주의점도 있습니다. 절대로 이 메소드를 통해 연산한 결과를 저장하여 사용하지 말아야 한다는 점인데 예를 들어 설명하자면 어떤 사이트에서 회원 정보를 받을 때 암호를 GetHashCode()를 이용해서 만들어진 hashcode를 DB에 저장해선 안된다는 것입니다.
지금까지 알아본것 처럼 CLR이 업데이트 되면서 내부 구현이 바뀌게 된다거나, 사용자가 직접 재정의한 GetHashCode()의 알고리즘이 변경된다면 저 DB에 저장된 hashcode는 모두 쓰레기가 되어 버리게 될 테니까요.
참고자료
CLR via C#
http://social.msdn.microsoft.com/Forums/ko-KR/visualcsharpko/thread/8b773719-4c69-4ba3-9435-ab7993110615
CLR via C#
http://social.msdn.microsoft.com/Forums/ko-KR/visualcsharpko/thread/8b773719-4c69-4ba3-9435-ab7993110615
'CLR' 카테고리의 다른 글
| 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-1. (1) | 2010.08.10 |
|---|---|
| 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 1. (2) | 2010.08.02 |
| 7. System.Object (0) | 2010.02.16 |
| 6. Assembly - GAC(Global Assembly Cache) (2) | 2010.02.02 |
| 5. Assembly - Strongly named assemblies (0) | 2010.01.26 |
TestSolution.zip
