У меня есть класс утилиты, который имеет нестатические методы без переменных экземпляра. Поэтому я думаю о преобразовании всех методов в методы static. Я сомневаюсь, что будет какое-то влияние на память или производительность. Но я просто хотел подтвердить.
Будет ли изменение такого метода в static иметь какое-либо влияние на производительность программы?
Последнее, что нужно добавить к тому, что сказали здесь люди.
Использование метода static имеет несколько меньшие накладные расходы из-за того, что вы гарантировали привязку времени компиляции. При вызове статических методов будет создана команда байт-кода invokestatic. ]
В типичном сценарии методы экземпляра привязаны во время выполнения и создадут инструкцию байт-кода invokevirtual, которая имеет более высокие накладные расходы, чем invokestatic.
Однако это становится актуальным только в случае вероятных миллионов итераций, и я бы предостерег от этого, управляя дизайном вашего класса. Сделайте то, что имеет смысл с точки зрения дизайна. Основываясь на вашем описании, методы static - это, вероятно, путь. На самом деле это стандартная практика создания класса утилиты:
public class MyUtilities {
private MyUtilities() { } // don't let anyone construct it.
public static String foo(String s) { ... }
}
EDIT: решение аспекта производительности: дешевле не создавать экземпляр чего-то бессмысленного, но разница, скорее всего, будет совершенно неактуальной. Сосредоточение внимания на четком дизайне гораздо более вероятно будет иметь важное значение с течением времени.
Утилиты часто статичны, и если все методы внутри класса являются статичными, вполне возможно, стоит сделать класс final и включить частный конструктор для предотвращения создания. По сути, с полезными классами, которые не представляют никакой реальной "вещи", логически не нужно строить экземпляр - так что не мешайте ему.
С другой стороны, это уменьшает гибкость: если какой-либо из этих служебных методов содержит функциональные возможности, которые вы можете изменять полиморфно (например, для целей тестирования), подумайте о том, чтобы оставить их в качестве методов экземпляра - и попытайтесь извлечь какое-либо значащее имя класса для представления "вещи". (Например, a FooConverter имеет смысл создать экземпляр - a FooUtil нет.)
Если класс утилиты не является подклассом, методы преобразования, которые не имеют доступа к переменным экземпляра в static, являются хорошей идеей. Вы должны пройти через код и преобразовать вызовы в статический синтаксис, т.е.
int res = utilityInstance.someMethod(arg1, arg2);
следует преобразовать в
int res = UtilityClass.someMethod(arg1, arg2);
для ясности.
Не будет заметного влияния на производительность: хотя теоретически статические вызовы немного менее дороги, разница слишком мала, чтобы считать важным в большинстве сценариев.
Для того, чтобы метод имел право на преобразование в static, необходимо выполнить два требования:
Однако, когда эти требования выполняются, на самом деле рекомендуется сделать статический метод, поскольку он сужает контекст, в котором запущен метод.
Наконец, обратите внимание на то, что здесь нет проблем с производительностью, и любая теоретическая разница на самом деле в пользу статических методов, поскольку они не связаны с разрешением динамического метода. Тем не менее, вызов метода экземпляра быстро растет в любой соответствующей реализации JVM.
Что касается памяти, то история одна и та же: теоретическая разница в пользу статического метода, но нет никакой практической разницы, если сравнивать с однотипным классом утилиты.
Обычно классы полезности без состояния (например, java.lang.Math например) имеют общедоступные статические методы. Таким образом вам не нужно создавать экземпляр класса для его использования.
Статический метод хорошая идея, когда вы собираетесь использовать конкретную функциональность очень часто.
Разница в том, что вам нужен экземпляр для их использования, поэтому пользователь должен создать экземпляр, который будет