ThreadPool.Workers04.07.2023 10:17

В предыдущих сериях

На этот раз длинная история. Но длинная она в основном из-за множества примеров, которые вы можете легко повторить у себя.

Продолжим, словно наощупь, продираться сквозь дремучие дебри многообразной информации об устройстве тредпула, которую, по моему мнению, необходимо не только знать, но и чувствовать.

Художественное отступление, шутка на текущую тему. Для того, чтобы узнать самое интересное, читать текст под катом совершенно не обязательно.

Как мы уже знаем, в дотнете наши async-методы превращаются в автоматы. И что наш (пользовательский) код, который мы написали при работе с Task’ами, исполняется непрерывно в одном и том же потоке вместе с кодом самого .NET’а, который собственно обслуживает эти автоматы, осуществляет переходы между их состояниями. Вместе с тем кодом, который понимает, что ему встретилось настоящее асинхронное ожидание, и что пора оставить текущую цепочку автоматов, и найти себе какой-то другой автомат, с которым никто не работает прямо сейчас (например, он был тоже оставлен ранее из-за асинхронного ожидания, и наконец-то случилось то, чего он ожидал, после чего можно продолжать работу), чтобы подобрать его на каком-то состоянии и продолжить работу в нём.

Давайте попробуем как-то описать, визуализировать, что происходит. Где-то у нас в процессе выделены какие-то потоки, которые заняты работой с Task’ами (как нашего кода внутри них, так и обслуживающего кода по связям и переходам между ними). Это не поток main-треда. Это не потоки, которые заняты фоновой сборкой мусора (GC-потоки). Это отдельные, специально выделенные для этого потоки.

Раз за работу тасок отвечает какой-то набор потоков, значит он ограниченный. Их точно не бесконечно много. А значит, этим ограниченным ресурсом нужно аккуратно пользоваться. Ведь легко себе представить, как можно занять все имеющиеся у нас под работу с Task’ами потоки. Например, используя синхронные ожидания — они блокируют поток. Что тогда будет делать .NET? И какое количество потоков под работу с Task’ами нам доступно?

Учимся измерять бассейн с нитками

Для начала научимся смотреть, а сколько потоков у нас заняты работой с Task’ами. В этом нам поможет стандартный класс ThreadPool. Раз в секунду будем спрашивать, сколько у нас всего максимум возможно потоков (GetMaxThreads), и сколько ещё можно создать (GetAvailableThreads). Так, с помощью MaxThreads - AvailableThreads, будем высчитывать количество уже созданных потоков (и, вероятнее всего, занятых какой-то работой). Ещё есть количество потоков, которые у нас сразу созданы и готовы к работе (GetMinThreads):

public static (int, int) GetPoolState()
{
    ThreadPool.GetMinThreads(out var minWorkerThreads, out var minIocpThreads);
    ThreadPool.GetMaxThreads(out var maxWorkerThreads, out var maxIocpThreads);
    ThreadPool.GetAvailableThreads(out var availableWorkerThreads, out var availableIocpThreads);
 
    return (minWorkerThreads, maxWorkerThreads - availableWorkerThreads);
}
 
private static void Main(string[] args)
{
    while (true)
    {
        var poolState = GetPoolState();
        Console.WriteLine($"Workers: {poolState.Item2}/{poolState.Item1}");
        Thread.Sleep(1000);
    }
}

Легко убедиться, что такой код не потребляет никаких ресурсов и раз в секунду печатает, сколько потоков у нас заняты:

Теперь будем нагружать наше приложение работой с Task’ами и изучать, как это скажется на состоянии пула потоков для работы с Task’ами.

Имитируем http-сервис

Давайте начнём с имитирования работы простейшего http-сервиса, который на запрос ходит в БД и возвращает ответ. Если кратко, то обычно где-то в самом низу http-сервиса крутится while-цикл, который на каждый новый «прилетевший» запрос запускает new Task по его обработке. А асинхронное обращение к БД будем имитировать с помощью Task.Delay ().

private static void Main(string[] args)
{
    Task.Run(StartHttpServiceImitation);
 
    while (true)
    {
        var poolState = GetPoolState();
        Console.WriteLine($"Workers: {poolState.Item2}/{poolState.Item1}");
        Thread.Sleep(1000);
    }
}
 
private static void StartHttpServiceImitation()
{
    while (true)
    {
        Task.Run(HandleHttpRequest);
        Thread.Sleep(1);
    }
}
 
private static async Task HandleHttpRequest()
{
    //Some cpu work
    await Task.Delay(10000);
    return 42;
}

