Historia de la pregunta
Este tema se origina en la evolución de Python desde el conteo de referencias puro hasta un modelo de recolección de basura híbrido introducido en Python 2.0. El problema central surgió cuando los desarrolladores usaron métodos finalizadores (__del__) para gestionar recursos externos como manejadores de archivos o sockets de red. Cuando los objetos con finalizadores formaban referencias circulares, Python no podía determinar un orden de destrucción seguro, lo que podría causar bloqueos o filtraciones de recursos. Esta limitación llevó a la implementación del módulo de recolector de basura cíclico (gc) y al manejo especial de basura "no recolectable".
El problema
Cuando un grupo de objetos forma un ciclo de referencia y al menos uno define un método __del__ personalizado, Python se enfrenta a un dilema de destrucción determinista. El intérprete no puede decidir qué objeto finalizar primero porque el ciclo implica dependencia mutua, y destruir uno podría dejar a otros en un estado no válido. En consecuencia, Python mueve estos objetos a la lista gc.garbage en lugar de liberar su memoria. Este comportamiento persiste en las versiones modernas cuando los finalizadores impiden una recolección segura, lo que lleva a filtraciones de memoria graduales en aplicaciones de larga duración.
La solución
La solución definitiva implica evitar completamente los métodos __del__ a favor de administradores de contexto (with statements) o callbacks de weakref para la limpieza de recursos. Si los finalizadores son inevitables, se deben romper explícitamente los ciclos de referencia antes de que los objetos se vuelvan inalcanzables configurando las variables de instancia a None en los métodos de limpieza. A partir de Python 3.4, el recolector de basura puede recolectar ciclos con finalizadores en muchos casos al ordenar cuidadosamente la finalización, pero la gestión explícita de recursos sigue siendo el patrón más confiable.
import gc class Resource: def __init__(self, name): self.name = name self.peer = None def __del__(self): print(f"Limpiando {self.name}") # Creando un ciclo con finalizadores a = Resource("A") b = Resource("B") a.peer = b b.peer = a # Eliminar referencias externas del a, b gc.collect() print(f"No recolectable: {gc.garbage}") # Puede contener objetos en escenarios complejos
Manteníamos un canal de procesamiento de datos de alto rendimiento donde los objetos Node representaban pasos computacionales en un grafo. Cada nodo contenía referencias a sus vecinos y contenía un método __del__ para liberar manejadores de memoria GPU. Durante cargas de trabajo intensas, observamos un crecimiento monotónico de la memoria a pesar de que no había filtraciones de memoria aparentes en la profilación. La investigación reveló que topologías de grafo complejas creaban ciclos de referencia entre nodos, y la presencia de métodos __del__ impedía que el GC cíclico reclamara estos objetos, causando que se acumularan en gc.garbage hasta la terminación del proceso.
Solución 1: Refactorizar a administradores de contexto
Consideramos reemplazar __del__ con métodos explícitos acquire() y release() llamados a través de administradores de contexto. Este enfoque eliminaría completamente la barrera del finalizador para la recolección de basura y proporcionaría una limpieza de recursos determinista. Sin embargo, esto requería modificar miles de líneas de código de construcción de grafos y ponía en riesgo filtraciones de recursos si los desarrolladores se olvidaban de envolver el uso de nodos en bloques with, especialmente en componentes basados en callbacks legados.
Solución 2: Implementar referencias débiles para los bordes del grafo
Exploramos cambiar todas las referencias de vecino a objetos weakref.ref, lo que permitiría a los nodos ser recolectados de inmediato cuando no quedaran referencias externas, independientemente de la conectividad del grafo. Aunque elegante, esto introdujo una complejidad significativa porque los algoritmos de recorrido del grafo necesitaban verificar constantemente referencias débiles muertas y manejar nodos "fantasmas" transitorios durante la iteración. Este enfoque degradó sustancialmente el rendimiento para nuestro caso de uso y requirió una extensa refactorización de la lógica de recorrido del grafo.
Solución 3: Ruptura explícita del ciclo a través del protocolo de limpieza
Implementamos un método destroy() que configuraba explícitamente self.neighbors = [] y self.gpu_handle = None antes de eliminar nodos del grafo. Esto rompía ciclos de manera determinista mientras mantenía intacta la superficie de la API existente. Elegimos esta solución porque localizó los cambios en la lógica de eliminación de nodos en lugar de dispersar preocupaciones por toda la base de código, y mantuvo la compatibilidad hacia atrás con los algoritmos de grafo existentes.
Resultado
Después de implementar el protocolo de limpieza explícito y agregar afirmaciones para verificar que gc.garbage permaneciera vacío durante las pruebas de CI, el uso de memoria se estabilizó en un nivel constante. El servicio funcionó durante semanas sin la acumulación gradual de memoria anterior. También documentamos el patrón para garantizar que los futuros desarrolladores entendieran la interacción entre finalizadores y referencias cíclicas.
¿Por qué sigue gc.garbage conteniendo objetos en Python 3.4+ incluso cuando los finalizadores están presentes en ciclos?
Si bien Python 3.4 mejoró significativamente el GC cíclico para manejar finalizadores al invocarlos en un orden seguro y limpiar referencias después, los objetos pueden seguir apareciendo en gc.garbage bajo condiciones específicas. Si un método __del__ resucita el objeto al almacenarlo en una variable global, el GC no puede recolectar de forma segura el ciclo y lo mueve a gc.garbage para evitar bucles infinitos. Además, los objetos de extensión C con ranuras tp_dealloc personalizadas que no admiten correctamente el protocolo de GC cíclico pueden ser tratados como no recolectables para evitar bloqueos en el código nativo.
¿Cómo interactúa weakref.ref con un callback con el recolector de basura cíclico cuando el referente es parte de un ciclo no recolectable?
Los candidatos a menudo asumen incorrectamente que los callbacks de referencia débil se ejecutan inmediatamente cuando un objeto se vuelve inalcanzable. En realidad, el callback se ejecuta cuando el objeto es realmente destruido y su memoria se libera. Si un objeto participa en un ciclo de referencia que contiene finalizadores que el GC no puede romper, el objeto permanece asignado en gc.garbage y el callback de referencia débil nunca se ejecuta. Esta distinción es crucial para diseñar sistemas de limpieza de recursos que dependen de callbacks de referencia débiles para la notificación de la destrucción del objeto.
¿Cuál es el problema de la "resurrección" en los métodos __del__ y cómo impide la recolección de basura de referencias circulares?
La resurrección ocurre cuando un método finalizador asigna la instancia moribunda a una variable global o la inserta en un contenedor persistente, reviviéndola efectivamente después de que el GC la haya marcado para la destrucción. En un escenario de referencia circular, si el __del__ de un objeto resucita cualquier objeto en el ciclo, todo el ciclo vuelve a ser alcanzable. El recolector de basura de Python detecta esta anomalía y mueve todo el ciclo a gc.garbage en lugar de intentar resolver el potencial bucle infinito de destrucción y resurrección, dejando la memoria sin reclamar hasta la terminación del proceso.