Подозрительно ли ключевое слово «синхронизированный» в классическом корпоративном приложении?

Question

Я говорю о классических корпоративных приложениях. Обычно размещается в каком-то приложении-сервере или контейнере. Ничего особенного, только сущности, сервисы, презентация / пользовательский интерфейс и реляционное хранилище.

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

Ты разделяешь мое мышление здесь? Или я совсем не в курсе? Есть ли у вас случаи использования, когда синхронизация действительно необходима в классическом корпоративном приложении?

Answer 1

Я согласен с вами в отношении кода бизнес-логики, но в корпоративном приложении у вас также есть технический код, и иногда вам требуется некоторая синхронизация для общего «технического» состояния. Синхронизированное ключевое слово может использоваться для этого. (Вы также можете ретранслировать атомарную переменную или использовать что-то вне вашего приложения, например последовательность БД, для обмена техническим состоянием ...)

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

Answer 2

Я согласен с вами.

Я думаю, что синхронизация важна при разработке поточно-ориентированных компонентов, но обычно это не требуется в коде "бизнес-логики".

Внедряя общее состояние, вы можете повысить производительность, но в будущем вы уменьшаете масштабируемость вашего приложения.

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