Cuando la aplicación se cuelga

Las cinco causas

Y la observación práctica de la tercera columna: mirar el uso de procesador distingue mucho. Con procesador al máximo hay un bucle; con procesador a cero hay una espera o un abrazo mortal.

Distinguir desde fuera

Cuando pasa en la máquina de un usuario, tres preguntas que acotan bastante:

• ¿El ventilador está a tope? Procesador ocupado: causas 1 o 2 calculando.
• ¿Se desbloquea sola pasado un rato? Causa 4 casi seguro: algo tenía un tiempo de espera largo.
• ¿Va lento todo el ordenador o solo esta aplicación? Causa 5 si es todo.

Y una cuarta, muy útil: ¿el icono de bandeja sigue respondiendo? Si la ventana está muerta y el menú de bandeja funciona, el core está vivo y el problema es del frontend — causa 1.

Dejar rastro

Lo que convierte un cuelgue en algo diagnosticable, y son tres cosas:

El segundo es el más valioso y el menos común: un aviso automático de «el hilo principal lleva cinco segundos bloqueado» convierte la causa más frecuente en algo que se detecta solo, incluso en desarrollo, antes de que llegue a nadie.

Prevenir las que se pueden

Tres de las cinco se previenen por construcción, y las tres ya aparecieron:

• La causa 2 con la disciplina del nivel 42.1: nada bloqueante fuera de un hilo pensado para eso. Y el vigilante la detecta si se cuela.
• La causa 4 con límites de tiempo en todo: peticiones —nivel 48.5—, procesos —nivel 47.1—, llamadas al almacén —nivel 37.3—. Una espera sin límite es un cuelgue esperando a ocurrir.
• Y la causa 3 con un orden fijo de adquisición de cerrojos, y no manteniendo un cerrojo mientras se espera a otra cosa.

La causa 1 es del frontend y se previene igual que en cualquier página: trabajo largo en trozos, listas virtualizadas, nada de bucles de diez mil iteraciones síncronos.