必须基于99分位内存峰值预留：web类服务按full gc前老年代瞬时峰值×1.3～1.5设堆上限，并显式预留metaspace、direct memory及线程栈余量，总内存≤容器限制的85%。
直接给结论：别用平均值乘系数，必须基于压测或线上监控的99分位内存峰值来预留，Web类服务（如Spring Boot）按“Full GC前瞬时峰值 × 1.3～1.5”设堆上限，且要单独为老年代剩余空间、Metaspace、Direct Memory留出显式余量。
怎么抓准那个真实的内存峰值
很多人看 jstat -gc 里老年代使用率缓慢爬升，就以为那是峰值——错。真正的压力点往往藏在GC触发临界前的那几百毫秒。你应该盯住两个指标：
- Full GC发生前瞬间的老年代占用（不是GC后释放完的值）
- 单次高负载请求链路中，所有线程局部变量、NIO缓冲区、临时集合对象叠加后的瞬时堆外+堆内总和
推荐用 jcmd <pid> VM.native_memory summary scale=MB</pid> 配合压测工具（如JMeter+Custom Thread Group）做阶梯式加压，在QPS冲到目标120%时采样3次以上。避免只看 top 或容器 memory.usage_in_bytes，它们反映的是RSS，包含大量未归还操作系统的内存页。
为什么1.3～1.5倍是Web服务的安全区间
这个系数不是拍脑袋来的，它覆盖三类突发场景：
- 会话堆积：比如用户登录后长时间不操作，但Session没过期，
HttpSession对象持续驻留老年代 - GC间隙堆积：G1或ZGC在并发标记阶段仍允许新对象分配，若此时突发流量，Eden区快速填满并晋升，老年代瞬时涨30%+很常见
- 框架代理膨胀：Spring AOP生成的CGLIB代理类、Feign动态接口实现类，在高频调用下元空间增长快于类卸载速度
低于1.3，可能扛不住促销秒杀；高于1.5，又浪费资源且增加GC扫描耗时。我们在线上一个订单服务实测：峰值1.8GB → 设 -Xmx2g 后OOM率降为0，但设 -Xmx2.4g 后Young GC平均耗时反增12%，因为G1Region数量变多，RSet更新开销上升。
容易被忽略的非堆内存余量怎么算
堆只是冰山一角。高并发下真正咬人的常是这几块：
-
Metaspace：Spring Boot应用启动后通常占200～350MB，但若用大量反射或动态生成类（如QueryDSL、Lombok @Builder），建议按-XX:MaxMetaspaceSize=512m硬限制，再加100MB余量 -
Direct Memory：Netty、数据库驱动（如MySQL Connector/J 8.x默认启用useDirectBuffers）隐式分配，必须配-XX:MaxDirectMemorySize=1g（堆的20%～30%），否则OS级OOM Killer会直接杀进程 - 线程栈：
-Xss256k是安全起点，1000个线程 ≈ 256MB，别用默认1MB——那在单机跑12个微服务时，光线程栈就能吃掉近10GB
总内存 = 堆 + Metaspace上限 + Direct上限 + （线程数 × 栈大小）。这个总和必须 ≤ 容器内存限制 × 0.85，否则Linux OOM Killer随时介入。
容器环境下峰值预留要额外防什么
在Docker/Kubernetes里，-XX:+UseContainerSupport 是基础，但还不够。你得确认：
- JVM是否真的读到了cgroup v2的内存限制（
cat /sys/fs/cgroup/memory.max），而不是 fallback 到宿主机内存 - 如果用了
-XX:MaxRAMPercentage，务必验证它是否对齐你的峰值策略——例如设75%，但实际峰值已达容器限制的82%，那就白搭 - K8s中
resources.limits.memory和resources.requests.memory要分开设：requests按稳态均值，limits按峰值×1.5，否则Horizontal Pod Autoscaler（HPA）会误判
最致命的坑是：把堆设小了，结果 Metaspace 或 Direct Memory 撑爆容器限制，而 java.lang.OutOfMemoryError: Compressed class space 这类错误日志根本不会触发 -XX:+HeapDumpOnOutOfMemoryError，排查时毫无头绪。
