File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes Which Java Collection construct will be suitable ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Which Java Collection construct will be suitable ?" Watch "Which Java Collection construct will be suitable ?" New topic

Which Java Collection construct will be suitable ?

Manimekala Velautham

Joined: May 31, 2006
Posts: 16
I want to have a HashTable or a HashMap or some other Collection object in my application. I am not able to decide which collection object will meet my requirements. Can anyone please help me which collection construct can I use?

The Considerations are,
1.Should be readale as fast as possible
2.It should able to grow(upto 1 million or more) and not slow down the search process.
3. Should be thread safe.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
You only need a Map if you need your collection to map from keys to values. If you just have a collection of objects, you should use a List or a Set.

So, does your application require mapping keys to values?

If you need good performance with a lot of entries, then you need to know how you are going to access it. A hashed collection (HashMap or HashSet) is good for random access, providing the objects you will be storing have proper implementations of hashCode() and equals(). An ArrayList is good for random access, bad for adding/removing in the middle. A LinkedList is good for adding and removing, but bad for random access.

Thread safety may be as simple as synchronising all access to the collection. However, if the collection is tied in to other data structures, as is very common, that won't be enough.


Basically, you have not told anything like enough information to make a choice.

One thing I can say is that you should never use Hashtable or Vector in new code. These old classes are superceded by HashMap and ArrayList.

Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Manimekala Velautham

Joined: May 31, 2006
Posts: 16
Thanks for your suggestions.

Yes.The Application requires a collection object that maps keys to values.
It is a servlet application, which will have one collection object as a in memory database. The requests to this servlet will have the key to get the value. The response is a xml file with the corresponding value. The keys and values all are String objects. It is a ramdom search. This collection object should be recreated at specified intervals by reading a text file which will have the keys and values comma separated.
Murali Nanchala
Ranch Hand

Joined: Mar 14, 2001
Posts: 74
Then you can use a HashMap object AND synchronize it.

But if you intend to put million items in the collection, I suggest you re-think your approach. It is definitely going to slow down with increase in size. Especially after synchronization.

What would be your servlet's client [traffic] volume?
[ November 29, 2007: Message edited by: Murali Nanchala ]

"It is almost always answered in the API" - Murali Nanchala
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
You could use a ConcurrentHashMap, perhaps. That's optimised for multi-threading.

However, I can think of another approach that might suit your application very well.

Use an unsynchronised HashMap, and keep your global reference to it in a field that is declared "volatile".

When periodically re-reading the data, do so in a separate thread and create a new unsynchronised HashMap. When you have finished filling in that HashMap, change the volatile field to point to the new map.

That way, there's no synchronisation at all, so it should scale well, from that point of view.

If the map keys have good hashCode() and equals() implementations, then the HashMap should perform well, even with huge numbers of entries.

A final refinement would be to wrap the HashMap in Collections.unmodifiableMap(), before storing it in the volatile field. That would ensure that no unintended changes could be applied (e.g. by a later maintainance programmer who doesn't realise it's a read-only map).
[ November 30, 2007: Message edited by: Peter Chase ]
I agree. Here's the link:
subject: Which Java Collection construct will be suitable ?
It's not a secret anymore!