必须使用aarch64架构JDK：OpenJDK官网选linux-aarch64包，Adoptium选AArch64，Amazon Corretto选arm64版本，file $(which java)输出须含aarch64且与uname -m一致。
java -version能跑，但Spring Boot启动就卡住或报Illegal instruction
这是ARM64机器（M1/M2 Mac、鲲鹏服务器、麒麟V10 SP3、openEuler ARM版）上最典型的架构错配现象。JDK安装包选错架构后，java -version往往仍能输出版本号——因为JVM启动器本身可能只是个轻量外壳，真正出问题在JIT编译或JNI调用阶段。一旦项目加载Spring容器、触发字节码验证或调用本地库（如Netty的epoll、Log4j2的JMX），就会立刻崩在Illegal instruction (core dumped)或Failed to create JVM。这不是配置问题，是CPU指令集根本对不上。
Windows弹出“此应用无法在你的电脑上运行”
这个系统级弹窗不是Java报错，而是Windows PE加载器在解析安装包头部时直接拦截。触发条件很明确：win-x64系统装了win-arm64 JDK安装包，或win-arm64设备硬装win-x64包。Oracle JDK 23和Temurin 21.0.4+已彻底移除x86支持，如果你的旧笔记本是32位x86处理器（少见但存在），连下载页都找不到对应包。
- 验证方式：PowerShell里执行
echo $env:PROCESSOR_ARCHITECTURE，结果必须和JDK包名里的win-x64/win-arm64严格匹配 - 别信“兼容模式”——Rosetta 2只在macOS存在，Windows没有等效方案
- Adoptium官网下载页会明确标出
jdk-21.0.2+13.1-aarch64这类完整架构标识，漏看后缀就容易下错
file $(which java)显示x86-64，但系统是ARM64
在Linux/macOS终端执行file $(which java)，如果输出含x86-64或Intel 80386，而uname -m返回aarch64，说明你正通过Rosetta 2（macOS）或QEMU（Linux容器）转译运行——性能必然受损，且某些底层操作（如ZGC内存屏障、硬件随机数生成）会静默失败。ARM服务器上还可能触发内核SIGILL信号，日志里只留一行Killed。
- 正确输出应为
aarch64、ARM aarch64或AArch64 - Docker镜像也得对齐：别用
openjdk:17-jre-slim（默认x86），改用eclipse-temurin:17-jre-jammy或显式拉取arm64v8/openjdk:17-jre-slim - 国产系统如麒麟V10 SP3，必须选带
-headless-arm64后缀的包，否则JavaFX模块缺失还会引发NoClassDefFoundError
启动慢一倍、GC停顿翻倍、JNI库加载失败
架构勉强能跑 ≠ 运行正常。x86 JDK在ARM上靠转译层运行，所有CPU密集型操作都要多一层翻译，实测Spring Boot启动时间增加62%，G1GC年轻代回收耗时从20ms跳到50ms以上。更隐蔽的是JNI问题：java.lang.UnsatisfiedLinkError: no net in java.library.path这类错误，90%是因为你装的JDK自带的libnet.so是x86_64编译的，而系统只认aarch64版本。
- 国产密码算法（SM2/SM4）依赖特定JNI库，架构错配会导致
java.security.NoSuchProviderException - ARM服务器上禁用
-XX:+UseCompressedClassPointers，因为ARM64地址空间宽，压缩反而增加解码开销 - 别指望“自动适配”——JVM是原生二进制，没有Java字节码那种跨平台抽象
Killed提示后。确认架构匹配，永远是装完JDK后第一行该敲的命令。 
