dashmap: a sharded HashMap so you can stop wrapping it in an RwLock

Every method takes &self, which is the whole API decision

The README states the design goal plainly: DashMap tries to be very simple to use and to be a direct replacement for `RwLock<HashMap<K, V>>`. To accomplish that, all methods take `&self` instead of modifying methods taking `&mut self`, and the consequence is spelled out: you can put a DashMap in an `Arc<T>` and share it between threads while still being able to modify it.

That is a narrower and more honest goal than being the fastest concurrent map. The change from a read-write-locked map to a DashMap is meant to be mechanical, because the surface deliberately resembles `std::collections::HashMap` with slight changes to handle concurrency. The description in `Cargo.toml` is blunter, blazing fast concurrent HashMap for Rust, and the README says it puts great effort into performance and aims to be as fast as possible.

What you get underneath is sharding. There is no global map lock; the map is divided into shards, each protected by its own lock, which is why concurrent writes to different keys do not queue behind each other. The dependency list in `Cargo.toml` names the pieces: `lock_api` for the locking primitives and `parking_lot_core` for the parking-lot implementation. The `raw-api` crate feature exists precisely because the shard layout is otherwise an implementation detail, and it exposes it as an unstable raw-shard API for the cases where the default is wrong.

The feature flags, and what Cargo.toml documents that the README does not

The README lists five cargo features: `serde` for serde support, `raw-api` for the unstable raw-shard API, `rayon` for rayon support, `inline-more` which forwards to the `inline-more` feature of `hashbrown` and carries the usual tradeoffs of possibly excessive inlining, and `arbitrary` for the `arbitrary` crate.

The manifest in the repository tells a slightly different story, and the differences are worth knowing:

[features]
all = ["raw-api", "typesize", "serde", "rayon", "arbitrary"]
raw-api = []
typesize = ["dep:typesize"]
inline-more = ["hashbrown/inline-more"]

There is a `typesize` feature that the README does not mention, which pulls in the `typesize` dependency and enables it with the `hashbrown_15` feature. There is also an `all` feature that enables everything except `inline-more`, and it is what the docs.rs metadata requests:

[package.metadata.docs.rs]
features = ["all"]

Reading `Cargo.toml` rather than the README for the feature list is the safer habit here, since the README's list is a subset.

The dependency versions give a sense of how tightly this tracks the ecosystem: `hashbrown` at 0.15.2 with default features disabled, `lock_api` 0.4.12, `parking_lot_core` 0.9.10, `crossbeam-utils` 0.8, `cfg-if` 1.0.0, and `equivalent` 1.0.1. The `equivalent` crate replaced `Borrow` for key equality checks in the 7.0.0 release candidates, which is a small change with real semantic consequences for custom key types.

Version strategy: a 7.0 release candidate, a 6.x MSRV bump, and a 1.70 claim

Here is the part of the project where the documentation and the repository disagree, so it is worth reading all three sources before you pin anything.

The README says the current MSRV is 1.70 and is not changed in patch releases, and adds that you can pin a minor version for perfect stability, while noting that dashmap always stays at least 1 year behind the current stable release. `Cargo.toml` agrees on the floor, declaring `rust-version = "1.70"`, and declares the package version as 7.0.0-rc2.

The releases tell a different story about the floor. Version 6.2.1, published on 2026-05-17, is described as an interim maintenance release for the existing v6 branch before v7 can be released, and it bumps the MSRV to 1.85 while updating dependencies to their latest versions. So the README's 1.70 statement describes the 7.0 line as declared in the manifest, while the newest actually published release moved the floor upward.

The 7.0.0 release candidates carry an explicit warning that they do not fall under semantic versioning guarantees and are intended to permit early access via crates.io, testing and discussing desired changes. Their changelogs are commit logs rather than prose summaries, which is useful if you want to audit the change. Notable entries include the upgrade to hashbrown 0.15 with the HashTable API, removal of `SharedValue`, removal of misc unsafe code, replacing `once_cell::sync::OnceCell` with `std::sync::OnceLock`, setting the README contents as the crate docs, and a fix for a downgrade.

