Как я могу узнать, работает ли я в 64-разрядной JVM или 32-разрядной JVM (изнутри программы)?
Как я могу определить, является ли JVM, в которой выполняется мое приложение, 32-разрядной или 64-разрядной? В частности, какие функции или свойства я могу использовать для обнаружения этого в программе?
Ответы
Ответ 1
Вы получаете системное свойство, которое помечает разрядность этой JVM с помощью:
System.getProperty("sun.arch.data.model");
Возможные результаты:
-
"32"
- 32- бит JVM -
"64"
- 64-битная JVM -
"unknown"
- неизвестный JVM
Как описано в FAQ по HotSpot:
Когда я пишу код Java, как различить 32- и 64-битные операции?
Нет общедоступного API, позволяющего различать 32- и 64-разрядные операции. Подумайте о 64-битной архитектуре как об очередной платформе, которую можно написать один раз, запустить в любом месте. Однако, если вы хотите написать код, который зависит от платформы (позор вам), системное свойство sun.arch.data.model имеет значение "32", "64" или "неизвестно".
Например, это может быть необходимо, если ваш код Java зависит от собственных библиотек, и вам нужно определить, загружать ли 32- или 64-битную версию библиотек при запуске.
Ответ 2
Для определенных версий Java вы можете проверить битность JVM из командной строки с флагами -d32
и -d64
.
$ java -help
...
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
Чтобы проверить наличие 64-битной JVM, выполните:
$ java -d64 -version
Если это не 64-битная JVM, вы получите это:
Error: This Java instance does not support a 64-bit JVM.
Please install the desired version.
Аналогично, чтобы проверить 32-битную JVM, запустите:
$ java -d32 -version
Если это не 32-битная JVM, вы получите это:
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
Эти флаги были добавлены в Java 7, устарели в Java 9, удалены в Java 10 и больше не доступны в современных версиях Java.
Ответ 3
Просто введите java -version
в свою консоль.
Если 64-разрядная версия запущена, вы получите сообщение типа:
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)
32-битная версия покажет что-то похожее на:
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)
Обратите внимание Client
вместо 64-Bit Server
в третьей строке. Часть Client/Server
не имеет значения, это имеет значение 64-Bit
.
Если в вашей системе установлено несколько версий Java, перейдите в папку /bin версии Java, которую вы хотите проверить, и введите java -version
там.
Ответ 4
Я установил 32-битную JVM и повторил попытку, похоже, что следующее говорит вам о битности JVM, а не об ОС:
System.getProperty("os.arch");
#
# on a 64-bit Linux box:
# "x86" when using 32-bit JVM
# "amd64" when using 64-bit JVM
Это было проверено как на SUN, так и на IBM JVM (32- и 64-разрядной). Понятно, что системное свойство - это не просто арка операционной системы.
Ответ 5
Дополнительная информация:
В текущем процессе вы можете использовать (по крайней мере, некоторые недавние версии 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
где 14680 - это PID jvm, запускающей приложение. "os.arch" тоже работает.
Также поддерживаются другие сценарии:
jinfo [ option ] pid
jinfo [ option ] executable core
jinfo [ option ] [[email protected]]remote-hostname-or-IP
Однако рассмотрим также эту заметку:
"NOTE - эта утилита не поддерживается и может быть доступна или недоступна в будущих версиях JDK. В системах Windows, где dbgent.dll отсутствует" Инструменты отладки для Windows "должны быть установлены для работы этих инструментов. Кроме того, переменная среды PATH должна содержать расположение jvm.dll, используемое целевым процессом, или местоположение, из которого был создан файл дампа сбоев".
Ответ 6
В Linux вы можете получить информацию заголовка ELF, используя одну из следующих двух команд:
file {YOUR_JRE_LOCATION_HERE}/bin/java
о/р:
ELF 64-разрядный исполняемый файл LSB, AMD x86-64, версия 1 (SYSV), для GNU/Linux 2.4.0, динамически связанный (использует общие библиотеки), для GNU/Linux 2.4.0, а не раздели
или
readelf -h {YOUR_JRE_LOCATION_HERE}/bin/java | grep 'Class'
о/р:
Класс: ELF 64
Ответ 7
Если вы используете JNA, вы можете проверить, есть ли com.sun.jna.Native.POINTER_SIZE == 4
(32 бит) или com.sun.jna.Native.POINTER_SIZE == 8
(64 бит).
Ответ 8
В Windows 7 в "Панели управления" в разделе "Программы и программы" 64-разрядные варианты JRE и JDK перечислены в скобках "64-бит" (например, "Java SE Development Kit 7 Update 65 ( 64-бит)", в то время как для 32-битных вариантов вариант не упоминается в круглых скобках (например, просто "Java SE Development Kit 8 Update 60" ).
Ответ 9
В Windows
вы можете проверить исходное местоположение Java
. Если он содержит (x86)
он 32-bit
иначе 64-bit
:
public static boolean is32Bit()
{
val javaHome = System.getProperty("java.home");
return javaHome.contains("(x86)");
}
public static boolean is64Bit()
{
return !is32Bit();
}
Примеры путей:
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
Зачем заботиться о решении Windows
только?
Если вам нужно знать, в какой битовой версии вы работаете, вы, вероятно, будете играть с родным кодом в Windows
так что независимость от платформы в любом случае выходит за пределы окна.
Ответ 10
Если вы используете JNA, вы можете сделать это Platform.is64Bit()
.
Ответ 11
Чтобы получить версию JVM, в настоящее время запущенную программу
System.out.println(Runtime.class.getPackage().getImplementationVersion());