高并发web服务需“量体裁衣”式jvm调优：-xms与-xmx相等（如4g），选用g1回收器并设maxgcpausemillis=200，-xmn1.5g或newratio=2，-xss256k，开启gc日志。
JVM 参数不是一套通用配置能打天下，得按业务特点“量体裁衣”。不同场景对内存、延迟、吞吐、线程数、类加载行为的要求差异很大，盲目套用容易适得其反。关键不是堆多大，而是参数组合是否匹配真实负载。
高并发 Web 服务（如电商秒杀、API 网关）
这类应用请求密集、对象生命周期短、GC 频繁，核心目标是降低 GC 停顿、支撑大量线程。 - 堆内存建议设为物理内存的 1/4～1/2，且 -Xms 和 -Xmx 必须相等（比如 -Xms4g -Xmx4g），避免运行时扩缩堆带来的卡顿 - 使用 G1 回收器：-XX:+UseG1GC，并设定停顿目标：-XX:MaxGCPauseMillis=200 - 新生代比例调高些（短生命周期对象多）：-XX:NewRatio=2 或直接设大小：-Xmn1.5g - 线程栈不宜过大：-Xss256k（默认 1MB 容易撑爆内存），保障万级线程容量 - 开启 GC 日志便于监控：-Xloggc:/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps大数据批处理（如 Spark Executor、ETL 任务）
单次运行时间长、内存占用高、对象存活久，更关注吞吐量和大堆稳定性。 - 堆可设更大（如 -Xms8g -Xmx8g），但需预留系统内存，避免触发 OS swap - 老年代压力大，-XX:NewRatio=4 或 -XX:NewRatio=6 更合理（新生代占比较小） - 元空间容易因动态生成类膨胀：-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1g - 可考虑 Parallel GC（吞吐优先）：-XX:+UseParallelGC -XX:+UseParallelOldGC - 关闭偏向锁（高竞争下反而拖慢）：-XX:-UseBiasedLocking低延迟实时系统（如风控引擎、交易撮合）
毫秒级响应不可妥协，GC 暂停必须可控，甚至要求亚毫秒级。 - 优先选用 ZGC（JDK 11+）或 Shenandoah（JDK 12+）：-XX:+UseZGC，配合足够 CPU：-XX:ConcGCThreads=4 - 堆大小建议控制在 8–16GB 区间（ZGC 对超大堆支持好，但需权衡内存带宽） - 关闭显式 GC：-XX:+DisableExplicitGC（防止 System.gc() 打断） - 启用 GC 统计输出：-Xlog:gc*,gc+heap=debug,safepoint（JDK 10+ 新日志格式） - 避免使用 finalizer 和 ReferenceQueue，它们会引入不可控延迟轻量级微服务（Spring Boot 小模块、Sidecar）
资源受限、启动快、实例多，重在快速冷启动与内存精简。 - 堆不必大：-Xms256m -Xmx512m 即可，避免浪费 - G1 仍是首选（小堆也表现稳定）：-XX:+UseG1GC - 减少元空间开销：-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m - 启用类数据共享（JDK 10+）：-XX:+UseSharedSpaces -XX:SharedArchiveFile=shared.jsa，加速类加载 - 可关闭分层编译以减少 JIT 预热时间：-XX:-TieredStopAtLevel=1（仅解释执行，适合短命进程）不复杂但容易忽略：所有生产配置都应配套开启 GC 日志，并接入监控（如 Prometheus + Grafana 抓取 jvm_gc_collection_seconds_count），靠日志和指标说话，而不是凭经验猜。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
