JVM性能调优实现原理及配置
1、JVM内存模型
总结：可以发现最明显的一个变化是元空间从虚拟机转移到了本地内存。默认情况下，元数据空间大小仅受限于本地内存， 这意味着以后不会因为永久代大小不够而抛出OOM异常了。 jdk1.8以前，HotSpot VM将class和类的jar包数据存储在PermGen里， PermGen大小是固定的，而且项目之间无法公用公有的class，所以很容易碰到OOM异常。改成MateSpace后， 各个项目会共享同样的class空间。比如多个项目都引用了apache-common包， 在MateSpace中只会存储一份的apache-common的class，提高了内存的利用率，垃圾回收更有效。
2、JVM堆内存常用参数
| 参数 | 描述 |
|---|---|
| -Xms | 堆内存初始大小，单位m、g |
| -Xmx（MaxHeapSize） | 堆内存最大允许大小，一般不要大于物理内存的80% |
| -XX:PermSize | 非堆内存初始大小，一般应用设置初始化200m，最大1024m就够了 |
| -XX:MaxPermSize | 非堆内存最大允许大小 |
| -XX:NewSize（-Xns） | 年轻代内存初始大小 |
| -XX:MaxNewSize（-Xmn） | 年轻代内存最大允许大小，也可以缩写 |
| -XX:SurvivorRatio=8 | 年轻代中Eden区与Survivor区的容量比例值，默认为8，即8:1 |
| -Xss | 堆栈内存大小 |
3、GC（Garbage Collection）算法
这里的GC具体指的是新生代的复制算法
首先贴一张网上盗来的大图，用它来说明一下GC的过程
内存分配策略：
大多数情况下，对象在新生代的Eden中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC，而大对象（需要大量连续内存空间的Java对象，类似长字符串和数组）将通过分配担保机制直接进入老年代。
Minor GC——复制算法具体过程：
将Eden和S0中还存活着的对象一次性的复制到S1中，并且清理掉Eden与S0的空间。如果S1放不下还存活着的对象，那这些对象将通过分配担保机制进入老年代。【原理上随时保持S0和S1有一个是空的，用来存下一次的对象】
Eden区快满的时候，会进行上一步类似操作，将Eden和S1区的年纪大的对象放到S0区【此时S1区就是空的】
直到Eden区快满，S0或者S1也快满的时候，这时候就把这两个区的年纪大的对象放到Old区。
依次循环，直到Old区也快满的时候，Eden区也快满的时候，会对整个这一块内存区域进行一次大清洗（FullGC），腾出内存，为之后的对象创建，程序运行腾地方。
新生代GC（Minor GC）:指发生在新生代的垃圾回收动作，因为java对象大多具备朝生夕灭的特征，所以Minor GC发生的特别频繁，
一般回收速度也很快。
老年代GC（Major GC/Full GC）:指发生在老年代的GC，出现了Major GC，至少会伴随一次的MinorGC（但非绝对，
在Parallel Scavenge收集器的收集策略里就有直接进行Minor GC的策略选择过程）。Major GC的速度一般比Minor GC慢10倍以上。
4、JVM参数配置
在jdk1.8以前，生产环境一般有如下配置
-XX:PermSize=512M -XX:MaxPermSize=1024M
表示在JVM里存储Java类信息，常量池和静态变量的永久代区域初始大小为512M，最大为1024M。在项目启动后，这个值是固定的，如果项目class过多，很可能遇到OutOfMemoryError: PermGen异常。
升级JDK1.8之后，上面的perm配置已经变成
-XX:MetaspaceSize=512M XX:MaxMetaspaceSize=1024M
MetaspaceSize如果不做配置，通过jinfo查看默认MetaspaceSize大小（约21M）,MaxMetaspaceSize很大很大，前面说过MetaSpace只受本地内存大小限制。
jinfo -flag MetaspaceSize 1234 #结果为：-XX:MetaspaceSize=21807104
jinfo -flag MaxMetaspaceSize 1234 #结果为：-XX:MaxMetaspaceSize=18446744073709547520
干货：MetaspaceSize为触发FullGC的阈值，默认约为21M，如做了配置，最小阈值为自定义配置大小。空间使用达到阈值，触发FullGC，同时对该值扩大。当然如果元空间实际使用小于阈值，在GC的时候也会对该值缩小。
MaxMetaspaceSize为元空间的最大值，如果设置太小，可能会导致频繁FullGC，甚至OOM。
5. JVM参数配置指南
前面三个部分对JVM进行了整体的了解，接下来是本文的重点。
-XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256M -Xms256m -Xmx256m
文章看下来上面这段配置的意思很简单，设置元空间的初始值和最大值，设置堆空间的初始值和最大值。
为什么MetaspaceSize要设置为128M？为什么堆内存初始值Xms设置为256M而不是512M？
按照Java官方的指导
- Java堆大小设置，Xms 和 Xmx设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍
- MaxPermSize(元空间)设置为老年代存活对象的1.2-1.5倍。
- 年轻代Xmn的设置为老年代存活对象的1-1.5倍。
- 老年代的内存大小设置为老年代存活对象的2-3倍。
5. JVM监控jstat
可以让系统运行一段时间后查看系统的各个指标，然后在进行配置。如下用jstat工具查看jvm的情况
jstat -gc 12345
###
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
13824.0 22528.0 13377.0 0.0 548864.0 535257.2 113152.0 46189.3 73984.0 71119.8 9728.0 9196.2 14 0.259 3 0.287 0.546
OU表示老年代所占用的内存为 46189.3 K（大约45M）；那么jvm相应的配置参数应该做如下修改
-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M -Xms180m -Xmx180m
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。
相关推荐
-
JVM Client和Server端有什么区别
java -version 命令大家都用过,大部分就是看下jdk版本或检查下环境变量的设置,但最后一行的信息也挺重要,如下图所示: Server VM表示我们的虚拟机类型,mixed mode表示虚拟机以混合模式工作. 一. 虚拟机 先说下本篇文章的内容都是基于HotSpot虚拟机. 我们熟知的Java虚拟机是一种规范标准,有多种实现,比如HotSpot虚拟机就是JVM的一种实现,也是目前使用范围最广的Java虚拟机.其实HotSpot最早也不是Sun开发的,是他早期收购的一家公司开发的,后来S
-
JVM类运行机制实现原理解析
1.一段java程序是如何运行起来的呢? Java源文件,通过编译器,产生.Class字节码文件,字节码文件通过Java虚拟机中的解释器,编译成特定及其上的机器码,那Java虚拟机又是怎样加载java程序并执行起来的呢? 简单来说:通过类加载器加载字节码文件,被分配到JVM的运行时数据区的字节码会被执行引擎执行. (1)类加载器,加载.class文件 (2)运行数据区:栈区.堆区.PC寄存器.本地方法栈.方法区 (3)执行引擎:执行包在装载类方法中的指令 2. 类加载器 类的加载是指将类的.cl
-
JVM创建对象及访问定位过程详解
1.对象的创建 虚拟机接收到new指令时,检查这个指令能否在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载.解析和初始化.如果都没有,先执行类加载过程. 在类加载通过后,虚拟机为新对象分配内存(把一块确定大小的内存从Java堆中划分出来),内存大小在类加载完成后即可完全确定. 两种分配方式: (1):指针碰撞:假设Java堆中内存是绝对规整的,即使用过的内存在一边,空闲的内存在另外一边,中间放着一个指针作为指示器,通过移动指针实现内存分配. (2):空闲列表:如果Jav
-
解决jmap命令打印JVM堆信息异常的问题
jmap命令可以打印java进程的JVM堆信息,今天在某台机器上运行该命令查看 19560进程的堆信息 jmap -heap 19560 出现以下异常 Attaching to process ID 19560, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24.79-b02 using thread-local object allocation. Paralle
-
JVM Metaspace内存溢出问题解决方案
一. 现象 前段时间公司线上环境的一个Java应用因为OOM的异常报警,导致整个服务不可用被拉出集群,本地模拟重现的现象如下: 当时的解决方案是增加metaspace的容量:-XX:MaxMetaspaceSize=500m,从原来默认的256m改为500m,虽然没有再出现oom,但这个只是临时解决方案,通过公司的监控系统观察metaspace的使用情况还是在上升,而且后面随着业务访问量越来越大还是有可能达到阈值. 二. 分析 Metaspace元空间主要是存储类的元数据信息,我们的应用里加载的
-
IdeaGo启动报错Failed to create JVM的问题解析
[内容]: 问题情况 出现之前做了什么 出错之前通过这个功能增加了个错误的vm参数:-agent:xxx.jar 怎么办? 百度了一圈,都是让删掉:C盘\用户\用户名\.IntelliJIdea2019.3\config\idea64.exe.vmoptions 然而,我这并没有这个文件.百思不得其解,重装等各种方式都试过还是不能用. 思考之: 1.这明显是一个用户下的配置文件,因此肯定是配置文件使用到了用户级别的,改idea下的配置文件肯定是没用的. 2.明显是因为我修改了VM 参数导致的,网
-
java编译器和JVM的区别
Java虚拟机(JVM)是可运行Java代码的假想计算机.只要根据JVM规格描述将解释器移植到特定的计算机上,就能保证经过编译的任何Java代码能够在该系统上运行.java编译器把java编译成字节码,也就是.class文件,然后JVM给编译成的字节码提供运行环境.java的源代码是无法直接在JVM上运行的. 1.java编译器 Java语言写的源程序通过Java编译器,编译成与平台无关的'字节码程序'(.class文件,也就是0,1二进制程序),然后在OS之上的Java解释器中解释执行. 也相
-
浅析JVM的垃圾回收器
JVM的GC经过多年的发展,大家对Minor GC.major GC的理解并不完全一致,所以我不打算在本文中使用这个概念.我把GC大概分为一下4类: Young GC:只是负责回收年轻代对象的GC: Old GC:只是负责回收老年代对象的GC: Full GC:回收整个堆的对象,包括年轻代.老年代.持久带: Mixed GC:回收年轻代和部分老年代的GC (G1): 因为笔者目前使用G1还是比较少的,所以本文不打算将G1. 垃圾回收器算法 目前主流垃圾回收器都采用的是可达性分析算法来判断对象是否
-
JVM代码缓存区CodeCache原理及用法解析
一. CodeCache简介 从字面意思理解就是代码缓存区,它缓存的是JIT(Just in Time)编译器编译的代码,简言之codeCache是存放JIT生成的机器码(native code).当然JNI(Java本地接口)的机器码也放在codeCache里,不过JIT编译生成的native code占主要部分. 大致在JVM中的分布如下: 大家都知道javac编译器,把java代码编译成class字节码,它和JIT编译器的区别是,javac只是前端编译(有的叫前期编译),jvm是通过执行机
-
JVM性能调优实现原理及配置
1.JVM内存模型 总结:可以发现最明显的一个变化是元空间从虚拟机转移到了本地内存.默认情况下,元数据空间大小仅受限于本地内存, 这意味着以后不会因为永久代大小不够而抛出OOM异常了. jdk1.8以前,HotSpot VM将class和类的jar包数据存储在PermGen里, PermGen大小是固定的,而且项目之间无法公用公有的class,所以很容易碰到OOM异常.改成MateSpace后, 各个项目会共享同样的class空间.比如多个项目都引用了apache-common包, 在MateS
-
JVM性能调优实战:让你的IntelliJ Idea纵享丝滑
本文已被Github仓库收录 https://github.com/silently9527/JavaCore 前言 在前面整理了一篇关于JVM故障诊断和处理工具,考虑到大部分的Java程序员都使用的是IntelliJ Idea,本篇就使用工具来实战演练对IntelliJ Idea运行速度调优 调优前的运行状态 原始配置内容 要查询idea原始配置文件的路径可以在VisualVM中的概述中查看 原始配置内容: -XX:ReservedCodeCacheSize=240m -XX:+UseComp
-
TCP性能调优实现原理及过程解析
三次握手阶段 客户端SYN包的重试次数 sysctl -w net.ipv4.tcp_syn_retries=6 相关介绍 第 1 次重试发生在 1 秒钟后,接着会以翻倍的方式在第 2.4.8.16.32 秒共做 6 次重试,最后一次重试会等待 64 秒,如果仍然没有返回 ACK,才会终止三次握手.所以,总耗时是 1+2+4+8+16+32+64=127 秒,超过 2 分钟. 服务端半连接池大小 sysctl -w net.ipv4.tcp_max_syn_backlog=16384 服务端半连
-
jvm垃圾回收GC调优基础原理分析
目录 核心概念(Core Concepts) Latency(延迟) Throughput(吞吐量) Capacity(系统容量) 相关示例 Tuning for Latency(调优延迟指标) Tuning for Throughput(吞吐量调优) Tuning for Capacity(调优系统容量) 说明: Capacity: 性能,能力,系统容量; 文中翻译为”系统容量“; 意为硬件配置. GC调优(Tuning Garbage Collection)和其他性能调优是同样的原理.初学者
-
Java性能调优概述
程序性能的主要表现点: 执行速度:程序的反映是否迅速,响应时间是否足够短 内存分配:内存分配是否合理,是否过多地消耗内存或者存在内存泄漏 启动时间:程序从运行到可以正常处理业务需要花费多少时间 负载承受能力:当系统压力上升时,系统的执行速度.响应时间的上升曲线是否平缓 衡量程序性能的主要指标: 执行时间:程序从运行到结束所使用的时间 CPU时间:函数或者线程占用CPU的时间 内存分配:程序在运行时占用内容的空间 磁盘吞吐量:描述I/O的使用情况 网络吞吐量:描述网络的使用情况 响应时间:系统对用
-
SpringBoot JVM参数调优方式
目录 SpringBoot JVM参数调优 各种参数 SpringBoot jar包启动设置JVM参数 配置初始化堆和最大堆的大小 SpringBoot JVM参数调优 各种参数 参数名称 含义 默认值 说明 -Xms 初始堆大小 物理内存的1/64(<1GB) 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制. -Xmx 最大堆大小 物理内存的1/4(<1GB) 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大
-
java性能调优System的gc垃圾回收方法
目录 一.什么是System.gc()? 二.谁可以调用System.gc()? 三.调用System.gc()有什么弊端? 四.哪些场景适合显式调用System.gc()? 五.如何检测您的应用程序正在进行System.gc()? 六.如何禁止GC显式调用或调整调用GC的频率? 搜索和替换 通过JVM参数强制禁止 RMI 一.什么是System.gc()? System.gc()是用Java,C#和许多其他流行的高级编程语言提供的API.当它被调用时,它将尽最大努力从内存中清除垃圾(即未被引用
-
web性能优化之javascript性能调优
JavaScript 是一个比较完善的前端开发语言,在现今的 web 开发中应用非常广泛,尤其是对 Web 2.0 的应用.随着 Web 2.0 越来越流行的今天,我们会发现:在我们的 web 应用项目中,会有大量的 JavaScript 代码,并且以后会越来越多.JavaScript 作为一个解释执行的语言,以及它的单线程机制,决定了性能问题是 JavaScript 的软肋,也是 web 软件工程师们在写 JavaScript 需要高度重视的一个问题,尤其是针对 Web 2.0 的应用.绝大多
-
.NET性能调优之一：ANTS Performance Profiler的使用介绍
在使用.NET进行快速地上手与开发出应用程序后,接下来面临的问题可能就是程序性能调优方面的问题,而性能调优有时候会涉及方方面面的问题,如程序宿主系统.数据库.网络环境等等,而当程序异常庞大复杂的时候,性能调优将变得更加无从下手. 本系列文章主要会介绍一些.NET性能调优的工具.Web性能优化的规则(如YSlow)及方法等等内容.成文前最不希望看到的就是园子里不间断的"哪个语言好,哪个语言性能高"的争论,不多说,真正的明白人都应该知道这样的争论有没有意义,希望我们能从实际性能优化的角度去
-
10个MySQL性能调优的方法
MYSQL 应该是最流行了 WEB 后端数据库.WEB 开发语言最近发展很快,PHP, Ruby, Python, Java 各有特点,虽然 NOSQL 最近越來越多的被提到,但是相信大部分架构师还是会选择 MYSQL 来做数据存储. MYSQL 如此方便和稳定,以至于我们在开发 WEB 程序的时候很少想到它.即使想到优化也是程序级别的,比如,不要写过于消耗资源的 SQL 语句.但是除此之外,在整个系统上仍然有很多可以优化的地方. 1. 选择合适的存储引擎: InnoDB 除非你的数据表使用来做