Глава 17. Потоки и блокировки

Действия ожидания происходят при вызове wait() или временных формах wait(long millisecs) и wait(long millisecs, int nanosecs).

Вызов wait(long millisecs) с параметром ноль или вызов wait(long millisecs, int nanosecs) с двумя нулевыми параметрами эквивалентен вызову wait().

Поток возвращается нормально из ожидания, если он возвращается без выбрасывания InterruptedException.

Пусть поток t выполняет метод wait на объекте m, и пусть n — количество действий блокировки потоком t на m, которые не были согласованы действиями разблокировки. Происходит одно из следующих действий:

Действия уведомления происходят при вызове методов notify и notifyAll.

Пусть поток t выполняет любой из этих методов на объекте m, и пусть n — количество действий блокировки потоком t на m, которые не были согласованы действиями разблокировки. Происходит одно из следующих действий:

Действия прерывания происходят при вызове Thread.interrupt, а также методов, определяющих его вызов, таких как ThreadGroup.interrupt.

Пусть t — поток, вызывающий u.interrupt для некоторого потока u, где t и u могут быть одинаковыми. Это действие приводит к установке состояния прерывания u в истинное.

Кроме того, если существует какой-либо объект m, чей набор ожидания содержит u, то u удаляется из набора ожидания m. Это позволяет u возобновить действие ожидания, в котором после повторной блокировки монитора m будет сгенерировано исключение InterruptedException.

Вызовы Thread.isInterrupted могут определять состояние прерывания потока. Метод static Thread.interrupted может быть вызван потоком для наблюдения и очистки собственного состояния прерывания.

Вышеперечисленные спецификации позволяют нам определить несколько свойств, связанных с взаимодействием ожиданий, уведомлений и прерываний.

Если поток как уведомлен, так и прерван во время ожидания, он может:

Поток не может сбросить свой статус прерывания и вернуться нормально из вызова wait.

Аналогично, уведомления не могут быть потеряны из-за прерываний. Предположим, что множество s потоков находится в наборе ожиданий объекта m, а другой поток выполняет операцию notify для m. Тогда либо:

Обратите внимание, что если поток прерывается и пробуждается посредством notify, а этот поток возвращается из wait, выбросив исключение InterruptedException, то какой-то другой поток в наборе ожиданий должен быть уведомлен.

Память, которую можно использовать совместно между потоками, называется совместной памятью или кучей.

Все поля экземпляров, поля static и элементы массивов хранятся в куче. В этой главе мы используем термин переменная для обозначения как полей, так и элементов массивов.

Локальные переменные (§14.4), формальные параметры методов (§8.4.1) и параметры обработчика исключений (§14.20) никогда не используются совместно между потоками и не затрагиваются моделью памяти.

Два доступа к (чтения или записи) одной переменной называются конфликтующими, если по крайней мере один из доступов является записью.

Действие между потоками — это действие, выполняемое одним потоком, которое может быть обнаружено или непосредственно повлиять на другой поток. Существует несколько видов действий между потоками, которые может выполнять программа:

Этот спецификация касается только действий между потоками. Мы не должны беспокоиться о действиях внутри потока (например, сложение двух локальных переменных и сохранение результата в третьей локальной переменной). Как уже упоминалось ранее, все потоки должны подчиняться правильным внутрипоточным семантикам для Java-программ. Мы обычно будем ссылаться на действия между потоками более кратко, как просто действия.

Действие a описывается кортежем < t, k, v, u >, состоящим из:

Кортеж внешнего действия содержит дополнительный компонент, который содержит результаты внешнего действия, воспринимаемые потоком, выполняющим действие. Это может быть информация о успехе или неудаче действия, и любые значения, прочитанные действием.

Параметры внешнего действия (например, какие байты записываются в какой сокет) не входят в кортеж внешнего действия. Эти параметры настраиваются другими действиями в потоке и могут быть определены путем проверки внутрипотоковой семантики. Они не обсуждаются в явном виде в модели памяти.

При выполнении бесконечных циклов не все внешние действия наблюдаемы. Бесконечные циклы и наблюдаемые действия обсуждаются в §17.4.9.

Среди всех действий между потоками, выполняемых каждым потоком t, порядок программы для t — это полный порядок, который отражает порядок, в котором эти действия будут выполняться согласно внутрипотоковой семантике t.

