Может использование слишком многих статических переменных вызывать утечку памяти в Java?
121 - целочисленное представление символа y. Поскольку вы предоставили i как часть выражения, компилятор интерпретирует его как вызов System.out.print(int) вместо System.out.print(char).
Обратите внимание, что при изменении на System.out.print(false ? (char)i : y); печатается y.
5 ответов
Статические методы являются просто методами, они не хранятся на "куче", они просто не добираются для использования "этого" параметра.
Статические переменные служат "корнями" к GC. В результате, если Вы явно не устанавливаете их в NULL, они будут жить пока жизни программы и так являются всем достижимым от них.
ситуацию с А только считают утечкой памяти, если Вы предназначаете, чтобы память стала свободной, и это не становится свободным. Если Вы предназначаете, чтобы Ваша статическая переменная содержала ссылку на объект для части времени, и Вы забываете устанавливать его в NULL, когда Вы сделаны с тем объектом, Вы, вероятно, закончили бы с утечкой. Однако, если Вы помещаете его в статическую переменную и предназначаете, чтобы это было там столько, сколько программа работает, тогда это - совершенно определенно не утечка, это более вероятно "постоянный одиночный элемент". Если объект был исправлен, в то время как Вы хотели, чтобы он все еще существовал, который будет очень плох.
Что касается Вашего вопроса о "куче": Все объекты в Java существуют или на "куче" или на стеке. Объекты создаются на "куче" с новым оператором. Ссылка тогда присоединена к ним. Если ссылка становится пустой или падает из объема (например, конец блока), GC понимает, что нет никакого способа достигнуть того объекта когда-либо снова и не исправляет его. Если Ваша ссылка находится в статической переменной, она никогда не падает из объема, но можно все еще установить ее в NULL или к другому объекту.
Если у Вас будет статический hashmap, и Вы добавляете данные к нему, то... данные никогда не будут исчезать, и у Вас есть утечка - в случае, если Вам больше не нужны данные. При необходимости в данных это не утечка, а огромная груда бродящей вокруг памяти.
Объекты, на которые прямо или косвенно ссылаются помехи, останутся на "куче", пока соответствующий загрузчик класса не сможет быть собран. Существуют случаи (ThreadLocal, например), где другие объекты косвенно ссылаются на загрузчик класса, заставляющий его оставаться неинкассированными.
, Если Вы имеете статический Список, скажем, и добавляете ссылки на него динамично, тогда можно очень легко закончить с "объектными пожизненными состязательными проблемами". Избегайте изменяемых помех по многим причинам.
Пока можно сослаться на эти переменные от где-нибудь в коде, он не может GCed, что означает, что они будут там до конца приложения.
Может Вы называть это утечкой памяти, я не назвал бы это утечкой памяти, обычно утечка памяти является памятью, которую Вы обычно ожидаете восстанавливать, но Вы никогда не делаете, или Вы только восстанавливаете часть его. Также утечки памяти обычно ухудшаются вовремя (например: каждый раз, когда Вы называете метод, больше памяти "пропущено"), однако в этом случае, использование памяти для тех переменных (довольно) статично.
Это не вызовет утечку памяти в классическом смысле C... Например
Class A{
static B foo;
...
static void makeFoo(){
foo = new B();
foo = new B();
}
В этом случае, вызов к makeFoo () не приведет к утечке памяти, поскольку первая инстанция может быть собрана "мусор".