JVM在百GB级服务器上配置的核心是防止规格虚高，需扣除元空间、线程栈、直接内存等固定开销后严格对齐容器限制，堆设为可用内存的75%左右，并显式设置-Xmn、硬限非堆区域、启用G1关键调优参数。
在百GB级别内存服务器上配置JVM，核心不是“堆多大”，而是防止规格虚高——即参数设得看似充足，实际因结构失衡、资源争抢或容器约束导致频繁GC、OOMKilled或响应抖动。关键在于让JVM真实可用内存与系统资源严格对齐，不浪费也不越界。
堆大小必须严守物理边界和容器限制
即使服务器有128GB内存，也不能直接-Xmx64g。需扣除以下固定开销：
- 元空间（-XX:MaxMetaspaceSize）：Spring Boot类多的服务建议512m~1g
- 线程栈（-Xss512k × 线程数）：若并发线程3000个，仅栈就占1.5GB
- 直接内存（-XX:MaxDirectMemorySize）：Netty/ByteBuffer密集型应用建议显式设为1g~2g
- 代码缓存、GC内部结构、JIT编译器等：预留1~2GB
例如：128GB服务器运行K8s Pod，limit=64Gi → JVM堆上限建议设为48g（约75%），即-Xms48g -Xmx48g。多留余量比压到极限更稳。
新生代不能靠比例硬算，要按对象创建速率反推
百GB堆下用-XX:NewRatio=2（新生代占1/3≈16g）极易出问题：Minor GC周期拉长、单次耗时飙升、Survivor区反复复制大对象。应改用-Xmn显式控制，并结合GC日志验证：
立即学习“Java免费学习笔记（深入）”；
- 观察Eden填满时间：若平均30秒填满，说明-Xmn偏大；若3秒就满，说明偏小
- 监控Promotion Rate（晋升率）：持续高于30MB/s，说明老年代压力大，需调大-Xmn或检查是否存在隐式大对象
- 推荐起点：48g堆对应-Xmn12g~16g，再根据Minor GC频率（目标20~60秒一次）微调
元空间和线程栈必须设硬上限，否则“隐形吃内存”
大内存服务器上最容易被忽略的是非堆区域失控：
- 不设-XX:MaxMetaspaceSize时，Spring动态代理、Groovy脚本、热部署会无限加载类，最终触发本地内存OOM（非java.lang.OutOfMemoryError: Metaspace）
- -Xss默认1MB，在千级线程场景下直接吃掉几GB，且无法被GC回收；确认无深度递归后，统一降至512k甚至256k
- 务必配合监控：jstat -gc <pid> 查看MetaspaceUsed，或Prometheus+JMX暴露MetaspaceCommitted指标
G1回收器必须开启关键调优开关
百GB堆默认G1易出现Mixed GC迟迟不触发、老年代碎片累积、最后被迫Full GC。必须启用：
- -XX:+UseG1GC（强制G1）
- -XX:G1HeapRegionSize=4M（避免Region过小导致管理开销大）
- -XX:G1MaxNewSizePercent=60（允许新生代弹性扩大，应对流量突增）
- -XX:G1MixedGCCountTarget=8（控制Mixed GC分多次清理，降低单次停顿）
- -Xlog:gc*:file=gc.log:time,tags:filecount=5,filesize=100m（开启结构化GC日志，别用旧版-XX:+PrintGCDetails）
不复杂但容易忽略
