Reclamación automática de memoria no utilizada en un tiempo de ejecución de programación mediante la identificación y liberación de objetos que ya no son alcanzables desde las raíces del programa o necesarios por la semántica de ejecución.

Principio

La mayoría de los recolectores se apoyan en análisis de alcanzabilidad o vivacidad: los objetos alcanzables desde las raíces (pilas, registros, variables globales) se consideran vivos; los inalcanzables son reclamables. Ideas organizadoras comunes incluyen trazado (mark‑and‑sweep, copia), conteo de referencias, hipótesis generacional y recolección incremental/paralela para equilibrar pausas y rendimiento.

Demostración

Ejemplos: un recolector generacional de la JVM que promueve objetos de vida larga entre generación joven y vieja y efectúa colecciones menores stop‑the‑world; el conteo de referencias de Python con un detector de ciclos auxiliar; recolectores concurrentes que se ejecutan junto a los hilos mutadores para reducir pausas.

Aplicación incorrecta

Asumir que la recolección de basura elimina todos los errores relacionados con la memoria—el GC no puede reclamar objetos alcanzables pero no usados (fugas por referencias persistentes), ni gestiona automáticamente recursos no memorísticos (descriptores de archivo, sockets) salvo que se empleen finalizadores o patrones RAII con cuidado. Tratar las pausas del GC como despreciables en sistemas de tiempo real o sensibles a la latencia es otro error común.

Consecuencia

Un GC bien diseñado reduce errores de gestión manual (uso tras liberación, doble liberación) y aligera la carga del programador, permitiendo abstracciones más seguras. Introduce sobrecarga en tiempo de ejecución, posibles pausas y tiempos de reclamación no deterministas, que requieren gestión en contextos sensibles a la latencia.

Inversión

La gestión manual de memoria (asignación y liberación explícita por el programador o destructores deterministas) proporciona puntos de reclamación previsibles y a menudo menor sobrecarga estable, pero aumenta el riesgo de corrupción de memoria, fugas y errores humanos.

Límite

Se aplica a entornos gestionados y heaps donde el runtime controla la vida útil de los objetos; excluye paginación/intercambio a nivel de SO, basura del sistema de archivos y recuperación de recursos no memorísticos salvo que el runtime los gestione explícitamente. Diferentes estrategias de GC ofrecen distintas garantías (por ejemplo, límites de pausa, rendimiento).

Tensión semántica

Existe tensión entre la recolección automática y la gestión determinista de recursos (RAII/ownership), y entre sistemas de latencia predecible y diseños orientados al rendimiento; las decisiones sobre GC intercambian facilidad de programación por latencia, uso de memoria y coste CPU.

Síntesis

La recolección de basura es el mecanismo de runtime que identifica y recupera automáticamente la memoria que ya no es alcanzable según el conjunto de raíces y el modelo de memoria del programa; integra técnicas de trazado y conteo con estrategias generacionales y concurrentes para balancear pausas, rendimiento y complejidad, mientras deja recursos no memorísticos y fugas alcanzables bajo la responsabilidad del programador.