Java Singleton vs static - есть ли реальная производительность?

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Задайте себе следующие вопросы:

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

Ответ 5

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

Ответ 6

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

Обсуждение Sun по этому вопросу

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

Ответ 7

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