- The data in shallow is not how much, how much. Instead of starting with 16 bytes in a 64-bit JVM dump, and then increasing the number of 8 bytes, you'll find that 1 byte fields and 2 byte fields are station 16 bytes, 5 bytes in a byte field, and 24 bytes in the beginning with hidden overhead. This is done for byte alignment, a multiple of 8 bytes under 64 bits, and a multiple of 4 bytes under 32 bits. This also introduces the question of how much memory an int occupies in 32 bits and under 64 bits. I prefer that the base type occupies a certain number of bytes, but if byte alignment is required, there is room for redundancy, and this redundant space is not counted on the underlying type but on the object. Because of the byte-aligned relationship, the small object is more wasteful of memory in 64 bits than in 32 bits.
- The specific data in retained is important, and many people mistakenly think that the retained of an object is the object that it is associated with, or is pulling on, and that this understanding is itself a mistake. C can be a traction, C can also be B traction, then when the calculation of retained, C in the end is to calculate the retained of a or on the B retained? If an object is retained by its association, or the object being towed is interpreted at all, because the observed result is that C does not count to a retained and not to the retained of B. The correct understanding is that the retained of an object is the amount of memory space (object collection) that the object can free when it is in the GC. After selecting the AB show retained set you can see that C is only counted in retained.
Mat analysis of two bugs that are often misunderstood in JVM dump
