java应用高可用核心在于显式、合理、可验证的jvm参数配置：堆内存需固定（-xms=-xmx）、大小适配物理内存50%–70%且≤16gb；必须开启gc日志与oom自动转储；元空间和线程栈须设上限；按sla选配gc策略。
Java 应用要保障高可用，核心不是“加机器”或“堆资源”，而是让 JVM 在故障前可感知、出问题时有线索、崩溃后能复盘。这必须通过显式、合理、可验证的 JVM 参数配置来实现，不能依赖默认值。
堆内存必须固定且合理
生产环境最常见宕机原因就是堆动态伸缩 + OOM 突然退出。必须切断这两个风险点：
-
-Xms 和 -Xmx 必须设为相同值，例如
-Xms4g -Xmx4g，避免运行时扩容缩容引发 STW 卡顿 - 堆大小建议为服务器物理内存的 50%–70%，单实例不建议超过 16GB（GC 停顿会显著上升）
- 若部署在容器中，需与容器内存限制对齐，比如容器 limit=8Gi，则
-Xmx6g更稳妥（预留系统和元空间空间）
必须开启 GC 日志与 OOM 自动转储
没有日志的 JVM 就像没有仪表盘的飞机——飞得再高也看不见状态。
- 启用详细 GC 日志：
-Xloggc:/data/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps - OOM 时必须保留现场：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/jvm/dump/heap_%p_%t.hprof - 配合
-XX:+PrintCommandLineFlags，启动时自动打印最终生效参数，避免配置被覆盖却不知情
元空间和线程栈要设上限
这两项常被忽略，却是静默泄漏和突发雪崩的源头：
- 元空间不设限 = 类加载器泄漏直接耗尽系统内存，必须配：
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m - 线程栈过大（如默认 1MB）会导致高并发下线程数锐减，建议业务服务设为
-Xss512k；微服务轻量接口甚至可用-Xss256k - 若应用使用大量反射或动态代理（如 Spring AOP），可适当上调 Metaspace 上限至 768m
按场景选对垃圾收集器并设目标
没有“最好”的 GC，只有“最适合当前 SLA”的 GC：
- 吞吐优先（批处理、后台任务）：
-XX:+UseParallelGC，配合-XX:MaxGCPauseMillis=500控制停顿 - 响应敏感（API 服务、实时查询）：
-XX:+UseG1GC，加上-XX:MaxGCPauseMillis=200和-XX:InitiatingHeapOccupancyPercent=35 - 超低延迟要求（金融交易）：JDK 11+ 可评估
-XX:+UseZGC，但需确认 CPU 资源充足
不复杂但容易忽略——真正决定高可用的，往往不是代码多优雅，而是 JVM 启动那一行参数写得够不够狠、够不够细。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
