Java EE Подводные камни # 1: Игнорировать блокировку по умолчанию @Singleton

EJB Singleton Beans были введены спецификацией EJB 3.1 и часто используются для хранения кэшированных данных. Это означает, что мы пытаемся улучшить производительность нашего приложения с помощью Singleton. В целом, это работает довольно хорошо. Особенно если параллельно не слишком много звонков. Но это изменится, если мы проигнорируем блокировку по умолчанию и количество параллельных вызовов увеличится.

Разумные значения по умолчанию

Давайте начнем с некоторого кода Java и посмотрим, как работает разумное значение по умолчанию блокировки. В следующем фрагменте показан простой EJB Singleton со счетчиком и двумя методами. method1 записывает текущее значение счетчика в журнал, а method2 считает от 0 до 100.

Как видите, блокировка не определена. Что вы ожидаете увидеть в файле журнала, если мы вызовем оба метода параллельно?

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

Как этого избежать?

Ответ на этот вопрос очевиден, нам нужно позаботиться об управлении параллелизмом. Как обычно в Java EE, есть два способа справиться с этим. Мы можем сделать это сами или попросить контейнер сделать это.

Бин Управляемый Параллелизм

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

Управляемый контейнером параллелизм

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

Как мы видели в журнале, управляемый контейнером параллелизм является значением по умолчанию для EJB Singleton. Контейнер устанавливает блокировку записи для всего Singleton и сериализует все вызовы методов.

Мы можем изменить это поведение и определить блокировки чтения и записи на уровне метода и / или класса. Это можно сделать, аннотируя класс Singleton или методы с помощью @ javax.ejb.Lock (javax.ejb.LockType) . Перечисление LockType предоставляет значения WRITE и READ для определения исключительной блокировки записи или блокировки чтения.

В следующем фрагменте показано, как установить Lock для method1 и method2 в LockType.READ .

Как уже упоминалось, мы могли бы добиться того же, аннотируя класс с помощью @Lock (LockType.READ) вместо аннотирования обоих методов.

Хорошо, если все работает так, как ожидалось, оба метода должны быть доступны в paralel. Итак, давайте посмотрим на файл журнала.

Вывод

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

Мы рассмотрели два существующих варианта управления параллелизмом: параллельный управляемый компонент и управляемый контейнером параллелизм.

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