The practical reading is that this is a maintainer running a stable 6.x line as a bridge while 7.0 stabilizes. If your build environment cannot take a 1.85 floor, the 6.x line is the one to stay on, and you should check which MSRV your chosen 6.x tag actually declares rather than trusting the README's number.

What sharding buys, and what it does not

The performance claim in the README is pointed at a benchmark suite rather than asserted standalone: a comprehensive benchmark suite including DashMap can be found in the author's `conc-map-bench` repository. That is a separate project, so the numbers are reproducible but not in this repository, and they compare against other concurrent maps rather than against `RwLock<HashMap<K, V>>` specifically.

The mechanism is worth understanding before you adopt it, because it determines when sharding helps and when it does not. Multiple threads reading and writing distinct keys proceed in parallel across shards. Two threads writing the same key serialize on that key's shard, and heavily skewed key distributions concentrate contention on a small number of shards. An `RwLock<HashMap>` inverts that pattern: reads are cheap in parallel, writes are exclusive and total. If your workload is read-heavy and write-rare, the `RwLock` version may already be adequate, which is exactly the baseline the README claims to be replacing.

Iteration is the other thing to think about. A map made of independently locked shards cannot hand you a consistent snapshot without locking everything, so an iterator over a `DashMap` sees a moving target. That is usually fine for aggregating or filtering, and a problem if you are computing a multi-step invariant across the whole map.

The tree is small, which is a good sign for review: `Cargo.toml`, `Cargo.lock`, `LICENSE`, `README.md`, `rust-toolchain.toml`, and a `src/` directory. A pinned toolchain file and a committed lockfile mean the CI environment is reproducible even when the MSRV policy changes between lines.

Maintenance reality, license, and when to choose something else

The repository is not archived, MIT licensed, and the last push was on 2026-05-17, the same day as the 6.2.1 release. There is no homepage field, so docs.rs is the reference documentation and the README links it with a badge.

The contributing section is unusually candid and is worth reading before you file anything. DashMap gladly accepts contributions, issues and pull requests are welcome, but the maintainer says they will take a look as soon as there is time, and states plainly that they are not yet paid to work on open source, which means their time is limited and the work comes after their personal life. That is a polite warning that a large refactor is unlikely to land quickly, and it is a factor when you are deciding whether a crate is a good foundation for a component you own.

The special-thanks list names six people, including Conrad Ludgate, whose branch for `rwlock-detached` merged into the 7.0 line. Several of those names are recognisable from the Rust audio and demoscene communities, which is a decent proxy for how the contributor base skews.

Where dashmap is the wrong tool is straightforward. If you need transactions across several keys, sharded locks do not give you that; a database or a single exclusive lock does. If your workload is genuinely write-heavy on one hot key, sharding buys nothing. If you need a consistent snapshot, iterate a copy. And if you need an ordered map, this is not it, since it is a hash map with no ordering guarantee. The honest comparison is not against the standard library map, which is not concurrent at all, but against your current `RwLock<HashMap>` and against crates that expose the shard API as stable rather than unstable.

Editorial conclusion

dashmap earns its place by being the least interesting possible answer to a real problem. If your code has an `RwLock<HashMap<K, V>>` that is read far more often than it is written, replacing it with a `DashMap` inside an `Arc` is a small diff with the API shaped so nothing has to change at the call site. What you accept is per-shard locking rather than a single lock, which means writers to the same shard still contend and iteration is only weakly consistent. The version situation is the part to sort out first: `Cargo.toml` declares 7.0.0-rc2 while the newest published release is the 6.x maintenance tag, and the README's MSRV statement of 1.70 does not match the 1.85 bump in the 6.2.1 notes. Decide whether you want the release candidate or the stable 6.x line before you add it to a lockfile.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. xacrimon/dashmap on GitHub