Философия Java3
Шрифт:
lock.unlockO,
}
}
public static void main(String[] args) {
EvenChecker test(new MutexEvenGeneratorO).
}
} /// ~
MutexEvenGenerator добавляет мьютекс с именем lock и использует методы lock и unlock для создания критической секции в next. При использовании объектов Lock следует применять идиому, показанную в примере: сразу же за вызовом lock необходимо разместить конструкцию try-finally, при этом в секцию finally включается вызов unlock — только так можно гарантировать снятие блокировки.
Хотя try-finally требует большего объема кода, чем ключевое
В общем случае использование synchronized уменьшает объем кода, а также радикально снижает вероятность ошибки со стороны программиста, поэтому явные операции с объектами Lock обычно выполняются только при решении особых задач. Например, с ключевым словом synchronized нельзя попытаться получить блокировку с неудачным исходом или попытаться получить блокировку в течение некоторого промежутка времени с последующим отказом — в подобных случаях приходится использовать библиотеку concurrent:
//: concurrency/AttemptLocking java
// Объекты Lock из библиотеки concurrent делают возможными
// попытки установить блокировку в течение некоторого времени
import java.util.concurrent *;
import java util concurrent.locks.*;
public class AttemptLocking {
private ReentrantLock lock = new ReentrantLockO;
public void untimedO {
boolean captured = lock.tryLockO, try {
System.out printlnCtryLockO: " + captured); } finally {
if(captured)
lock unlockO;
}
}
public void timedO {
boolean captured = false; try {
captured = lock tryLock(2, TimeUnit SECONDS); } catch(InterruptedException e) {
throw new RuntimeException(e);
}
try {
System out println("tryLock(2. TimeUnit SECONDS): " +
captured),
} finally {
if(captured)
lock unlockO,
}
}
public static void main(String[] args) {
final AttemptLocking al = new AttemptLocking,
al untimedO. // True -- блокировка доступна al timedO. // True -- блокировка доступна // Теперь создаем отдельную задачу для установления блокировки new ThreadO {
{ setDaemon(true), } public void run {
al lock lockO.
System.out printlnC'acquired");
}
} startO,
Thread yieldO, // Даем возможность 2-й задаче al untimedO; // False -- блокировка захвачена задачей al.timedO. // False -- блокировка захвачена задачей
}
} /* Output-tryLockO. true
tryLock(2, TimeUnit.SECONDS): true acquired
tryLockO false
tryLock(2, TimeUnit SECONDS)- false */// ~
Класс ReentrantLock делает возможной попытку получения блокировки с последующим отказом от нее. Таким образом, если кто-то уже захватил блокировку, вы можете отказаться от своих намерений (вместо того, чтобы дожидаться ее освобождения). В методе timed делается попытка установления блокировки, которая может завершиться неудачей через 2
Атомарные операции и ключевое слово volatile
В дискуссиях, посвященных механизму потоков в Java, часто можно услышать такое утверждение: «Атомарные операции не требуют синхронизации». Атомарная операция — это операция, которую не может прервать планировщик потоков — если она начинается, то продолжается до завершения, без возможности переключения контекста (переключения выполнения на другой поток). Не полагайтесь на атомарность, она ненадежна и опасна — используйте ее вместо синхронизации только в том случае, если вы являетесь экспертом в области синхронизации или, по крайней мере, можете получить помощь от такого эксперта.
Атомарные операции, упоминаемые в таких дискуссиях, включают в себя «простые операции» с примитивными типами, за исключением long и double.
Чтение и запись примитивных переменных гарантированно выполняются как атомарные (неделимые) операции. С другой стороны, JVM разрешается выполнять чтение и запись 64-разрядных величин (long и double) в виде двух раздельных 32-разрядных операций, с ненулевой вероятностью переключения контекста в ходе чтения или записи. Для достижения атомарности (при простом присваивании и возврате значений) можно определить типы long и double с модификатором volatile (учтите, что до выхода Java SE5 ключевое слово volatile не всегда работало корректно). Некоторые реализации JVM могут предоставлять более сильные гарантии, но вы не должны полагаться на платформенно-специ-фические возможности.
В многопроцессорных системах (которые в наши дни представлены многоядерными процессорами, то есть несколькими процесорами на одном чипе) видимость (visibility) играет гораздо более важную роль, чем в однопроцессорных системах. Изменения, вносимые одной задачей, — даже атомарные в смысле невозможности прерывания — могут оставаться невидимыми для других задач (например, если изменения временно хранятся в локальном кэше процессора). Таким образом, разные задачи будут по-разному воспринимать состояние приложения. Механизм синхронизации обеспечивает распространение видимости изменений, вносимых одной задачей в многопроцессорной системе, по всему приложению. Без синхронизации невозможно заранее предсказать, когда именно изменения станут видимыми.
Ключевое слово volatile обеспечивает видимость в рамках приложения. Если поле объявлено как volatile, это означает, что сразу же после записи в поле изменение будет отражено во всех последующих операциях чтения. Утверждение истинно даже при участии локальных кэшей — поля volatile немедленно записываются в основную память, и дальнейшее чтение происходит из основной памяти.
Если слепо следовать концепции атомарности, можно заметить, что метод getValue в следующем примере вроде бы отвечает этому описанию: