Java Singleton против статики – есть ли реальный выигрыш в производительности?

Question

Я объединяю ветку CVS, и одним из наиболее крупных изменений является замена шаблона Singleton везде, где он встречается, абстрактными классами, имеющими статический блок инициализации и все статические методы.

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

Мы запускаем это приложение под управлением Weblogic 8.1 (то есть JDK 1.4.2).

---

извини, Томас, позволь мне уточнить..

версия HEAD имеет традиционный шаблон Singleton (частный конструктор, getInstance() и т.д.)

версия ветки не имеет конструктора, является «публичным абстрактным классом» и изменила все методы объекта на «статические».Код, который раньше существовал в частном конструкторе, перемещается в статический блок.

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

Есть несколько случаев, когда это изменение было сделано.

Answer 1

С точки зрения строгой производительности во время выполнения разница действительно незначительна.Основное различие между ними заключается в том, что «статический» жизненный цикл связан с загрузчиком классов, тогда как для синглтона это обычный жизненный цикл экземпляра.Обычно лучше держаться подальше от ClassLoader, так вы избежите некоторых сложных проблем, особенно при попытке перезагрузить веб-приложение.

Answer 2

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

Answer 3

Статика плоха для расширяемости, поскольку статические методы и поля не могут быть расширены или переопределены подклассами.

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

Синглтон, как правило, является хорошим шаблоном, если использовать его экономно.Я предпочитаю использовать структуру DI и позволить ей управлять моими экземплярами за меня (возможно, в разных областях, как в Guice).

Answer 4

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

Задайте себе эти вопросы:

1. Объект Singleton делает то, что я делаю, более понятным?
2. Нужен ли мне объект для выполнения этой задачи или он больше подходит для статических методов?
3. Нужна ли мне производительность, которую я могу получить, не используя синглтон?

Answer 5

По моему опыту, единственное, что имеет значение, это то, какой из них легче имитировать в модульных тестах.Я всегда считал, что над Синглтоном высмеивать проще и естественнее.Если ваша организация позволяет вам использовать JMockit, это не имеет значения, поскольку вы можете преодолеть эти проблемы.

Answer 6

Поможет ли это обсуждение?(Не знаю, запрещено ли ссылаться на другой форум по программированию, но я бы не стал просто цитировать всю дискуссию =) )

ВС Дискуссия на эту тему

Судя по всему, вердикт таков: в большинстве случаев это не имеет большого значения, хотя технически статические методы более эффективны.

Answer 7

Напишите код для измерения производительности.Ответ будет зависеть от JVM (JDK от Sun может работать иначе, чем JRockit) и флагов виртуальной машины, которые использует ваше приложение.