深入理解java虚拟机JVM(上)

深入理解java虚拟机JVM(上)

链接:https://pan.baidu.com/s/1c6pZjLeMQqc9t-OXvUM66w
提取码:uwak
复制这段内容后打开百度网盘手机App,操作更方便哦

1. java的技术体系概述

1.1 java介绍

ava的体系结构规范:

  • java编程语言
  • java Class文件格式
  • java API
  • java VM

java VM

  • JVM的核心组件:Class loader
  • 执行引擎(解释器)-----> java进程启动

java编程语言的主要特性:纯面向对象的编程,多线程,结构化错误处理,自动垃圾收集,动态链接,动态扩展

java2 EE:

java 2 SE:JDK

  • Open JDK,Oracle JDK

java 2 EE:JDK + 企业级类库

  • Servlet,JSP,EJB,JMS,JMX,javaMall....
  • 商业实现:Weblogic,WebSphere,Oc4j,tomcat(java实现阉割版)

Web Container :

  • Servlet Container :Tomcat 3.x

实现:

商业版:

  • WebSphere(IBM)
  • Weblogic(Oracle)
  • JBoss

开源实现:

  • Tomcat:轻量级javaWeb服务器(servlet,jsp,jdk)
  • Jetty
  • Resin:重量级javaWeb服务器

1.2 java代码的编译与执行

image.png-64.4kB

1.3 java代码的类库调用过程

image.png-62.9kB

index.java --> javaC --> index.class --> class loader --> JVM

1.4 javaEE的处理流程

  • JSP(java server pages):运行于服务端的java程序,遵循servlet格式标准。
  • JS(javascript):网页中的脚本语言(html管理内容,css管理位置,js管理动作)
#Servlet格式:
JSP:
    <html>
        <title></title>
        <body>
            <h1>...<h1>
            <%
                ...
                java code here
                ...
            %>
        </body>
    </html>
  • 以上代码java编译器显然并不认识;
  • 所以我们才需要基于Servlet,将其转换为纯java代码,格式为servlet;
  • 如此一来java编译器才能认识,才能进行公共类的封装。

index.jsp --> Servlet(转译器) --> index_jsp.java--> javaC(编译器) -->index_jsp.class --> class loader(加载器) -->JVM

1.5 Tomcat架构分析

Tomcat官方网站 http://tomcat.apache.org

image.png-43.4kB

#tomcat组件:
    <Server>
        <Service>
            <Connector/>
            <Connector/>
            <Engine>
                <Host>
                    <Context/>
                    ...
                </Host>
                <Host>
                </Host>
                ...
            </Engine>
        </Service>
    </Server>

每个组件都是由“类”实现,此些组件可分为如下几类:

  • 顶级组件:Server
  • 服务组件:Service
  • 连接器组件:http,https,ajp
  • 容器类:Engine,Host,Context
  • 被嵌套类组件:valve,logger,realm,loader manager
  • 集群类组件:listener...

2. JVM执行分析

2.1 Java内存模型概述

image.png-50.1kB

运行时数据区之中内存的分配一共有五块:

  • 堆内存(Heap):保存真正的程序的数据的部分;
  • java栈(Stack):保存堆内存的地址,基本数据,方法的执行;
  • 方法区:保存所有的方法的具体操作,该区域属于共享;
  • 程序计数器:这是一块很小内存,只是做一个数据的计数;
  • 本地方法栈:该栈之中说保存的都是操作系统的原生函数。

在整个的JVM内存组成过程中,栈内存是一个非常重要的概念,因为在该内存之中,他需要保存的是一组内容。


栈是运行时的单位,而堆是存储的单元

  • 栈因为是运行单位,里面存储的信息都是跟当前线程(或程序)相关的信息。包括局部变量,程序运行状态,方法返回值等;
  • 堆知识保存对象信息

image.png-67.1kB

