Java 对于这个特定的内部非静态类，是否有显著的开销？

我正在为学校作业编写我自己的双链接列表实现，我在列表类中使用了一个名为

node

的内部节点类，它表示相互链接的列表节点（链接列表通常就是这种情况）

类双链接列表
{
类节点
{
T-obj；
}
}

我想知道，对于具有多个节点的大型列表，由于每个

节点
对象都可能引用父列表类的一个实例，这是否是一个显著的开销和次优设计？将其作为一个非静态类使用当然很方便-然后节点可以更改父列表
first
和
last
引用，我发现这对于封装非常有用

如果我将
节点
设置为静态，它就不能再（没有对列表的明确成员引用）用于操作父列表
第一个
和
最后一个
，我必须从另一个角度来处理它-列表将通过自己的方法分配和操作节点，即将它们彼此链接，取消链接并自然调整其
第一个
和
最后一个
值

为了更好的设计和学习，我想知道什么是明智的做法（c）（如果有的话）？
如果内部类不是
静态的
，那么对父类的隐式引用已经存在，您可以通过
双链接列表来引用它。这是
节点内部的
类

在任何情况下，我都不明白为什么
节点
类应该能够直接修改其父类的属性。改变列表的方法（也包括
first
和
last
）应该是
DoubleLinkedList
类，而不是直接属于
Node
类。这正是为了封装，一个
节点
实例不应该知道它包含在什么地方，也不应该知道如何从外部使用它。
开销正好是每个节点一个引用。假设除了有效负载之外，节点还具有前向链路和后向链路，在额外的内存使用中，对父节点的额外引用的开销将达到大约33%（1个引用位于3个现有引用之上）。这是相当大的开销，特别是对于大节点数和小有效负载。另一方面，有了更大的有效载荷，这也没什么大不了的

不过，一般来说，我不会对有效负载大小进行假设，而是将节点类设置为静态的，谢谢。这不是我第一次实现双链表。我以前是按照你建议的方式做的，但出于某种有趣的原因，我觉得值得一试。我现在为一个静态节点类重构了它。我不认为让它成为静态的有什么意义。如果您接受您的
节点
类使用对列表实例的引用，那么这两个类都是紧密耦合的：没有父类的
节点
实例没有任何意义（因为它使用对它的引用），因此允许在没有
双链接列表
的封闭实例的情况下进行实例化是没有意义的。如果你让它
成为静态的
，你可以通过设计随时实例化它，这会破坏整个行为。好吧，对我来说，开销是决定性的因素，我只是为了方便，才将类设置为非静态的。我将其设置为静态，从而解决了不必要的开销问题，并将引用列表的方法从节点类移到列表类本身。在大多数情况下，我没有失去任何东西，而是获得了尺寸和速度优势。类之间的耦合现在也更加松散，代码也更加可移植（在我的例子中这并不重要），因为并非所有OOP语言都支持非静态类。将方法移到内部类之外确实是最好的选择。但是如果使用非静态类，则可以通过
DoublyLinkedList获得对父类的引用。这样就不会有任何开销。您不必在内部类中存储任何局部变量就可以访问包含该局部变量的类。
class DoublyLinkedList<T>
{
    class Node
    {
        T obj;
    }
}