Respuesta.

Historia del tema:

En Rust, una de las colecciones más utilizadas es HashMap — un diccionario implementado con una tabla hash. La diferencia en la implementación de Rust es el estricto cumplimiento de las reglas de propiedad y seguridad de memoria, así como la seguridad de hilos solo bajo ciertas condiciones.

Problema:

A diferencia de otros lenguajes con recolección de basura, en Rust cualquier operación con HashMap (adición, extracción, modificación) requiere seguir las reglas de propiedad. Por ejemplo, no se puede modificar la colección si hay referencias activas a su contenido. También hay una cuestión de propiedad al insertar: los elementos se mueven o se clonan. Y en el acceso concurrente hay riesgo de condiciones de carrera.

Solución:

Las claves y los valores se mueven a HashMap al insertar (o se copian, si son Copy), permaneciendo bajo el control de la colección.
La extracción por clave devuelve una referencia u Option, para acceso mutable — a través de get_mut o entry API.
Para un acceso concurrente seguro, HashMap debe colocarse en envolturas de sincronización (Mutex, RwLock) o utilizar mapas hash concurrentes especiales de crates.

Ejemplo de código:

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"));
}

Características clave:

HashMap requiere la transferencia de propiedad de los elementos, lo que afecta la duración y la mutabilidad.
Al modificar o extraer un valor a través de get_mut, no se puede modificar la estructura del mapa en sí (insertar o eliminar claves).
No es seguro para hilos por defecto; se requiere sincronización adicional.

Preguntas capciosas.

¿Puede haber acceso concurrente a varios elementos de HashMap a través de diferentes referencias?

No, Rust no lo permite a través de la API estándar: la iteración con modificación solo es posible con una referencia exclusiva a todo el HashMap.

¿Qué pasará si se intenta obtener una referencia mutable y una no mutable al mismo elemento?

El compilador dará un error por violar las reglas del verificador de préstamos: no se puede combinar un préstamo mutable y uno no mutable del mismo valor.

¿Funciona la API entry() solo para insertar nuevos elementos?

No, a través de la API Entry también se puede acceder para modificar un valor existente, no solo para insertar.

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

Errores comunes y anti-patrones

Almacenar referencias a valores de HashMap fuera del tiempo de vida del mapa, lo que lleva a referencias colgantes.
Modificación y lectura simultáneas sin Mutex o RwLock en un entorno de múltiples hilos.
Uso incorrecto de la API Entry solo como alternativa a insert, en lugar de como medio atómico para trabajar con el contenido.

Ejemplo de la vida real

Caso negativo

Emitir referencias a valores de HashMap en variables globales sin garantía del tiempo de vida del mapa.

Pros:

Alta velocidad de acceso.

Contras:

Referencias colgantes, UB, bugs difíciles de depurar.

Caso positivo

Encapsular HashMap en Arc<Mutex<_>> para su uso desde varios hilos.