Rule of thumb for choosing an implementation of a Java Collection?

I've always made those decisions on a case by case basis, depending on the use case, such as:

  • Do I need the ordering to remain?
  • Will I have null key/values? Dups?
  • Will it be accessed by multiple threads
  • Do I need a key/value pair
  • Will I need random access?

And then I break out my handy 5th edition Java in a Nutshell and compare the ~20 or so options. It has nice little tables in Chapter five to help one figure out what is appropriate.

Ok, maybe if I know off the cuff that a simple ArrayList or HashSet will do the trick I won't look it all up. ;) but if there is anything remotely complex about my indended use, you bet I'm in the book. BTW, I though Vector is supposed to be 'old hat'--I've not used on in years.


I really like this cheat sheet from Sergiy Kovalchuk's blog entry, but unfortunately it is offline. However, the Wayback Machine has a historical copy:

Java Map/Collection Cheat Sheet

More detailed was Alexander Zagniotov's flowchart, also offline therefor also a historical copy of the blog:

Alexander Zaniotov's flowchart for choosing Collection implementations

Excerpt from the blog on concerns raised in comments: "This cheat sheet doesn't include rarely used classes like WeakHashMap, LinkedList, etc. because they are designed for very specific or exotic tasks and shouldn't be chosen in 99% cases."


I'll assume you know the difference between a List, Set and Map from the above answers. Why you would choose between their implementing classes is another thing. For example:

List:

  1. ArrayList is quick on retrieving, but slow on inserting. It's good for an implementation that reads a lot but doesn't insert/remove a lot. It keeps its data in one continuous block of memory, so every time it needs to expand, it copies the whole array.
  2. LinkedList is slow on retrieving, but quick on inserting. It's good for an implementation that inserts/removes a lot but doesn't read a lot. It doesn't keep the entire array in one continuous block of memory.

Set:

  1. HashSet doesn't guarantee the order of iteration, and therefore is fastest of the sets. It has high overhead and is slower than ArrayList, so you shouldn't use it except for a large amount of data when its hashing speed becomes a factor.
  2. TreeSet keeps the data ordered, therefore is slower than HashSet.

Map: The performance and behavior of HashMap and TreeMap are parallel to the Set implementations.

Vector and Hashtable should not be used. They are synchronized implementations, before the release of the new Collection hierarchy, thus slow. If synchronization is needed, use Collections.synchronizedCollection().


Theoretically there are useful Big-Oh tradeoffs, but in practice these almost never matter.

In real-world benchmarks, ArrayList out-performs LinkedList even with big lists and with operations like "lots of insertions near the front." Academics ignore the fact that real algorithms have constant factors that can overwhelm the asymptotic curve. For example, linked-lists require an additional object allocation for every node, meaning slower to create a node and vastly worse memory-access characteristics.

My rule is:

  1. Always start with ArrayList and HashSet and HashMap (i.e. not LinkedList or TreeMap).
  2. Type declarations should always be an interface (i.e. List, Set, Map) so if a profiler or code review proves otherwise you can change the implementation without breaking anything.