C# Delay - Task.Delay czy Thread.Sleep? Wybierz mądrze!

Opóźnienie w kodzie C# przydaje się przy retry, odświeżaniu danych, prostych animacjach, symulacji pracy i zadaniach cyklicznych. Problem zaczyna się wtedy, gdy pauza blokuje wątek, który powinien dalej obsługiwać użytkownika albo ruch sieciowy. W praktyce c# delay to najczęściej wybór między blokującą pauzą a asynchronicznym odroczeniem pracy.

Co naprawdę oznacza pauza w kodzie C#

Pauza nie zawsze znaczy to samo. Czasem chodzi o zatrzymanie bieżącego wątku, czasem o przesunięcie wykonania dalszej części metody o kilka milisekund lub sekund. Różnica jest ważna, bo w aplikacji webowej, desktopowej i konsolowej skutki są inne.

Ja traktuję ten temat dość praktycznie: blokada wątku odbiera zasób procesora na czas czekania, a opóźnienie asynchroniczne pozwala temu samemu wątkowi zająć się inną pracą. To właśnie dlatego sam pomysł „zrobić przerwę” nie mówi jeszcze, jakiego mechanizmu użyć.

Jeśli patrzysz na pauzę jak na zwykłe „uśpienie programu”, łatwo wybrać źle. W następnym kroku rozbijam więc najważniejszy wybór na konkretne scenariusze.

Kiedy wybrać Task.Delay, a kiedy Thread.Sleep

Tu różnica jest bardzo konkretna. W kodzie asynchronicznym, w API, w aplikacji webowej i w większości przypadków nowoczesnego .NET wygrywa Task.Delay. Thread.Sleep zostawiam sobie tylko wtedy, gdy naprawdę chcę zatrzymać cały bieżący wątek i wiem, że to nie zaszkodzi architekturze.

W webie jestem dość bezwzględny w ocenie: jeśli kod obsługuje żądania HTTP, Thread.Sleep prawie zawsze przegrywa. Blokuje worker thread, a wtedy serwer robi się mniej wydajny bez żadnej korzyści logicznej. Jeśli chcesz, żeby praca wróciła później, ale wątek nie stał bezczynnie, użyj asynchronicznego opóźnienia.

To prowadzi do prostego wniosku: wybór mechanizmu zależy nie od samej długości pauzy, ale od tego, czy kod ma pozostać reaktywny. Poniżej pokazuję, jak robić to w praktyce.

Jak używać Task.Delay w praktyce

Najczęściej zaczynam od najprostszego wariantu: metoda musi być async, a opóźnienie powinno być awaitowane. Bez tego kod po prostu nie czeka tak, jak wielu początkujących zakłada.

Najprostsza pauza

public async Task PokazKomunikatPoChwiliAsync()
{
    await Task.Delay(1500);
    Console.WriteLine("Gotowe");
}

To przykład czysty i czytelny. Metoda zwalnia wątek, czeka 1,5 sekundy i dopiero potem przechodzi dalej. W kodzie produkcyjnym taka forma dobrze sprawdza się tam, gdzie chcesz tylko odroczyć kolejną akcję, na przykład pokazanie komunikatu, wysłanie przypomnienia albo wykonanie kolejnego kroku po krótkim odstępie.

Pauza z możliwością anulowania

public async Task WykonajRuchAsync(CancellationToken cancellationToken)
{
    await Task.Delay(TimeSpan.FromSeconds(2), cancellationToken);
    await PrzetworzDalejAsync(cancellationToken);
}

Ten wariant jest dużo dojrzalszy. W praktyce pozwala zatrzymać operację, gdy użytkownik ją przerwie, serwis się wyłącza albo system przestaje potrzebować wyniku. Ja traktuję CancellationToken jako obowiązkowy element wszystkich dłuższych opóźnień w kodzie, który może żyć dłużej niż jedną sekcję ekranu lub jedno żądanie.

Retry z przerwą między próbami

public async Task PobierzDaneZRutynaAsync(CancellationToken cancellationToken)
{
    for (var attempt = 1; attempt <= 3; attempt++)
    {
        try
        {
            await WywolajApiAsync(cancellationToken);
            return;
        }
        catch (HttpRequestException) when (attempt < 3)
        {
            var delay = TimeSpan.FromMilliseconds(300 * attempt);
            await Task.Delay(delay, cancellationToken);
        }
    }
}

To już nie jest kosmetyczna pauza, tylko element sensownej strategii obsługi błędów. Krótki odstęp między próbami ogranicza „spamowanie” zewnętrznego API i daje czas na chwilową niedostępność usługi. Taki wzorzec widuję często w integracjach webowych i właśnie tam opóźnienie ma realną wartość.

