Garbage Collection (GC) es un proceso automático de gestión de memoria que identifica y libera bloques de memoria que han sido asignados dinámicamente pero que ya no son accesibles o referenciados por el programa en ejecución. Su objetivo principal es prevenir fugas de memoria y reducir la complejidad asociada con la gestión manual de la memoria. Los algoritmos de GC operan en ciclos, marcando objetos accesibles desde las raíces del programa y luego 'barriendo' (sweeping) aquellos que no fueron marcados, considerándolos 'basura' (garbage). Existen diversas estrategias de GC, como 'mark-and-sweep', 'copying collection' (ej. Cheney's algorithm), 'generational GC' (que optimiza al asumir que la mayoría de los objetos mueren jóvenes), y 'concurrent GC' (que intenta minimizar las pausas de la aplicación).
La implementación de Garbage Collection es fundamental en muchos lenguajes de programación y entornos de ejecución modernos. Ejemplos prominentes incluyen la Java Virtual Machine (JVM) con sus recolectores como G1, ParallelGC, y ZGC; el Common Language Runtime (CLR) de .NET; el entorno de ejecución de Go; y JavaScript (a través de los motores V8, SpiderMonkey, etc.). Otros lenguajes como Python y Ruby también incorporan GC, a menudo combinando 'reference counting' con un recolector de ciclo para manejar referencias circulares. En el ámbito de las bases de datos, sistemas como Apache Cassandra utilizan GC para limpiar datos obsoletos o eliminados, aunque esto se refiere más a la gestión de almacenamiento que a la memoria de la aplicación.
Para un Arquitecto de Sistemas, la elección y configuración del Garbage Collector es una decisión crítica con implicaciones directas en el rendimiento, la latencia y la estabilidad de una aplicación. Un GC ineficiente puede introducir pausas significativas ('stop-the-world pauses') que impactan la experiencia del usuario y los SLAs, especialmente en sistemas de alta concurrencia o baja latencia. Comprender los trade-offs entre diferentes algoritmos de GC (ej. mayor throughput vs. menor latencia, uso de memoria vs. tiempo de CPU) es esencial. Un arquitecto debe considerar factores como el tamaño del heap, el patrón de asignación de objetos de la aplicación, y los requisitos de latencia para seleccionar el GC adecuado y ajustar sus parámetros, o incluso diseñar la aplicación para minimizar la creación de objetos efímeros y reducir la carga del recolector.