Проблема блокувальних викликів

1. Вступ

Блокувальний виклик — це будь‑який виклик, який «блокує» виконання потоку доти, доки не завершиться якась операція. Зазвичай це:

• Читання або запис даних (наприклад, із диска).
• Довгий запит до бази даних або мережі.
• Виклик сторонньої бібліотеки, яка працює повільно.

У такі моменти потік просто стоїть і чекає: «Ну що там, коли вже відповідь?»

Приклад із життя

// Ваша основна логіка
Console.WriteLine("Очікую відповідь від сервера…");
string response = CallServer(); // тут усе зависло!
Console.WriteLine("Сервер відповів: " + response);

Поки сервер не відповість, ваш потік «завис» — і більше нічого зробити не може!

Як це виглядає у застосунках

У різних типах застосунків це проявляється по‑своєму. У консольному застосунку все виглядає так, ніби він просто завмер — курсор перестає блимати, і жодної реакції не видно. У графічному інтерфейсі, наприклад у WinForms чи WPF, вікно раптово перестає відповідати, з’являється знайоме більшості «Не відповідає», і користувач уже готовий сердитися і на застосунок, і на його автора. А в серверних застосунках ситуація ще неприємніша: один заблокований потік означає мінус одного обслуговуваного користувача.

2. Блокувальні виклики в C# на практиці

Розберімо ситуацію на практиці, використавши навчальний проєкт. Припустімо, у нас є застосунок магічної кулі. У ньому може бути, наприклад, такий фрагмент:

Console.WriteLine("Введіть ваше запитання для магічної кулі:");
string question = Console.ReadLine(); // блокувальний виклик: чекаємо введення!
Console.WriteLine("Думаю над відповіддю...");
Thread.Sleep(5000); // Імітація тривалої роботи
Console.WriteLine("Відповідь: спробуйте завтра знову!");

• Console.ReadLine() — чекає введення користувача стільки, скільки потрібно (блокуючи потік).
• Thread.Sleep(5000) — штучно робить паузу, «заморожує» потік.

Питання: Що поганого, якщо ми просто працюємо з консольним застосунком?

Відповідь: У консольному застосунку це не так критично — ваш користувач сам чекає. Але що, якщо користувач не один? Якщо це сервер, якому прилітає одразу 1 000 запитів? Або GUI‑застосунок, де користувач очікує реакції інтерфейсу, а не вашого філософського міркування?

Приклад: Блокування UI

// У WinForms обробник кнопки:
private void button1_Click(object sender, EventArgs e)
{
    label1.Text = "Завантажуюся…";
    DoHeavyWork(); // важка операція (наприклад, запит до БД)
    label1.Text = "Готово!";
}

Проблема: Поки працює DoHeavyWork, вікно не оновлює інтерфейс, не реагує і на клавіатуру, і на мишу, не перемальовується. Якщо користувач спробує закрити вікно — Windows покаже «Не відповідає» і запропонує завершити завдання.

3. Головний біль багатопоточного світу

Проблеми блокувальних викликів

• Витрати ресурсів. Кожен потік (Thread) у .NET — це доволі «важкий» об’єкт. ОС виділяє для нього пам’ять під стек (зазвичай 1 МБ), дескриптори, синхронізацію тощо. Якщо потік простоює (чекає файл або мережу), то він робить марну справу («нічого не роблячи, споживає пам’ять»).
• Обмеженість потоків. У серверних застосунках зазвичай є пул потоків. Якщо всі потоки блокуються — нові запити не обробляються. Наприклад, в ASP.NET: якщо всі доступні потоки чекають відповіді від бази даних, то сайт «зависає» для всіх нових користувачів.
• Поганий відгук інтерфейсу. У GUI‑застосунках вікно перестає реагувати навіть на «закрити», коли UI‑потік заблокований.
• Падіння продуктивності. Чим більше потоків блокується, тим більше перемикань контексту, тим вище навантаження на ОС, і тим повільніше працює весь комп’ютер.

Типові джерела блокувальних викликів

Давайте подивимося, які виклики можуть «на рівному місці» заблокувати потік:

• Мережеві операції: звернення до API, завантаження файлів, завантаження оновлень.
• Диск/файлова система: читання або запис великих файлів.
• Бази даних: довгий запит до SQL Server або навіть локальної бази.
• Введення користувача: тривале ReadLine — дрібниця, але теж блокує.
• Thread.Sleep, а також деякі способи очікування Task.Delay: можуть штучно «заморожувати» потік.

