4

出于兴趣：最近，我在我的一个 Java 项目中遇到了一种情况，我可以将一些数据存储在二维数组中，或者为它创建一个专用类，我会将其实例放入一维数组中。所以我想知道在性能（运行时，内存消耗）方面是否存在一些关于这个主题的规范设计建议？

不考虑设计模式（极其简化的情况），假设我可以存储数据

class MyContainer {
  public double a;
  public double b;
  ...
}

接着

MyContainer[] myArray = new MyContainer[10000];
for(int i = myArray.length; (--i) >= 0;) {
  myArray[i] = new MyContainer();
}
...

相对

double[][] myData = new double[10000][2];  
...

我不知何故认为基于数组的方法应该更紧凑（内存）和更快（访问）。再说一次，也许不是，数组也是对象，数组访问需要检查索引，而对象成员访问不需要。（？）对象数组的分配可能（？）需要更长的时间，因为我需要迭代地创建由于额外的类，实例和我的代码会更大。

因此，我想知道常见 JVM 的设计是否在访问速度和内存消耗方面为一种方法提供了优于另一种方法的优势？

非常感谢。

4

3 回答 3

3

我在这种情况下看到的规范建议是，过早优化是万恶之源。遵循这意味着您应该坚持使用最容易编写/维护/通过代码质量制度的代码，然后如果您有可衡量的性能问题，请查看优化。

在您的示例中，内存消耗是相似的，因为在对象情况下，您有 10,000 个引用加上每个引用两个双精度值，而在二维数组情况下，您有 10,000 个引用（第一个维度）到每个包含两个双精度值的小数组。所以两者都是一个基本参考加上 10,000 个参考加上 20,000 个双精度。

更有效的表示是两个数组，其中有两个基本引用加上 20,000 个双精度数。

double[] a = new double[10000];
double[] b = new double[10000];
于 2015-10-08T02:56:40.393 回答
3

我不知何故认为基于数组的方法应该更紧凑（内存）和更快（访问）

它不会。您可以使用 Java 管理界面轻松确认这一点：

com.sun.management.ThreadMXBean b = (com.sun.management.ThreadMXBean) ManagementFactory.getThreadMXBean();
long selfId = Thread.currentThread().getId();
long memoryBefore = b.getThreadAllocatedBytes(selfId);

// <-- Put measured code here

long memoryAfter = b.getThreadAllocatedBytes(selfId);
System.out.println(memoryAfter - memoryBefore);

在测量的代码下new double[0]，new Object()您会看到这些分配将需要完全相同的内存量。

可能是 JVM/JIT 以一种特殊的方式处理数组，这可以使它们以一种或另一种方式更快地访问。

如果 for-loops ，JIT 会对数组操作进行一些向量化。但它更多的是关于算术运算的速度而不是访问速度。除此之外，什么都想不出来。

于 2015-10-08T02:37:16.277 回答
3

再说一次，也许不是，数组也是对象

这是正确的。所以我认为这种方法不会给你带来任何东西。

如果你想沿着这条路线走，你可以把它展平成一个一维数组（你的每个“对象”然后占用两个插槽）。这将使您可以立即访问所有对象中的所有字段，而无需遵循指针，并且整个事情只是一个大内存分配：由于您的组件类型是原始的，就内存分配而言只有一个对象（容器数组本身）。

这是人们希望在 Java 中拥有结构和值类型的动机之一，类似的考虑推动了专用高性能数据结构库的开发（摆脱了不必要的对象包装器）。

不过，在您真正拥有庞大的数据结构之前，我不会担心。只有这样，面向对象方式的开销才有意义。

于 2015-10-08T00:25:14.720 回答