En entornos de producción, es común encontrarse con situaciones donde la ocupación de recursos RAM crece progresivamente sin mostrar signos de estabilización. En estos casos, reiniciar el servicio solo ofrece una solución temporal antes de que el consumo se eleve nuevamente. Para diagnosticar la causa raíz cuando el proceso mantiene gigabytes de memoria asignada, es necesario recurrir a herramientas de análisis forense a nivel de sistema.

Obtención del volcado de memoria

El primer paso para investigar este comportamiento consiste en generar un archivo de descarga (dump) del estado actual del proceso. Identificando el identificador del proceso mediante utilidades del sistema como ps o monitores de tareas avanzados, ejecutamos la siguiente instrucción con permisos elevados:

createdump --full <ID_DEL_PROCESO>

Este comando genera un archivo binario detallado almacenado típicamente en directorios temporales, cnoservando toda la información de las pilas de ejecución y los objetos en memoria para su posterior inspección.

Diagnóstico inicial con WinDbg

Al abrir el archivo resultante en Windows Debugger (WinDbg), cargamos las extensiones necesarias (.NET SOS) si no están disponibles automáticamente mediante .load sos. La primera inspección general se realiza evaluando el uso de regiones de dirección:

0:000> !address -summary

La salida proporciona un desglose del mapeo de memoria. Un indicador crítico suele ser la sección MEM_COMMIT, la cual muestra la cantidad real de memoria física reservada. Si observamos valores cercanos a 4 GB bajo esta categoría, debemos profundizar para distinguir entre memoria gestionada por el CLR y memoria no gestionada.

Para verificar el consumo específico del Runtime de .NET, empleamos el comando de estadísticas de montón:

0:000> !sos eeheap -gc

Este reporte detalla el tamaño total consumido por el CLR. Si los valores superan significativamente lo esperado para la carga de trabajo, confirma que el problema reside dentro del ecosistema de gestión automática de memoria. A continuación, analizamos la distribución de objetos utilizando:

0:000> !sos dumpheap -stat

Esta utilidad lista todos los tipos de objeto presentes, ordenados por el volumen de memoria ocupado. Es frecuente encontrar que tipos básicos como cadenas o enteros dominan levemente, pero en escenarios de fuga, tipos de delegados o manejadores específicos suelen destacar anómalamente. En nuestro caso, se detectaron millones de instancias de System.EventHandler relacionadas con eventos de conexión de bases de datos distribuidas, consumiendo cientos de megabytes acumuladamente.

Rastreo de Referencias de Memoria

Para comprender por qué estos objetos persisten sin ser recolectados, seleccionamos una instancia representativa y utilizamos la herramienta de rastreo de raíces de GC:

0:000> !sos gcroot <DIRECCION_MEMORIA_OBJETO>

La salida revela la cadena de referencias que impide que el Recolector de Basura libere el recurso. En este incidente específico, todos los manejadores de eventos estaban vinculados directamente a una instancia estática de ConnectionMultiplexer de un cliente Redis popular. Esto indicaba que cada vez que se accedía al servicio de caché, se suscribían nuevos observadores de eventos sobre el mismo canal de comunicación base.

Localización del Código Problemático

Identificar el origen exacto requiere vincular las direcciones de memoria estáticas con el código fuente compilado. Primero, localizamos la ubicación del puntero estático que retiene el multiplexor de conexiones mediante búsquedas de secuencia de bytes en el espacio de direcciones virtual. Una vez identificada la dirección de inicio del segmento de código responsable, podemos desensamblar la función asociada:

0:000> !u <DIRECCION_INSTRUCCION>

El desensamblador muestra la pila de llamadas JITeada, permitiendo identificar el método propiedad que gestiona el singleton del cliente de datos. Mediante comandos auxiliares para mapear módulos (!md) y archivos (lm), determinamos la librería DLL específica involucrada y procedemos a revisar la implementación lógica correspondiente.

El error común radica en la estructura del acceso al singleton. Al mover la inscripción de eventos fuera del bloque de inicialización estricta, cada solicitud dispara una nueva suscripción. Abajo se presenta una versión refactorizada del patrón incorrecto corregida para evitar la acumulación de delegados.

Implementación Corregida

A continuación, mostramos cómo debe estructurarse la fábrica de clientes para garantizar que los eventos solo se registren durante la creación inicial del recurso compartido:

namespace Infraestructura.Almacenamiento.Datos
{
    public class ServicioCacheRedistribuida
    {
        private static ConexionPersistente _canalUnico = null;
        private static readonly objetoBloqueo Sincronizacion = new objetoBloqueo();

        /// <summary>
        /// Provee acceso al canal de comunicación persistente.
        /// Garantiza que los observadores se adjunten únicamente tras la creación.
        /// </summary>
        public static ConexionPersistente ObtenerCanal
        {
            get
            {
                // Validación de configuración previa
                if (string.IsNullOrEmpty(Configuracion.ClaveConex))
                {
                    throw new ExcepcionCritica("Parámetro de enlace ausente");
                }

                // Verificación lazy-load inicial
                if (_canalUnico == null)
                {
                    lock (Sincronizacion)
                    {
                        // Revalidación en doble comprobación
                        if (_canalUnico == null || !_canalUnico.EstaActivo)
                        {
                            var opciones = OpcionesConexion.Construir(Configuracion.ClaveConex);
                            opciones.TimeoutEstablecimiento = TimeSpan.FromSeconds(10);
                            opciones.TimeoutOperacion = TimeSpan.FromSeconds(15);

                            _canalUnico = ConexionPersistente.Establecer(opciones);

                            // CORRECCIÓN: Registro de listeners dentro del bloque de construcción
                            // Esto evita nuevas instancias de Delegate en accesos subsiguientes
                            SuscribirseEventosMonitorio(_canalUnico);
                        }
                    }
                }

                return _canalUnico;
            }
        }

        private static void SuscribirseEventosMonitorio(ConexionPersistente receptor)
        {
            receptor.EnlacePerdido += ManejarCaídaEnlace;
            receptor.EnlaceRecuperado += ManejarRestauracionEnlace;
            receptor.MensajeError += RegistrarDiagnosticos;
            receptor.CambioConfiguracion += AuditarCambiosEstado;
            receptor.DesplazamientoHash += NotificarMovimientoDatos;
            receptor.ErrorInterno += GestionarExcepcionesSistema;
        }

        private static void ManejarCaídaEnlace(object remitente, ArgumentosEventos args)
        {
            Logger.Vigilancia($"Pérdida de enlace detectada: {args.Origen}");
        }
        
        private static void ManejarRestauracionEnlace(object remitente, ArgumentosEventos args)
        {
            Logger.Vigilancia("Conexión restablecida exitosamente");
        }
    }
}

La clave fundamental radica en encapsular la lógica de subscripción dentro del método privado auxiliar SuscribirseEventosMonitorio, invocado exclusivamente cuando se instancia por primera vez el objeto _canalUnico. Si estas líneas permanecen en el cuerpo principal del getter, cada lectura disparará la creación de un nuevo objeto delegado, reteniendo referencias vivas en la tabla de manejo de eventos del multiplexor. Esta práctica asegura que la cantidad de objetos manejadores se mantenga constante independientemente de la frecuencia de acceso a la propiedad.