Лекції

Розбираємо базову мотивацію корутин у Kotlin: чим блокування потоку через Thread.sleep відрізняється від призупинення корутини через delay; що означає ключове слово suspend (це контракт, а не «прискорювач»); навіщо потрібна бібліотека kotlinx.coroutines і «міст» runBlocking; а також яких помилок найчастіше припускаються новачки під час першого знайомства з асинхронністю.

Розбираємося, чому зі звичайного main не можна безпосередньо викликати suspend-функції; як runBlocking працює як «міст» у корутинний світ; і чому він насправді блокує потік. Підʼєднуємо залежність kotlinx.coroutines і вибудовуємо правильний стиль: один runBlocking у точці входу та ланцюжок suspend-сценаріїв (наприклад, runApp). Наприкінці розглянемо практичний приклад: завантаження даних і формування звіту.

Розбираємося, чим відрізняється «очікування» в корутинах і в потоках. Навіщо потрібен suspend як чесний контракт функції, як працює delay (призупиняє корутину без блокування потоку) і чому Thread . sleep «заморожує» реальний потік. Закріплюємо різницю таблицею, практичним патерном «очікування всередині suspend-функції» та списком типових помилок.

Розбираємо два основні будівники корутин із kotlinx.coroutines: launch (корутина заради дії / побічного ефекту) і async (корутина заради результату). Зʼясуємо, що таке Deferred<T>, навіщо потрібен await(), як не зруйнувати конкурентність передчасним очікуванням, де доречно поєднувати launch і async, а також яких помилок найчастіше припускаються новачки.

Розбираємося, як вибрати правильний Dispatcher для корутини: Dispatchers.Default — для CPU-обчислень, а Dispatchers.IO — для блокувального введення/виведення. Окремо розглядаємо часті проблеми: використання GlobalScope у консольних застосунках, забутий await() у Deferred<T>, а також блокування через Thread . sleep ( ... ) замість коректного delay ( ... ). Наприкінці — мінісценарій із паралельними звітами та схема вибору «де це має виконуватися».