栈内存是线程私有的,其生命周期和线程相同;
虚拟机栈描述的是Java方法执行的内存模型:执行一个方法时会产生一个栈帧,随后将其保存到栈(后进先出)的顶部,方法执行完毕后会自动将此栈帧进行出栈。顶部的栈帧就表示的是当前方法;

  • 如果请求的栈的深度过大,虚拟机可能会抛出StackOverflowError异常;
  • 如果虚拟机的实现中允许,虚拟机栈动态扩展,当内存不足以扩展栈的时候,会抛出OutOfMemoryError异常。
    Java虚拟机栈----栈帧(Stack Frame),Java虚拟机栈会存放的是多个栈帧,包括如下主要组成部分
  • 局部变量表(Local Variables):方法的局部变量或形参,其以变量槽(solt)为最小单位,只允许保存32位长度的变量,如果超过32位则会开辟两个连续的solt(64位长度,long和double);
  • 操作数栈(Operand Stack):表达式计算在栈中完成;
  • 指向当前方法所属的类的运行时常量池的引用(Reference to runtime constant pool):引用其他类的常量或者使用String池中的字符串;
  • 方法返回地址(Return Address):方法执行完后需要返回调用此方法的位置,所以需要在栈帧中保存方法返回地址;

2.2 java对象的访问模式

在很多面向对象的语言里,都会存在一个叫做句柄的概念,而Java是没有提供有句柄的概念。这个概念的产生主要是在引用数据类型上,例如我们利用Python的句柄去打开一个文件,代码示例如下所示:

#句柄在python中的使用
f = open("test")      #创建文件句柄以相对路径打开文件(f ===> 指代文件的内存地址)
first_line = f.readline()    #读取文件内容的一行,并赋值
print (first_line)           #打印文件内容第一行                 
for num in range(4) :        #循环迭代4次
    print (f.readline())     #再读一行继续打印(重复4次)
f.close()                    #关闭文件
#对象(句柄)在java中的使用
Object obj              #声明对象,实际上只是表示一个本地的引用,那么这个本地的引用本身一定会保存一个堆内存的地址,在这之中还会包含一个本地变量表的概念,也就是说,引用类型通过本地变量表才能找到一个具体的堆内存的引用数据。

obj = new Object()    #实例化对象,实例化对象就会开辟堆内存空间;在这个过程中有两种做法:通过句柄进行访问;直接指针访问;

image.png-43.1kB

image.png-64.4kB

image.png-59.9kB

2.3 JVM的规范标准

image.png-32.1kB

现在最具有权威性的只有Oracle一家公司,因为拥有两个虚拟机的版权;
那么,我们现在用的虚拟机到底是什么版本呢?

#在安装了jdk环境的系统上查看
[root@Tomcat-Jvm ~]# which java
/usr/jdk/bin/java

[root@Tomcat-Jvm ~]# java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

image.png-14.7kB

  • 当前虚拟机采用的是混合模式mixed mode(解释与编译);
  • 这个的编译并不是像javaC一样将.java编译成.class那么简单;
  • 这里面包含了一个JIT(Just Is Time,即时编译);
  • VM在运行的时候,class loader只是把*.class文件做了一个简单的加载过程;
  • 真正运行*.class是JVM的执行引擎在执行的过程中动态完成的。
  • 当然,我们也可以改变这种模式,如下所示:
#JVM虚拟机的纯解释模式
[root@Tomcat-Jvm ~]# java -Xint -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, interpreted mode)

#JVM虚拟机的纯编译模式
[root@Tomcat-Jvm ~]# java -Xcomp -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, compiled mode)

image.png-21.4kB

3. JVM内存模型与垃圾收集

  • JVM的垃圾收集主要指的是堆内存空间,那么在我们每一次执行GC的时候需要区分出哪些堆内存需要被回收,哪些不需要被回收,所以为了整体的回收处理方便,JVM将堆内存分为如下的几个组成部分,而这几个组成部分你还需要去考虑JDK版本。
  • 现在的JVM内存划分就必须考虑JDK1.8以前和JDK1.8以后的问题;

3.1 Java堆内存模型

image.png-206.1kB

如果简化点来理解的话:

  • 新生代:那些刚刚创建的对象,刚刚创建的对象有可能会存在有许多的垃圾对象,那么这些对象是应该被优先回收的;
  • 老年代:老不死的那类对象,经过了很多次的清理之后你发现该对象依然有用;
  • 永久代:JAVA的intern()方法进行入池的对象实际上就在永久代中,永久代不会被回收;正因为它的存在本身属于一个BUG性的存在,因此在JDK1.8之后,将它更换为了元空间(电脑的直接内存)。

