Багатопотоковість

— Привіт, Аміго! У нас нова та дуже важка тема. Часто вона вважається однією з найскладніших у Java, та й у програмуванні загалом. Це – багатопотоковість (multithreading).

Уяви собі якусь комп'ютерну гру, наприклад, гонки на зорельотах. Ти летиш просторами космосу, ухиляючись від метеоритів і патрульних крейсерів, а з тобою ще два десятки учасників цих нелегальних перегонів.

Припустимо, ти вирішив написати таку саму гру. Твоїй програмі доведеться відстежувати команди управління (введення з клавіатури), переміщати зорельоти, розраховувати їхні траєкторії та наслідки зіткнення, а також малювати все це на екрані користувача. Це дуже складна робота.

Згадай, як ми вирішили «проблему великої складності» в тому прикладі про зростання кур'єрської компанії.

— Ми розділили її на незалежні відділи і чітко задали (стандартизували) способи їхньої взаємодії.

— Але що робити, коли незалежним частинам потрібно виконати якийсь обсяг роботи паралельно з іншими частинами?! Відповідь на це питання – потоки (треди).

Спробуй уявити програму, як маленького робота, який бігає по коду і виконує команди. Спочатку виконав команду, написану в одному рядку, потім перейшов на наступний, і так далі.

— Уявив. Нічого складного!

— Чудово. А тепер уяви, що таких роботів у тебе декілька. І доки один займається введенням від користувача, другий змінює об'єкти відповідно до нього. Третій виконує код для відображення цих об'єктів на екран, а четвертий кілька разів на секунду перевіряє, чи не зіткнулися кораблі і у разі зіткнення прораховує його результати.

Таким чином, ми можемо розділити програму не тільки на незалежні частини/об'єкти, але й домогтися того, що ці частини виконуватимуть свою роботу незалежно одна від одної. А чим менша взаємодія між окремими частинами, тим менша складність програми.

Уяви, що тобі вдалося замінити менеджера скрпитом, , що розсилає листи. Інші відділи компанії про це навіть не здогадалися. Такі приклади вже мали місце у 26 столітті та показали відмінні результати. Більшість менеджерів, і навіть топ-менеджерів може бути успішно замінена скриптом середньої складності. Лише після втручання «профспілки офісного планктону» вдалося зупинити масові звільнення менеджерів. Але це так – відволікання від теми.

— Як цікаво.

— Крім того, що в програмі може бути кілька таких «маленьких роботів», які виконують код, то ці роботи можуть ще спілкуватися один з одним і породжувати нових роботів.

— Породжувати нових роботів?

— Так, для виконання нових завдань. Іноді вигідно створити ще одного робота (ще один потік), що виконуватиме якусь дію одночасно з першим потоком (роботом).

— Думаю, що це хороша річ, хоч поки що не можу придумати, де це можна використати.

А чому це називається «потоки»?

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

У кожного такого маленького робота є завдання, для виконання якого його створили. І потік – це набір команд, що виконуються у процесі виконання цього завдання.

Припустимо, ти летиш на зорельоті, щоб доставити вантаж. Тоді «доставити вантаж» — це твоє завдання, ти у процесі його виконання. А шлях, який ти пролетів – це твій потік. Можна сказати, що кожному новому завданню, кожному ще не вирішеному завданню відповідає свій потік – шлях, який ще належить пройти.

— Іншими словами, є завдання і «маленький робот», який його виконує, а потік – це лише погляд на поточний стан справ з боку?

— Саме так.

А ось як усе це працює глибоко всередині. Оскільки процесор у комп'ютера один, він може виконувати лише одну команду одночасно. Тому відбувається ось що: процесор постійно перемикається між потоками. Переключився на новий потік, виконав кілька його команд, потім переключився на наступний потік, виконав кілька його команд тощо. Але оскільки перемикання між потоками відбувається сотні разів на секунду, збоку здається, що всі потоки працюють одночасно.