Приклад (завантаження даних із сайту)

using System.Net.Http;

HttpClient client = new HttpClient();
string result = client.GetStringAsync("https://google.com").Result; // блокувальний синхронний виклик!
Console.WriteLine(result);

Що тут відбувається? Метод .Result блокує потік до отримання відповіді!

4. Як зрозуміти, що ваш виклик блокує потік?

Усе просто: якщо метод не повертає керування до завершення своєї роботи (очікування, введення, мережа, диск) — це блокувальний виклик.

• Методи з Thread.Sleep, Task.Wait, .Result, .Wait() — блокують.
• Методи, у яких є «читання/запис даних» без асинхронності, — теж.
• Вікно, що «не відповідає», або підвислий сервер — часта ознака.

Візуальний елемент: Блок‑схема блокувального виклику

+-------------------+
| Запуск методу     |
+-------------------+
         |
         v
+-------------------+
| Виклик блокуваль- |
| ного методу       |
| (наприклад,       |
| читання файлу)    |
+-------------------+
         |
         v
+-------------------+
| Чекаємо завершення|
| операції          |
+-------------------+
         |
         v
+-------------------+
| Повертаємось із   |
| методу і йдемо    |
| далі              |
+-------------------+

5. Чим погані блокувальні виклики в серверних застосунках

Більшість сучасних застосунків — мережеві або серверні. Навіть якщо ви пишете гру, там є завантаження з сервера. Якщо ви робите вебсайт, там точно буде робота з мережею та диском.

Уявіть, що ваш сервер обробляє 1 000 запитів на секунду. Кожному запиту треба поспілкуватися з базою даних. Ви пишете:

// Веб-обробник
string data = db.ReadDataSync(); // Синхронне блокування!
return new Response(data);

Поки триває запит до бази даних, потік простоює й чекає. Один запит — ще не біда. Але коли їх набирається багато, усі потоки забиваються вщерть. Нові не потрапляють у роботу й шикуються в чергу. Урешті сервер перетворюється на довжелезну чергу, де всі стоять і чекають, доки процес хоч трохи зрушить.

Ілюстрація: «Синхронна обробка запитів»

Запит 1: зайняв потік -> чекає базу -> звільнився
Запит 2: зайняв потік -> чекає базу -> звільнився
...
Запит 100: немає вільних потоків, чекає в черзі...

6. Асинхронність — ліки від блокувальних викликів

Щоб побороти блокування, використовують асинхронні виклики. У C# це «магічні» слова: async і await.

Вони дозволяють:

• Не блокувати потік (особливо цінний UI‑ або серверний потік).
• Не займати ресурси даремно.
• Поліпшувати відгук GUI.
• Не «тримати» потік, поки йде повільна операція.

Зверніть увагу: ми не починаємо одразу з асинхронності, адже вона потребує розуміння потоків і блокувань. Тепер, коли ви відчули проблеми від блокувальних викликів, асинхронний підхід сприйматиметься як помітне полегшення і для мозку, і для користувача.

Таблиця: Що блокує, а що ні?

Console.ReadLine()

Thread.Sleep(1000)

File.ReadAllText()

Task.Delay(1000).Wait()

HttpClient.GetStringAsync().Result

await File.ReadAllTextAsync()

await Task.Delay(1000)

await HttpClient.GetStringAsync()

Примітка: await працює тільки в асинхронному методі (async Task ...), який ми детально розглянемо вже в найближчих лекціях.

7. Легендарні помилки під час роботи з блокувальними викликами

«Блокую UI — користувач проклинає все»

private void btnLoad_Click(object sender, EventArgs e)
{
    var data = BigFileReader.Read(@"C:\huge.dat"); // блокувальний виклик!
    textBox1.Text = data;
}

Поки не прочитається великий файл, вікно зависає.

«Зависання сервера — клієнти розбігаються»

public IActionResult Download()
{
    var content = File.ReadAllBytes("bigfile.zip"); // синхронно, довго, блокує потік ASP.NET!
    return File(content, "application/zip");
}

Невеликі сервери (наприклад, на безкоштовному хостингу) можуть просто впасти за такого підходу.

«Асинхронний метод + .Wait()/.Result = синхронна смерть»

public void LoadData()
{
    var result = DoAsyncWork().Result; // Блокує потік!
}

.Result і .Wait() перетворюють навіть акуратний асинхронний код на банальний блокувальний виклик.