image.png-202.6kB

  • 在整个内存的组成过程之中每一代的内存都会有一个伸缩区,那么该区域就可以由JVM根据空间的使用情况动态扩充;
  • 当我们适当合理的设置了伸缩区的内存大小之后,就可以得到良好的性能提升,也就是说最容易的性能提升就是改变伸缩区的内存大小设置。

3.2 Java对象创建与垃圾回收流程

在Java之中支持有GC的概念,那么GC有两种调用形式:自动调用,手工调用(Runtime.getRuntime().gc())。但一般情况下,我们很少用手工调用GC的方式。那么什么时候我们会进行自动的GC调用呢?这里面就牵扯到了两类的GC操作环境

image.png-154.8kB

  • 当我们的程序中需要产生新的实例化对象(关键字new,对象克隆,反射实例化)的时候那么就一定要进行内存空间的开辟,所以此时需要申请新的内存空间;
  • 新对象要申请的对象空间默认都是在伊甸园区(新生)进行开辟,所以首先需要判断伊甸园区是否有空余的内存空间,如果有,那么直接在伊甸园区开辟新的堆内存空间,此时不会发生有GC处理;
  • 如果新对象无法在伊甸园空间申请出新的空间,那么就表示现在的伊甸园的内存空间不足,不足就需要将那些无用的新对象进行回收(Minor GC),当回收完成后要继续判断该空间是否可以容纳新的对象,如果可以容纳,则开辟新的空间保存新的对象;
  • 如果此时伊甸园区即使执行了Minor GC之后发现依然没有可以被回收的对象,那么这个时候将继续判断存活区是否有空间(存活区一般与伊甸园区比率:1:1:8),如果存活区有空余空间,则将那些活跃的伊甸园区的部分对象直接保存给存活区,就相当于伊甸园区可以腾出部分的空间(这个空间非常小)来,供新对象进行使用;
  • 如果此时存活区依然满了(空间不足),则继续向老年代进行内存空间的申请,首先会判断老年代的空间是否空余,如果有空余的空间,则将存活区中的活跃对象保存在老年代,而后存活区得到了空间释放,伊甸园区也就得到了空间释放,从而伊甸园区就可以开辟新的内存空间来保存新的对象;
  • 如果现在老年区也是满的,那么这个时候就会执行FULL GC(完全GC,Major GC)进行老年代的内存释放,如果可以释放成功,则进行对象的保存,如果释放不成功则表示已经没有无用的内存空间了,那么就会抛出OOM错误(OutOfMemoryError)。

3.2.1 请问自动的GC什么时候触发?

GC的触发有两类:

  • Minor GC:发生在新生代内存空间,当新生代内存空间不足时会进行触发,释放新生代中不活跃的对象;
  • Full GC:发生在老年代内存空间,当老年代的空间不足时会自动触发Full GC,如果触发Full GC之后内存空间依然不足,则会产生OutOfMemoryError的错误提示信息;

3.3 Java堆内存基础调整策略(JVM基础优化策略)

GC 虽然可以进行内存空间的释放,但同时频繁的GC一定会影响系统性能,那么如何才可以不频繁的发生GC呢?

  • 内存越大GC发生的频率就越低,你的系统的性能一定就越高效。
    如果我们给用户使用的内存空间留有伸缩区,那么
  • 可用内存空间不足,就会判断伸缩区是否有空间,而后部分开辟伸缩区的空间。那么这种伸缩区的开辟与回收就有可能产生性能下降。

image.png-207.1kB

如果说现在取消掉伸缩区的概念,让初始化的内存就是最大的可用内存空间,这样就可以实现JVM的性能调整,避免每次gc后都重复性调整堆的大小,可以让整个的代码的执行速度得到提升。

例如:-Xms16g -Xmx16g 将堆内存初始大小和堆内存最大大小设成一样,如此就把“伸缩区”给取消掉了

3.3.1 Tomcat堆内存调优实操演示

#在一台启动了tomcat的虚拟机上进行如下操作(未调优前 
[root@Tomcat-Jvm ~]# pgrep java    #查看tomcat的pid号
7862

[root@Tomcat-Jvm ~]# jmap -heap 7862   #通过jmap命令追踪java进程的堆信息
Attaching to process ID 7862, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.60-b23

using thread-local object allocation.
Mark Sweep Compact GC