Набор действий последовательно согласован, если все действия происходят в полном порядке (порядке выполнения), который согласован с порядком программы, и кроме того, каждое чтение r переменной v видит значение, записанное записью w в v таким образом, что:

Последовательная согласованность — очень сильная гарантия, которая дается относительно видимости и порядка в выполнении программы. В рамках последовательно согласованного выполнения существует полный порядок всех отдельных действий (например, чтений и записей), который согласуется с порядком программы, и каждое отдельное действие является атомным и немедленно видно каждому потоку.

Если программа не имеет гонок данных, то все выполнения программы будут казаться последовательно согласованными.

Последовательная согласованность и/или отсутствие гонок данных все еще допускают ошибки, возникающие из-за групп операций, которые должны восприниматься атомарно и не являются таковыми.

Если бы мы использовали последовательную согласованность как нашу модель памяти, многие из упомянутых нами оптимизаций компилятора и процессора были бы незаконными. Например, в трассировке в Table 17.4-C, как только произошла запись 3 в p.x, последующие чтения этого места должны были бы увидеть это значение.

Каждое выполнение имеет порядок синхронизации. Порядок синхронизации — это общий порядок всех действий синхронизации в выполнении. Для каждой нити t порядок синхронизации действий синхронизации (§17.4.2) в t согласуется с порядком программы (§17.4.3) нити t.

Действия синхронизации вызывают отношение synchronized-with между действиями, определяемое следующим образом:

Источник synchronizes-with связи называется освобождением, а место назначения — приобретением.

Два действия могут быть упорядочены отношением happens-before. Если одно действие happens-before другое, то первое действие видно и упорядочено перед вторым.

Если у нас есть два действия x и y, мы записываем hb(x, y), чтобы указать, что x происходит до y.

Методы wait класса Object (§17.2.1) имеют связанные с ними действия блокировки и разблокировки; их отношения happens-before определяются этими связанными действиями.

Следует отметить, что наличие отношения happens-before между двумя действиями не обязательно подразумевает, что они должны выполняться в этом порядке в реализации. Если переупорядочение приводит к результатам, согласованным с законным выполнением, это не является незаконным.

Например, запись значения по умолчанию в каждый поле объекта, созданного потоком, не обязательно должна происходить до начала работы этого потока, пока ни один чтение не обнаружит этот факт.

Более конкретно, если два действия разделяют отношение happens-before, они не обязательно должны казаться произошедшими в этом порядке для любого кода, с которым они не разделяют отношение happens-before. Например, записи в одном потоке, которые находятся в гонке данных с чтениями в другом потоке, могут, по-видимому, происходить в неправильном порядке для этих чтений.

Отношение happens-before определяет, когда происходят гонки данных.

Набор синхронизационных рёбер S является достаточным, если это минимальный набор, такой что транзитивное замыкание S с порядком программы определяет все рёбра happens-before в выполнении. Этот набор уникален.

Из вышеперечисленных определений следует, что:

Когда программа содержит два конфликтующих доступа (§17.4.1), которые не упорядочены отношением happens-before, говорят, что программа содержит гонку данных.

Семантика операций, отличных от межпоточных действий, таких как чтение длин массивов (§10.7), выполнения проверок типов (§5.5, §15.16) и вызова виртуальных методов (§15.12), непосредственно не затрагиваются гонками данных.

Поэтому гонка данных не может привести к неправильному поведению, например, возвращению неправильной длины массива.

Программа корректно синхронизирована тогда и только тогда, когда все последовательно согласованные выполнения свободны от гонок данных.

Если программа корректно синхронизирована, то все выполнения программы будут казаться последовательно согласованными (§17.4.3).

Это чрезвычайно сильная гарантия для программистов. Программисты не должны рассматривать переупорядочения, чтобы определить, содержит ли их код гонки данных. Поэтому им не нужно задумываться о переупорядочениях при определении, корректно ли синхронизирован их код. После того, как было установлено, что код корректно синхронизирован, программист не должен беспокоиться о том, что переупорядочения повлияют на его код.

Программа должна быть корректно синхронизирована, чтобы избежать непонятного поведения, которое может наблюдаться при переупорядочении кода. Использование корректной синхронизации не гарантирует правильности поведения всей программы. Однако его использование позволяет программисту просто рассуждать о возможных поведениях программы; поведение корректно синхронизированной программы гораздо менее зависит от возможных переупорядочений. Без корректной синхронизации возможны очень странные, запутанные и непонятные поведения.

