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.
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.
Joined: May 31, 2006
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.
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 ]