Java Singleton vs static - есть ли реальный выигрыш в производительности?
Я объединяю ветку CVS, и одним из самых больших изменений является замена шаблона Singleton абстрактными классами, которые имеют блок статической инициализации и все статические методы.
Стоит ли это сохранить, поскольку для этого потребуется слияние множества конфликтов, в какой ситуации я буду искать, чтобы этот рефакторинг был целесообразным?
Мы запускаем это приложение под Weblogic 8.1 (так что JDK 1.4.2)
прости Томас, позволь мне уточнить ..
версия HEAD имеет традиционный шаблон singleton (частный конструктор, getInstance () и т. д.)
версия ветки не имеет конструктора, является «общедоступным абстрактным классом» и изменила все методы объекта на «статические». Код, который раньше существовал в частном конструкторе, перемещается в статический блок.
Затем все использования класса изменяются, что вызывает множественные конфликты при слиянии.
Есть несколько случаев, когда это изменение было внесено.
Ответы 7
Это обсуждение помогает? (Я не знаю, запрещено ли ссылаться на другой форум по программированию, но я бы предпочел не просто цитировать всю дискуссию =))
Похоже, что вердикт таков, что в большинстве случаев это не имеет большого значения, хотя технически статические методы более эффективны.
С точки зрения производительности во время выполнения, разница действительно незначительна. Основное различие между ними заключается в том, что «статический» жизненный цикл связан с загрузчиком классов, тогда как для синглтона это обычный жизненный цикл экземпляра. Обычно лучше держаться подальше от бизнеса ClassLoader, вы избежите некоторых сложных проблем, особенно когда вы пытаетесь перезагрузить веб-приложение.
И? Все привязано к времени жизни ClassLoader, но, помещая синглтон, вы получаете дополнительный уровень жизненного цикла с большими шансами (завершить) для правильной обработки вещей.
Если мой исходный пост был правильным, а обсуждение Sun, на которое была ссылка, является точным (что, я думаю, может быть), то я думаю, вам нужно найти компромисс между ясностью и производительностью.
Задайте себе следующие вопросы:
- Объясняет ли объект Singleton то, что я делаю, более понятным?
- Нужен ли мне объект для выполнения этой задачи или он больше подходит для статических методов?
- Нужна ли мне производительность, которую я могу получить, не используя синглтон?
На самом деле вопрос заключается в приросте производительности :-) Предположим, у вас есть контроллер, который обрабатывает 100 запросов в секунду. актуально ли это для выбора между синглтоном или классом в качестве службы без отслеживания состояния?
Я бы использовал синглтон, если ему нужно было хранить какое-либо состояние, и статические классы в противном случае. Нет смысла создавать что-то, даже единичный, если только ему не нужно что-то хранить.
По моему опыту, единственное, что имеет значение, - это то, что легче имитировать в модульных тестах. Мне всегда казалось, что синглтон легче и естественнее высмеивать. Если ваша организация позволяет вам использовать JMockit, это не имеет значения, поскольку вы можете преодолеть эти проблемы.
Статика плохо сказывается на расширяемости, поскольку статические методы и поля не могут быть расширены или переопределены подклассами.
Также плохо для модульных тестов. В рамках модульного теста вы не можете предотвратить распространение побочных эффектов различных тестов, поскольку вы не можете управлять загрузчиком классов. Статические поля, инициализированные в одном модульном тесте, будут видны в другом, или, что еще хуже, одновременное выполнение тестов приведет к непредсказуемым результатам.
Синглтон обычно является хорошим шаблоном при умеренном использовании. Я предпочитаю использовать структуру DI и позволяю ей управлять моими экземплярами за меня (возможно, в разных областях, как в Guice).
Напишите код для измерения производительности. Ответ будет зависеть от JVM (Sun JDK может работать иначе, чем JRockit) и флагов виртуальной машины, которые использует ваше приложение.
Синглтон привязан к времени жизни ClassLoader загрузчика классов, который его загрузил, так же, как и статика.