Heap Configuration:                   #堆内存初始化配置
   MinHeapFreeRatio         = 40      #JVM堆最小空闲比率
   MaxHeapFreeRatio         = 70      #JVM堆最大空闲比率
   MaxHeapSize              = 255852544 (244.0MB)   #JVM堆的最大大小
   NewSize                  = 5570560 (5.3125MB)    #新生代的堆内存默认大小
   MaxNewSize               = 85262336 (81.3125MB)  #新生代的堆内存最大大小
   OldSize                  = 11206656 (10.6875MB)  #老年代的堆内存最大大小
   NewRatio                 = 2     #新生代和老年代的大小比率(新生代:老年代=1:2)
   SurvivorRatio            = 8     #新生代中eden区和存活区的大小比值(eden:S0:S1=8:1:1)
   MetaspaceSize            = 21807104 (20.796875MB)  #元空间的默认大小
   CompressedClassSpaceSize = 1073741824 (1024.0MB)   #类指针压缩空间大小,默认1G
   MaxMetaspaceSize         = 17592186044415 MB       #元数据最大值,超过此值会触发FULL GC,受限与系统内存大小
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):    #新生代对内存统计
   capacity = 8257536 (7.875MB)
   used     = 5357464 (5.109275817871094MB)
   free     = 2900072 (2.7657241821289062MB)
   64.87969292534723% used
Eden Space:
   capacity = 7340032 (7.0MB)
   used     = 4439968 (4.234283447265625MB)
   free     = 2900064 (2.765716552734375MB)
   60.48976353236607% used
From Space:
   capacity = 917504 (0.875MB)
   used     = 917496 (0.8749923706054688MB)
   free     = 8 (7.62939453125E-6MB)
   99.99912806919643% used
To Space:
   capacity = 917504 (0.875MB)
   used     = 0 (0.0MB)
   free     = 917504 (0.875MB)
   0.0% used
tenured generation:     #老年代堆内存统计
   capacity = 18305024 (17.45703125MB)
   used     = 14210536 (13.552223205566406MB)
   free     = 4094488 (3.9048080444335938MB)
   77.6318894747147% used

9903 interned Strings occupying 857912 bytes.
#进行tomcat的基础堆内存参数调优
#调优tomcat的java内存需要在/usr/tomcat/bin/catalina.sh文件中加入参数
[root@Tomcat-Jvm bin]# vim catalina.sh 
[root@Tomcat-Jvm bin]# sed -n '121p' catalina.sh 
JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m -Xmx1024m"

#重启动tomcat
[root@Tomcat-Jvm ~]# /usr/tomcat/bin/shutdown.sh 

[root@Tomcat-Jvm ~]# /usr/tomcat/bin/startup.sh 
#再次最终java进程的堆信息
[root@Tomcat-Jvm ~]# pgrep java
7933

[root@Tomcat-Jvm ~]# jmap -heap 7933
Attaching to process ID 7933, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.60-b23

