Java Statics Primitivas, objetos, métodos y el montón (gestión de memoria y mejores prácticas)

Question

Bien, entonces he estado desarrollando en Java desde hace poco más de un año y estoy haciendo un esfuerzo para profundizar en el lenguaje y su mejor prácticas.

Así que aquí es lo que sé:

• Java "pasa por tipo" - es decir primitivas pasan por copia y pase referencia de objeto de copia (referencias apuntan a su objeto en el montón).

• Las variables de instancia primitiva y las referencias viven en su objeto de clase en el montón y las primitivas locales y las referencias en vivo en la pila (en su respectivo marco de pila).

• Perm Gen. espacio de memoria es donde se almacenan metadatos de clase (utilizados para la reflexión).

• El Heap tiene un espacio Eden donde los objetos nuevos son lugares, un espacio Joven donde se guardan los objetos que han sobrevivido a un GC y un espacio Tenured donde se colocan objetos de larga vida.

Así que aquí es lo que me gustaría entender:

• ¿Dónde primitivas y referencias static final y estáticas en vivo que la JVM es capaz de utilizar una única instancia?

• ¿Están los objetos finales estáticos y estáticos almacenados en el Heap (supongo que se mueven a la tenencia)?

• ¿Cuál es la mejor práctica en cuanto a la cantidad de referencias finales estáticas en una aplicación?

• ¿La creación de más referencias finales estáticas disminuirá la cantidad de espacio de Heap en JVM?

He leído muchas explicaciones diferentes sobre esto (todo diferían) y me gustaría si es un veterano en el lenguaje Java podría proporcionar una buena explicación. ¡Gracias por adelantado!

Answer 1

El espacio juvenil incluye el espacio eden y los espacios para sobrevivientes.

¿Dónde viven las primitivas y referencias finales estáticas y estáticas que la JVM puede usar una sola instancia?

No está definido, pero en Sun/Oracle JVM, los campos estáticos viven en un objeto especial para los campos de clase. Tiene una instancia por cargador de clases, por lo que los campos estáticos pueden tener varias instancias.

¿Están los objetos finales estáticos y estáticos almacenados en el Heap (supongo que se mueven a la tenencia)?

En el Sun/Oracle Java 7 son. Podrían estar en Perm Gen o en cualquier otro lugar.

¿Cuál es la mejor práctica en cuanto a la cantidad de referencias finales estáticas en una aplicación?

Manténgalos al mínimo.

¿La creación de más referencias finales estáticas disminuye la cantidad de espacio de Heap en JVM?

Si puede cambiar un campo final en un campo final estático, esto puede ahorrar algo de espacio (si tiene varias instancias) Sin embargo, la claridad suele ser más importante que el rendimiento. (Y lo haría por claridad)

BTW: He estado desarrollando en Java durante 13 años.

lo tanto no puede haber varias instancias de los campos estáticos - no altera la JVM cada instancia

Son independientes. Cada cargador de clases puede cargar su propia versión de una clase (el código no tiene que ser el mismo) y cada uno obtiene sus propios campos estáticos (tampoco tienen que ser los mismos)

si una estática el campo se cambia (es decir, static int instanceCount donde se ejecuta el instanceCount ++ en cada construcción del objeto)?

Nº

Asimismo, los objetos se pueden mover a Perm Gen?

No. Algunos datos que no están definidos en una ubicación pueden estar en cualquier lugar, según la implementación y la versión.

¿Se considera que Perm Gen. es parte del Heap?

Es parte de la antigua gen = tenured + perm gen.

joven generación = + eden espacio sobreviviente * 2

Tamaño máximo de almacenamiento dinámico limita la generación joven & total del titular. Perm gen y memoria directa tienen sus propios límites. Los archivos de memoria mapeados siguen cualquiera de estos límites.

Esto es válido para el colector paralelo predeterminado y el barrido de marcas concurrente.

El colector G1 no divide los espacios de la misma manera.

---

enlaces para obtener más detalles

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

Java heap terminology: young, old and permanent generations?

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