HashSet contains problem with custom objects

前端 未结 4 1094
旧时难觅i
旧时难觅i 2020-12-05 11:06

My Custom class that will be contained by HashSet

public class Person {
    String name;
    int age;

    public Person(String name, int age) {
        this         


        
相关标签:
4条回答
  • 2020-12-05 11:34

    Hashes are simple pairing of key and values. Here's how the state of your code would look before and after the renaming in pseudo-code:

    Before:

    personSet => {
        SOME_NUM1 => Person(name=>"raghu", 12),
        SOME_NUM2 => Person(name=>"rimmu", 21)
    }
    
    p1.setName("raghus"); #p1.hashcode() = SOME_NEW_NUM
    p1.setAge(13);#p1.hashcode() = SOME_OTHER_NEW_NUM
    

    After:

    personSet => {
        SOME_NUM1 => Person(name=>"raghu", 13),
        SOME_NUM2 => Person(name=>"rimmu", 21)
    }
    

    Since you have direct access to the p1 the object within the HashSet is updated correctly, but HashSet does not pay attention to contained objects hashcodes being updated. When a call to personSet.contains(p1) is called, the HashSet looks for an entry with the new value of p1.hashcode().

    The p1 object is associated with its previous hashcode at the time when it was added to the HashSet.

    0 讨论(0)
  • 2020-12-05 11:39

    Because p1.hashCode() changes when you modify p1, so it can't be found at its original index in the hash table anymore. Never let a hash value depend on a mutable field.

    (You're quite lucky that it fails during testing; it might just as well have succeeded, only to fail in production.)

    0 讨论(0)
  • 2020-12-05 11:41

    HashSet implements Set. The ApiDoc specifies:

    Note: Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is an element in the set.

    In your example this is the case, because changing name or age on p1 affects equal-comparison. So according the ApiDoc, the behavior of Set in your case is unspecified.

    0 讨论(0)
  • 2020-12-05 11:44

    I think you need to have hashCode depends on mutable fields quite often indeed: when you override equals that depends on mutable fields.

    From hashCode's contract: "If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result."

    So, if you create two objects such that A.equals(B) is true, and then modify A such a way that you get A.equals(B) became false, you need to have hashCodes change too.

    It's true that in hashCode's documentation is stated that "It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results.", but I don't know how this can help.

    0 讨论(0)
提交回复
热议问题