liberar - Java: la variable nula requiere espacio en la memoria

guardar objetos en memoria java

Question

class CheckStore {
    private String displayText;
    private boolean state;
    private String meaningfulText;
    private URL url;

    public CheckStore(String text, boolean state) {
        this.displayText = text;
        this.state = state;
    }
    :
    :
}

Como estoy inicializando solo dos variables ( displayText y state ) en el constructor, las otras dos variables ( meaningfulText y url que tendrán el valor null ) requerirán espacio en la memoria para almacenar el valor null .

Q1. Creo que requerirán espacio. Si lo hacen, ¿cuánta memoria tiene un valor null en la memoria (como int toma 4 bytes)?

Q2. Cuánto espacio lleva una secuencia en la memoria. Supongo que dependerá de la longitud de la cadena. Entonces, ¿cuánto espacio ocupa una cuerda en cuanto a la longitud?

Answer 1

En Java, null es solo un valor que puede tener una referencia (que básicamente es un puntero restringido). Significa que la referencia no hace referencia a nada. En este caso, aún consume el espacio para la referencia. Esto es 4 bytes en sistemas de 32 bits u 8 bytes en sistemas de 64 bits. Sin embargo, no está consumiendo ningún espacio para la clase a la que apunta la referencia hasta que realmente asigne una instancia de esa clase para apuntar la referencia a.

Editar: En cuanto a la Cadena, una String en Java toma 16 bits (2 bytes) para cada carácter, más una pequeña cantidad de gastos generales de contabilidad, que probablemente no esté documentada y sea específica de la implementación.

Answer 2

Me gustaría agregar:

1. la variable de tipo de referencia se inicializará como valor nulo.
2. null no es un objeto. porque (instancia nula de objeto) es igual a falso

3. solo hay un valor nulo en JVM. No importa cuántas variables se refieran a nulo.

   Objeto s = (String) nulo;

   Objeto i = (Entero) nulo;

   System.out.println (s == i); // true

Answer 3

Nulo significa 0. Generalmente hay un lugar nulo definido en la memoria. Siempre que uno lo señale utilizando un lenguaje de programación. Todo apunta al mismo lugar. Significa que solo se consume una memoria de 4 bytes para NULL. Entonces, lo que sea que señale no consume más memoria. La definición de NULL es específica del lenguaje pero lo define void * ptr = 0; es común en C y C ++. JAVA debe haberlo definido de manera similar. No es posible señalar nada ofc. Tienes que señalar algo. Pero definimos una nada común y todo apunta a que solo consume ese espacio.

Answer 4

Puedes usar jol para obtener el diseño de esa clase. (Sin embargo, tenga cuidado, es posible que necesite una comprensión más profunda de la mecánica subyacente, no confíe ciegamente en el resultado y tenga en cuenta que es solo una estimación de la máquina virtual actualmente utilizada (1.7.0_76 x64 gana en mi caso :):

Utilizo la versión de CLI Supongo que el método correcto sería incluir la biblioteca en su proyecto, pero de todos modos, parece funcionar de esta manera:

test>java -cp target/classes;jol-cli-0.3.1-full.jar org.openjdk.jol.Main internals test.CheckStore
Running 64-bit HotSpot VM.
Using compressed oop with 0-bit shift.
Using compressed klass with 0-bit shift.
Objects are 8 bytes aligned.
Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

VM fails to invoke the default constructor, falling back to class-only introspection.

test.CheckStore object internals:
 OFFSET  SIZE    TYPE DESCRIPTION                    VALUE
      0    12         (object header)                N/A
     12     1 boolean CheckStore.state               N/A
     13     3         (alignment/padding gap)        N/A
     16     4  String CheckStore.displayText         N/A
     20     4  String CheckStore.meaningfulText      N/A
     24     4     URL CheckStore.url                 N/A
     28     4         (loss due to the next object alignment)
Instance size: 32 bytes (estimated, the sample instance is not available)
Space losses: 3 bytes internal + 4 bytes external = 7 bytes total

y lo mismo con oops automáticos comprimidos:

test>java -XX:-UseCompressedOops -cp target/classes;jol-cli-0.3.1-full.jar org.openjdk.jol.Main internals test.CheckStore
Running 64-bit HotSpot VM.
Objects are 8 bytes aligned.
Field sizes by type: 8, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
Array element sizes: 8, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

VM fails to invoke the default constructor, falling back to class-only  introspection.

test.CheckStore object internals:
 OFFSET  SIZE    TYPE DESCRIPTION                    VALUE
      0    16         (object header)                N/A
     16     1 boolean CheckStore.state               N/A
     17     7         (alignment/padding gap)        N/A
     24     8  String CheckStore.displayText         N/A
     32     8  String CheckStore.meaningfulText      N/A
     40     8     URL CheckStore.url                 N/A
Instance size: 48 bytes (estimated, the sample instance is not available)
Space losses: 7 bytes internal + 0 bytes external = 7 bytes total

Esos son solo los diseños para el objeto en sí, si sus campos son nulos, entonces no apuntará a más objetos, de lo contrario, tendrá que mirar los tipos de destino ( URL y String ) también. (Y si tiene varias instancias de todas ellas, depende si usa las mismas varias veces o diferentes). No se puede omitir un campo nulo en la memoria, ya que requeriría cambiar el tamaño de la instancia cuando se asigna. Entonces, todos los campos están preconstruidos, simplemente no hacen referencia a los objetos asignados en otro lugar en el montón.

NB: obtendrá más detalles si implementa un constructor predeterminado, pero el tamaño en este caso específico sería el mismo. En caso de que se pregunte de dónde viene la secuencia y el relleno de los campos, puede consultar este artículo - (básicamente alinea los objetos en 8 bytes, ordena los campos por tamaño, agrupa los mismos tipos juntos, las referencias son las últimas. Los campos de los supernombres son los primeros, 4 bytes alineados)