Премиум

Как работает `time.After` и в чем его опасность?

Тип вопроса: Golang Вероятность: 10% Категория: Golang Разработчик

Ответ

time.After — это удобная функция, которая возвращает канал (<-chan Time). В этот канал будет отправлено текущее время по истечении указанного промежутка времени. Чаще всего её используют для реализации таймаутов в select.

Пример использования:

select {
case res := <-someChan:
    fmt.Println("Получены данные:", res)
case <-time.After(2 * time.Second):
    fmt.Println("Операция превысила лимит времени!")
}

Особенности и потенциальные проблемы:

  1. Утечка ресурсов (Resource Leak): Это главная опасность time.After. При каждом вызове создается внутренний объект time.Timer и канал. Если time.After используется в цикле, и таймаут не срабатывает (т.е. всегда выполняется другой case), то созданный таймер не будет остановлен сборщиком мусора до тех пор, пока не сработает. Это приводит к накоплению таймеров и утечке памяти.

  2. Одноразовое использование: Канал, возвращаемый time.After, отправляет значение только один раз.

Правильные альтернативы:

  • Для таймаутов в циклах — time.NewTimer: Он позволяет явно управлять таймером с помощью методов Stop() и Reset().

    timer := time.NewTimer(2 * time.Second)
defer timer.Stop() // Освобождаем ресурсы

for {
    select {
    case <-someChan:
        // Сбрасываем таймер, если получили данные вовремя
        if !timer.Stop() {
            <-timer.C
        }
        timer.Reset(2 * time.Second)
    case <-timer.C:
        fmt.Println("Таймаут!")
        return
    }
}

  • Для повторяющихся событий — time.Ticker: Если нужно выполнять действие через равные промежутки времени, Ticker является наиболее подходящим и эффективным инструментом.

Ответ 18+ 🔞

А, ну вот, опять про этот time.After заговорили. Слушай, как будто специально для распиздяев придумали, честное слово. Смотри, в чём прикол.

Вот представь: тебе надо в select поставить таймаут, чтобы не ждать вечность, если канал молчит как рыба об лёд. Ну, логично же. И ты пишешь:

select {
case res := <-someChan:
    fmt.Println("Получены данные:", res)
case <-time.After(2 * time.Second):
    fmt.Println("Операция превысила лимит времени!")
}

Вроде бы всё гениально и просто, да? Ну типа «эй, через две секунды, если нихуя не пришло, давай сигнал». И канал этот, который time.After вернула, сработает — время туда прилетит, и ты вывалишься из select с криком «всё, пиздец, таймаут!».

НО! Вот тут-то и начинается, блядь, самое интересное. Прямо трагедия в трёх актах, ёпта.

Акт первый. Утечка, сука, ресурсов.

Ты в курсе, что каждый раз, когда ты вызываешь time.After(2 * time.Second), где-то в недрах Go рождается новый time.Timer? И канал к нему прикручивается? Так вот, представь, что ты это дело в цикл засунул. И у тебя в 99% случаев данные из someChan прилетают быстро. Таймаут не срабатывает. А таймер-то, сука, уже создан! Он тихонечко себе отсчитывает эти две секунды где-то на задворках рантайма. Потом «бац!» — и шлёт время в свой канал. Но ты уже из select вывалился, ты этот канал не читаешь, он никому не нужен.

И что? А то, что этот таймер не остановлен! Сборщик мусора на него смотрит, чешет репу: «Ну, канал-то ещё жив, кто-то же может прочитать...». И не трогает его. А ты в следующей итерации цикла — опять новый таймер создаёшь. И ещё. И ещё. И их становится овердохуища. Память тихо и незаметно уплывает в никуда. Это и есть та самая «утечка». Красота, да? Один вызов — и ты уже в долгах как в шелках перед своей же программой.

Акт второй. Одноразовость.

Ну, тут всё просто. Канал от time.After — он как одноразовый шприц. Сработал один раз — и нахуй. Хочешь новый таймаут? Зови функцию снова. Для циклов — полная жопа.

Так что же делать, спросишь ты? Не использовать вообще?

Использовать-то можно, блядь, но с умом! Если у тебя таймаут разовый, вне цикла — то да, похуй, пусть будет time.After. Удобно же.

А вот если ты в цикле крутишься, или таймаут нужно сбрасывать — тут уже надо брать в руки time.NewTimer. Это как перейти с одноразовой зажигалки на хорошую турбо-зажигалку, которую можно перезаправлять.

Смотри, как это выглядит без этих уёбищных утечек:

timer := time.NewTimer(2 * time.Second)
defer timer.Stop() // Вот это, блядь, святое! Освобождаем ресурсы на выходе.

for {
    select {
    case <-someChan:
        // Ура, данные пришли! Надо таймер сбросить.
        if !timer.Stop() {
            <-timer.C // Выгребаем возможный сигнал, если он уже прилетел.
        }
        timer.Reset(2 * time.Second) // Заводим заново.
    case <-timer.C:
        fmt.Println("Всё, пиздец, таймаут!")
        return
    }
}

Да, кода больше. Зато никаких утечек, всё под контролем. Таймер один, и он переиспользуется. Красота.

А если надо просто тикать раз в N времени?

Тогда тут вообще не место time.After. Тут царь и бог — time.Ticker. Он для периодических действий создан. time.After для этого — всё равно что гвозди микроскопом забивать.

Короче, суть в чём: time.After — это как быстрый фастфуд. Разок перекусить — ок. Питаться им каждый день — себе дороже, здоровье (память) похеришь. Для серьёзных дел бери нормальные инструменты. Всё.

© ХакСобесов, 2026
support@hacksobesov.com