commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joerg Schaible (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LANG-459) Issue in HashCodeBuilder which only shows up under high load multi-threaded usage.
Date Tue, 16 Sep 2008 10:48:44 GMT

    [ https://issues.apache.org/jira/browse/LANG-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631332#action_12631332
] 

Joerg Schaible commented on LANG-459:
-------------------------------------

The general contract of hashCode is:

* Whenever it is invoked on the same object more than once during an execution of a Java application,
the hashCode method must consistently return the same integer, provided no information used
in equals comparisons on the object is modified. This integer need not remain consistent from
one execution of an application to another execution of the same application.
* 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.
* 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. However, the programmer should be aware that producing distinct integer results
for unequal objects may improve the performance of hashtables. 

The problem is that a common implementation like

{code}
    public static class MyClass {
        public Object arg;

        public MyClass(Object arg) {
            this.arg = arg;
        }

        public boolean equals(Object o) {
            return EqualsBuilder.reflectionEquals(o, this);
        }

        public int hashCode() {
            return HashCodeBuilder.reflectionHashCode(this);
        }
    }
{code}

... will simply violate point two of the upper specification if HashCodeBuilder.reflectionHashCode(Object)
will use the identityHashCode.

> Issue in HashCodeBuilder which only shows up under high load multi-threaded usage.
> ----------------------------------------------------------------------------------
>
>                 Key: LANG-459
>                 URL: https://issues.apache.org/jira/browse/LANG-459
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: All
>            Reporter: Andrew Wilson
>             Fix For: 3.0, Nightly Builds
>
>         Attachments: HashCodeBuilder.java, MyTest.java
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> We found we were having problems with HashCodeBuilder under multi-threaded high load.
> I narrowed this down to the following attached test case.
> When I dug into the code, I found the problem was solved by commenting out the isRegistered
method (though this would break the infinite loop problem).
> ( I did a lot of other digging that I wont bore you with).
> So instead I replaced the HashSet with an ArrayList and just added the object, rather
than the toIdentityHashCodeInteger(object)
> This results in about 5 lines of change.  
> My suspicion is that System.identityHashCode does not return unique values (it is after
all a hashcode method).  The code assumes it will return a unique value and this causes the
problem at high loads.
> The downside is a List vs. a Set, but I believe this is necessary.
> I'd like to submit this fix and have it verified (and perhaps improved).  I am convinced
it is a necessary fix which we have seen show up under high loads.
> Kindest regards, 
> Andrew.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message