A high-performance, thread-safe concurrent map for Go using sharding to minimize lock contention.
cmap is a concurrent map implementation for the Go programming language that provides thread-safe key-value storage. It solves the problem of Go's built-in map not supporting concurrent reads and writes by using a sharded design to minimize lock contention. This makes it suitable for high-performance scenarios where multiple goroutines need to access shared data frequently.
Go developers building concurrent applications that require high-performance, thread-safe in-memory data storage, such as web servers, caching systems, or real-time data processing pipelines.
Developers choose cmap over alternatives like sync.Map because it offers better performance for non-append-only workloads, thanks to its sharded architecture that reduces lock contention. It also provides a more familiar API and includes generics support for type safety in modern Go versions.
a thread-safe concurrent map for go
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Partitions the map into segments to minimize lock contention, improving performance in high-concurrency scenarios as shown in benchmarks for operations like adversarial alloc and delete.
Provides atomic Store, Load, and Delete methods safe for concurrent use, addressing the built-in map's limitation without data races, similar to sync.Map but with sharding.
Offers a type-safe cmap.Map for Go 1.18+, enhancing code clarity and reducing runtime type assertions, as demonstrated in the README's generics example.
Benchmarks indicate strong results in write-heavy and adversarial scenarios, outperforming sync.Map in tests like LoadOrStoreUnique and adversarial delete.
Mirrors the interface of standard Go maps and sync.Map with intuitive methods, making adoption straightforward, as seen in the usage examples.
In benchmarks, cmap's Range is about 3x slower than sync.Map's (31107 ns/op vs 9317 ns/op), making it inefficient for applications needing frequent full-map iteration.
Shows mixed results in benchmarks, underperforming sync.Map in read-heavy scenarios like LoadMostlyHits and LoadOrStoreCollision, indicating variable suitability depending on workload.
The API is basic with only core operations; lacks built-in methods for atomic updates or conditional logic that might be needed in complex concurrent use cases.
As a third-party package, it introduces dependency management overhead and potential maintenance risks compared to using the standard library's sync.Map.