JVM性能调优（一）
1、java -XX:+UseConcMarkSweepGC -Xmx8192m -Xms8192m -Xss256k -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:./logs/java_gc.log -XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/ -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 -jar api.jar --spring.profiles.active=ifaas --isJar=true
PS：-Xms为JVM启动时分配的内存
-Xmx为JVM运行过程中分配的最大内存，也就是当启动时分配的不够用是，JVM进程最多只能够占用的内存（此值一般和Xms相同，以避免每次垃圾回收完成后JVM重新分配内存）
-Xss 为JVM启动的每个线程分配的内存大小（此值减小能生成更多的线程，但有限制，经验值在3000~5000）
-Xmn为年轻代大小：整个堆大小=年轻代大小+年老代大小+持久代大小（所以官方推荐配置为整个堆的3/8）
吞吐量优先的并行收集器：-XX:+UseParallelGC -XX:ParallelGCThreads=20 （并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等 ）
响应时间优先的并发收集器： - XX:+UseConcMarkSweepGC -XX:+UseParNewGC （保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域 ）
GC日志分析：
GC 5.617: [ParNew: 43296K->7006K(47808K), 0.0136826 secs] 44992K->8702K(252608K), 0.0137904 secs
5.617（时间戳）: [GC（Young GC） 5.617（时间戳）: [ParNew（使用ParNew作为年轻代的垃圾回收期）: 43296K（年轻代垃圾回收前的大小）->7006K（年轻代垃圾回收以后的大小）(47808K)（年轻代的总大小）, 0.0136826 secs（回收时间）] 44992K（堆区垃圾回收前的大小）->8702K（堆区垃圾回收后的大小）(252608K)（堆区总大小）, 0.0137904 secs（回收时间）] [Times: user=0.03（Young GC用户耗时） sys=0.00（Young GC系统耗时）, real=0.02 secs（Young GC实际耗时）]
7.429: [GC 7.429: [ParNew: 45278K->6723K(47808K), 0.0251993 secs] 46974K->10551K(252608K), 0.0252421 secs]
从最后一条GC记录中我们可以看到 Young GC回收了 45278-6723=38555K的内存
Heap区通过这次回收总共减少了 46974-10551=36423K的内存。
38555-36423=2132K说明通过该次Young GC有2132K的内存被移动到了Old Gen
2、jmap -dump:file=文件名.dump [pid]
PS：这种是主动生成dump文件的方式，但JVM是暂停服务的，所以对线上的运行产生影响
3、服务卡顿问题分析
- ps -ef|grep java 或者 jps -l 或者 top :查看应用服务进程ID
- top -Hp pid : 查看进程中占用CPU率最高的线程ID
- prinf “%x” xpid : 把线程的ID 转成成16进制 ，因为 jstack 打印的堆栈信息 记录的是 十六进制寻址地址
- jstack pid | grep 69b3 -C11 -color ： 输出应用进程ID的堆栈信息，并通过grep定位线程的具体位置细信息
- jmap -heap pid (堆区具体信息)
- jmap -histo:live pid（堆区变量具体信息）
- jstat -gc pid 2000 （没个2000ms输出 堆区 young gc 和 full gc 具体信息）： 持续输出，对比两条有差异的总耗时ygct或者fgct 就可以知道发生young gc 时间差 和 full gc 的时间差