上篇文章说jvm的实际运行情况。
Jvm实际运行情况-JVM（十七）
- Arthas介绍
因为arthas完全是java代码写的，我们直接用命令启动：
Java -jar arthas-boot.jar
启动成功后，选择我们项目的进程。
进入我们可用dashboard查询看板。
之后可以看到76线程较高，用thread 线程id来查看哪些异常导致cpu过高。
arthas的 jad命令可以反编译线上代码。
当我们系统上线，但我们感觉并没有把代码上线，或者上错分支，这时候怎么办呢，于是可以用这个命令来反编译代码，看看是否正常。
当我们需要查看某个类里对象的值，这时候可以通过
ognl @com.zto.jvm.JvmController@hashSet
甚至调用线上代码修改里面的值：
ognl @com.zto.jvm.JvmController@hashSet.add(“arthasAdd”)
- GC日志详解
Java -jar -Xloggc:./gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps -XX:+PrintGCCause
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=100M service-eureka-server.jar
这里解释下会把时间戳替换成%t
陆续分段打到10个文件，打100M，保留10个文件，超过一个G则会覆盖。
Parallel：
图上是parallel策略垃圾收集，可以看到minor GC和fullGC。
年轻代在minorGC之前有57M，发生垃圾收集之后成为65M，年轻代总大小为66M。
218M为堆的总大小。
fullGC原因在日志文件也可以看到，原因是Metadata GC threshold，元空间不够。
为什么都是元空间不够导致的fullGC呢，因为项目刚启动，加载类，每次元空间加载类信息满了，会扩展内存加载新的类，所以项目启动时候会因为元空间不够多次fullGC。
CMS:
这时候我们需要改jvm启动参数：
-Xloggc:d:/gc-cms-%t.log
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-Xms50M -Xmx50M
首先垃圾收集器改为parNew和CMS，为了快速内存溢出，我们把堆大小设置成50M。
从这些日志可以看到，我们cms垃圾收集器的过程，初始化标记，是会STW的，然后会并发标记，之后重新标记又会STW，之后并发清理会有新对象，这时候标记成黑色方便下次清理，这属于浮动垃圾。
当进入的对象速率超过垃圾回收器回收对象时间，这时候则会单线程serail垃圾回收器回收，从图中Allocation Failture就可以看到内存溢出会进入单线程回收。
G1:
这时候我们需要改jvm启动参数：
-Xloggc:d:/gc-g1-%t.log -XX:+UseG1GC
这是G1的初始标记，并发标记，最终标记，回收。
Java -XX:+PrintFlagsInitial打印默认值。
Java -XX:+PrintFlagsFinal打印运行程序生效值。
