ヒープの容量は別として、JavaでInteger.MAX_VALUE制約を超える方法はありますか?
例は次のとおりです。
- コレクションは、それ自体をInteger.MAX_VALUEに制限します。
- StringBuilder / StringBufferは、それ自体をInteger.MAX_VALUEに制限します。
ヒープの容量は別として、JavaでInteger.MAX_VALUE制約を超える方法はありますか?
例は次のとおりです。
膨大なコレクションがある場合、2 31-1アイテムが含まれる前に、あらゆる種類の実用的な制限に達することになります。百万のアイテムが含まれているコレクションは、それよりも千倍以上多いコレクションは言うまでもなく、かなり扱いにくいものになります。
MAX_VALUE
同様に、StringBuilderは、実用的な目的には十分すぎるほどの制限に達する前に、サイズが2GBの文字列を作成できます。
これらの制限に達している可能性があると本当に思っている場合は、アプリケーションでデータを別の方法で、おそらくデータベースに保存する必要があります。
長いで?私のために働きます。
編集:ああ、質問の明確化。涼しい。私の新しく改善された答え:
ページングアルゴリズムを使用します。
偶然にも、最近、別の質問(javaのソートされた(メモリマップト?)ファイルでのバイナリ検索)について、java.nio.MappedByteBufferAPIのintパラメータを回避するためにページングアルゴリズムを作成しました。
それらのコレクションのソースコードに基づいて、長いsize()を持つ独自のコレクションを作成できます。たとえば、オブジェクトのより大きな配列を作成するには、配列の配列を作成します(そしてこれらをつなぎ合わせます)
このアプローチでは、ほぼ2^62個の要素が許可されます。
配列インデックスは、配列の物理サイズではなく、Integer.MAX_VALUEによって制限されます。
したがって、配列の最大サイズは配列タイプのサイズにリンクされます。
byte = 1 byte => max 2 Gb data
char = 2 byte => max 4 Gb data
int = 4 byte => max 8 Gb data
long = 8 byte => max 16 Gb data
辞書は、バケットや内部データレイアウトなどの手法をツリーとして使用することが多いため、別の話になります。したがって、これらの「制限」は通常は適用されません。制限に達するには、さらに多くのデータが必要になります。
短い:実際に制限に達するには大量のメモリが必要なため、Integer.MAX_VALUEは実際には制限ではありません。この制限に達した場合は、アルゴリズムやデータレイアウトの改善を検討することをお勧めします:)
はい、BigIntegerクラスを使用します。
メモリのアップグレードが必要です.. :)