Использование явных блокировок считается дорогим?

Question

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

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

Я что-то здесь упускаю?

public class DemoClass
{
    private final Object lock = new Object();
    public void demoMethod(){
        synchronized (lock)
        {
            //other thread safe code
        }
    }
}

Answer 1

Использование явных блокировок считается дорогим?

Как правило, нет. Это не считается дорогим. (По модулю, что разные люди имеют разные мнения, а разные приложения предъявляют разные требования.)

Стоимость экземпляра блокировки Object составляет около 8 байт памяти плюс память для переменной, содержащей ссылку на блокировку. в родительском объекте. Это всего 12 или 16 байт.

Стоимость создания экземпляра блокировки Object составляет ... несколько наносекунд. (Не совсем точно, сколько, но это тривиально.)

Стоимость восстановления экземпляра блокировки Object, когда он становится мусором, обычно равна нулю. (Затраты G C возникают, когда замок и его родительский объект не являются мусором ...)

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

(Или, если вы решили установить / использовать блокировки на вещи, которые не нужно блокировать. Но это другая проблема.)

Существует (AFAIK) минимальная разница в стоимость приобретения или снятия блокировки на объекте явной блокировки по сравнению с получением / снятием блокировки на this. Возможно один доступ к памяти.

---

Для типичного приложения эти различия в стоимости не будут иметь значения. Будут более важные вещи для оптимизации. Действует стандартная рекомендация:

• Начните с простого ¹ . Простое проще писать и отлаживать ... и читать.
• Избегайте оптимизации слишком рано; например, во время написания кода.
• Проведите тестирование и профилируйте свою заявку до , которую вы оптимизируете.
• Используйте результаты измерений, чтобы решить, что стоит оптимизировать.

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

---

^{1 - достаточно просто для вас и ваших коллег. Это зависит от контекста.}