Что можно сказать, смотря на этот код? Что у нас каждую миллисекунду «прилетает» новый запрос и запускается таска по его обработке. А каждая таска «живёт» по ~10 секунд, и все эти 10 секунд ожидает «ответа от БД». То есть в каждый момент времени (спустя 10 секунд) у нас в процессе «работают» 10.000 живых Task (на самом деле значительно меньше, но всё равно много). Сколько же потоков тредпула будут заняты настоящей работой?

А занятых работой потоков тредпула совсем не 10к. Их очень мало, только те, что именно в данный момент заняты CPU работой нашей Task (которая крайне мала — всего лишь return 42).

А кто внимательный, может заметить, что одна Task у нас не «освобождает» поток никогда — это та таска, в которой работает метод StartHttpServiceImitation, и которая запускает новые таски по «обработке запросов». Она всегда держит поток занятым, поскольку делает Thread.Sleep(). А Thread.Sleep это не async-метод, который мы вызываем с использованием await. То есть Task’а при своей работе не меняет никаких состояний в своём автомате (а напомним, что их смена происходит в моменте await’а). А значит один поток всегда занят работой над одним состоянием автомата этой таски, которому не повезло оказаться «вечным циклом».

Имитируем идеальный http-сервис

Если не рассматривать ту таску, которая работает в методе StartHttpServiceImitation, то можно заметить, что бывают моменты,  когда вообще никакой поток тредпула не работает над тасками с «полезной работой» (ожиданием «ответа от БД», то есть Task.Delay()). Я намеренно создал такую ситуацию. И сейчас мы от неё избавимся и посмотрим, что изменится. Избавляться будем таким образом: вместо блокирующего поток Thread.Sleep() используем await Task.Delay(). Важно, что не Task.Delay().Wait(), не Task.Delay().Result, не Task.Delay().GetAwaiter().GetResult(). А именно await Task.Delay(). Именно ключевое слово await заставит .NET отпустить поток, пока мы ждём завершения этого настоящего асинхронного ожидания. (Это не единственный способ, как мы видели в статье про async\await. И не забывайте про то, что не каждый await должен приводить к смене потока в цепочке await-вызовов async-методов.)

private static async Task StartHttpServiceImitation()
{
    while (true)
    {
        Task.Run(HandleHttpRequest);
        await Task.Delay(1);
    }
}
 
private static async Task HandleHttpRequest()
{
    //Some cpu work
    await Task.Delay(10000);
    return 42;
}

Как замечательно. Ждущие таски есть, а потоков не занимают. Занимают только тогда, когда надо именно CPU работу сделать:

Можете поиграться сами с длительностью ожидания внутри Task и убедиться, что потребление потоков никак не изменится. Оно всё равно будет около нуля.

Я не зря назвал параграф «идеальным сервисом».

Нагружаем CPU-работой.

Мы выяснили, что потоки, которые отвечают за работу Task’ов, не напрягаясь могут обрабатывать тысячи Task. Но это если они честно и асинхронно чего-то ждут. Давайте проверим, что будет, если нагрузить Task’и CPU работой?

Пусть наш «хендлер» считает сумму всех простых чисел от 2 до int.MaxValue. Никакого Решета Эратосфена и прочих премудростей — мы хотим намеренно надолго загрузить Task’у CPU работой!

private static async Task StartHttpServiceImitation()
{
    while (true)
    {
        Task.Run(GetPrimeNumbersSum);
        await Task.Delay(1);
    }
}
 
private static async Task GetPrimeNumbersSum()
{
    var primes = FindAllPrimeNumbers();
    await Task.Delay(10);
    return primes.Sum();
}
 
//Ты в самом деле будешь читать код этого метода?
//Это же совершенно не важно :)
private static List FindAllPrimeNumbers()
{
    var primes = new List();
    for (long i = 2; i <= int.MaxValue; i++)
    {
        var hasDivider = false;
        for (var j = 2; j*j <= i; j++)
        {
            if (i % j != 0) continue;
 
            hasDivider = true;
            break;
        }
 
        if (!hasDivider)
            primes.Add((int)i);
    }
 
    return primes;
}

Смотрите как интересно, теперь все восемь из восьми потоков заняты!

Ой, нет… 9/8 Потоков?

Они размножаются!

У меня на компьютере всего 4 ядра (и мультитрединг, то есть «типа восемь»). Понятно, что >= 8 потоков могут делать CPU работу и потреблять почти 100% CPU. Давайте пошаримся в процессе:

Потребление CPU действительно близко к 100% (больше ему не даёт ОС, всё-таки надо делать ещё кучу всякой другой работы):

А сколько наш процесс создал настоящих потоков ОС:

Тех, которые начинаются с coreclr_initialize+0x5db80 (и с большим числом Cycles Delta), 18 штук. То есть можно с уверенностью сказать, что действительно, 18 потоков ОС заняты работой с Task’ами.

А что, если потоки ничего не делают, но неправильно (синхронно) ждут?

