Home未分类JVM图文系列–一文学会JVM性能优化！

JVM图文系列–一文学会JVM性能优化！

2008 年 11 月 7 日

公众号ID：Java-jiagou
码字不易，加个鸡腿吧！

9 实战性能优化

9.1 重新认知JVM

之前
我们画过一张图，是从Class文件到类装载器，再到运行时数据区的过程，现在咱们把这张图不妨丰富完善一下，展示了JVM的大体物理结构图。


执行引擎:用于执行JVM字节码指令
主要由两种实现方式：
（1）将输入的字节码指令在加载时或执行时翻译成另外一种虚拟机指令；

（2）将输入的字节码指令在加载时或执行时翻译成宿主主机本地CPU的指令集。
这两种方式对应着字节码的解释执行和即时编译。

9.2 堆内存溢出

9.2.1 代码

@RestController

public class HeapController {

    List list=new ArrayList();

    @GetMapping("/heap")

    public String heap(){

        while(true){

            list.add(new Person());

        }

    }

}

记得设置参数比如-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代码

xml

<dependency>

    <groupId>asm</groupId>

    <artifactId>asm</artifactId>

    <version>3.3.1</version>

</dependency>
public class MyMetaspace extends ClassLoader {

    public static List<Class> createClasses() {

        List<Class> classes = new ArrayList<Class>();

        for (int i = 0; i < 10000000; ++i) {

            ClassWriter cw = new ClassWriter(0);

            cw.visit(Opcodes.V1_1, Opcodes.ACC_PUBLIC, "Class" + i, null,

                    "java/lang/Object", null);

            MethodVisitor mw = cw.visitMethod(Opcodes.ACC_PUBLIC, "",

                    "()V", null, null);

            mw.visitVarInsn(Opcodes.ALOAD, 0);

            mw.visitMethodInsn(Opcodes.INVOKESPECIAL, "java/lang/Object",

                    "", "()V");

            mw.visitInsn(Opcodes.RETURN);

            mw.visitMaxs(1, 1);

            mw.visitEnd();

            Metaspace test = new Metaspace();

            byte[] code = cw.toByteArray();

            Class exampleClass = test.defineClass("Class" + i, code, 0, code.length);

            classes.add(exampleClass);

        }

        return classes;

    }

}

9.3.2 代码

@RestController

public class NonHeapController {

    List<Class> list=new ArrayList<Class>();







    @GetMapping("/nonheap")

    public String nonheap(){

        while(true){

            list.addAll(MyMetaspace.createClasses());

        }

    }

}

设置Metaspace的大小，比如-XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=50M
9.3.3 运行结果
访问->http://localhost:8080/nonheap

java.lang.OutOfMemoryError: Metaspace

  at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_191]

  at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_191]

9.4 虚拟机栈

9.4.1 代码演示StackOverFlow

public class StackDemo {

    public static long count=0;

    public static void method(long i){

        System.out.println(count++);

        method(i);

    }

    public static void main(String[] args) {

        method(1);

    }

}

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 代码

//运行主类

public class DeadLockDemo

{

    public static void main(String[] args)

{

        DeadLock d1=new DeadLock(true);

        DeadLock d2=new DeadLock(false);

        Thread t1=new Thread(d1);

        Thread t2=new Thread(d2);

        t1.start();

        t2.start();

    }

}

//定义锁对象

class MyLock{

    public static Object obj1=new Object();

    public static Object obj2=new Object();

}

//死锁代码

class DeadLock implements Runnable{

    private boolean flag;

    DeadLock(boolean flag){

        this.flag=flag;

    }

    public void run() {

        if(flag) {

            while(true) {

                synchronized(MyLock.obj1) {

                    System.out.println(Thread.currentThread().getName()+"----if获得obj1锁");

                    synchronized(MyLock.obj2) {

                        System.out.println(Thread.currentThread().getName()+"----if获得obj2锁");

                    }

                }

            }

        }

        else {

            while(true){

                synchronized(MyLock.obj2) {

                    System.out.println(Thread.currentThread().getName()+"----否则获得obj2锁");

                    synchronized(MyLock.obj1) {

                        System.out.println(Thread.currentThread().getName()+"----否则获得obj1锁");







                    }

                }

            }

        }

    }

}

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性能优化


全文完！


欢迎关注“Java架构师学习”

如果觉得不错，请给个「在看」

分享给你的朋友！

THANDKS
– End –

Related Posts

About The Author

stack