为什么在Java中创建一个MAX_INT大小的数组是不可能的？

Question

我已阅读此问题的一些答案（Why I can't create an array with large size?和https://bugs.openjdk.java.net/browse/JDK-8029587），我不理解以下内容。 “在GC代码中，我们将字中大小的对象作为int来传递。”据我所知，JVM中一个单词的大小是4个字节。据此，如果我们以int的形式传递长整型大数组（例如，MAX_INT - 5）的大小，我们必须通过得到OutOfMemoryException请求的数组大小超过了VM限制，因为大小太大即使没有标题大小也是如此。那么为什么不同类型的数组对最大元素数有相同的限制？

Answer 1

只处理为什么不同类型的数组对最大元素数有相同的限制？部分：

因为它在实际中并不重要，但允许实现JVM的代码更简单。

当只有一个限制;对于各种阵列来说都是一样的;那么你可以使用该代码处理所有数组。而不是有很多类型特定的代码。

并且考虑到需要“大”数组的人仍然可以创建它们;只有那些需要真的很大的阵列受到影响;为什么花了这个努力？

Answer 2

答案是在jdk中，据我所知（我在看jdk-9）;还写它之后，我不知道这是否应该是一个评论，而不是（如果它回答您的问题），但它是一个评论太长......

首先错误是来自hotspot/src/share/vm/oops/arrayKlass.cpp这里抛出：

现在

if (length > arrayOopDesc::max_array_length(T_ARRAY)) { 
    report_java_out_of_memory("Requested array size exceeds VM limit"); 
    .... 
} 

，T_ARRAY实际上是BasicType类型的枚举，看起来像这样：

public static final BasicType T_ARRAY = new BasicType(tArray); 
// tArray is an int with value = 13 

这是第一个迹象表明，计算的最大尺寸时，JDK不护理该数组将保存什么（T_ARRAY未指定该数组将保存哪些类型）。

现在，真正验证了最大的数组大小的方法是这样的：

static int32_t max_array_length(BasicType type) { 
     assert(type >= 0 && type < T_CONFLICT, "wrong type"); 
     assert(type2aelembytes(type) != 0, "wrong type"); 

     const size_t max_element_words_per_size_t = 
     align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); 
     const size_t max_elements_per_size_t = 
     HeapWordSize * max_element_words_per_size_t/type2aelembytes(type); 
     if ((size_t)max_jint < max_elements_per_size_t) { 
     // It should be ok to return max_jint here, but parts of the code 
     // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for 
     // passing around the size (in words) of an object. So, we need to avoid 
     // overflowing an int when we add the header. See CRs 4718400 and 7110613. 
     return align_size_down(max_jint - header_size(type), MinObjAlignment); 
     } 
     return (int32_t)max_elements_per_size_t; 
} 

我没有去跳水进过多的代码，但它是基于HeapWordSize;这是8 bytes at least。 here是一个很好的参考（我试图把它看成代码本身，但有太多的参考）。