Параллелизм в 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().

Выброшенное и необработанное исключение приведёт к завершению потока. Главный поток автоматически напечатает исключение в консоль, а потоки, созданные пользователем, могут сделать это только зарегистрировав обработчик.[1][2]

Коммуникация потоков осуществляется посредством разделения доступа к полям и объектам, на которые ссылаются поля. Данная форма коммуникации является предельно эффективной, но делает возможным возникновение ошибок двух разновидностей: вмешательство в поток (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).[4] В сущности, это отношение является гарантией того, что всё, что было видимо для потока A, когда он писал в volatile-поле f, становится видимым для потока B, когда он прочтёт f.

Volatile-поля являются атомарными. Чтение из volatile-поля имеет тот же эффект, что и получение блокировки: данные в рабочей памяти объявляются недействительными, значение volatile-поля заново читается из памяти. Запись в volatile-поле имеет тот же эффект для памяти, что и освобождение блокировки: volatile-поле немедленно записывается в память.

Поле, которое объявлено final, называется финальным и не может быть изменено после инициализации. Финальные поля объекта инициализируются в его конструкторе. Если конструктор соответствует определённым простым правилам, то корректное значение финального поля будет видимо для остальных потоков без синхронизации. Простое правило: ссылка this не должна покинуть конструктор до его завершения.