High Performance is elusive, not because you can't reach it, but because the sacrifices you must make to get there. Dashmap, a self declared high perf map, hands you a footgun, the worst kind of footgun in a concurrent hashmap. It doesn't matter what experience level you are, you will shoot yourself in the foot.
The footgun is in the form of a shard lock whenever you grab a value using some key. What stops you from trying to write to a key (not that you know of) in that same thread where you have the shard lock? It's not re-entrant so you are dead locked on yourself. You won't know this until it happens in production, you are lucky if you surface it during a test.
I used dashmap in my clustering library and wondered why peers would lock up upon discovery process at times, turns out dashmap was the issue. Holding the shard lock because you did a simple get operation and held onto the value while trying to write back to the map on another key while another peer is holds the write lock to the key and trying to gain read access to the designated peer. Yeah, why the hell did I even use dashmap for this? To avoid the Arc<RWLock<HashMap<X>>> abomination i guess.
Never the less, I am obliterating dashmap from all of my libraries and applications. Fibre Cache (GitHub, Crates.io), set to unbounded and null policy, is high performance and more than good enough for all dashmap cases without any footguns. Fibre Cache can be used as a high performance concurrent hash map with same semantics just like in Java's Concurrent Hashmap and Caching libraries.
I would argue dashmap is badly named, Fibre Cache is also badly named because it sounds like a Caching application, "Fibre ConcurrentMap" with caching semantics is more appropriate. Nevertheless, put Dashmap as a last resort unless you know exactly what you are doing. The scenarios to use dashmap without shooting yourself in the foot are very very limited.