ProgramaciónDesarrollador Go

¿Qué se necesita saber sobre el trabajo con time.Timer y time.Ticker en Go? ¿Cuáles son las diferencias clave, características de uso correcto y errores comunes al detener/resetearlos?

Supere entrevistas con el asistente de IA Hintsage

Respuesta

El paquete time proporciona dos herramientas útiles: Timer y Ticker.

  • Timer se utiliza para un retraso único (se activa una vez después de un tiempo determinado).
  • Ticker — para eventos periódicos regulares (intervalo).

Diferencias clave:

  • Timer después de activarse "se apaga", debe ser reiniciado (Reset) para usarlo de nuevo.
  • Ticker genera eventos hasta que se detiene explícitamente con el método Stop().

Características de uso:

  • Siempre llame a Stop() en Timer/Ticker al finalizar el trabajo para evitar fugas de recursos.
  • Después de llamar a Stop() en Timer, puede ser necesario "drain" el canal: si el temporizador se activó antes de Stop(), la lectura del canal es obligatoria.

Ejemplo de uso correcto de Timer:

t := time.NewTimer(2 * time.Second) defer t.Stop() // ¡obligatorio! select { case <-t.C: fmt.Println("¡Se acabó el tiempo!") case <-otherDone: if !t.Stop() { <-t.C // drenamos el canal si es necesario } }

Pregunta capciosa

¿Se puede reutilizar de inmediato un Timer después de recibir un valor del canal t.C? ¿Qué sucederá si no se hace t.Stop()?

Respuesta: El temporizador no debe restablecerse inmediatamente sin llamar a Stop() y posiblemente leer del canal. Si no se hace t.Stop(), puede quedar una gorutina "muerta" o un disparador inesperado en el siguiente ciclo (el canal no se ha limpiado). Uso correcto: llame a Stop(), y si Stop() devuelve falso, asegúrese de drenar el canal leyendo de t.C.

Ejemplos de errores reales debido a la falta de conocimiento sobre los detalles del tema


Historia

En el servicio de notificaciones de una startup, se utilizaron temporizadores para reiniciar los intentos de entrega. Después de activarse, se reiniciaban inmediatamente sin detenerse; resultado: el flujo de gorutinas aumentaba, el proceso "fugaba" y el sistema colapsaba por falta de memoria.

Historia

En un gran proyecto de e-commerce, para actualizaciones periódicas de productos se utilizaba Ticker, que no se detenía al finalizar el manejador. El manejador "colgaba" incluso después de eliminar un usuario, continuando consumiendo CPU.

Historia

En las pruebas, no se llamaba a Stop() para el temporizador; las pruebas se colgaban aleatoriamente porque el canal del temporizador no se liberaba, se esperaba un segundo "ping" del temporizador, que nunca llegaba.