Если мое приложение имеет слишком много статических переменных или методов, то согласно определению они будут храниться в куче. Пожалуйста, поправьте меня, если я ошибаюсь
1) Будут ли эти переменные находиться в куче до закрытия приложения?
2) Будут ли они доступны для GC в любое время? Если нет, я могу сказать, что это утечка памяти?
Статические методы - это просто методы, они не хранятся в куче, они просто не могут использовать параметр "this".
Статические переменные служат "корнями" для GC. В результате, если вы явно не установили их равными нулю, они будут жить до тех пор, пока программа будет жить, и поэтому все будет доступно для них.
Ситуация считается только утечкой памяти, если вы намерены освободить память, и она не станет свободной. Если вы хотите, чтобы ваша статическая переменная содержала ссылку на объект в течение части времени, и вы забудете установить значение null, когда вы закончите с этим объектом, вы, скорее всего, закончите утечку. Однако, если вы поместите его в статическую переменную и намереваетесь, чтобы он был там до тех пор, пока программа работает, то это определенно не утечка, скорее это "постоянный синглтон". Если объект был восстановлен, пока вы хотите, чтобы он все еще существовал, это было бы очень плохо.
Что касается вашего вопроса о куче: все объекты в Java существуют либо в куче, либо в стеке. Объекты создаются в куче с новым оператором. Затем к ним прикрепляется ссылка. Если ссылка становится нулевой или выпадает из области действия (например, конец блока), GC понимает, что нет возможности снова достичь этого объекта и восстановить его. Если ваша ссылка находится в статической переменной, она никогда не выпадает из области видимости, но вы все равно можете установить ее в null или на другой объект.
Если у вас есть статический хэш файл и вы добавляете в него данные... данные никогда не исчезнут, и у вас будет утечка - если вам больше не нужны данные. Если вам нужны данные, это не утечка, а огромная куча памяти, висящая вокруг.
Объекты, которые прямо или косвенно ссылаются на статику, остаются в куче до тех пор, пока не будет собран соответствующий загрузчик классов. Есть случаи (например, ThreadLocal), где другие объекты косвенно ссылаются на загрузчик классов, заставляя его оставаться неподключенным.
Если у вас есть статический список, скажем, и добавьте ссылки на него динамически, то вы можете очень легко в конечном итоге "решить проблемы со сроком жизни объекта". Избегайте изменчивой статики по многим причинам.
Пока вы можете ссылаться на эти переменные где-то в коде, это не может GCed, что означает, что они будут там до конца приложения.
Можете ли вы назвать это утечкой памяти, я бы не назвал ее утечкой памяти, обычно утечка памяти - это память, которую вы обычно ожидаете восстановить, но вы никогда этого не делаете, или вы только возвращаете ее часть. Также утечка памяти обычно ухудшается во времени (например: каждый раз, когда вы вызываете метод, больше памяти "утечка" ), однако в этом случае использование памяти для этих переменных является (вроде) статичным.
Это не вызовет утечку памяти в классическом смысле C... Например
Class A{
static B foo;
...
static void makeFoo(){
foo = new B();
foo = new B();
}
В этом случае вызов makeFoo() не приведет к утечке памяти, так как первым экземпляром может быть сбор мусора.