实战性能优化
重新认知JVM
之前我们画过一张图，是从Class文件到类装载器，再到运行时数据区的过程，现在咱们把这张图不妨丰富完善一下，展示了JVM的大体物理结构图。
执行引擎:用于执行JVM字节码指令
主要由两种实现方式：
（1）将输入的字节码指令在加载时或执行时翻译成另外一种虚拟机指令；
（2）将输入的字节码指令在加载时或执行时翻译成宿主主机本地CPU的指令集。这两种方式对应着字节码的解释执行和即时编译。
9.2 堆内存溢出
9.2.1 代码
记得设置参数比如-Xmx20M -Xms20M
9.2.2 运行结果
访问->http://localhost:8080/heap
Exception in thread "http-nio-8080-exec-2" java.lang.OutOfMemoryError: GC overhead limit exceeded
9.2.3 回顾jps和jinfo
9.2.4 回顾jmap手动导出和参数自动导出
jmap手动导出：jmap -dump:format=b,file=heap.hprof PID
参数自动导出：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof
9.3 方法区内存溢出
比如向方法区中添加Class的信息
9.3.1 asm依赖和Class代码
9.3.2 代码
设置Metaspace的大小，比如-XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=50M
9.3.3 运行结果
访问->http://localhost:8080/nonheap
9.4 虚拟机栈
9.4.1 代码演示StackOverFlow
9.4.2 运行结果
9.4.3 说明
Stack Space用来做方法的递归调用时压入Stack Frame(栈帧)。所以当递归调用太深的时候，就有可能耗尽Stack Space，爆出StackOverflow的错误。
-Xss128k：设置每个线程的堆栈大小。JDK 5以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
线程栈的大小是个双刃剑，如果设置过小，可能会出现栈溢出，特别是在该线程内有递归、大的循环时出现溢出的可能性更大，如果该值设置过大，就有影响到创建栈的数量，如果是多线程的应用，就会出现内存溢出的错误。
9.5 线程死锁
9.5.1 代码
9.4.2 运行结果
9.4.3 jstack分析
把打印信息拉到最后可以发现
9.4.4 jvisualvm
将线程信息dump出来
9.6 垃圾收集
内存被使用了之后，难免会有不够用或者达到设定值的时候，就需要对内存空间进行垃圾回收。
9.6.1 垃圾收集发生的时机
GC是由JVM自动完成的，根据JVM系统环境而定，所以时机是不确定的。
当然，我们可以手动进行垃圾回收，比如调用System.gc()方法通知JVM进行一次垃圾回收，但是具体什么时刻运行也无法控制。也就是说System.gc()只是通知要回收，什么时候回收由JVM决定。
但是不建议手动调用该方法，因为消耗的资源比较大。
一般以下几种情况会发生垃圾回收
（1）当Eden区或者S区不够用了
（2）老年代空间不够用了
（3）方法区空间不够用了
（4）System.gc()
虽然垃圾回收的时机是不确定的，但是可以结合之前一个对象的一辈子案例，文字图解再次梳理一下堆内存回收的流程。
一个对象的一辈子
我是一个普通的Java对象,我出生在Eden区,在Eden区我还看到和我长的很像的小兄弟,我们在Eden区中玩了挺长时间。
有一天Eden区中的人实在是太多了,我就被迫去了Survivor区的“From”区,自从去了Survivor区,我就开始漂了,有时候在Survivor的“From”区,有时候在Survivor的“To”区,居无定所。直到我18岁的时候,爸爸说我成人了,该去社会上闯闯了。
于是我就去了年老代那边,年老代里,人很多,并且年龄都挺大的,我在这里也认识了很多人。在年老代里,我生活了20年(每次GC加一岁),然后被回收。
9.6.2 实验环境准备
我的本地机器使用的是jdk1.8和tomcat8.5，大家也可以使用linux上的tomcat，然后把gc日志下载下来即可。
9.6.3 GC日志文件
回顾升华一下垃圾收集器图
要想分析日志的信息，得先拿到GC日志文件才行，所以得先配置一下，之前也看过这些参数。
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:$CATALINA_HOME/logs/gc.log
比如打开windows中的catalina.bat，在第一行加上
set JAVA_OPTS=%JAVA_OPTS% -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:gc.log
这样使用startup.bat启动tomcat的时候就能够在当前目录下拿到gc.log文件
可以看到默认使用的是ParallelGC
9.6.3.1 Parallel GC日志
【吞吐量优先】
2019-06-10T23:21:53.305+0800: 1.303: [GC (Allocation Failure) [PSYoungGen: 65536K[Young区回收前]->10748K[Young区回收后](76288K[Young区总大小])] 65536K[整个堆回收前]->15039K[整个堆回收后](251392K[整个堆总大小]), 0.0113277 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
`注意`如果回收的差值中间有出入，说明这部分空间是Old区释放出来的
9.6.3.2 CMS日志
【停顿时间优先】
参数设置
-XX:+UseConcMarkSweepGC
重启tomcat获取gc日志，这里的日志格式和上面差不多，不作分析。
9.6.3.3 G1日志
G1日志格式参考链接：
https://blogs.oracle.com/poonam/understanding-g1-gc-logs
【停顿时间优先】
why?
https://blogs.oracle.com/poonam/increased-heap-usage-with-g1-gc
参数设置
-XX:+UseG1GC
9.6.4 GC日志文件分析工具
9.6.4.1 gceasy
可以比较不同的垃圾收集器的吞吐量和停顿时间
9.6.4.2 GCViewer
9.6.5 G1调优
是否选用G1垃圾收集器的判断依据
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/G1.html#use_cases
（1）50%以上的堆被存活对象占用
（2）对象分配和晋升的速度变化非常大
（3）垃圾回收时间比较长
(1)使用G1GC垃圾收集器: -XX:+UseG1GC
修改配置参数，获取到gc日志，使用GCViewer分析吞吐量和响应时间
Throughput MinPause MaxPause AvgPause GCcount
99.16% 0.00016s 0.0137s 0.00559s 12
(2)调整内存大小再获取gc日志分析
-XX:MetaspaceSize=100M-Xms300M-Xmx300M
比如设置堆内存的大小，获取到gc日志，使用GCViewer分析吞吐量和响应时间
Throughput MinPause MaxPause AvgPause GCcount
98.89% 0.00021s 0.01531s 0.00538s 12
(3)调整最大停顿时间
-XX:MaxGCPauseMillis=200 设置最大GC停顿时间指标
比如设置最大停顿时间，获取到gc日志，使用GCViewer分析吞吐量和响应时间
Throughput MinPause MaxPause AvgPause GCcount
98.96% 0.00015s 0.01737s 0.00574s 12
(4)启动并发GC时堆内存占用百分比
-XX:InitiatingHeapOccupancyPercent=45 G1用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比例。值为 0 则表示“一直执行GC循环)'. 默认值为 45 (例如, 全部的 45% 或者使用了45%).
比如设置该百分比参数，获取到gc日志，使用GCViewer分析吞吐量和响应时间
Throughput MinPause MaxPause AvgPause GCcount
98.11% 0.00406s 0.00532s 0.00469s 12
9.6.6 G1调优的最佳实践
官网建议：
(https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#recommendations)
(1)不要手动设置新生代和老年代的大小，只要设置整个堆的大小
G1收集器在运行过程中，会自己调整新生代和老年代的大小
其实是通过adapt代的大小来调整对象晋升的速度和年龄，从而达到为收集器设置的暂停时间目标
如果手动设置了大小就意味着放弃了G1的自动调优
(2)不断调优暂停时间目标
一般情况下这个值设置到100ms或者200ms都是可以的(不同情况下会不一样)，但如果设置成50ms就不太合理。暂停时间设置的太短，就会导致出现G1跟不上垃圾产生的速度。最终退化成Full GC。所以对这个参数的调优是一个持续的过程，逐步调整到最佳状态。暂停时间只是一个目标，并不能总是得到满足。
(3)使用-XX:ConcGCThreads=n来增加标记线程的数量
IHOP如果阀值设置过高，可能会遇到转移失败的风险，比如对象进行转移时空间不足。如果阀值设置过低，就会使标记周期运行过于频繁，并且有可能混合收集期回收不到空间。
> IHOP值如果设置合理，但是在并发周期时间过长时，可以尝试增加并发线程数，调高ConcGCThreads。
(4)MixedGC调优
-XX:InitiatingHeapOccupancyPercent
-XX:G1MixedGCLiveThresholdPercent
-XX:G1MixedGCCountTarger
-XX:G1OldCSetRegionThresholdPercent
(5)适当增加堆内存大小
9.7 一张图总结JVM性能优化
全文完！thanks for watching
欢迎关注“Java架构师学习”