Мы говорим, что чтение r переменной v может наблюдать запись w в v, если в частичном порядке happens-before следа выполнения:

Неформально, чтение r может увидеть результат записи w, если нет упорядочения happens-before, препятствующего этому чтению.

Набор действий A является согласованным по happens-before, если для всех чтений r в A, где W(r) — действие записи, видимое r, не выполняется ни hb(r, W(r)), ни то, что существует запись w в A такая, что w.v = r.v и hb(W(r), w) и hb(w, r).

В наборе действий, согласованном по happens-before, каждое чтение видит запись, которую оно может увидеть согласно упорядочению happens-before.

1: B = 1;
3: A = 2;
2: r2 = A;  // sees initial write of 0
4: r1 = B;  // sees initial write of 0

1: r2 = A;  // sees write of A = 2
3: r1 = B;  // sees write of B = 1
2: B = 1;
4: A = 2;

Выполнение E описывается кортежем < P, A, po, so, W, V, sw, hb >, включающим:

Обратите внимание, что элементы синхронизируется-с и происходит-до однозначно определяются другими компонентами выполнения и правилами для корректных выполнений (§17.4.7).

Выполнение является согласованным по принципу происходит-до, если его набор действий является согласованным по принципу происходит-до (§17.4.5).

Мы рассматриваем только корректные выполнения. Выполнение E = < P, A, po, so, W, V, sw, hb > является корректным, если следующие утверждения верны:

Для программ, которые всегда завершаются в какой-то ограниченной конечной период времени, их поведение может быть понято (неформально) просто в терминах их допустимых исполнений. Для программ, которые могут не завершиться за ограниченное время, возникают более тонкие вопросы.

Наблюдаемое поведение программы определяется конечными множествами внешних действий, которые программа может выполнить. Программа, которая, например, просто бесконечно печатает "Hello", описывается набором поведений, которые для любого неотрицательного целого числа i включают поведение печати "Hello" i раз.

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

Мы также определяем специальное действие hang. Если поведение описывается множеством внешних действий, включающих действие hang, это указывает на поведение, где после наблюдения внешних действий программа может выполняться неограниченное время без выполнения дополнительных внешних действий или завершения. Программы могут зависнуть, если все потоки заблокированы или если программа может выполнить неограниченное число действий без выполнения каких-либо внешних действий.

Поток может быть заблокирован в различных обстоятельствах, например, когда он пытается получить блокировку или выполнить внешнее действие (например, чтение), которое зависит от внешних данных.

Выполнение может привести к тому, что поток будет заблокирован неопределенно, и выполнение не завершится. В таких случаях действия, сгенерированные заблокированным потоком, должны состоять из всех действий, сгенерированных этим потоком до и включая действие, которое привело к блокировке потока, и ни одного действия, которое было бы сгенерировано потоком после этого действия.

Чтобы рассуждать о наблюдаемых поведении, нам нужно говорить о множествах наблюдаемых действий.

Если O — множество наблюдаемых действий для выполнения E, то множество O должно быть подмножеством действий E, A, и должно содержать только конечное число действий, даже если A содержит бесконечное число действий. Кроме того, если действие y находится в O, и либо hb(x, y), либо so(x, y), то x находится в O.

Обратите внимание, что множество наблюдаемых действий не ограничивается внешними действиями. Скорее, только внешние действия, которые находятся в множестве наблюдаемых действий, считаются наблюдаемыми внешними действиями.

Поведение B является допустимым поведением программы P тогда и только тогда, когда B является конечным множеством внешних действий и либо:

Обратите внимание, что поведение B не описывает порядок наблюдения внешних действий в B, но другие (внутренние) ограничения на то, как генерируются и выполняются внешние действия, могут накладывать такие ограничения.

Пусть o — объект, а c — конструктор для o, в котором записывается final поле f. Действие замораживания final поля f объекта o происходит при выходе c, как нормальным, так и аварийным способом.

Обратите внимание, что если один конструктор вызывает другой конструктор, и вызванный конструктор устанавливает final поле, замораживание для final поля происходит в конце вызванного конструктора.

Для каждого выполнения поведение чтений определяется двумя дополнительными частичными порядками, цепочкой ссылок dereferences() и цепочкой памяти mc(), которые считаются частью выполнения (и, следовательно, фиксированы для любого конкретного выполнения). Эти частичные порядки должны удовлетворять следующим ограничениям (у которых не должно быть единственного решения):

