Jak mogę sprawdzić, czy korzystam z 64-bitowej JVM czy 32-bitowej JVM (z poziomu programu)?

Jak mogę sprawdzić, czy JVM, w którym działa moja aplikacja, jest 32-bitowy czy 64-bitowy? W szczególności, jakich funkcji lub właściwości mogę użyć do wykrycia tego w programie?

Ci odzyskać właściwości systemu , który wyznacza bitness tego JVM z:

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

Możliwe wyniki to:

• "32" - 32-bitowa JVM
• "64" - 64-bitowa JVM
• "unknown" - Nieznany JVM

Zgodnie z opisem w HotSpot FAQ :

Jak pisząc kod Java, jak odróżnić operacje 32- i 64-bitowe?

Nie ma publicznego interfejsu API, który pozwala rozróżnić operacje 32- i 64-bitowe. Myśl o wersji 64-bitowej jako o jednej platformie do zapisu, działającej wszędzie. Jeśli jednak chcesz napisać kod specyficzny dla platformy (wstydź się), właściwość systemowa sun.arch.data.model ma wartość „32”, „64” lub „nieznany”.

Przykładem, w którym może to być konieczne, jest to, jeśli kod Java zależy od bibliotek rodzimych i należy określić, czy podczas uruchamiania należy załadować 32- lub 64-bitową wersję bibliotek.

W przypadku niektórych wersji Java można sprawdzić bitowość JVM z wiersza polecenia za pomocą flag -d32i -d64.

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

Aby sprawdzić 64-bitową maszynę JVM, uruchom:

$ java -d64 -version

Jeśli nie jest to 64-bitowa maszyna JVM, otrzymasz:

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

Podobnie, aby sprawdzić 32-bitową maszynę JVM, uruchom:

$ java -d32 -version

Jeśli nie jest to 32-bitowa maszyna JVM, otrzymasz:

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

Te flagi zostały dodane w Javie 7, przestarzałe w Javie 9, usunięte w Javie 10 i nie są już dostępne w nowoczesnych wersjach Java.

Po prostu wpisz java -versionswoją konsolę.

Jeśli działa wersja 64-bitowa, pojawi się komunikat:

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)

Wersja 32-bitowa pokaże coś podobnego do:

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)

Uwaga Clientzamiast 64-Bit Serverw trzeciej linii. Ta Client/Serverczęść jest nieistotna, liczy się jej brak 64-Bit.

Jeśli w systemie zainstalowanych jest wiele wersji Java, przejdź do folderu / bin wersji Java, którą chcesz sprawdzić, i wpisz java -versiontam.

Zainstalowałem 32-bitową maszynę JVM i ponowiłem ją, wygląda na to, że poniższe informacje wskazują bitowość maszyny JVM, a nie arch. Systemu operacyjnego:

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

Zostało to przetestowane zarówno dla SUN, jak i IBM JVM (32 i 64-bit). Oczywiście właściwość systemowa to nie tylko łuk systemu operacyjnego.

Informacje uzupełniające:

W uruchomionym procesie możesz użyć (przynajmniej w niektórych najnowszych wersjach 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

gdzie 14680 to PID jvm uruchomionej aplikacji. Działa również „os.arch”.

Obsługiwane są również inne scenariusze:

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

Zastanów się jednak również nad tą uwagą:

„ UWAGA - To narzędzie nie jest obsługiwane i może być dostępne w przyszłych wersjach JDK. W systemach Windows, w których nie ma pliku dbgent.dll, należy zainstalować„ Narzędzia debugowania dla systemu Windows ”, aby te narzędzia działały. Zmienna środowiskowa PATH powinna zawierać lokalizację pliku jvm.dll używaną przez proces docelowy lub lokalizację, z której utworzono plik zrzutu awaryjnego. ”

W systemie Linux informacje o nagłówkach ELF można uzyskać za pomocą jednego z dwóch poniższych poleceń:

file {YOUR_JRE_LOCATION_HERE}/bin/java

o / p: ELF 64-bitowy plik wykonywalny LSB , AMD x86-64, wersja 1 (SYSV), dla GNU / Linux 2.4.0, dynamicznie połączony (używa wspólnych bibliotek), dla GNU / Linux 2.4.0, bez usuwania

lub

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

o / p: klasa: ELF 64

Jeśli używasz JNA, możesz sprawdzić, czy com.sun.jna.Native.POINTER_SIZE == 4(32-bitowy) czy com.sun.jna.Native.POINTER_SIZE == 8(64-bitowy).

W systemie Windows 7 w „ Panelu sterowania ” w „ Programy | Programy i funkcje ” 64-bitowe wersje JRE i JDK są wymienione w nawiasach jako „ 64-bit ” (np. „ Java SE Development Kit 7 Update 65 (64-bit) ) ”), podczas gdy dla wariantów 32-bitowych wariant nie jest wymieniony w nawiasach (np.„ Java SE Development Kit 8 Update 60 ”).

Jeśli używasz JNA, możesz to zrobić Platform.is64Bit().

Dla Windowsmożna sprawdzić Javalokalizację domu. Jeśli zawiera (x86), jest 32-bitinaczej 64-bit:

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

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

Przykładowe ścieżki:

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

Po co dbać o Windowsjedyne rozwiązanie?

Jeśli chcesz wiedzieć, na której wersji bitowej pracujesz, prawdopodobnie bawisz się natywnym kodem, Windowsaby i tak niezależność od platformy była poza oknem.

Aby uzyskać wersję JVM aktualnie uruchomionego programu

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