Un servicio se reinicia cada pocos días con un OutOfMemoryError. ¿Cómo encuentras la causa?

Primero lee el mensaje, porque heap space, metaspace, buffer directo y GC overhead limit exceeded apuntan a causas muy distintas. Arranca con volcado de heap ante out of memory para capturar el estado en el momento del fallo, luego abre el volcado en un analizador de memoria y mira el árbol de dominadores para ver qué retiene más. Compara volcados a lo largo del tiempo para separar una fuga real de un conjunto de trabajo que simplemente es mayor que el heap.

La variante importa. Java heap space significa que los objetos vivos llenan de verdad el heap, metaspace significa que se cargan clases y nunca se liberan, y un error de buffer directo apunta a NIO o a una librería nativa más que a mis objetos. Así que leo eso primero, luego me aseguro de que la JVM corre con volcado de heap ante out of memory y con una ruta en un volumen que sobreviva al reinicio, porque adivinar sin un volcado gasta días. Con el volcado miro el tamaño retenido y no el superficial, y el árbol de dominadores suele señalar al culpable en un par de minutos. Lo que encuentro de verdad es repetitivo: un mapa usado como caché sin desalojo, un thread local puesto en un hilo de pool y nunca limpiado, así que vive tanto como el pool, o un método de repositorio que devuelve todas las filas porque alguien quitó la paginación. También reviso los logs de recolección para ver si el heap subía de forma sostenida o daba picos en peticiones concretas. El arreglo es acotar algo, una caché con tamaño máximo y expiración, o hacer la consulta en streaming, y luego vigilo el conjunto vivo durante una semana para confirmar que queda plano.