hashmap put performance issue

Question

i have a hashmap in my application. The map is in a singleton and access to update or read it is protected using synchronized methods.

My problem occurs when testing with large numbers(20000+) of concurrent threads. When threads are writing to the map using put() im getting OutOfMemory exception.

Read operations are fine (i can simulate 1000000+ threads) without any issue.

Any recommendations on how i can make my hashmap more performant for writes? This may also be a limitation with my approach of storing so much data in memory?

Yes, a large set of data such as this should be (partially) stored in a disk-backed hashmap, which is a database. — Chris Dennett, Apr 30 '11 at 23:45

score 4 · Accepted Answer · answered May 01 '11 at 01:16

4

I suspect you're running out of PermGen memory due to the number of threads. Your OutOfMemoryError exception should tell you if it's heap or PermGen.

Each thread in Java uses about 256-512 Kbytes for its stack, which is allocated from PermGen. So 20,000 threads * 256 Kbytes = 5 Gbytes which way beyond the default PermGen size (usually 64-256 Mbytes).

You should limit the number of threads to less than a few hundred. Take a look Java 5/6's concurrent package, in particular ThreadPoolExecutor.

answered May 01 '11 at 01:16

Steve Kuo

61,876
75
195
257

thanks for good information, how can i see if its out of PermGen? When the OOM exception is thrown it only gives the folllowing exception "OutOfMemoryError: unable to create new native thread" along with the stack trace. When i use a profiler the generated log shows exception thrown with "java.lang.OutOfMemoryError: requested 160008 bytes for Chunk::new. Out of swap space?". In this log the perm gen usage-total=11288k,used=4498k. I think using profiler causes different memory usage so i cant trust it. I tried the -XX:HeapDumpPath arg to create heap dump whenever OOM occurs but its not. – cdugga May 01 '11 at 09:34
if the read operation allows 100000 threads then is this a PermGen issue? – cdugga May 01 '11 at 11:55
`unable to create new native thread`, so it appears the Java, for whatever reason, can't create a new thread. So it looks like you have too many threads. – Steve Kuo May 01 '11 at 15:22
1

Is it correct of me to assume that the put operation in the hashmap creates such a performance hit that the number of threads my app can handle will reduce by a factor of 20% as opposed to just doing reads? – cdugga May 01 '11 at 16:21

score 1 · Answer 2 · edited May 23 '17 at 12:29

1

If you are using JDK1.5+, ConcurrentHashMap is a good choice. It's effective.

See: What's the difference between ConcurrentHashMap and Collections.synchronizedMap(Map)?

Also, I think put() may lead new memory allocate in map and more time consuming, but get() not. So more threads will be blocked in put().

Also, Optimize the hashCode() method of your key class. It's important, as hash code calculation is intensive operation in your case. If the key object is immutable, calculate the hash code just once and save it as a member and return it directly in hashCode().

edited May 23 '17 at 12:29

Community

1
1

answered Apr 30 '11 at 23:24

卢声远 Shengyuan Lu

31,208
22
85
130

regarding optimizing the hashcode function, if im using an Integer as the key can i not trust that its hashcode will be better than what i can write? Im not using an custom objects the hashmap – cdugga May 01 '11 at 09:26
In my map i also reuse keys to enter new values when a certain condition is met. Would this add to the memory issue? – cdugga May 01 '11 at 16:22

MJB · Answer 3 · 2011-04-30T23:35:05.020

1

Have you tried a ConcurrentHashMap? Under the right coding circumstances you won't need any synchronization. There are multiple striped locks internally to reduce contention, and many nice compound atomic operations like putIfAbsent that may allow you to drop external locks entirely.

As for memory, I suspect you really are storing a lot in the JVM. Use a monitor tool like visualvm to check it out, or add more memory to the JVM allocation. Consider a cache like EHCache that will automatically overflow to disk and internally uses a ConcurrentHashMap, and has all kinds of nice bounding options

edited Apr 30 '11 at 23:35

answered Apr 30 '11 at 23:24

MJB

9,352
6
34
49

cheers, with visualvm i could identify with certainty it was too many threads. – cdugga May 03 '11 at 18:37

score 1 · Answer 4 · answered Apr 30 '11 at 23:28

Sounds like your problem is memory, not performance.

Try writing least recently accessed keys and values with same hashcode to a file and clearing them from memory.

If a file stored hashcode is addressed, write next least recently used hash code's keys and sales to a file and clear from memory, then read desired stored read file to memory.

Consider multiple levels of hashmaps (each with different keys) for improving performance of this.

score 1 · Answer 5 · answered Apr 30 '11 at 23:46

If you would like to keep your current implementation, you might also want to consider changing the amount of memory allocated to the application by changing the -Xms and -Xmx parameters passed to Java. Many other parameters exist as well. It may be necessary to do this regardless of the implementation used.

score 1 · Answer 6 · edited May 01 '11 at 01:54

1

You can use ConcurrentHashMap instead of that and it has more advantages over regular map. I am not sure whether you are using Java5, since it is available from version 5 only.

Also, I would say that, think once again on your logic whether you really require synchronization on read operations. If it's not, you can remove that and you will save some performance.

If you are really feel a low memory issue, you can run the jvm with more vm memory options said above. Give it a try. :)

Have your hashcode method for the keys efficient. You can depend on other apis such as Pojomatic to do that stuff.

edited May 01 '11 at 01:54

user229044

232,980
40
330
338

answered May 01 '11 at 01:22

San

11
1

i want to keep the synchronized behavior to because i dont want the possibility of one thread reading a record while another thread is updating it. – cdugga May 01 '11 at 11:58

score 0 · Answer 7 · answered Aug 25 '11 at 14:17

As far as the last part of your question:

Any recommendations on how i can make my hashmap more performant for writes? This may also be a limitation with my approach of storing so much data in memory?

I use a tool to take a look at what the application is doing. It can do heap and thread dumps. It also has a montior that displays the cpu, classes loaded, threads, heap, and perm gen. It's called Java VisualVM and it's part of jdk 1.6 The exe is in the bin folder of the jdk. I'm going to use it for tracking down some threading issues in our code.

HTH, James

score -2 · Answer 8 · answered Apr 30 '11 at 23:24

-2

OutOfMemoryError can be caused by large number of objects stored, not by large number of threads, and OOME is not a performance problem.

BTW, you can use ConcurrentHashMap for fast concurrent reads and writes, and do not use one global lock.

answered Apr 30 '11 at 23:24

stepancheg

4,262
2
33
38

hashmap put performance issue

8 Answers8