java7优化_一文学会JVM性能优化

实战性能优化

1 重新认知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       min pause       max pause      avg pause       gc count

99.16%         0.00016s         0.0137s        0.00559s          12

(2)调整内存大小再获取gc日志分析

-xx:metaspacesize=100m-xms300m-xmx300m

比如设置堆内存的大小，获取到gc日志，使用gcviewer分析吞吐量和响应时间

throughput       min pause       max pause      avg pause       gc count

98.89%             0.00021s             0.01531s            0.00538s             12

(3)调整最大停顿时间

-xx:maxgcpausemillis=200    设置最大gc停顿时间指标

比如设置最大停顿时间，获取到gc日志，使用gcviewer分析吞吐量和响应时间

throughput       min pause       max pause      avg pause       gc count

98.96%          0.00015s        0.01737s       0.00574s          12

(4)启动并发gc时堆内存占用百分比

-xx:initiatingheapoccupancypercent=45 g1用它来触发并发gc周期,基于整个堆的使用率,而不只是某一代内存的使用比例。值为 0 则表示“一直执行gc循环)'. 默认值为 45 (例如, 全部的 45% 或者使用了45%).

比如设置该百分比参数，获取到gc日志，使用gcviewer分析吞吐量和响应时间

throughput       min pause       max pause      avg pause       gc count

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

相关阅读：

希望与广大网友互动？？

点此进行留言吧！