java 参数
-XX 参数 使用得最多的参数类型
非标准化参数,相对不稳定,主要用于JVM调优和Debug
a.Boolean类型
格式:-XX:[+-] +或-表示启用或者禁用name属性
比如:-XX:+UseConcMarkSweepGC 表示启用CMS类型的垃圾回收器
-XX:+UseG1GC 表示启用G1类型的垃圾回收器
b.非Boolean类型
格式:-XX=表示name属性的值是value
比如:-XX:MaxGCPauseMillis=500
查看参数
java -XX:+PrintFalgsFinal -version > flags.txt
"="表示默认值,":="表示被用户或JVM修改后的值
1Byte(字节)=8bit(位)
1KB=1024Byte(字节)
1MB=1024KB
1GB=1024MB
1TB=1024GB
1073741824Byte= 1MB(10位数),1099511627776Byte= 1GB(13位数据)
各参数含义表
./flags.txt:320: uintx MaxMetaspaceSize = 18446744073709547520 {product} ./flags.txt:329: uintx MetaspaceSize = 21807104 {pd product}
单位K 、M 、G
参数 | 含义 | 说明 | 本机配置,请查看上文 |
---|---|---|---|
-XX:InitialHeapSize=100M | 初始化堆大小 | 简写-Xms 100M, | := 134217728换算 |
-XX:MaxHeapSize=100M | 这种堆最大值 | 简写-Xmx 100M | := 715653120,一般不超过物理内存的80% |
-XX:NewSize=20M | 设置年轻代大小 | -Xns | |
-XX:MaxNewSize=50M | 这种年轻代最大大小 | -Xmn | |
-XX:OldSize=50M | 设置老年代 | ||
-XX:MetaspaceSize=50M | 设置元数据区(方法区) | ||
-XX:MaxspaceSize=50M | 设置方法区最大大小 | ||
-XX:PermSize | 非堆内存初始化大小 | 一般应用设置初始化值200M | |
-XX:MaxPermSize | 非堆内存最大值 | 一般应用设置1024M | |
-XX:NewRatio=4 | 新生代比例值 | 如设置4,表示新时代:老年代=1:4,也就是新时代占整个堆内存的1/5 | |
-XX:SurvivorRatio=8 | 年轻代中Eden区与两个Survivor区比例 | 默认8,即(S0+S1):Eden=2:8=1:1:8,,S占了新时代的1/10 | |
-XX:TheadStackSize=1024k | 设置每个线程的堆栈内存大小 | -Xss | 经验值是3000-5000最佳 |
-XX:UseParallelGC | 使用UseParallelGC,并行收集器 | 新生代,吞吐量优先 | |
-XX:UseParallelOldGC | 老年代并行收集器 | 老年代,吞吐量优先 | |
-XX:UseConcMarkSweepGC | 启用CMS GC | 老年代,停顿时间优先 | |
-XX:UseG1GC | 启用G1GC | 新生代和老年代,停顿时间优先 | |
-XX:HeapDumpOnOutOfMemoryError | 启用堆内存溢出打印 | 当OOM时自动生成dump文件 | |
-XX:HeapDumpPath=heap.hprof | 指定堆内存溢出打印目录 | 当前目录生成一个heap.hprof文件 | |
-XX:+PrintGCDetails -XX:+PrintGCTimeStammps -XX:+PrintGCDateStamps -Xlogggc:g1-gc.log | 打印出GC日志 | 可以使用不同的垃圾回收器对比查看GC情况。 | |
-XX:MaxTenuringThreshold = 6 | 提示老年代的最大临界值 | 默认是15 | |
-XX:InitiatingHeapOccupancyPercent=45 | 启动并发GC周期时堆内存使用占比 | G1之类的垃圾收集器用它来触 发并发GC周期,基于整个堆的使 用率,而不只是某一代内存的使 用比. 值为 0 则表示”一直执行 GC循环”. 默认值为 45.内存大小到了45%就触发GC。 | |
-XX:G1HeapWastePercent | 允许浪费堆空间的占比 | 默认10%,如果并发标记可 回收的空间小于10%,则不会触 发MixedGC。 | |
-XX:MaxGCPauseMillis = 200ms | G1最大停顿时间 | 暂停时间不能太小,太小的话 就会导致出现G1跟不上垃圾产 生的速度。最终退化成Full GC。所以对这个参数的调优是 一个持续的过程,逐步调整到 最佳状态。 |
吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间) 比如虚拟机总共运行了100分钟,垃圾收集时间用了1分钟,吞吐量=(100-1)/100=99%。
若吞吐量越大,意味着垃圾收集的时间越短,则用户代码可以充分利用CPU资源,尽快完成程序 的运算任务。
垃圾收集器
图中展示了其中作用于不同分代的收集器,如果两个收集器之间存在连线,就说明它们可以搭配使用。图中收集器所处的区域,则表示它是属于新生代收集器抑或是老年代收集器。 ps:虽然垃圾收集器的技术在不断进步,但直到现在还没有最好的收集器出现,更加不存在"万能"的收集器,所以我们选择的只是对具体应用最合适的收集器。如果有一种放之四海而皆准、任何场景下都适用的完美收集器存在。HotSpot虚拟机完全没必要实现那么多种不同的收集器了.
总体来说分了适用于新时代的收集器和老年代的收集器+G1
在这个基础上又分了单线程的和多线程的,回收过程会停止整个JVM
设计的目标场景有 吞吐量优先的、最短停顿时间优先的。
CMS流程图,目的是最短回收停顿时间
\