using thread-local object allocation.
Mark Sweep Compact GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 1073741824 (1024.0MB)
   NewSize                  = 357892096 (341.3125MB)
   MaxNewSize               = 357892096 (341.3125MB)
   OldSize                  = 715849728 (682.6875MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 322109440 (307.1875MB)
   used     = 137906424 (131.51781463623047MB)
   free     = 184203016 (175.66968536376953MB)
   42.81353070558876% used
Eden Space:
   capacity = 286326784 (273.0625MB)   #eden+两个存活区大小刚好为MaxNewSize大小,没有伸缩区了
   used     = 137906424 (131.51781463623047MB)
   free     = 148420360 (141.54468536376953MB)
   48.163997120157646% used
From Space:
   capacity = 35782656 (34.125MB)
   used     = 0 (0.0MB)
   free     = 35782656 (34.125MB)
   0.0% used
To Space:
   capacity = 35782656 (34.125MB)
   used     = 0 (0.0MB)
   free     = 35782656 (34.125MB)
   0.0% used
tenured generation:
   capacity = 715849728 (682.6875MB)
   used     = 0 (0.0MB)
   free     = 715849728 (682.6875MB)
   0.0% used

9909 interned Strings occupying 858528 bytes.
3.3.2 项目中如何对java(JVM)进行调优?

在堆内存之中会存在有一个伸缩区的概念。

  • 默认情况下最大可用内存为整体内存的四分之一;
  • 默认使用的内存为整体可用内存的六十四分之一;
  • 这时候只需要避免伸缩区的频繁变更,就可以提升程序的性能。
  • 可以在程序执行的时候使用“-Xmx”设置最大可用内存空间大小;
  • 可以在程序执行的时候使用“-Xms”设置初始化内存空间大小;
  • 将这两个内容设置为一样的空间大小,就可以提升JVM的运行性能

3.4 新生代

新生代主要分为两个区域

  • 伊甸园区
  • 存活区

image.png-115.7kB

所有新创建的对象都会存活在伊甸园区,但是伊甸园区保存的空间一定是最大的,毕竟产生新对象的几率是很高的,在伊甸园区里面由于里面的对象经常可能只是临时创建,所以拥有一个Minor GC的操作处理,而经过多次的Minor GC后依然被保留下来的对象就认为该对象不应该被回收,则将此对象保存到存活区之中。
存活区一共分为两类:

  • 存活0区(S0区,From Space)
  • 存活1区(S1区,To Space)

这两个存活区主要是负责对象的晋级,向老年代进行晋级,并且这两个存活区有一块是专门负责对象回收的,因此有一块内存空间总是空的。(一个负责晋升,一个负责回收)。由于伊甸园区保存的数据对象一般比较多,所以默认的比率8:1:1。

3.4.1 新生代GC算法----复制算法(Copying)

算法:复制采用的方式为从根集合扫描出存活的对象,并将找到的存活对象复制到一块新的完全未使用的空间中。

下图红色部分为不存活对象所占内存空间,绿色为存活对象所占内存空间;

image.png-179.1kB

在进行GC之前一定要先发生一次全对象的扫描处理操作,通过扫描才可以知道哪些对象是垃圾空间

3.4.2 新生代中的算法优化

在实际运行中,由于Eden区总是会保存大量的新生对象,所以HotSpot虚拟机为了可以加快此空间的内存分配,而使用了两种技术。

  • BTP(Bump-The-Pointer)
  • TLAB(Thread-Local Alloction Buffers)

(1)BTP(Bump-The-Pointer)

image.png-283.2kB

虽然BTP的做法可以极大提高内存分配的速度;但堆内存和方法区都是线程共享的,在java多线程的情况下,线程间如果同时都要向Eden存入对象,那么就会产生冲突

(2)TLAB(Thread-Local Alloction Buffers)

image.png-342.2kB

  • TLAB这种算法既解决了内存分配速度问题还解决了线程间冲突的问题;
  • 但是这种算法会产生内存碎片(已经占用,但未存入对象);
  • 而且如果Eden区为每个线程开辟的数据块过大,那么就会影响程序多线程的能力;
  • 因此每个线程在Eden中的线程栈的大小,是需要我们进行调优的。

3.4.3 新生代内存参数调整

image.png-247.7kB

3.4.4 新生代堆内存参数调优实操演示

[root@Tomcat-Jvm bin]# pwd
/usr/tomcat/bin
[root@Tomcat-Jvm bin]# sed -n '121p' catalina.sh    #源参数
JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m -Xmx1024m"
[root@Tomcat-Jvm bin]# vim catalina.sh 
[root@Tomcat-Jvm bin]# sed -n '121p' catalina.sh    #现参数
JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m -Xmx1024m -Xmn500m -Xss256k"

#重启动tomcat
[root@Tomcat-Jvm bin]# pgrep java
7631
[root@Tomcat-Jvm bin]# kill -9 7631
[root@Tomcat-Jvm bin]# sh startup.sh    
[root@Tomcat-Jvm bin]# pgrep java
7734
[root@Tomcat-Jvm bin]# pgrep java
7734

[root@Tomcat-Jvm bin]# jmap -heap 7734
Attaching to process ID 7734, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.60-b23

using thread-local object allocation.
Mark Sweep Compact GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 1073741824 (1024.0MB)
   NewSize                  = 524288000 (500.0MB)
   MaxNewSize               = 524288000 (500.0MB)
   OldSize                  = 549453824 (524.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 471859200 (450.0MB)
   used     = 168826264 (161.0052719116211MB)
   free     = 303032936 (288.9947280883789MB)
   35.77894931369357% used
Eden Space:
   capacity = 419430400 (400.0MB)
   used     = 168826264 (161.0052719116211MB)
   free     = 250604136 (238.9947280883789MB)
   40.25131797790527% used
From Space:
   capacity = 52428800 (50.0MB)
   used     = 0 (0.0MB)
   free     = 52428800 (50.0MB)
   0.0% used
To Space:
   capacity = 52428800 (50.0MB)
   used     = 0 (0.0MB)
   free     = 52428800 (50.0MB)
   0.0% used
tenured generation:
   capacity = 549453824 (524.0MB)
   used     = 0 (0.0MB)
   free     = 549453824 (524.0MB)
   0.0% used

9870 interned Strings occupying 856216 bytes.

3.5 老年代

  • 一个对象要想真正的活到老年代实在是太难了,因为现在的程序属于多线程访问,所有的业务操作的对象都是针对于线程操作的,那么所有的线程在整体的操作过程中时间都是非常短的。那么这些对象往往都在新生代中开辟,很少能跑到老年代中。
  • 老年代空间的主要目的是用于存储由Eden发送来的对象,一般在经历好几次“Minor GC”还会被保存下来的对象,才会被复制到老年代,一般老年代的内存空间大小会设置的比新生代要大,这样就可以存放更多的对象,同时在老年代中执行GC的次数也相对较少,当老年代内存不足时会自动执行“FULL GC”(也叫做“Major GC”)

3.5.1 老年代GC算法1----标记-清除(Mark-Sweep)

算法:标记-清除采用的方式为从根集合开始扫描,对存活的对象进行标记,标记完毕后,再扫描整个空间中未标记的对象,并进行回收。

image.png-59.8kB

优缺点:在空间中存活对象较多的情况下较为高效,但由于该算法为直接回收不存活对象所占用的内存,因此会造成内存碎片

3.5.2 老年代GC算法2----标记-压缩(Mark-Compact)

算法:标记阶段与“标记-清除”算法相同,但在清除阶段有所不同。在回收不存活对象所占用的内存空间后,会将其他所有存活对象都往左端空闲的空间进行移动,并更新引用其对象指针。

image.png-84.2kB

优缺点:在“标记-清除”的基础上还需要进行对象移动,降低性能,成本相对较高,好处则是不产生内存碎片。

3.5.3 老年代内存参数调整

image.png-203.5kB

  • 默认情况下,所有的对象都会通过新生代进行创建,而后经过不断的Minor GC之后要将其保存在老年代之中,但是如果现在有些对象的内容特别庞大。那么就建议不经过新生代而将其直接保存到老年代之中,就可以设置-XX:PretenureSizeThreshold=512K参数
  • 一般一个良好的程序开发,是不可能出现对象过大的问题的。如果这种情况过多,就会造成老年代空间占满而触发FULL GC,一旦进行FULL GC那么持续时间会很长,对性能的影响很大。

3.6 永久代(JDK1.8后被废除了)

  • 永久代是在JDK1.8以前的一个bug性的存在,其核心的本质在于:该区域中的对象不会被回收。当时简单的理解就是方法区就是永久代。
  • 我们知道HotSpot虚拟机规范之中是存在有永久代概念的,但是BEA和IBM的虚拟机之中是不包含永久代概念的,Oracle公司现在将HotSpot中的永久代取消了,那么就意味着它现在希望可以将HotSpot与JRockit两个虚拟机的规范进行合并。

3.6.1 永久代内存参数调整(设置也已经没用了)

image.png-203.7kB

3.7 元空间

从JDK1.8开始正式取消了永久代之后,取而代之的就是元空间(MetaSpace),所谓的元空间的本质指的就是本机的物理内存,其作用和永久代相同。但是元空间和永久代最大的区别:元空间用的是物理内存(受到本机的物理内存限制),而永久代是JVM的内存空间,本身受到JVM的限制。

3.7.1 元空间的内存参数调整

image.png-386.3kB

基本上并不需要做调整

3.8 关于java的堆内存溢出(java.lang.OutOfMemoryError)

java的OOM报错有三种情况:

  • java的堆内存溢出(java heap space)
  • 永久代溢出(PermGen space)
  • 元空间溢出(Meta space)

3.8.1 请问是否知道什么叫OOM?什么情况下会出现?

OutOfMemoryError:指的是内存溢出问题,内存的溢出需要考虑以下情况

  • java的堆内存溢出(java heap space):往往出现在Full GC失败之后;
  • 永久代溢出(PermGen space):一个方法中出现的内存溢出;
  • 元空间溢出(Meta space):分配的物理内存不足,或者数据量高于物理内存。