commons-issues mailing list archives

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


Sebb commented on LANG-459:

Unified diff format is the usual method.

For example, as created by Eclipse or "svn diff".

By the way, I can confim that I have seen the bug, and it is a problem with indentityHashCode
- identical system hashcodes can be generated for both the class MyClass1 and the field containing
the class MyClass2. Object.equals() on the two objects gives false (I commented out the overrides
of equals) so the objects are different.

A quick google shows that this has been noticed elsewhere. 

It is not a bug in indentityHashCode bcause that is not guaranteed to generate unique hashes
for distinct objects.
- it just has to try to do so. The hashcode is only an int (rather than long), which reduces
the number of possible values somewhat.

It's not possible to use HashMap on the original object, as HashMap uses the hash to decide
where to store the key.
If there is no other way of generating a unique value for an object, then something other
than a HashMap will have to be used - e.g. ArrayList.

Debuggers seem to be able to generate unique names for objects, but the code may be rather

> Issue in HashCodeBuilder which only shows up under high load multi-threaded usage.
> ----------------------------------------------------------------------------------
>                 Key: LANG-459
>                 URL:
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: All
>            Reporter: Andrew Wilson
>             Fix For: 3.0, Nightly Builds
>         Attachments:,
>   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.

View raw message