Answer.

Background:

In Rust, one of the frequently used collections is HashMap — an associative array implemented by a hash table. The difference in the Rust implementation is a strict adherence to ownership and memory safety rules, as well as thread-safety only under certain conditions.

The Problem:

Unlike other languages with garbage collection, in Rust any operations with HashMap (adding, retrieving, modifying) require compliance with ownership rules. For example, you cannot modify the collection while having active references to its contents. There is also a question of ownership during insertion: elements can either be moved or cloned. Additionally, there is a risk of data race during concurrent access.

The Solution:

Keys and values are moved into the HashMap upon insertion (or copied if they implement Copy), remaining under the control of the collection.
Retrieval by key returns a reference or Option, for mutable access — through the get_mut or entry API.
For safe concurrent access, HashMap should be wrapped in synchronization wrappers (Mutex, RwLock) or use special concurrent hashmaps from crates.

Code Example:

use std::collections::HashMap;

fn main() {
    let mut map = HashMap::new();
    map.insert("key", 10);
    if let Some(value) = map.get_mut("key") {
        *value += 1;
    }
    println!("{:?}", map.get("key"));
}

Key Features:

HashMap requires transferring ownership of its elements, which affects lifetime and mutability.
When modifying or retrieving a value via get_mut, the structure of the map itself cannot be changed (inserting or deleting keys).
It is not thread-safe by default, requiring additional synchronization for that.

Trick Questions.

Can there be simultaneous access to multiple elements of HashMap through different references?

No, Rust does not permit this through the standard API: iteration with modification is possible only with an exclusive reference to the entire HashMap.

What happens if you try to get a mutable and an immutable reference to the same element?

The compiler will raise an error for violating borrow checker rules: you cannot mix mutable and immutable borrowing of the same value.

Does the entry() API work only for inserting new elements?

No, you can also access it for modifying existing values via the Entry API, not just for insertion.

map.entry("key").and_modify(|v| *v += 1).or_insert(0);

Common Mistakes and Anti-Patterns

Storing references to HashMap values outside the lifetime of the map, leading to dangling references.
Simultaneous modification and reading without Mutex or RwLock in a multithreaded environment.
Incorrect use of Entry API solely as an alternative to insert, rather than as a means of atomic operation with contents.

Real-Life Example

Negative Case

Providing references to HashMap values in global variables without lifetime guarantees of the map.

Pros:

High access speed.

Cons:

Dangling references, UB, complicated bug debugging.

Positive Case

Wrapping HashMap in Arc<Mutex<_>> for use across multiple threads.