-Xms和-Xmx设为相同值可避免堆动态扩容引发的Stop-The-World及Full GC；需≤物理内存75%，G1需配MaxGCPauseMillis，-Xss建议256k，GC日志须含safepoint等维度。
为什么-Xms和-Xmx设成一样能减少GC停顿
堆内存动态伸缩看似灵活，实则在生产环境引发频繁的Full GC和内存碎片。JVM每次扩容都要触发一次Stop-The-World，尤其当老年代快满时，-Xms和-Xmx不一致会导致多次扩容+CMS/SerialOld并发失败，直接卡顿1秒以上。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把
-Xms和-Xmx设为相同值（如-Xms4g -Xmx4g），强制堆预分配，避免运行期扩容 - 该值不能超过物理内存75%，否则容易触发OS级swap，响应延迟翻倍
- 若用G1，还需配
-XX:MaxGCPauseMillis=200，但别设太低——G1会为此牺牲吞吐，反而增加Young GC频率
G1垃圾收集器的关键参数怎么调才不翻车
G1不是“开箱即用”的银弹。默认参数在中大型服务上常导致Mixed GC过于激进，或迟迟不触发导致大对象直接进老年代，最终OOM。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 必须设
-XX:+UseG1GC显式启用，JDK9+虽默认G1，但旧配置可能残留-XX:+UseParallelGC -
-XX:G1HeapRegionSize别乱调：默认值（1~4MB）已适配多数场景；手动设小了会导致Region数暴增，Remembered Set维护开销飙升 - 观察
G1 Evacuation Pause日志里的other耗时——若占比超30%，说明Remembered Set扫描太重，应适当增大-XX:G1RSetUpdatingPauseTimePercent（默认10）
线程栈大小（-Xss）设太大反而拖慢响应
每个线程默认占1MB栈空间（Linux 64位），看似够用，但高并发下线程数一上来，虚拟内存就吃紧。更隐蔽的问题是：栈过大，导致TLAB（Thread Local Allocation Buffer）变小，对象分配更容易进入共享Eden区，竞争加剧，Young GC变多。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- Web应用通常
-Xss256k足够，Spring Boot + Netty这类异步栈深度浅的服务甚至可用-Xss128k - 若遇到
java.lang.StackOverflowError，先查递归或AOP代理链过深，而不是盲目加-Xss - 注意：
-Xss值必须是系统页大小（通常是4KB）的整数倍，设-Xss300k会被JVM自动向下对齐到296k，实际无效
GC日志里哪些字段真正影响响应诊断
只开-Xloggc:gc.log没用，缺关键维度根本定位不了毛刺来源。比如看到“GC pause 120ms”，但不知道这120ms里有多少花在Ref Proc、Class Unloading或SafePoint同步上。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- JDK8用：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics - JDK11+必须换新格式：
-Xlog:gc*,safepoint,heap*=debug:file=gc.log:time,tags,uptime - 重点关注日志里的
Application time和GC pause差值——如果停顿只有50ms，但应用停了300ms，大概率是安全点同步卡住了（比如长循环没安全点轮询）
真实瓶颈往往不在GC本身，而在安全点等待、类加载锁、或者JIT编译线程抢占CPU。GC日志只是入口，别盯着GC pause数字反复调参。
