Scaling problem of HashMap (introduced with alternative hashing)
zhong.j.yu at gmail.com
Thu Dec 27 20:21:52 UTC 2012
On Thu, Dec 27, 2012 at 1:55 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
> I am responding on the StackOverflow thread. I will look into using ThreadLocalRandom.
> The random.next() is clearly a potential bottleneck but given that this happens only once per HashMap instance it is still unclear why a reasonable application would want to create hundreds or thousands of hash maps per second.
That is pretty common, for example, in a web server, each request may
use a HashMap for headers, and there are thousands of requests per
second. That's probably not a big deal either on commodity hardware,
but OP got 64 cores.
> On Dec 27 2012, at 11:38 , Aleksey Shipilev wrote:
>> Looks very like dumb inlined java.util.Random?
>> Is there a security threat to use ThreadLocalRandom instead there?
>> On 27.12.2012, at 23:16, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>> Reported by the SO question
>>> the HashMap constructor contains a CAS, which is kind of surprising.
>>> Could it be removed?
>>> transient final int hashSeed =
>>> sun.misc.Hashing.randomHashSeed(this); // CAS
>>> Zhong Yu
More information about the core-libs-dev