Come posso sapere se sto eseguendo JVM a 64 bit o JVM a 32 bit (dall'interno di un programma)?

Come posso sapere se la JVM in cui viene eseguita la mia applicazione è a 32 o 64 bit? In particolare, quali funzioni o proprietà posso utilizzare per rilevarlo all'interno del programma?

Si recupera la proprietà di sistema che contrassegna il testimone di questa JVM con:

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

I risultati possibili sono:

• "32" - JVM a 32 bit
• "64" - JVM a 64 bit
• "unknown" - JVM sconosciuto

Come descritto nelle FAQ di HotSpot :

Quando si scrive il codice Java, come si distingue tra operazioni a 32 e 64 bit?

Non esiste un'API pubblica che ti consenta di distinguere tra operazioni a 32 e 64 bit. Pensa a 64 bit come solo un'altra piattaforma nella scrittura una volta, esegui ovunque la tradizione. Tuttavia, se desideri scrivere un codice specifico per la piattaforma (peccato per te), la proprietà di sistema sun.arch.data.model ha il valore "32", "64" o "sconosciuto".

Un esempio in cui ciò potrebbe essere necessario è se il codice Java dipende dalle librerie native e è necessario determinare se caricare la versione a 32 o 64 bit delle librerie all'avvio.

Per alcune versioni di Java, è possibile controllare il testimone della JVM dalla riga di comando con i flag -d32e -d64.

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

Per verificare la presenza di una JVM a 64 bit, eseguire:

$ java -d64 -version

Se non è una JVM a 64 bit, otterrai questo:

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

Allo stesso modo, per verificare la presenza di una JVM a 32 bit, eseguire:

$ java -d32 -version

Se non è una JVM a 32 bit, otterrai questo:

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

Questi flag sono stati aggiunti in Java 7, deprecati in Java 9, rimossi in Java 10 e non più disponibili nelle versioni moderne di Java.

Digita la java -versiontua console.

Se è in esecuzione una versione a 64 bit, riceverai un messaggio del tipo:

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)

Una versione a 32 bit mostrerà qualcosa di simile a:

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)

Nota Clientinvece che 64-Bit Servernella terza riga. La Client/Serverparte è irrilevante, è l'assenza di 64-Bitciò che conta.

Se sul tuo sistema sono installate più versioni Java, vai alla cartella / bin della versione Java che desideri controllare e digita java -versionlì.

Ho installato JVM a 32 bit e riprovato di nuovo, sembra che quanto segue ti dice testimone JVM, non arco del sistema operativo:

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

Questo è stato testato sia su SUN che su IBM JVM (32 e 64 bit). Chiaramente, la proprietà di sistema non è solo l'arco del sistema operativo.

Informazioni complementari:

Durante un processo in esecuzione è possibile utilizzare (almeno con alcune versioni recenti di Sun JDK5 / 6):

$ /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

dove 14680 è PID di jvm che esegue l'applicazione. Anche "os.arch" funziona.

Sono supportati anche altri scenari:

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

Tuttavia considera anche questa nota:

" NOTA : questa utility non è supportata e potrebbe essere o non essere disponibile nelle versioni future di JDK. Nei sistemi Windows in cui dbgent.dll non è presente," Strumenti di debug per Windows "deve essere installato per far funzionare questi strumenti. Anche La variabile di ambiente PATH deve contenere il percorso di jvm.dll utilizzato dal processo di destinazione o il percorso da cui è stato prodotto il file Crash Dump. "

Su Linux, è possibile ottenere informazioni sull'intestazione ELF utilizzando uno dei due comandi seguenti:

file {YOUR_JRE_LOCATION_HERE}/bin/java

o / p: eseguibile LSB a 64 bit ELF , AMD x86-64, versione 1 (SYSV), per GNU / Linux 2.4.0, collegato dinamicamente (usa librerie condivise), per GNU / Linux 2.4.0, non rimosso

o

readelf -h {YOUR_JRE_LOCATION_HERE}/bin/java | grep 'Class'

o / p: Classe: ELF 64

Se si utilizza JNA, è possibile verificare se com.sun.jna.Native.POINTER_SIZE == 4(32 bit) o com.sun.jna.Native.POINTER_SIZE == 8(64 bit).

In Windows 7 nel " Pannello di controllo " in " Programmi | Programmi e funzionalità " le varianti a 64 bit di JRE e JDK sono elencate con " 64 bit " tra parentesi (ad es. " Aggiornamento 65 SE Java Kit di sviluppo 7 (64 bit) ) "), mentre per le varianti a 32 bit la variante non è menzionata tra parentesi (ad es. solo" Java SE Development Kit 8 Update 60 ").

Se stai usando JNA, puoi farlo Platform.is64Bit().

Per Windows, è possibile controllare la Javaposizione di casa. Se lo contiene (x86)è 32-bitaltrimenti 64-bit:

public static boolean is32Bit()
{
    val javaHome = System.getProperty("java.home");
    return javaHome.contains("(x86)");
}

public static boolean is64Bit()
{
    return !is32Bit();
}

Percorsi di esempio:

C:\Program Files (x86)\Java\jdk1.8.0_181\bin\java.exe # 32-bit
C:\Program Files\Java\jdk-10.0.2\bin\java.exe # 64-bit

Perché preoccuparsi di Windowsun'unica soluzione?

Se devi sapere su quale versione di bit stai eseguendo, probabilmente stai armeggiando con il codice nativo su in Windowsmodo che l'indipendenza dalla piattaforma sia fuori dalla finestra comunque.

Per ottenere la versione di JVM attualmente in esecuzione il programma

System.out.println(Runtime.class.getPackage().getImplementationVersion());