java - 关于内存分配的几个问题

Question

我尝试找到它，但我没有适当的术语知识，也无法在 Google 上提出正确的问题。

第一:我正在制作一个类似于树的结构，其中一个对象具有子级映射，子级和下一个对象相同......

public class Attribute
{
    private String key;
    private int value;
    private HashMap<String, Attribute> modifiers;

    public Attribute(String key, int value)
    {
        this.key = key;
        this.value = value;
    }
}

MODIFIERS 仅在您实际放入某些内容时才会初始化(使用本地 void 方法 ofc)。 HashMap 在 JUST 声明上使用了多少内存(如果有的话)(如上面的代码)？

第二:玩家已关闭。存储玩家所有数据的玩家对象。

public class Something
{
    private Player player;

    public Something() {}

    public Something(Player player)
    {
        this.player = player;
    }
}

1:类似的问题，如果我调用 Something()，未初始化的 PLAYER 对象是否使用了一些内存，多少？我在某处读到，当您声明“某物”时，内存是根据该“某物”的类型分配的。但它如何处理对象呢？

2:如果我调用 Something(Player 玩家)，并且由于我正在引用已经存在的对象，那么该引用使用多少内存？ (this.PLAYER = 玩家)我猜这样的引用就像指针一样，但是它使用了多少内存，对于Java中的所有对象来说它都是恒定的吗？

Answer 1

这取决于虚拟机。在大多数情况下，对于 32 位 Oracle JVM 或堆空间小于约 32GB 的 64 位 Oracle JVM 7+ 实例，它将增加 4 个字节。

无论是 null 还是引用对象，空间使用都是相同的(尽管显然引用的对象有自己的空间要求)。

这是来自 Oracle's tech notes on JavaSE 7 JVM enhancements 的副本:

Compressed Oops

An "oop", or ordinary object pointer in Java Hotspot parlance, is a managed pointer to an object. An oop is normally the same size as a native machine pointer, which means 64 bits on an LP64 system. On an ILP32 system, maximum heap size is somewhat less than 4 gigabytes, which is insufficient for many applications. On an LP64 system, the heap used by a given program might have to be around 1.5 times larger than when it is run on an ILP32 system. This requirement is due to the expanded size of managed pointers. Memory is inexpensive, but these days bandwidth and cache are in short supply, so significantly increasing the size of the heap and only getting just over the 4 gigabyte limit is undesirable.

Managed pointers in the Java heap point to objects which are aligned on 8-byte address boundaries. Compressed oops represent managed pointers (in many but not all places in the JVM software) as 32-bit object offsets from the 64-bit Java heap base address. Because they're object offsets rather than byte offsets, they can be used to address up to four billion objects (not bytes), or a heap size of up to about 32 gigabytes. To use them, they must be scaled by a factor of 8 and added to the Java heap base address to find the object to which they refer. Object sizes using compressed oops are comparable to those in ILP32 mode.

The term decode is used to express the operation by which a 32-bit compressed oop is converted into a 64-bit native address into the managed heap. The inverse operation is referred to as encoding.

Compressed oops is supported and enabled by default in Java SE 6u23 and later. In Java SE 7, use of compressed oops is the default for 64-bit JVM processes when -Xmx isn't specified and for values of -Xmx less than 32 gigabytes. For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature.