1

If two objects of the same class have the same hashCode in Java then how would they be stored in a HashMap / HashTable? What is the actual architecture for hashcode and memory address. Where does hashCode reside in memory?

Example: There is a class A. when creating objects a1 and a2 then they will represent some memory address but I overrode hashcode every time same. When I read an article then I found that hashcode functions generate a hashcode from the memory address. this means the memory address will same if hashcode is same. Please clear my doubt. 

public class A {

    @Override
    public int hashCode() {
        return 1;
    }

    public static void main(String args[]) {
        A a1 = new A();
        A a2 = new A();
        System.out.println(a1.hashCode());
        System.out.println(a2.hashCode());
    }
}
stanleyxu2005
  • 8,081
  • 14
  • 59
  • 94
Rahul Tripathi
  • 545
  • 2
  • 7
  • 17
  • `because hashcodes are generated calculating memory adresses` Please link to where you read this. – Sotirios Delimanolis Aug 28 '14 at 01:33
  • possible duplicate of [What is the default implementation of \`hashCode\`?](http://stackoverflow.com/questions/15130764/what-is-the-default-implementation-of-hashcode) – keshlam Aug 28 '14 at 01:36
  • @SotiriosDelimanolis [`Object.hashCode()`](http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode%28%29) javadoc, *This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language*. – Elliott Frisch Aug 28 '14 at 01:37

8 Answers8

5

No two objects (that exist at the same time) can have the same memory address.

They can have the same hash code, though hashCode implementations try to avoid that. And the default implementation of hashCode doesn't have to be based on the object's memory address (though it can be).

So if two objects have the same hash code, you can't assume that they have the same memory address. In fact, if two variables refer to different objects (i.e. comparing them with == returns false), they definitely do not have the same address.

The article you read about hash codes being based on memory addresses was referring to the default implementation of the hashCode method in the Object class. If you override hashCode in a subclass, you're not using that default implementation anymore. Your return 1 has nothing to do with memory addresses.

Wyzard
  • 33,849
  • 3
  • 67
  • 87
0

The default object version of hashCode() is based on a memory address. When you override the hashCode() method and return a different value it does not change the Object's memory address. Nor does returning a constant 1 break HashMap, but it does severely effect performance.

Elliott Frisch
  • 198,278
  • 20
  • 158
  • 249
0

System.out.println(a1==a2); The Result is false.

Willen
  • 123
  • 1
  • 1
  • 5
  • that is fine.but we same hashcode is depend on memory address when default implementation.When override 1 every time then what does mean by here object's uniqueness. – Rahul Tripathi Aug 28 '14 at 01:43
0

Note that since objects commonly define their own implementation of hashcode and equals, based on their contents/value rather than object identity, hashcode is NOT reliably related to the object's address.

The identity hashcode -- which is also the default hashcode implementation provided by java.lang.Object -- may or may not be related to the object address, depending on how this JRE's garbage collector manages memory.

keshlam
  • 7,931
  • 2
  • 19
  • 33
0

Hashcode and memory addresses are two different things. Hashcode is used to identify the bucket position in the memory to store the key. But two non equal objects with the same hashcode will reside in the same bucket but at a different memory address.

how would they be stored in a HashMap / HashTable?Hashcode does not reside in the memory anywhere.

Any hashed collection uses hashed buckets architecture to decide where to store the object. This helps in the quick retrieval of objects. This is the saving mechanism:

  • Objects with different hashcode and non equal(equals() return false on two object) : Will be saved in different hashed buckets

  • Objects with different hashcode and equal: Will be saved at the same hashed bucket but in a linked list

  • Object with same hashcode and equal: Will overwrite each other when saved

What is the actual architecture for hashcode and memory address.

Where does hashCode reside in memory?

It is always calculated when you try to put/retrieve an element in a hashed collection. And hashcode method provides the logic.

Juned Ahsan
  • 67,789
  • 12
  • 98
  • 136
0

I think root of the question is to understand the relation between hash value and memory location. Hash map/table use array for storing key and values. The value obtained from hash(key) function is used to determine the index in the array. If you go one more step deep in native side, memory address will be (memory address of first element of array + index). At this memory location, address of actual object will be stored.

As others have already answered, if two objects have same hash value then those objects will be in same bucket. Meaning, at the same index value of the array. But, in this case to avoid collision each element of array could be linked list. Thus, objects with same hash value will be added to a linked list.

Omkar Shetkar
  • 3,488
  • 5
  • 35
  • 50
0

I wanna make some supplementary instructions for the answer having most votes @Wyzard

The article you read about hash codes being based on memory addresses was referring to the default implementation of the hashCode method in the Object class.

In fact, the default implementation of the hashCode is not only one, instead, there are almost 6 ways (according to OpenJDK). You can get this conclusion by refer to the method get_next_hash found in the synchronizer.cpp, which is critical to calculate the hash code. For your convenience, I've posted a screenshot below: enter image description of the method here

What's more, different version of JDK just uses different way to calculate the hash code. For example, JDK1.8 product the result utilizing thread state combined with xorshift, seeing from enter image description here.

Now turn to the algorithm of generating a hash code base on the object memory address. Provided that it just simply cast the memory address to a hash code, what will happen if GC occurs during the Java running time? The address of the object may change, and then the original hash code will change too. Hence there are must more other extra operation to make sure the hash code will remain consistent using this kind of algorithm to implement the hashCode().

Sea Bean
  • 17
  • 5
-2

If two objects have the same hashcode and are of the same class - the second will replace the first if both are added to a Hashtable/HashMap.

ControlAltDel
  • 33,923
  • 10
  • 53
  • 80
  • 1
    "Added" to what? And no, different objects (with different addresses) can have the same hash code. – Wyzard Aug 28 '14 at 01:35
  • But the second *won't* replace the first. `HashMap` can handle different objects with the same hash code. You can write a class whose `hashCode` implementation is simply `return 0` and it'll still work correctly in `HashMap` (though it's likely to be slow). – Wyzard Aug 28 '14 at 01:42
  • @ControlAltDel -- at best, that's true of the Identity Hash Code and/or the default implementation inherited from java.lang.Object. And it isn't guaranteed to be true even in that case. By definition, two objects CAN have the same hashcode; only the == operation will test whether they are the same object. (In fact, two objects with the same value often _do_ have the same hashcode.) – keshlam Aug 28 '14 at 01:45