Daemon vs non-daemon: la regla de salida del JVM que genera fugas
Un booleano que decide si el proceso vive o muere, y el error que lo convierte en una fuga de memoria.
La diferencia entre hilos daemon y non-daemon en Java no es un detalle menor, sino la regla fundamental que determina cuándo el JVM decide cerrar el proceso. El motor de ejecución tiene una única condición de salida: termina cuando todos los hilos non-daemon han finalizado. Los hilos daemon se ignoran por completo en ese cálculo. Si el último hilo no daemon se apaga, el JVM mata al instante cualquier hilo daemon que esté en ejecución, en medio de un bucle, una lectura o una escritura, sin más preámbulos.
La decisión práctica
El criterio para elegir uno u otro es estrictamente operativo. Si la pérdida del trabajo en curso supusiera un problema real para el usuario o la integridad de los datos, el hilo debe ser non-daemon. Es el caso de las transacciones financieras, las escrituras en almacenamiento persistente, las solicitudes de red iniciadas por el cliente o cualquier tarea crítica. Forzar el cierre a medias corrupta el estado o deja operaciones colgadas.
Por el contrario, si el trabajo es opcional, de mejor esfuerzo o puramente de fondo, debe ser daemon. Un ejemplo claro es un uploader de analítica que envía lotes de eventos. Si el usuario cierra la aplicación, un hilo non-daemon obligaría al JVM a esperar a que termine la subida, manteniendo el proceso activo, consumiendo batería y bloqueando la salida. Con un hilo daemon, el proceso muere limpiamente; se pierde el lote en curso, lo cual es un coste aceptable frente a la penalización de mantener la app abierta.
Lo mismo aplica a los heartbeat de telemetría o los precalentadores de caché. Si la aplicación principal muere, esos hilos son irrelevantes y deben ser eliminados para no dejar procesos zombis que el sistema operativo tenga que matar a la fuerza después de minutos de inactividad.
El matiz en Android
En entornos móviles, la situación es más compleja. El runtime de Android gestiona la vida del proceso principalmente a través del ciclo de vida de los componentes (Activities, Services) y no por el conteo de hilos. Sin embargo, un hilo non-daemon que persiste tras la destrucción de una Activity puede acaparar referencias al contexto y la jerarquía de vistas, impidiendo que el Garbage Collector recicle la memoria. Marcar como daemon a los pools de hilos cuyo trabajo es desechable ayuda al sistema a limpiar la memoria de forma más predecible, evitándole fugas que degraden el rendimiento de la app con el tiempo.
La pregunta que debe responderse antes de lanzar cualquier hilo en segundo plano es sencilla: ¿es crítico que esta tarea termine? Si la respuesta es sí, protege la vida del proceso. Si es no, deja que muera con el resto para no cargar el sistema con tareas residuales.
