Wie kann ich feststellen, ob ich in einer 64-Bit-JVM oder einer 32-Bit-JVM arbeite (innerhalb eines Programms)?

Question

Wie kann ich feststellen, ob die JVM, in der meine Anwendung läuft, 32-Bit oder 64-Bit ist? Welche Funktionen oder Eigenschaften kann ich verwenden, um dies innerhalb des Programms zu erkennen?

Answer 1

Bei bestimmten Versionen von Java können Sie die Bitlastigkeit der JVM von der Kommandozeile aus mit den Flags -d32 y -d64 .

$ java -help
...
    -d32          use a 32-bit data model if available
    -d64          use a 64-bit data model if available

Um zu prüfen, ob eine 64-Bit-JVM vorhanden ist, führen Sie aus:

$ java -d64 -version

Wenn es sich nicht um eine 64-Bit-JVM handelt, erhalten Sie diese Meldung:

Error: This Java instance does not support a 64-bit JVM.
Please install the desired version.

Um zu prüfen, ob eine 32-Bit-JVM vorhanden ist, führen Sie einen ähnlichen Vorgang aus:

$ java -d32 -version

Wenn es sich nicht um eine 32-Bit-JVM handelt, erhalten Sie diese Meldung:

Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.

Diese Flags wurden in Java 7 hinzugefügt, Abgelehnt in Java 9, entfernt in Java 10 und ist in modernen Versionen von Java nicht mehr verfügbar.

Answer 2

Sie rufen die Systemeigenschaft die die Bitdichte dieser JVM mit markiert:

System.getProperty("sun.arch.data.model");

Mögliche Ergebnisse sind:

• "32" - 32-Bit-JVM
• "64" - 64-Bit-JVM
• "unknown" - Unbekannte JVM

Wie in der HotSpot-FAQ :

Wie kann ich beim Schreiben von Java-Code zwischen 32- und 64-Bit-Betrieb unterscheiden?

Es gibt keine öffentliche API, mit der man zwischen 32- und 64-Bit-Betrieb unterscheiden kann. Betrachten Sie 64-Bit als eine weitere Plattform in der Tradition von "write once, run anywhere". Wenn Sie jedoch Code schreiben möchten, der plattformspezifisch ist (Schande über Sie), hat die Systemeigenschaft sun.arch.data.model den Wert "32", "64" oder "unknown".

Ein Beispiel, bei dem dies notwendig sein könnte, ist, wenn Ihr Java-Code von nativen Bibliotheken abhängt und Sie festlegen müssen, ob beim Start die 32- oder 64-Bit-Version der Bibliotheken geladen werden soll.

Answer 3

Tippen Sie einfach java -version in Ihrer Konsole.

Wenn eine 64-Bit-Version ausgeführt wird, erhalten Sie eine Meldung wie diese:

java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)

Bei einer 32-Bit-Version wird etwas Ähnliches angezeigt:

java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Client VM (build 20.14-b01, mixed mode, sharing)

Hinweis Client の代わりに 64-Bit Server in der dritten Zeile. Die Client/Server Teil ist irrelevant, es ist das Fehlen des 64-Bit das zählt.

Wenn mehrere Java-Versionen auf Ihrem System installiert sind, navigieren Sie zum Ordner /bin der Java-Version, die Sie überprüfen möchten, und geben Sie ein java -version dort.

Answer 4

Ich installierte 32-Bit-JVM und versuchte es erneut, sieht aus wie die folgenden Sie JVM-Bitness, nicht OS arch angeben:

System.getProperty("os.arch");
#
# on a 64-bit Linux box:
# "x86" when using 32-bit JVM
# "amd64" when using 64-bit JVM

Dies wurde sowohl mit der SUN als auch mit der IBM JVM (32 und 64 Bit) getestet. Offensichtlich ist die Systemeigenschaft nicht nur der Betriebssystemarch.

Answer 5

Ergänzende Informationen:

Bei einem laufender Prozess die Sie verwenden können (zumindest bei einigen neueren Sun JDK5/6-Versionen):

$ /opt/java1.5/bin/jinfo -sysprops 14680 | grep sun.arch.data.model
Attaching to process ID 14680, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.5.0_16-b02
sun.arch.data.model = 32

wobei 14680 die PID des JVM ist, auf dem die Anwendung läuft. "os.arch" funktioniert auch.

Auch andere Szenarien werden unterstützt:

jinfo [ option ] pid
jinfo [ option ] executable core
jinfo [ option ] [server-id@]remote-hostname-or-IP 

Beachten Sie jedoch auch diesen Hinweis:

" NOTA - Dieses Dienstprogramm wird nicht unterstützt und kann in zukünftigen Versionen des JDK verfügbar sein oder auch nicht. Auf Windows-Systemen, auf denen dbgent.dll nicht vorhanden ist, müssen die "Debugging Tools for Windows" installiert werden, damit diese Tools funktionieren. Außerdem sollte die Umgebungsvariable PATH den Speicherort von jvm.dll enthalten, der vom Zielprozess verwendet wird, oder den Speicherort, von dem die Crash-Dump-Datei erzeugt wurde."