JVM配置参数小记
4C * 16G java -Xms8g -Xmx8g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:ParallelGCThreads=4 -XX:ConcGCThreads=2 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError分析（ai）：
内存：16G物理机分配8G堆，留出了8G给系统。对于现代Java应用（特别是微服务），8G堆是一个比较舒适的配置，可以容纳较多的对象，减少GC频率。
线程：CPU只有4核，将GC并发线程设置为2（约为ParallelGCThreads的1/4~1/2），留出了一半的CPU给业务线程，这个配比很经典，既保证了GC效率，又不至于完全阻塞业务
4C * 10G java -Xms6g -Xmx6g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:ParallelGCThreads=4 -XX:ConcGCThreads=2 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError分析（ai）：
内存配比合适（留4G给系统/元空间/堆外）。
线程数没有变化（因为CPU还是4C），这符合逻辑。GC线程数只与CPU核心数强相关，与内存大小无关。
4C * 8G java -Xms4g -Xmx4g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:ParallelGCThreads=4 -XX:ConcGCThreads=2 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError分析（ai）：
4C/8G是生产环境比较常见的低配机型。分配4G堆内存是比较安全的，剩下4G留给操作系统和JVM自身（Direct Memory、Stack、Metaspace）。
G1GC在4G堆上的表现：虽然G1的设计初衷是面向大堆（>6G），但在4G堆上表现也不错。只是如果应用的对象分配速率很高，4G堆可能依然会面临较频繁的Mixed GC。
2C * 8G java -Xms4g -Xmx4g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError分析（ai）：
CPU：将
ParallelGCThreads降为2，ConcGCThreads降为1，这步做得非常到位。在2C环境下如果用4个GC线程，CPU调度会频繁"吵架"（上下文切换），导致应用卡顿。降低线程数能保证GC工作平稳进行。内存风险提示：
CPU/内存失衡：2C的处理能力有限，但分配了4G堆。如果该应用流量较大，2C的CPU可能无法及时处理业务逻辑 + GC标记/清理工作，容易出现CPU负载持续飙高的情况。
建议：如果实际流量很大，在2C环境下，4G堆可能"吃不完"（处理不过来），反而会因为CPU瓶颈导致应用变慢。如果能降为
-Xms2g -Xmx2g可能更安全（留更多CPU给GC和业务平衡），但具体取决于业务对象大小。
备注：JDK 8u131+ 引入了 -XX:+UseContainerSupport,在 JDK 8u191+ 后默认开启;使用较新JDK,可以考虑添加-XX:InitialRAMPercentage和-XX:MaxRAMPercentage来替代固定的-Xms -Xmx，让JVM自动根据容器内存计算堆大小（例如-XX:MaxRAMPercentage=80.0）。这样做的好处是：如果未来容器内存配置微调（比如16G变成14G），不用改启动参数。