Size of Java objects
The size of the basic data type is fixed, and there is no more to say. The size of a Java object of a non basic type is debatable.
In Java, the size of an empty object object is 8byte, which is just the size of the object in the heap that does not have any attributes. Look at the following statement:
Object ob = new Object();
This completes the life of a Java object in the program, but it occupies a space of: 4byte+8byte. 4byte is the space required to save references in the Java stack described in the above section. And that 8byte is the information of the objects in the Java heap. Because all Java-primitive types of objects need to inherit object objects by default, their size must be greater than 8byte, regardless of the Java object.
With the size of object objects, we can calculate the size of other objects.
Class NewObject {
int count;
boolean flag;
Object ob;
}
The size is: Empty object size (8byte) +int size (4byte) +boolean size (1byte) + null object reference size (4byte) =17byte. But because Java is divided into 8 integers in the allocation of object memory, the nearest 8 integer greater than 17byte is 24, so the size of this object is 24byte.
Here you need to pay attention to the size of the base type wrapper type. Because this type of packaging has become an object, it is necessary to treat them as objects. The size of the wrapper type is at least 12byte (the space required to declare an empty object), and 12byte does not contain any valid information, and because the Java object size is an integer multiple of 8, a base type wrapper class is at least 16byte in size. This memory footprint is very scary, it is using the basic type of N times (n>2), some types of memory footprint is exaggerated (just think about it). As a result, you should try to use less wrapper classes if possible. After JDK5.0, the Java virtual opportunities are optimized for storage because of the addition of automatic type replacement.
Reference type
Object reference types are divided into strong references, soft references, weak references, and virtual references.
Strong reference: That's what we typically declare an object is a reference generated by a virtual machine, a strong reference environment in which the current object is strongly referenced and, if strongly referenced, is not garbage collected
Soft references: Soft references are generally used as caching. The difference from strong references is that when a soft reference is garbage collected, the virtual opportunity decides whether to recycle the soft reference based on the remaining memory of the current system. If the remaining memory is tense, the virtual opportunity reclaims the space referenced by the soft reference, and if the remaining memory is relatively rich, it is not recycled. In other words, there must be no soft references when a virtual machine occurs outofmemory.
Weak references: Weak references are similar to soft references and are used as caches. However, unlike a soft reference, a weak reference is bound to be reclaimed when it is garbage collected, so its lifecycle exists only within a garbage collection cycle.
Strong references Needless to say, our system is generally used with strong references. "Soft references" and "weak references" are relatively rare. They are generally used as caching, and are generally cached in the case of a relatively limited memory size. Because if the memory is large enough, you can use a strong reference directly as a cache, while controllability is higher. Thus, they are commonly used in the caching of desktop application systems.