Hash tables are (usually) faster to do all sorts of operations than tree based maps, as most operations become a simple function to calculate a tree’s hash followed by a table lookup. Of course, they’re unordered, so if you need to iterate in order, or find all keys < a certain value, or things like that, tree maps can be better for your algorithm.

Also, TreeMap uses a red-black tree to implement the map, which is a basic type of binary tree. Depending on the data you’d like to store, other kinds of tree-based maps can have better performance characteristics. A map based on a Splay Tree[1] speeds up repeated accesses, so it could perform well if you had keys that were cheap to compute an ordering but expensive to compute a hash, and your access pattern has good temporal locality.

[1] https://en.wikipedia.org/wiki/Splay_tree

Simple answer: Use tree if you need range access or to get elements ordered by key, and use hash otherwise.

More nuance: - hashmap may be resized if it's over capacity, the resize may cause a latency spike.

- hashmap is essentially a single random memory access, tree is a couple of accesses but they are not random

- tree is a bit like a sorted array with fast inserts/deletes. Some trees, like leveldb, are in fact sorted arrays (plus some tricks, of course)

- if you use b-tree, you are more memory-efficient (but less cpu efficient), and access to nearby elements is almost free. That's why b-trees are used to store data in a permanent memory

- there are many other tree variants, each of them with different trade-off