JRE32ビットと64ビット
私はしばらくの間Javaを使用しており、新しい開発マシンをセットアップするという私の典型的な儀式には、Oracleのサイトから最新のJDKをダウンロードしてインストールするという規範が必要です。
これは今日、珍しい質問を引き起こしました、does it matter if I use the 32bit or 64bit JRE bundle?
振り返ってみると、以前は両方のバージョンをインストールしていて、通常のツールチェーンは（Eclipse）に問題なくプラグインされています。私の日常のプログラミングでは、64ビットJREを使用していた（またはその点で64ビットJREをターゲットにしていた）という理由だけで、何かを変更したり、別の方法で何かを考えたりする必要があったことを覚えていません。
64ビットと32ビットの私の理解から-それは実際には数字がカバーの下にどのように格納されるかに要約されます...そして私はintが32ビットであり、longが64ビットであることを知っています... floatが32ビットで、doubleが64ビットであるのと同じです。つまり、Javaがこの微妙な点さえも抽象化しただけで、おそらくずっと「64ビット互換」でしたか？
64ビットのJREを32ビットのシステムにインストールできないことに加えて、ここで何かが欠けていると確信しています。
64ビットと32ビットは、実際には、数値のサイズではなく、オブジェクト参照のサイズに要約されます。
32ビットモードでは、参照は4バイトであるため、JVMは2 ^ 32バイトのメモリを一意にアドレス指定できます。これが、32ビットJVMが最大ヒープサイズ4GBに制限されている理由です（実際には、他のJVMおよびOSのオーバーヘッドのために制限は小さく、OSによって異なります）。
64ビットモードでは、参照は（驚きの）8バイトであるため、JVMは2 ^ 64バイトのメモリを一意にアドレス指定できます。これは、誰にとっても十分なはずです。 64ビットモードのJVMヒープサイズ（-Xmxで指定）は非常に大きくなる可能性があります。
ただし、64ビットモードにはコストが伴います。参照のサイズが2倍になり、メモリ消費量が増加します。これが、Oracleが "Compressed oops" を導入した理由です。圧縮されたoopsを有効にすると（現在はデフォルトだと思います）、オブジェクト参照は4バイトに縮小されますが、ヒープは40億オブジェクト（および32GB Xmx）に制限されていることに注意してください。圧縮されたoopsは無料ではありません。メモリ消費のこの大幅な削減を達成するには、わずかな計算コストがかかります。
個人的な好みとして、私は常に64ビットJVMを自宅で実行しています。 CPUはx64に対応しており、OSも対応しているので、JVMも64ビットモードで実行するのが好きです。
お気づきのように、Javaのプリミティブ数値型は明確に定義されています。
ただし、32ビットと64ビットのJVMの選択は、Javaアプリケーションがネイティブを使用している場合はが重要です-コードライブラリ。32ビットアプリケーション、64ビットアプリケーション、またはその両方で使用するために構築できます。
32ビットアプリケーションのみをサポートするネイティブライブラリがある場合は、32ビットJVMを使用するか、64ビットバージョンのライブラリをビルドする必要があります。
コンテキストに応じて、ローカル開発では常に64ビットJDKを使用します。主な理由は、ビルドとIDEのためにメモリスペース全体が必要になる可能性があるためです。
それは本番環境への統合について言われていますが、可能であれば32ビットをお勧めします。どうして？
一部のJava本番用にライセンスされているEEサーバーの場合、どのマシンのコア数などのいくつかの要因によって異なります。特にWebSphere Liberty Profileの場合、2GBに制限されます。
64ビットJREはわずかに多くのメモリを消費し、2GB以上で2x 1GBクラスターのようなものに制限しようとすると、1セントも払わずに回避できるフレックススペースが増えます。
から https://plumbr.eu/blog/Java/should-i-use-32-or-64-bit-jvm
問題1：64ビットでは30〜50％のヒープが必要です。なぜそうなのか？主に64ビットアーキテクチャのメモリレイアウトが原因です。まず第一に、オブジェクトヘッダーは64ビットJVMでは12バイトです。次に、オブジェクト参照は、JVMフラグとヒープのサイズに応じて、4バイトまたは8バイトのいずれかになります。これにより、32ビットのヘッダーの8バイト、および参照の4バイトと比較して、確実にオーバーヘッドが追加されます。オブジェクトのメモリ消費量の計算の詳細については、以前の投稿の1つを掘り下げることもできます。
問題2：ガベージコレクションの一時停止が長くなります。より多くのヒープを構築することは、未使用のオブジェクトからそれをクリーンアップする間、GCによって実行されるより多くの作業があることを意味します。実生活での意味は、12〜16GBを超えるヒープを構築する場合は特に注意する必要があるということです。微調整や測定を行わなくても、数分間にわたる完全なGC一時停止を簡単に導入できます。レイテンシーが重要ではなく、スループットを最適化できるアプリケーションでは、これだけで問題ないかもしれませんが、ほとんどの場合、これは目を見張るものになる可能性があります。
Java EE環境への影響を制限するには、その一部を、検索用のElasticSearch、キャッシュ用のHazelcast、データストレージ用のデータベースなどの他のマイクロサービスにオフロードし、Java EEサーバーは、アプリケーションコア内でサービスを実行するのではなく、アプリケーションコア自体をホストします。
考慮すべき2つの主な違いがあると思います。 1つはここで言及されていますが、もう1つは言及されていません。
一方では、他に述べたように、メモリとデータ型。 32ビットと64ビットのJVMは、異なるネイティブデータ型サイズとメモリアドレス空間を使用します。
- 64ビットのJVMは、32ビットのJVMよりも多くのメモリを割り当てることができます（使用できます）。
- 64ビットは、より多くの容量を持つネイティブデータ型を使用しますが、より多くのスペースを占有します。そのため、同じオブジェクトがより多くのスペースを占める可能性があります。
- ガベージコレクター（GC）がマシンをフリーズするJVMの場合、GCがより大きなヒープ/オブジェクトをチェックする必要があり、時間がかかるため、64ビットバージョンは遅くなる可能性があります。
- IBMプレゼンテーション これらの違いを説明しています。
一方、サポートされているネイティブライブラリ。 Java JNIを使用してネイティブライブラリにアクセスするプログラムには、JVMのタイプに応じて異なるバージョンが必要です。
- 32ビットJVMは32ビットネイティブライブラリを使用し、64ビットJVMは64ビットライブラリを使用します。
- つまり、プログラムでSWTなどのネイティブコードに依存するライブラリを使用する場合は、それらの異なるバージョンが必要になります。 SWTダウンロードページ に注意してください。Linux/ Windows32ビットと64ビットには異なるバージョンがあります。 32ビットと64ビットには 異なるバージョンのEclipse （それぞれ異なるバージョンのSWT）があることに注意してください。
- Alloyなどの一部のアプリケーションは、32ビットのネイティブライブラリにパッケージ化されています。 64ビットJVMでは失敗します。これらの問題は、対応する64ビットのネイティブライブラリをダウンロードし、JNIを適切に構成するだけで解決できます。
32ビットJVMと64ビットJVMの違いを理解する必要がありますか？
パフォーマンスが重要なアプリケーションを構築していない場合は、違いを理解する必要はありません。 32ビットJVMと64ビットJVMの微妙な違いは、アプリケーションに大きな違いはありません。あなたはさらに読むことをスキップすることができます
64ビットJVMは32ビットJVMよりもパフォーマンスが優れていますか？
私たちのほとんどは、64ビットは32ビットよりも大きいと考えているため、64ビットのJVMのパフォーマンスは32ビットのJVMのパフォーマンスよりも優れています。残念ながら、そうではありません。 64ビットJVMは、32ビットJVMよりもパフォーマンスがわずかに低下する可能性があります。以下は、64ビットJVMのパフォーマンスに関するOracleJDKドキュメントからの抜粋です。
「一般に、大量のメモリに対応できるという利点は、32ビットVMで同じアプリケーションを実行する場合と比較して、64ビットVMでのパフォーマンスの低下がわずかです。
64ビットプラットフォームで実行されているアプリケーションとSPARC）で実行されている32ビットプラットフォームを比較した場合のパフォーマンスの違いは、64ビットVMに移行すると10〜20％程度低下します。 AMD64およびEM64Tプラットフォームでは、アプリケーションにアクセスするポインターの量に応じて、この差は0〜15％の範囲になります。」
2ビットJVMまたは64ビットJVMはもう重要ではありません。
32ビットJVMから64ビットJVMに移行する際に考慮すべきことは何ですか？ a。 GC一時停止時間
32ビットJVMから64ビットJVMに移行する主な理由は、大きなヒープサイズ（つまり-Xmx）を実現するためです。ヒープサイズを増やすと、自動的にGCの一時停止時間が長くなり始めます。これは、メモリ内にクリアするガベージが増えるためです。移行を行う前に適切なGCチューニングを行う必要があります。そうしないと、アプリケーションで数秒から数分の一時停止時間が発生する可能性があります。
b。ネイティブライブラリ
アプリケーションがJava Native Interface（JNI）を使用してネイティブライブラリにアクセスしている場合は、ネイティブライブラリもアップグレードする必要があります。32ビットJVMは32ビットネイティブライブラリしか使用できないためです。同様に、64ビットJVMは64ビットネイティブライブラリのみを使用できます。