• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

High CPU usage while accessing HashMap

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a requirement to find out a way to locate all hashmap objects all around project (java classes) that could be accessed by multi-thread, then change it accordingly.
Then we have to change it to concurrentHashMap, or have sync lock added.
How we can locate all hashmap objects all around project?
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the Ranch

I don't understand what you mean about locating all map objects. Do you mean find all maps, or find all objects referred to inside the maps? Also what has the CPU use got to do with it?

Try removing all import declarations for HashMap and look for the compiler errors
 
Sheriff
Posts: 5555
326
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would probably start with a straight file search in the source code directory. I'm on a Mac so would do this to give me a list of source files that instantiate new HashMaps.
find . -name "*.java" -exec grep -H "new HashMap" {} \;
Then go through the list of source files and replace the HashMaps.

Or, you could use the search and replace functionality of your IDE, or sed to replace "new HashMap" with "new ConcurrentHashMap". Then you just chase down the compile errors to fix the missing import statements, which is a pretty trivial thing to do if you have a decent IDE.
 
vik vij
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the prompt reply.
This is a very big project and has hundreds of classes. There is a requirement to find all the hashmap that could be accessed by multi-thread and then change it to ConcurrentHashMap.

Here you can find info related to hashmap
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457

If a HashMap is used in a concurrent setting with insufficient synchronization,
it is possible for the data structure to get corrupted in such a way that
infinite loops appear in the data structure and thus get() could loop forever.


Please suggest.
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Even with hundreds of classes, the suggestions of Tim Cooke's would find your maps in a few seconds. Even ctrl‑F would find them in a few minutes.
That is an interesting bug report, but it is old and uses JDK1.4. Have you considered Collections#synchronizedMap, as suggested here?
 
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can do as Tim has suggested and use a search tool to identify all occurrences of HashMap but you will need to study the code yourself to see if a particular instance requires synchronization.
Are you sure you want to use ConcurrentHashMap rather than using Collections.synchronizedMap() to wrap the existing HashMap? The former approach only synchronizes writes whereas the later approach synchronizes all access so they have slightly different uses.

BTW what does the subject line of "High CPU usage while accessing HashMap" have to do with synchronizing the existing HashMaps?
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tony Docherty wrote: . . . BTW what does the subject line of "High CPU usage while accessing HashMap" have to do with synchronizing the existing HashMaps?

It might have to do with get() going into an infinite loop as described in that old bug link. Which was not really a bug; it was concurrent use of a non‑thread‑safe object, so it was a user error.
 
Tony Docherty
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Tony Docherty wrote: . . . BTW what does the subject line of "High CPU usage while accessing HashMap" have to do with synchronizing the existing HashMaps?

It might have to do with get() going into an infinite loop as described in that old bug link. Which was not really a bug; it was concurrent use of a non‑thread‑safe object, so it was a user error.


Thanks. I've just gone and read the bug report and it's all become clear now.
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tony Docherty wrote: . . . Thanks. . . .

You're welcome
 
I brought this back from the farm where they grow the tiny ads:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic