Como posso saber se estou executando na JVM de 64 bits ou na JVM de 32 bits (de dentro de um programa)?

Como posso saber se a JVM na qual meu aplicativo é executado é de 32 ou 64 bits? Especificamente, quais funções ou propriedades posso usar para detectar isso no programa?

Você recupera a propriedade do sistema que marca a testemunha dessa JVM com:

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

Os resultados possíveis são:

• "32" - JVM de 32 bits
• "64" - JVM de 64 bits
• "unknown" - JVM desconhecida

Conforme descrito nas Perguntas frequentes sobre o HotSpot :

Ao escrever código Java, como faço para distinguir entre operação de 32 e 64 bits?

Não há API pública que permita distinguir entre operação de 32 e 64 bits. Pense em 64 bits como apenas outra plataforma na gravação uma vez, execute qualquer tradição. No entanto, se você deseja escrever um código específico da plataforma (que pena), a propriedade do sistema sun.arch.data.model possui o valor "32", "64" ou "unknown".

Um exemplo em que isso pode ser necessário é se o código Java depender de bibliotecas nativas e você precisar determinar se deve carregar a versão de 32 ou 64 bits das bibliotecas na inicialização.

Para determinadas versões do Java, é possível verificar a aceitação da JVM na linha de comandos com os sinalizadores -d32e -d64.

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

Para verificar uma JVM de 64 bits, execute:

$ java -d64 -version

Se não for uma JVM de 64 bits, você obterá o seguinte:

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

Da mesma forma, para verificar uma JVM de 32 bits, execute:

$ java -d32 -version

Se não for uma JVM de 32 bits, você obterá o seguinte:

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

Esses sinalizadores foram adicionados no Java 7, descontinuado no Java 9, removido no Java 10 e não estão mais disponíveis nas versões modernas do Java.

Basta digitar java -versionseu console.

Se uma versão de 64 bits estiver em execução, você receberá uma mensagem como:

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)

Uma versão de 32 bits mostrará algo semelhante 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)

Observe em Clientvez de 64-Bit Serverna terceira linha. A Client/Serverparte é irrelevante, é a ausência do 64-Bitque importa.

Se várias versões Java estiverem instaladas no seu sistema, navegue até a pasta / bin da versão Java que você deseja verificar e digite java -versionlá.

Eu instalei a JVM de 32 bits e tentei novamente, parece que o seguinte diz a você a testemunha da JVM, não o arco do SO:

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

Isso foi testado no SUN e no IBM JVM (32 e 64 bits). Claramente, a propriedade do sistema não é apenas o arco do sistema operacional.

Informações complementares:

Em um processo em execução, você pode usar (pelo menos em algumas versões recentes do 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

onde 14680 é o PID da jvm executando o aplicativo. O "os.arch" também funciona.

Também há suporte para outros cenários:

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

No entanto, considere também esta nota:

" NOTA - Este utilitário não é suportado e pode ou não estar disponível em versões futuras do JDK. Nos sistemas Windows em que o dbgent.dll não está presente, é necessário instalar o 'Debugging Tools for Windows' para que essas ferramentas funcionem. A variável de ambiente PATH deve conter o local do jvm.dll usado pelo processo de destino ou o local a partir do qual o arquivo Crash Dump foi produzido. "

No Linux, você pode obter informações do cabeçalho ELF usando um dos dois comandos a seguir:

file {YOUR_JRE_LOCATION_HERE}/bin/java

o / p: Executável em ELF de 64 bits LSB , AMD x86-64, versão 1 (SYSV), para GNU / Linux 2.4.0, vinculado dinamicamente (usa bibliotecas compartilhadas), para GNU / Linux 2.4.0, sem remoção

ou

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

o / p: Classe: ELF 64

Se você estiver usando o JNA, poderá verificar se com.sun.jna.Native.POINTER_SIZE == 4(32 bits) ou com.sun.jna.Native.POINTER_SIZE == 8(64 bits).

No Windows 7, no " Painel de Controle ", em " Programas | Programas e Recursos ", as variantes de 64 bits do JRE & JDK estão listadas com " 64 bits " entre parênteses (por exemplo, " Java SE Development Kit 7, Atualização 65 (64 bits) ) "), enquanto para as variantes de 32 bits a variante não é mencionada entre parênteses (por exemplo, apenas" Java SE Development Kit 8 Atualização 60 ").

Se você estiver usando JNA, poderá fazer isso Platform.is64Bit().

Para Windows, você pode verificar o Javalocal da casa. Se ele contiver (x86), é o 32-bitcontrário 64-bit:

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

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

Caminhos de exemplo:

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

Por que se preocupar com uma Windowsúnica solução?

Se você precisa saber em qual versão de bit está executando, provavelmente está mexendo com o código nativo Windowspara que a independência da plataforma fique fora da janela.

Para obter a versão da JVM atualmente executando o programa

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