Gdy opóźnienie ma coś „odczekać”, ale nie ma sensu blokować wątku, Task.Delay jest zwykle właściwym wyborem. Jeśli potrzebujesz pracy okresowej, lepiej przejść do timera, bo to czystszy model działania.

Przykłady z aplikacji webowych i usług w tle

W projektach webowych i backendowych pauza najczęściej pojawia się w dwóch miejscach: przy okresowym sprawdzaniu stanu oraz przy zadaniach uruchamianych w tle. Tu zwykłe spanie w pętli jest jednym z tych rozwiązań, które wyglądają prosto, ale później mszczą się na wydajności i czytelności kodu.

Pętla okresowa bez blokowania

using var timer = new PeriodicTimer(TimeSpan.FromSeconds(30));

while (await timer.WaitForNextTickAsync(stoppingToken))
{
    await SynchronizujDaneAsync(stoppingToken);
}

To podejście jest czytelne, bo od razu widać intencję: wykonuj zadanie co 30 sekund, dopóki system działa. W tle nie siedzi zbędnie zablokowany wątek, a kod łatwo połączyć z tokenem zatrzymania usługi. W przypadku worker service albo hosta ASP.NET Core to po prostu lepszy model niż ręczne Sleep w nieskończonej pętli.

Przeczytaj również: Pętla for w C# - Składnia, błędy i dobre praktyki

Symulacja pracy w konsoli

public static async Task Main()
{
    Console.WriteLine("Start");
    await Task.Delay(2000);
    Console.WriteLine("Koniec");
}

Ten przykład jest banalny, ale dobrze pokazuje logikę: metoda Main może być asynchroniczna, więc nawet prosta aplikacja konsolowa nie musi blokować procesu tylko po to, żeby coś „poczekało”. To szczególnie przydatne przy demonstracjach, testach i prostych narzędziach administracyjnych.

W aplikacji webowej główny sens jest jeszcze prostszy: nie blokować niczego, co ma obsługiwać kolejne żądania. Właśnie dlatego opóźnienie trzeba projektować inaczej niż w programach jednowątkowych sprzed lat.

Najczęstsze błędy przy wprowadzaniu opóźnienia

Najwięcej problemów widzę nie w samym użyciu pauzy, tylko w błędnym założeniu, że „kilka sekund nic nie zmieni”. Zmienia, i to często bardzo konkretne rzeczy: responsywność, wykorzystanie wątków, czas reakcji i łatwość anulowania operacji.

• Wywołanie Task.Delay bez await - metoda nie czeka, tylko natychmiast idzie dalej, więc pozornie poprawny kod zachowuje się nie tak, jak oczekujesz.
• Używanie Thread.Sleep w kodzie async - to klasyczna pułapka, bo blokujesz wątek tam, gdzie powinieneś go oddać do puli.
• Traktowanie pauzy jak synchronizacji - opóźnienie nie gwarantuje, że inna operacja już się zakończyła; do tego służą sygnały, taski, kolejki lub semafory.
• Brak anulowania - dłuższe czekanie bez tokena utrudnia zamykanie aplikacji i przerwanie operacji przez użytkownika.
• Oczekiwanie idealnej precyzji - bardzo krótkie pauzy mogą być zaokrąglane przez zegar systemowy; w praktyce opóźnienie rzędu 1 ms nie zawsze oznacza dokładnie 1 ms.

Ostatni punkt jest ważniejszy, niż wygląda. Jeśli potrzebujesz naprawdę precyzyjnego harmonogramu, lepiej projektować logikę wokół tolerancji czasowej, a nie wokół wiary, że każdy tick będzie identyczny. To właśnie tutaj doświadczenie oszczędza najwięcej nerwów.

Gdy pauza ma wspierać przepływ aplikacji

Jeśli miałbym zamknąć ten temat w kilku zasadach, powiedziałbym tak: w kodzie aplikacyjnym wybieraj rozwiązanie nieblokujące, w cyklicznych zadaniach używaj timera, a blokowanie wątku zostaw tylko dla prostych, świadomych przypadków. Dzięki temu opóźnienie staje się częścią architektury, a nie przypadkowym hamulcem.

• Jeśli pracujesz w async, zacznij od Task.Delay.
• Jeśli zadanie ma działać co określony czas, rozważ PeriodicTimer.
• Jeśli pauza może być przerwana, zawsze dodaj CancellationToken.
• Jeśli naprawdę chcesz zatrzymać wątek, zrób to świadomie i poza gorącą ścieżką requestów.

W praktyce najlepsze opóźnienie to takie, które widać w kodzie, da się przerwać i nie psuje responsywności całej aplikacji. Kiedy projektuję taki fragment, patrzę nie tylko na czas czekania, ale przede wszystkim na to, co dzieje się z wątkiem, gdy ten czas mija.