Производительность статического vs нестатического метода для класса полезности

Ответ 1

Последнее, что нужно добавить к тому, что сказали здесь люди.

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

В типичном сценарии методы экземпляра привязаны во время выполнения и создадут инструкцию байт-кода invokevirtual, которая имеет более высокие накладные расходы, чем invokestatic.

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

public class MyUtilities {
   private MyUtilities() { } // don't let anyone construct it.
   public static String foo(String s) { ... }
}

Ответ 2

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

Утилиты часто статичны, и если все методы внутри класса являются статичными, вполне возможно, стоит сделать класс final и включить частный конструктор для предотвращения создания. По сути, с полезными классами, которые не представляют никакой реальной "вещи", логически не нужно строить экземпляр - так что не мешайте ему.

С другой стороны, это уменьшает гибкость: если какой-либо из этих служебных методов содержит функциональные возможности, которые вы можете изменять полиморфно (например, для целей тестирования), подумайте о том, чтобы оставить их в качестве методов экземпляра - и попытайтесь извлечь какое-либо значащее имя класса для представления "вещи". (Например, a FooConverter имеет смысл создать экземпляр - a FooUtil нет.)

Ответ 3

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

int res = utilityInstance.someMethod(arg1, arg2);

следует преобразовать в

int res = UtilityClass.someMethod(arg1, arg2);

для ясности.

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

Ответ 4

Для того, чтобы метод имел право на преобразование в static, необходимо выполнить два требования:

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

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

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

Что касается памяти, то история одна и та же: теоретическая разница в пользу статического метода, но нет никакой практической разницы, если сравнивать с однотипным классом утилиты.

Ответ 5

Обычно классы полезности без состояния (например, java.lang.Math например) имеют общедоступные статические методы. Таким образом вам не нужно создавать экземпляр класса для его использования.

Ответ 6

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

Ответ 7

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