Давайте проверим, что случится. Вместо «правильного» await DoAsync() можно было бы написать DoAsync().Wait(),  DoAsync().Result,  DoAsync().GetAwaiter().GetResult(). Это всё не await — асинхронные — ожидания. А синхронные, или блокирующие ожидания.

private static async Task StartHttpServiceImitation()
{
    while (true)
    {
        Task.Run(SynchronousWait);
        await Task.Delay(1);
    }
}
 
private static async Task SynchronousWait()
{
    Task.Delay(10000).Wait();
    return 42;
}

Вот что у нас с потоками с точки зрения как приложения, так и ОС:

CPU usage у такого процесса, ожидаемо, было около нуля. Всего всех потоков в приложении 108, а в тредпуле с точки зрения самого приложения 102. И даже ровно 6 не-тредпульных (не coreclr_initialize+0x5db80) на скрине и видно. Совпадает!

А как себя чувствует приложение, когда ему не хватает потоков?

Как мы могли заметить, когда все потоки для работы с Task’ами заняты, и есть Task’и, готовые к работе, дотнет вынужден создавать новые потоки. Чтобы было где исполнять готовые к работе Task’и.

Также можно заметить, что Task’и мы создаем достаточно часто — пауза между итерациями всего 1 мс. При этом, длительность тасок очень высокая. А вот потоков для их исполнения совсем не много. И их количество растёт как-то медленно. Подозрительно, не правда ли? Кому-то же обязательно не хватает потоков для работы. А всё ли в порядке с приложением, когда оно в таком состоянии?

Давайте посмотрим, насколько свободно и непринуждённо работает приложение, когда у него «все хорошо», то есть в варианте из «Идеального http-сервиса». Когда все таски делают крайне мало CPU работы, честно и асинхронно ждут, и в приложении потоки под Task’и ничем не заняты. Например, давайте будем логировать время между запуском каждой следующей Task’и:

private static void Main(string[] args)
{
    Task.Run(StartHttpServiceImitation);
 
    while (true)
    {
        var poolState = GetPoolState();
        Console.WriteLine($"Workers: {poolState.Item2}/{poolState.Item1}");
        Thread.Sleep(1000);
    }
}
 
private static async Task StartHttpServiceImitation()
{
    while (true)
    {
        Task.Run(AsynchronousWait);
        await Task.Delay(1);
        Console.WriteLine(DateTime.UtcNow.ToString("hh:mm:ss.fff tt"));
    }
}
 
private static async Task AsynchronousWait()
{
    await Task.Delay(10000);
    return 42;
}

Консолька свободно и монотонно «бежит», печатая ровно и в одинаковом темпе всё новые и новые строчки:

А теперь давайте применим логирование из метода StartHttpServiceImitation к варианту с синхронными ожиданиями:

Картинка резко изменилась. Пауза между итерациями иногда (и даже очень часто) стала очень большой, вплоть до секунды. Всё дело в том, что наша StartHttpServiceImitation тоже работает на тредпуле — её же запустили в Task.Run. Ей тоже нужны доступные потоки, чтобы в них исполнялось тело этой функции. И когда потоков не достаточно, а её await Task.Delay(1) закончился, некому начать исполнять код после await Task.Delay(1). Пока .NET не создаст новый поток и этому потоку не достанется под исполнение именно та Task’а, которая крутится в цикле в StartHttpServiceImitation.

А вспоминая, что мы имитировали настоящий http-сервис и предполагалось, что метод StartHttpServiceImitation принимает новые http-запросы и запускает их обработку (а мы написали это очень похоже на то, как это делается в реальном мире), получается, что в настоящем приложении некому будет даже начать обрабатывать настоящий http-запрос! То есть, просто написав некорректную работу с Task’ами в пользовательском коде хотя бы в одном месте, можно испортить вообще весь остальной сервис, все остальные работающие библиотеки и фоновые процессы в вашем приложении, как бы хорошо это всё не было написано.

Можно ли обойти эту проблему (хотя бы в текущем примере, для метода StartHttpServiceImitation)? Есть ли способы защищаться от того, что где-то в чужом месте очень плохо обращаются с пулом потоков? О да, и не один! Разберём сейчас только два самых тривиальных. Правда, от того и применимых на практике лишь в очень узких сценариях.

1. Не используйте Task’и для длительных (бесконечных) и периодических работ!

Как уже говорилось, не используйте Task’и для длительных работ ;)

Особенно, если вам действительно нужна точность и регулярность работы, когда не допустимы паузы и простои. Что можно предложить вместо Task? Естественно, отдельный и самостоятельный поток, никак не связанный с потоками из тредпула!