Учитывая запись w, замораживание f, действие a (которое не является чтением final поля), чтение r₁ final поля, замороженного f, и чтение r₂, такое, что hb(w, f), hb(f, a), mc(a, r₁) и dereferences(r₁, r₂), то при определении, какие значения могут быть прочитаны r₂, мы рассматриваем hb(w, r₂). (Этот happens-before порядок не транзитивно закрывается с другими happens-before порядками.)

Обратите внимание, что порядок dereferences рефлексивен, и r₁ может быть таким же, как r₂.

Для чтений final полей, единственными записями, которые считаются предшествующими чтению final поля, являются те, которые получены через семантику final поля.

Чтение final поля объекта в потоке, который строит этот объект, упорядочено относительно инициализации этого поля в конструкторе обычными правилами happens-before. Если чтение происходит после установки поля в конструкторе, оно видит значение, присвоенное final полю; в противном случае оно видит значение по умолчанию.

В некоторых случаях, например, при десериализации, системе потребуется изменить поля final объекта после его создания. Поля final могут быть изменены с помощью рефлексии и других средств, зависящих от реализации. Единственный шаблон, в котором это имеет разумную семантику, — это такой, в котором объект создаётся, а затем поля final объекта обновляются. Объект не должен быть видимым для других потоков, и поля final не должны читаться, пока не будут завершены все обновления полей final объекта. Заморозки поля final происходят как в конце конструктора, в котором устанавливается поле final, так и сразу после каждого изменения поля final с помощью рефлексии или другого специального механизма.

Даже тогда существует ряд сложностей. Если поле final инициализируется константным выражением (§15.29) в объявлении поля, изменения поля final могут не быть замечены, так как использование этого поля final заменяется на значение константного выражения на этапе компиляции.

Другая проблема заключается в том, что спецификация допускает агрессивную оптимизацию полей final. В рамках одного потока разрешается переупорядочивать чтение поля final с теми изменениями поля final, которые не происходят в конструкторе.

class A {
    final int x;
    A() { 
        x = 1; 
    } 

    int f() { 
        return d(this,this); 
    } 

    int d(A a1, A a2) { 
        int i = a1.x; 
        g(a1); 
        int j = a2.x; 
        return j - i; 
    }

    static void g(A a) { 
        // uses reflection to change a.x to 2 
    } 
}

Реализация может предоставить способ выполнения блока кода в final-безопасном контексте для полей. Если объект создан в final-безопасном контексте для полей, чтение поля final этого объекта не будет переупорядочено с изменениями этого поля final, которые происходят в этом final-безопасном контексте для полей.

final-безопасный контекст для полей имеет дополнительные защиты. Если поток увидел неправильно опубликованную ссылку на объект, которая позволяет потоку увидеть значение по умолчанию поля final, а затем в final-безопасном контексте для полей прочитает правильно опубликованную ссылку на объект, ему гарантированно будет показано правильное значение поля final. В формализме код, исполняемый в final-безопасном контексте для полей, рассматривается как отдельный поток (только для целей семантики поля final).

В реализации компилятор не должен перемещать доступ к полю final в или из final-безопасного контекста для полей (хотя он может быть перемещён вокруг выполнения такого контекста, если объект не создаётся в этом контексте).

Одно место, где использование final-безопасного контекста для полей будет уместно, — это в исполнителе или пуле потоков. Выполняя каждый Runnable в отдельном final-безопасном контексте для полей, исполнителю можно гарантировать, что неправильный доступ одного Runnable к объекту o не лишит final гарантий для других Runnable, обрабатываемых тем же исполнителем.

Обычно поле, которое является final и static, не может быть изменено. Однако, поля System.in, System.out и System.err являются защищёнными от записи static final полями, которые по причинам совместимости должны быть разрешены для изменения методами System.setIn, System.setOut и System.setErr. Мы называем эти поля защищёнными от записи для отличия от обычных полей final.

Компилятор должен по-разному обрабатывать эти поля по сравнению с другими полями final. Например, чтение обычного поля final «иммунно» к синхронизации: барьер, связанный с блокировкой или чтением `volatile`, не должен влиять на то, какое значение читается из поля final. Поскольку значение защищённых от записи полей может изменяться, события синхронизации должны влиять на них. Таким образом, семантика предписывает обрабатывать эти поля как обычные поля, которые нельзя изменить кодом пользователя, если этот код пользователя не находится в классе System.