通过 System.getProperty("sun.arch.data.model") 输出结果可精确判断 JVM 位数：输出 64-bit 即为 64 位，32-bit 即为 32 位；该值源自 JVM 实际加载架构，不受 PATH 或启动器干扰，比 java -version 更可靠。
直接看 java -version 输出里有没有 64-Bit 字样，有就是64位；没有，大概率是32位——但不能完全依赖这点，得交叉验证。
怎么看 java -version 的输出是否可信
Windows 下打开 CMD，执行 java -version，注意观察第二行或第三行：
- 如果出现
Java HotSpot(TM) 64-Bit Server VM，说明当前运行的是64位 JDK - 如果只写
Java HotSpot(TM) Server VM（缺64-Bit），基本可判定是32位 JDK - 某些旧版 JDK（如早期 1.7）即使64位也可能不打印
64-Bit，所以不能单靠这一条判断
用 System.getProperty("sun.arch.data.model") 精确确认
写个最小测试类比命令行更可靠，因为绕过了 PATH 和启动器的干扰：
public class ArchCheck {
public static void main(String[] args) {
System.out.println(System.getProperty("sun.arch.data.model") + "-bit");
}
}
保存为 ArchCheck.java，在 CMD 中执行：
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
javac ArchCheck.javajava ArchCheck
输出 64-bit 就是64位；32-bit 就是32位。这个值来自 JVM 实际加载的架构，不受命令行包装器影响。
检查安装路径和系统环境变量指向哪个 JDK
很多人配了多个 JDK，java -version 显示的版本可能不是你认为的那个：
- 查
JAVA_HOME：CMD 里运行echo %JAVA_HOME%，看路径是否落在C:\Program Files\Java\（64位常见）还是C:\Program Files (x86)\Java\（32位常见） - 查实际调用的
java.exe：运行where java，它会列出所有 PATH 中匹配的java.exe路径，第一个生效 - 注意：PATH 中如果有
C:\Program Files (x86)\Common Files\Oracle\Java\javapath\这类 Oracle 自带的代理目录，它会劫持调用，此时where java显示的路径 ≠JAVA_HOME指向的 JDK
为什么 32/64 位不匹配会导致 exit code = 13
这是最典型的兼容性报错，尤其发生在 IDE 启动时（比如 Eclipse、IntelliJ）：
- Eclipse 是 64 位程序，但启动时调用了 32 位 JVM → 直接崩溃，报
java was started but returned exit code = 13 - 反过来（64位 JVM 启动 32位 IDE）一般不会发生，因为 IDE 多数自带 launcher，但 JVM 位数必须和宿主进程一致
- 解决方法不是“重装”，而是确保
JAVA_HOME和 PATH 指向同一套位数的 JDK，并且该 JDK 真实存在、未损坏
真正容易被忽略的是：你以为改了 JAVA_HOME，但 where java 还在返回旧路径——因为 PATH 里残留了其他 JDK 的 bin 目录，或者 Oracle 的 javapath 优先级更高。动手前先跑一遍 where java 和 echo %JAVA_HOME%，比盲目重装快得多。
