Примитивы статики Java, объекты, методы и куча (управление памятью и лучшие практики)

Question

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

Итак, вот что я знаю:

• Java "проходит по типу" - то есть примитивы передаются при копировании, а ссылки на объекты передаются при копировании(ссылки указывают на их объект в куче).

• Примитивные переменные экземпляра и ссылки живут в своем объекте класса в куче, а локальные примитивы и ссылки живут в стеке (в соответствующем кадре стека).

• Область памяти Perm Gen. - это место, где хранятся метаданные класса (используется для отражения).

• У кучи есть пространство Eden, где новые объекты - это места, пространство Young, где хранятся объекты, которые выжили в GC, и пространство Tenured, где размещаются долгоживущие объекты.

Итак, вот что я хотел бы понять :

• Где живут статические и статические конечные примитивы и ссылки в JVMможет использовать один экземпляр?

• Сохраняются ли статические и статические конечные объекты в куче (я предполагаю, что они перемещены в постоянные)?

• Что считается наилучшей практикой с точки зрения количества статических окончательных ссылок в приложении?

• Уменьшится ли создание дополнительных статических окончательных ссылокколичество пространства кучи в JVM?

Я прочитал много разных объяснений по этому поводу (все отличались), и мне бы очень хотелось, если бы опытный ветеран на языке Java смог дать хорошее объяснение.Заранее спасибо!

Answer 1

Молодое пространство включает в себя пространство Эдема и пространства выживших.

Где живут статические и статические конечные примитивы и ссылки, чтобы JVM могла использовать один экземпляр?

Не определено, но в JVM Sun / Oracle статические поля живут в специальном объекте для полей класса. У вас есть один экземпляр на загрузчик классов, поэтому у статических полей может быть несколько экземпляров.

Сохраняются ли статические и статические конечные объекты в куче (я предполагаю, что они перемещены в постоянные)?

В Sun / Oracle Java 7 они есть. Они могут быть в Пермском гене или где-нибудь еще.

Что считается наилучшей практикой с точки зрения количества статических окончательных ссылок в приложении?

Сведите их к минимуму.

Будет ли создание более статических окончательных ссылок уменьшать объем пространства кучи в JVM?

Если вы можете изменить конечное поле на статическое конечное поле, это может сэкономить некоторое пространство (если у вас несколько экземпляров). Однако ясность обычно важнее производительности. (И я бы сделал это для ясности)

Кстати: я работаю на Java уже 13 лет.

Так что может быть несколько экземпляров статических полей - JVM изменяет каждый экземпляр

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

если статическое поле изменено (т. Е. Static int instanceCount, где instanceCount ++ выполняется для каждой конструкции объекта)?

номер

Кроме того, объекты могут быть перемещены в Пермский генерал?

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

Считается ли Пермский генерал частью Кучи?

Это часть старого поколения = владение + постоянное поколение.

Молодой ген = Эдем + пространство выжившего * 2

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

Это верно для параллельного коллектора по умолчанию и одновременной развертки метки.

Коллектор G1 не разделяет пространства одинаково.

---

Ссылки для более подробной информации

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Терминология кучи Java: молодое, старое и постоянное поколение?

http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html