private static void Main(string[] args)
{
    new Thread(() =>
    {
        while (true)
        {
            Task.Run(SynchronousWait);
            Thread.Sleep(1);
            Console.WriteLine(DateTime.UtcNow.ToString("hh:mm:ss.fff tt"));
        }
    }).Start();
 
    while (true)
    {
        var poolState = GetPoolState();
        Console.WriteLine($"Workers: {poolState.Item2}/{poolState.Item1}");
        Thread.Sleep(1000);
    }
}
 
private static async Task StartHttpServiceImitation()
{
    while (true)
    {
        Task.Run(SynchronousWait);
        await Task.Delay(1);
        Console.WriteLine(DateTime.UtcNow.ToString("hh:mm:ss.fff tt"));
    }
}
 
private static async Task SynchronousWait()
{
    Task.Delay(10000).Wait();
    return 42;
}

Так, наш отдельный поток работает стабильно и никак не зависит от того, насколько нагружен пул потоков для работы с Task’ами. Он лишь сам туда докидывает новых Task’ов (в нашем варианте). Вот, посмотрите, пул потоков уже забит (13/8), а наш тред работает неустанно, без тех дурацких пауз, что мы наблюдали ранее:

2. Присоединяйтесь ко злу, украдите поток себе, и никому не отдавайте!

Помните переход от «имитируем http-сервис» к «имитируем идеальный http-сервис»? В первом случае один поток был всегда занят нашим StartHttpServiceImitation. А что, если мы намеренно так сделаем? Заберём один поток себе и никому не отдадим! Будет ли в таком случае этот поток стабильно работать?

private static void Main(string[] args)
{
    Task.Run(StartHttpServiceImitationSynchronously);
 
    while (true)
    {
        var poolState = GetPoolState();
        Console.WriteLine($"Workers: {poolState.Item2}/{poolState.Item1}");
        Thread.Sleep(1000);
    }
}
 
private static void StartHttpServiceImitationSynchronously()
{
    while (true)
    {
        Task.Run(SynchronousWait);
        Thread.Sleep(1);
        Console.WriteLine(DateTime.UtcNow.ToString("hh:mm:ss.fff tt"));
    }
}
 
private static async Task SynchronousWait()
{
    Task.Delay(10000).Wait();
    return 42;
}

Да, будет!

Мы отобрали себе один поток в методе StartHttpServiceImitationSynchronously, который стартанул в пуле потоков и никогда не делает await, крутится в вечном цикле. Соответственно он никогда не отдаёт свой поток другим для работы над другими Task’ами. Получается, что у него есть свой собственный поток и он никак не зависит от того, как быстро освободятся или создадутся новые потоки. Почти как из предыдущего варианта — свой персональный поток. Только не отдельный, а украденный из общего пула. Как грязно, как некрасиво! Но работает.

Что-то наша история затянулась

Да, мы поговорили уже о многом, и даже повеселились с воровством потоков. Пора подводить итог. Что мы знаем о пуле потоков?

Каждый такой поток называют воркером — Worker thread.

Каждый worker ищет себе ту Task’у, которая сейчас разблокирована и готова к работе. Он начинает с ней работать, ходит по разным состояниям автомата этой таски, переходит в другие таски (и их автоматы) по цепочке вызовов. И он продолжает работу над этой цепочкой до тех пор, пока не встретит первое честное асинхронное ожидание — await SmthReallyAsync ().

После того, как поток, worker, встретил первое честное асинхронное ожидание, он бросает работу с предыдущей Task’ой и тут же идёт искать себе новую Task’у, которая разблокирована и готова работать.

Если так случается, что готовые к работе Task’и есть, а свободных потоков нет, .NET создаёт новые потоки.

И, естественно, появилось ещё больше вопросов, на некоторые из которых мы, возможно, ответим в дальнейшем. Ну например:

• Почему потоки создаются не так быстро, как появляются Task’и? Это как-то регулируется, есть ли правила, по которым они создаются?

• А что плохого в том, чтобы создать сразу много потоков? Почему .NET не создаёт сразу 100500 потоков, и как это сделать самому?

• А как ещё можно разграничить работу одних Task от других, чтобы они не мешались друг другу? Было упомянуто, что способов сделать такое больше, чем два уже рассмотренных. Можно ли сделать несколько непересекающихся пулов потоков, чтобы если кто-то заполнил и испортил свой, то никак не повлиял на мой пул? (наличие вопроса намекает, что да, можно ;))

• Некоторые аспекты работы с тредпулом проявляются только на длительном промежутке времени. Как быть, и как доказывать, что приложение в самом деле будет хорошо работать на production?

• А что ещё за Iocp-треды, информацию о которых можно узнать из класса ThreadPool?

• А если .NET насоздавал много дополнительных потоков, и потом они стали не нужны, он от них избавится?

© Habrahabr.ru