ARM服务器运行Java必须使用aarch64架构JDK，禁用GraalVM AOT，优选G1GC并调优参数，容器需限制memory且JVM按cgroup动态分配内存，JNI库须为ARM64版。
Java版本选错直接导致JVM启动失败
ARM服务器上跑Java，最常踩的坑是拿x86编译的JDK硬上——java -version能显示，但一跑Spring Boot就卡在Failed to create JVM或报Illegal instruction (core dumped)。这不是JDK没装好，是CPU指令集不匹配。
必须用官方明确标“aarch64”的JDK：OpenJDK官网下载页里找带linux-aarch64后缀的tar.gz包；Adoptium（Eclipse Temurin）选AArch64架构；Amazon Corretto也得选arm64版本。别信“跨平台”宣传，JVM本身是原生二进制。
- 检查已装JDK是否真为ARM版：
file $(which java)输出应含aarch64，不是x86-64 - 容器部署时，基础镜像不能用
openjdk:17-jre-slim这种默认x86的，得换eclipse-temurin:17-jre-jammy（它自动适配ARM）或显式拉arm64v8/openjdk:17-jre-slim - Spring Boot 2.7+ 默认启用GraalVM native image预编译，ARM下需额外加
-Dspring.aot.enabled=false，否则编译阶段就挂
GC策略在ARM上容易触发长停顿
ARM服务器（尤其云上实例）内存带宽和L3缓存比同价位x86弱，ZGC和Shenandoah这类低延迟GC在ARM上反而可能因内存访问模式不匹配，导致G1 Evacuation Pause时间翻倍、甚至OOM。
实测下来，ARM64上最稳的是G1GC，但参数得调：默认-XX:+UseG1GC不够，要关掉自适应调优，手动控堆外行为。
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 强制固定年轻代大小：
-XX:NewRatio=2（避免G1动态调整引发抖动） - 限制最大GC线程数：
-XX:ParallelGCThreads=4（ARM核心数虚高常见，比如8核实际只有4个性能大核） - 禁用压缩类空间：
-XX:-UseCompressedClassPointers（ARM64地址空间宽，压缩反而多一层解码开销） - 观察关键指标：
jstat -gc <pid></pid>重点看YGCT（年轻代GC耗时）是否稳定在20ms内，超50ms就得调
Docker中Java进程被OOM Killer干掉
ARM云服务器内存资源紧张，Docker默认不限制cgroup memory上限，Java应用按-Xmx申请堆内存后，JVM还会额外吃掉堆外内存（CodeCache、Metaspace、Direct Buffer），宿主机看到RSS远超-Xmx，直接触发OOM Killer杀进程，日志里只留Killed process <java> (pid <xxx>) total-vm:<xxx>kB, anon-rss:<xxx>kB, file-rss:<xxx>kB</xxx></xxx></xxx></xxx></java>。
根本解法不是调-Xmx，而是让容器知道“这台机器总共就这么多内存”，逼JVM收敛。
- 启动容器时必须加：
--memory=4g --memory-reservation=3.5g（Reservation防突发抢占） - JVM参数同步对齐：
-XX:MaxRAMPercentage=75.0（别用-Xmx硬编码，让JVM从cgroup读可用内存） - 限制Metaspace：
-XX:MaxMetaspaceSize=256m（ARM上类加载慢，Metaspace易膨胀） - 检查是否泄漏Direct Buffer：
jcmd <pid> VM.native_memory summary</pid>看Internal项是否持续上涨
JNI库在ARM上加载失败的典型表现
只要Java代码里调了System.loadLibrary("xxx")，而对应libxxx.so是x86编译的，就会报UnsatisfiedLinkError: /tmp/xxx.so: wrong ELF class: ELFCLASS32或更隐蔽的undefined symbol: __libc_start_main@GLIBC_2.2.5（其实是架构不匹配导致符号解析失败）。
不是所有JNI库都提供ARM版，尤其国产中间件或硬件SDK，得提前验证。
- 查so文件架构：
readelf -h libxxx.so | grep Class必须输出ELFCLASS64且Data: 2's complement, little endian - 若只有x86版，别指望qemu-user-static透明转译——JNI涉及系统调用和信号处理，转译后大概率崩溃
- Spring Boot打包时，
src/main/resources/lib下放ARM版so，同时确保LD_LIBRARY_PATH包含该路径，或用-Djna.library.path=...指定 - Log4j2的
log4j-core自带log4j-api的JNI桥接，在ARM上建议降级到2.19.0（2.20+引入了ARM未适配的avx优化路径）
ARM服务器上Java不是“换个JDK就能跑”，关键是把JVM当成一个需要对齐硬件特性的系统组件来看——指令集、内存子系统、cgroup边界、本地库ABI，漏掉哪一层都可能在凌晨三点弹出告警。
