Page 187 - 6571

рівнозначний наведеному нижче фрагменту коду.
public void method() {
this.intrinsicLock.lock();
try {
тіло методу;
} finally {
this.intrinsicLock.unlock();

}
}

Наприклад, замість явного блокування можна просто
оголосити метод transfer() визначений в класі Bank із
ключовим словом synchronized. При цьому, вбудоване
блокування має єдину пов’язану з нею умову.

Окрім звичайних методів, допускається оголошувати
синхронізованими також і статичні методи. Коли викликається
такий метод, то він захоплює вбудоване блокування об’єкта

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

Вбудованим блокуванням притаманні деякі обмеження, в
тому числі наведені нижче:
1. Не можливо перервати потік, який намагається захопити

блокування.
2. Не можливо вказати час очікування, намагаючись захопити
блокування.
3. Наявність єдиної умови на блокування може виявитися

неефективним.
Що ж все-таки краще використовувати: об’єкти типу Lock та

Condition чи синхронізовані методи? Нижче наведені деякі
рекомендації, які дають відповідь на це питання:
1. Краще не користуватися ні об’єктами типу
Lock / Condition, ні ключовим словом synchronized. У

більшості випадків замість цього можна використати відповідний
клас з пакету java.util.concurrent, який реалізує

автоматичне блокування.
2. Якщо для розв’язання конкретної задачі підходить
ключове слово synchronized, то його неодмінно потрібно

186