Necesitas un trabajo nocturno que lea veinte millones de filas, las transforme y escriba resultados. ¿Cómo lo escribes para que no agote la memoria?

Haz streaming en vez de materializar: lee con un cursor desplazable o con paginación por clave, pon un fetch size para que el driver no lo bufferice todo, y procesa en trozos con un commit por trozo. Si usas JPA, limpia el contexto de persistencia entre trozos o usa una sesión sin estado, o si no cada entidad se queda en la caché de primer nivel. Agrupa las escrituras con batching de JDBC, y haz el trabajo reiniciable desde su último trozo confirmado.

La regla central es que ningún paso sostiene veinte millones de nada. Leo con paginación por clave sobre la clave primaria, o con un cursor desplazable con un fetch size explícito, y vale la pena saber que algunos drivers lo ignoran y bufferizan el conjunto de resultados entero salvo que además corras dentro de una transacción con autocommit desactivado, algo que la gente descubre por las malas cuando el heap se llena antes de procesar nada. Luego proceso en trozos de unos miles, escribo con batching de JDBC para que sea un viaje por trozo y no por fila, y confirmo por trozo. Con JPA la trampa extra es el contexto de persistencia: cada entidad leída queda gestionada, así que la memoria crece y los flush se vuelven más lentos según el dirty checking recorre más objetos. Lo limpio en cada trozo o uso una sesión sin estado. La reiniciabilidad importa tanto como la memoria, así que el trabajo registra la última clave confirmada, lo que significa que un fallo en la fila dieciocho millones reanuda en vez de empezar de nuevo. Y lo limito, porque un batch que satura la base de datos a las dos de la mañana sigue golpeando a quien esté despierto.