Паралелізм в Java

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

Кожен потік може бути запланований для виконання на окремому ядрі ЦП, використовувати квантування часу на одноядерному процесорі або використовувати квантування часу на декількох процесорах. В двох останніх випадках система буде періодично переключатися між потоками, по черзі даючи виконуватися то одному, то іншому. Така схема називається псевдо-паралелізмом. Немає універсального рішення, яке сказало би як саме потоки Java будуть перетворені в нативні потоки ОС. Це залежить від конкретної реалізації JVM.

В мові Java потік представляється в вигляді об'єкту-потомка класу Thread. Цей клас інкапсулює стандартні механізми роботи з потоком. Потоками можна управляти або напряму, або засобами абстрактних механізмів, таких як Executor і колекції з пакету java.util.concurrent.

Запустити новий потік можна двома способами:

• Реалізацією інтерфейсу Runnable

public class HelloRunnable implements Runnable {
    public void run() {
        System.out.println("Привіт з потоку!");
    }
    public static void main(String[] args) {
        (new Thread(new HelloRunnable())).start();
    }
}

• Наслідуванням від класу Thread

public class HelloThread extends Thread {
    public void run() {
        System.out.println("Привіт з потоку!");
    }
    public static void main(String[] args) {
        (new HelloThread()).start();
    }
}

Переривання — вказівка потоку, що він має припинити поточну роботу і зробити ще щось. Потік може послати переривання викликом методу interrupt() в об'єкта Thread, якщо потрібно перервати асоційований з ним потік. Механізм переривання реалізовано з використання внутрішньої мітки interrupt status (мітка переривання) класу Thread. Виклик Thread.interrupt() активує цю мітку. Згідно з узгодженнями будь-який метод, який завершується викиданням InterruptedException скидає мітку переривання. Перевірити чи встановлена та чи інша мітка можна двома способами. Перший спосіб — викликати метод bool isInterrupted() об'єкту потоку, другий — викликати статичний метод bool Thread.interrupted(). Перший метод повертає стан мітки переривання і залишає цю мітку недоторканою. Другий метод повертає стан мітки і скидає її. Зауважте, що Thread.interrupted() - статичний метод класу Thread, і його виклик повертає значення мітки переривання того потоку, з якого він був викликаний.

В Java передбачений механізм, який дозволяє одному потоку чекати виконання іншого. Для цього використовується метод Thread.join().

В Java процес завершується тоді, коли завершується останній його потік. Навіть коли метод main() вже завершився, але ще виконуються породжені ним потоки, система буде чекати їх завершення. Але це правило не відносить до особливого виду потоків — демонів. Якщо завершився останній звичайний потік процесу, і залишилися тільки потоки-демони, то вони будуть примусово завершені і виконання процесу закінчиться. Найчастіше потоки-демони використовуються для виконання фонових задач, які обслуговують процес протягом його життя.

Оголосити потік демоном досить просто - потрібно перед запуском потоку викликати його метод setDaemon(true); перевірити, чи є потік демоном, можна викликавши його метод boolean isDaemon().

Викинутий і необроблений виняток веде до завершення потоку. Головний потік автоматично виведе виняток в консоль, а потоки, створені користувачем, можуть зробити це тільки зареєструвавши оброблювач.

Комунікація потоків здійснюється за допомогою поділу доступу до полів і об'єктів, на які посилаються поля. Дана форма комунікації є дуже ефективною, але створює можливість виникнення помилок двох різновидів: втручання в потік (thread interference) і помилки консистентності пам'яті (memory consistency errors). Для запобігання їх виникнення існує механізм синхронізації.

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

Для синхронізації потоків в Java використовуються монітори, які є високорівневим механізмом, що дозволяє одночасно тільки одному потоку виконувати блок коду, захищений монітором. Поведінка моніторів розглянута в термінах блокувань; з кожним об'єктом асоціюється одне блокування.

Синхронізація має кілька аспектів. Найбільш добре розуміється взаємне виключення (mutual exclusion) - тільки один потік може володіти монітором, таким чином синхронізація на моніторі означає, що як тільки один потік входить в synchronized-блок, захищений монітором, ніякий інший потік не може увійти в блок, захищений цим монітором поки перший потік не вийде з synchronized-блоку.

Але синхронізація - це більше ніж просто взаємне виключення. Синхронізація гарантує, що дані, записані в пам'ять до або всередині синхронізованого блоку, стають видимими для інших потоків, які синхронізуються на тому ж моніторі. Після того як ми виходимо з синхронізованого блоку, ми звільняємо (release) монітор, що має ефект скидання (flush) кешу в оперативну пам'ять, так що записи, зроблені нашим потоком, можуть бути видимими для інших потоків. Перш ніж ми зможемо увійти в синхронізований блок, ми захоплюємо (acquire) монітор, що має ефект оголошення недійсними даних локального процесорного кешу (invalidating the local processor cache), так що змінні будуть завантажені з основної пам'яті. Тоді ми зможемо побачити всі записи, зроблені видимими попереднім звільненням (release) монітора. (JSR 133)

Читання-запис в поле є атомарною операцією, якщо поле оголошено volatile або захищене унікальним блокуванням, яке одержується перед будь-яким читанням-записом.

Ефект взаємного виключення і синхронізації потоків досягається входженням в synchronized-блок або метод, який неявно отримує блокування, або отриманням блокування явним чином (таким як ReentrantLockз пакету java.util.concurrent.locks). Обидва підходи мають однаковий вплив на поведінку пам'яті. Якщо всі спроби доступу до деякого полю захищені одним і тим самим блокуванням, то операції читання-запису цього поля є атомарними.

Стосовно до полів ключове слово volatile гарантує:

1. (У всіх версіях Java) Доступи до volatile-змінної впорядковані глобально. Це означає, що кожен потік, який звертається до volatile-полю, прочитає його значення перед тим як продовжити замість того, щоб (по можливості) використовувати закешоване значення. (Доступи до volatile-змінної не можуть бути переупорядкувані один з одним, але вони можуть бути переупорядкувані з доступами до звичайних змінних. Це зводить нанівець корисність volatile-полів як засобу передачі сигналу від одного потоку до іншого.)
2. (В Java 5 і пізніших) Запис в volatile-поле має той же ефект для пам'яті, що і звільнення монітора (англ. Monitor release), а читання - той же, що і захоплення (англ. Monitor acquire). Доступ до volatile-полів встановлює відношення «Виконується перед» (англ. happens before).[2] По суті, це відношення є гарантією того, що все, що було очевидно для потоку A, коли він писав в volatile-поле f, стає видимим для потоку B, коли він прочитає f.

Volatile-поля є атомарними. Читання з volatile-поля має той же ефект, що і отримання блокування: дані в робочій пам'яті оголошуються недійсними, значення volatile-поля заново читається з пам'яті. Запис в volatile-поле має той же ефект для пам'яті, що і звільнення блокування: volatile-поле негайно записується в пам'ять.

Поле, яке оголошено final, називається фінальним і не може бути змінено після ініціалізації. Фінальні поля об'єкта ініціалізуютьтся в його конструкторі. Якщо конструктор відповідає певним простим правилам, то коректне значення фінального поля буде видимим для інших потоків без синхронізації. Просте правило: посилання this не повинне покинути конструктор до його завершення.