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

Question

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

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

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

---

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

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Вс. Обсуждение на эту тему

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