Экземпляр класса C# со статическим методом по сравнению со статическим использованием памяти класса
Как делает C# или другие языки в этом отношении, обработайте выделение памяти (и освобождение памяти) между этими двумя сценариями:
1.) Метод на статическом классе вызывается.
public Program {
Foo foo = Loader.load();
}
public static Loader {
public static Foo load() {
return new Foo();
}
}
2.) Метод вызывается на экземпляр, который тогда падает из объема.
public Program {
Foo foo = new Loader().load();
}
public Loader {
public Foo load() {
return new Foo();
}
}
Я предполагаю, что статический класс загружается и остается в памяти; тогда как экземпляр класса уступает сборке "мусора" на досуге C#. Есть ли какие-либо профессионалы или недостатки к этим двум парадигмам? Существует ли когда-нибудь время, когда у Вас есть класс, который никогда нельзя инстанцировать (т.е. своего рода загрузчик ресурса или фабрика), но Вы используете вторую методологию так или иначе для использования в своих интересах сборки "мусора"?
Важная часть моего вопроса - может ли первая парадигма, будучи концептуально корректной при некоторых обстоятельствах, пострадать от того, чтобы держаться за память излишне.
4 ответа
Ваш второй пример не работает, поэтому давайте рассмотрим реальные варианты:
1.) Вызывается метод статического класса.
public Program {
Foo foo = Loader.Load();
}
public static Loader {
public static Foo Load() {
return new Foo();
}
}
2.) Вызывается статический метод в нестатическом классе.
public Program {
Foo foo = Loader.Load();
}
public Loader {
public static Foo Load() {
return new Foo();
}
}
3.) Метод экземпляра вызывается для экземпляра
public Program {
Foo foo = new Loader().Load();
}
public Loader {
public Foo Load() {
return new Foo();
}
}
Два первых одинаковы. Вызов статического метода одинаков, независимо от того, является ли класс статическим или нет.
Третий вариант создаст экземпляр класса в куче. Поскольку у класса нет членов данных, он будет иметь размер примерно 16 байт. В конечном итоге он будет собран в мусор, но из-за небольшого размера это не имеет большого значения, когда это произойдет.
Вызов метода экземпляра также немного отличается от статического метода. Отправляется ссылка на экземпляр класса, доступ к которому можно получить с помощью ключевого слова this . В этом случае это не имеет большого значения, поскольку в объекте нет реальных данных для доступа.
Я не могу найти никаких источников для этого, но, исходя из моих знаний программирования, когда вы ссылаетесь на класс (нестатический), его структура загружается в память
Создание экземпляра класса только для вызова метода потребует больших затрат вычислительной мощности (из-за создания экземпляра, присвоения ему памяти и сбора мусора).
Вместо того, чтобы сохранять определение, а затем поверх него - экземпляр. Почему бы просто не оставить определение (статичное).
Пока вы не храните какие-либо данные в статических переменных, ваш статический метод должен занимать тот же объем памяти, что и определение нестатического метода. Но при использовании статического метода только метод будет храниться в памяти и быть готовым к вызову в любое время без создания экземпляров. Если, как, например, если метод не является статическим, его нужно будет создать (используя память и вычислительную мощность) и собрать мусор (освободить память и использовать процессор), поэтому определенно лучше использовать статический член. Вот для чего они нужны.
Статический метод, поле, свойство или событие могут быть вызваны в классе, даже если экземпляр класса не был создан.
http://msdn.microsoft.com/en-us/library/79b3xss3 (VS.80) .aspx
Итак, в этом смысле ваши статические методы ведут себя так же, как если бы вы использовали их из класса экземпляр: он привязан к типу.
Вторая форма создает временный объект Loader (что очень дешево). Вам всегда придется загружать класс Loader, независимо от того, какой подход вы выберете.
Здесь очень мало производительности (экономия памяти). Обычно вы выбираете статический член в статическом классе, если нет необходимости в «состоянии» за пределами локальных переменных методов.