故障排查与优化深入专题(四):深入理解java虚拟机JVM(上)

一,java的技术体系概述

 

1.1 java介绍

  • java的体系结构规范:

    • java编程语言
    • java Class文件格式
    • java API
    • 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代码的编译与执行

QQ截图20181022220517.png-50.2kB

 

1.3 java代码的类库调用过程

QQ截图20181022224316.png-46.3kB

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

 

1.4 javaEE的处理流程

JSP(java server pages):运行于服务端的java程序,遵循servlet格式标准。
JS(javascript):网页中的脚本语言(html管理内容,css管理位置,js管理动作)

 
  1. #Servlet格式:
  2. JSP:
  3. <html>
  4. <title></title>
  5. <body>
  6. <h1>...<h1>
  7. <%
  8. ...
  9. java code here
  10. ...
  11. %>
  12. </body>
  13. </html>

以上代码java编译器显然并不认识;
所以我们才需要基于Servlet,将其转换为纯java代码,格式为servlet;
如此一来java编译器才能认识,才能进行公共类的封装。

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

 

1.5 Tomcat架构分析

QQ截图20181023000059.png-31.2kB

 
  1. #tomcat组件:
  2. <Server>
  3. <Service>
  4. <Connector/>
  5. <Connector/>
  6. <Engine>
  7. <Host>
  8. <Context/>
  9. ...
  10. </Host>
  11. <Host>
  12. </Host>
  13. ...
  14. </Engine>
  15. </Service>
  16. </Server>
  • 每个组件都是由“类”实现;
    • 此些组件可分为如下几类:
      • 顶级组件:Server
      • 服务组件:Service
      • 连接器组件:http,https,ajp
      • 容器类:Engine,Host,Context
      • 被嵌套类组件:valve,logger,realm,loader manager
      • 集群类组件:listener...
 

二,JVM执行分析

 

2.1 Java内存模型概述

QQ截图20181024224904.png-37.4kB

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

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

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

QQ截图20181026233116.png-54.4kB

  • 栈内存是线程私有的,其生命周期和线程相同;
  • 虚拟机栈描述的是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的句柄去打开一个文件,代码示例如下所示:

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

QQ截图20181030213702.png-33.3kB

QQ截图20181030220851.png-52.2kB

QQ截图20181030221744.png-47kB

 

2.3 JVM的规范标准

QQ截图20181030225503.png-25.1kB

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

 
  1. #在安装了jdk环境的系统上查看
  2. [root@Jenkins ~]# which java
  3. /usr/bin/java
  4. [root@Jenkins ~]# java -version
  5. java version "1.8.0_171"
  6. Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
  7. Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)

QQ截图20181030230041.png-16.1kB

当前虚拟机采用的是混合模式mixed mode(解释与编译);
这个的编译并不是像javaC一样将*.java编译成*.class那么简单;
这里面包含了一个JIT(Just Is Time,即时编译);
JVM在运行的时候,class loader只是把*.class文件做了一个简单的加载过程;
真正运行*.class是JVM的执行引擎在执行的过程中动态完成的。
当然,我们也可以改变这种模式,如下所示:

 
  1. #JVM虚拟机的纯解释模式
  2. [root@Jenkins ~]# java -Xint -version
  3. java version "1.8.0_171"
  4. Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
  5. Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, interpreted mode)
  6. #JVM虚拟机的纯编译模式
  7. [root@Jenkins ~]# java -Xcomp -version
  8. java version "1.8.0_171"
  9. Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
  10. Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, compiled mode)

QQ截图20181030231410.png-28.7kB

 

三,JVM内存模型与垃圾收集

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

3.1 Java堆内存模型

QQ截图20181031204758.png-136.1kB

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

QQ截图20181031210543.png-133.3kB

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

 

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

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

QQ截图20181101210811.png-127.3kB

  • 当我们的程序中需要产生新的实例化对象(关键字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发生的频率就越低,你的系统的性能一定就越高效。
  • 如果我们给用户使用的内存空间留有伸缩区,那么
    • 可用内存空间不足,就会判断伸缩区是否有空间,而后部分开辟伸缩区的空间。那么这种伸缩区的开辟与回收就有可能产生性能下降。

QQ截图20181101222244.png-194.5kB

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

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

 

3.3.1 Tomcat堆内存调优实操演示

 
  1. #在一台启动了tomcat的虚拟机上进行如下操作(未调优前)
  2. [root@Tomcat ~]# pgrep java #查看tomcat的pid号
  3. 15677
  4. [root@Tomcat ~]# jmap -heap 15677 #通过jmap命令追踪java进程的堆信息
  5. Attaching to process ID 15677, please wait...
  6. Debugger attached successfully.
  7. Server compiler detected.
  8. JVM version is 25.171-b11
  9. using thread-local object allocation.
  10. Mark Sweep Compact GC
  11. Heap Configuration: #堆内存初始化配置
  12. MinHeapFreeRatio = 40 #JVM堆最小空闲比率
  13. MaxHeapFreeRatio = 70 #JVM堆最大空闲比率
  14. MaxHeapSize = 255852544 (244.0MB) #JVM堆的最大大小
  15. NewSize = 5570560 (5.3125MB) #新生代的堆内存默认大小
  16. MaxNewSize = 85262336 (81.3125MB) #新生代的堆内存最大大小
  17. OldSize = 11206656 (10.6875MB) #老年代的堆内存最大大小
  18. NewRatio = 2 #新生代和老年代的大小比率(新生代:老年代=1:2)
  19. SurvivorRatio = 8 #新生代中eden区和存活区的大小比值(eden:S0:S1=8:1:1)
  20. MetaspaceSize = 21807104 (20.796875MB) #元空间的默认大小
  21. CompressedClassSpaceSize = 1073741824 (1024.0MB) #类指针压缩空间大小,默认1G
  22. MaxMetaspaceSize = 17592186044415 MB #元数据最大值,超过此值会触发FULL GC,受限与系统内存大小
  23. G1HeapRegionSize = 0 (0.0MB)
  24. Heap Usage:
  25. New Generation (Eden + 1 Survivor Space): #新生代对内存统计
  26. capacity = 12320768 (11.75MB)
  27. used = 1441680 (1.3748931884765625MB)
  28. free = 10879088 (10.375106811523438MB)
  29. 11.701218625332446% used
  30. Eden Space:
  31. capacity = 11010048 (10.5MB)
  32. used = 1441680 (1.3748931884765625MB)
  33. free = 9568368 (9.125106811523438MB)
  34. 13.094220842633929% used
  35. From Space:
  36. capacity = 1310720 (1.25MB)
  37. used = 0 (0.0MB)
  38. free = 1310720 (1.25MB)
  39. 0.0% used
  40. To Space:
  41. capacity = 1310720 (1.25MB)
  42. used = 0 (0.0MB)
  43. free = 1310720 (1.25MB)
  44. 0.0% used
  45. tenured generation: #老年代堆内存统计
  46. capacity = 27176960 (25.91796875MB)
  47. used = 15395720 (14.682502746582031MB)
  48. free = 11781240 (11.235466003417969MB)
  49. 56.64989756028636% used
  50. 15271 interned Strings occupying 1972184 bytes.
  51. #进行tomcat的基础堆内存参数调优
  52. #调优tomcat的java内存需要在/usr/local/tomcat/bin/catalina.sh文件中加入参数
  53. [root@Tomcat tomcat]# sed -n '121p' bin/catalina.sh
  54. JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m -Xmx1024m"
  55. #重启动tomcat
  56. [root@Tomcat ~]# /usr/local/tomcat/bin/shutdown.sh
  57. [root@Tomcat ~]# /usr/local/tomcat/bin/startup.sh
  58. #再次最终java进程的堆信息
  59. [root@Tomcat bin]# pgrep java
  60. 15826
  61. [root@Tomcat bin]# jmap -heap 15826
  62. Attaching to process ID 15826, please wait...
  63. Debugger attached successfully.
  64. Server compiler detected.
  65. JVM version is 25.171-b11
  66. using thread-local object allocation.
  67. Mark Sweep Compact GC
  68. Heap Configuration:
  69. MinHeapFreeRatio = 40
  70. MaxHeapFreeRatio = 70
  71. MaxHeapSize = 1073741824 (1024.0MB)
  72. NewSize = 357892096 (341.3125MB)
  73. MaxNewSize = 357892096 (341.3125MB)
  74. OldSize = 715849728 (682.6875MB)
  75. NewRatio = 2
  76. SurvivorRatio = 8
  77. MetaspaceSize = 21807104 (20.796875MB)
  78. CompressedClassSpaceSize = 1073741824 (1024.0MB)
  79. MaxMetaspaceSize = 17592186044415 MB
  80. G1HeapRegionSize = 0 (0.0MB)
  81. Heap Usage:
  82. New Generation (Eden + 1 Survivor Space):
  83. capacity = 322109440 (307.1875MB)
  84. used = 105070136 (100.20269012451172MB)
  85. free = 217039304 (206.98480987548828MB)
  86. 32.619390477969226% used
  87. Eden Space:
  88. capacity = 286326784 (273.0625MB) #eden+两个存活区大小刚好为MaxNewSize大小,没有伸缩区了
  89. used = 105070136 (100.20269012451172MB)
  90. free = 181256648 (172.85980987548828MB)
  91. 36.69588102522746% used
  92. From Space:
  93. capacity = 35782656 (34.125MB)
  94. used = 0 (0.0MB)
  95. free = 35782656 (34.125MB)
  96. 0.0% used
  97. To Space:
  98. capacity = 35782656 (34.125MB)
  99. used = 0 (0.0MB)
  100. free = 35782656 (34.125MB)
  101. 0.0% used
  102. tenured generation:
  103. capacity = 715849728 (682.6875MB)
  104. used = 22077792 (21.055023193359375MB)
  105. free = 693771936 (661.6324768066406MB)
  106. 3.084137792673716% used
  107. 16451 interned Strings occupying 2088032 bytes.
 

3.3.2 企业面试题:你们的项目中如何对java(JVM)进行调优?

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

3.4 新生代

新生代主要分为两个区域:伊甸园区和存活区。

QQ截图20181103213053.png-87kB

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

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

 

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

  • 算法:复制采用的方式为从根集合扫描出存活的对象,并将找到的存活对象复制到一块新的完全未使用的空间中。
    • 下图红色部分为不存活对象所占内存空间,绿色为存活对象所占内存空间;

QQ截图20181103222132.png-152.5kB

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

 

3.4.2 新生代中的算法优化

  • 在实际运行中,由于Eden区总是会保存大量的新生对象,所以HotSpot虚拟机为了可以加快此空间的内存分配,而使用了两种技术。
    • BTP(Bump-The-Pointer)
    • TLAB(Thread-Local Alloction Buffers)

(1)BTP(Bump-The-Pointer)

QQ截图20181104203618.png-350kB

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

(2)TLAB(Thread-Local Alloction Buffers)

QQ截图20181104204049.png-330.5kB

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

 

3.4.3 新生代内存参数调整

QQ截图20181103223512.png-230.4kB

 

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

 
  1. [root@Tomcat tomcat]# sed -n '121p' bin/catalina.sh
  2. JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m -Xmx1024m -Xmn500m -Xss256k"
  3. #重启动tomcat
  4. [root@Tomcat ~]# /usr/local/tomcat/bin/shutdown.sh
  5. [root@Tomcat ~]# /usr/local/tomcat/bin/startup.sh
  6. [root@Tomcat bin]# pgrep java
  7. 16111
  8. [root@Tomcat bin]# jmap -heap 16111
  9. Attaching to process ID 16111, please wait...
  10. Debugger attached successfully.
  11. Server compiler detected.
  12. JVM version is 25.171-b11
  13. using thread-local object allocation.
  14. Mark Sweep Compact GC
  15. Heap Configuration:
  16. MinHeapFreeRatio = 40
  17. MaxHeapFreeRatio = 70
  18. MaxHeapSize = 1073741824 (1024.0MB)
  19. NewSize = 524288000 (500.0MB) #新生代500M
  20. MaxNewSize = 524288000 (500.0MB)
  21. OldSize = 549453824 (524.0MB)
  22. NewRatio = 2
  23. SurvivorRatio = 8
  24. MetaspaceSize = 21807104 (20.796875MB)
  25. CompressedClassSpaceSize = 1073741824 (1024.0MB)
  26. MaxMetaspaceSize = 17592186044415 MB
  27. G1HeapRegionSize = 0 (0.0MB)
  28. Heap Usage:
  29. New Generation (Eden + 1 Survivor Space):
  30. capacity = 471859200 (450.0MB)
  31. used = 138288216 (131.88191986083984MB)
  32. free = 333570984 (318.11808013916016MB)
  33. 29.307093302408855% used
  34. Eden Space:
  35. capacity = 419430400 (400.0MB)
  36. used = 138288216 (131.88191986083984MB)
  37. free = 281142184 (268.11808013916016MB)
  38. 32.97047996520996% used
  39. From Space:
  40. capacity = 52428800 (50.0MB)
  41. used = 0 (0.0MB)
  42. free = 52428800 (50.0MB)
  43. 0.0% used
  44. To Space:
  45. capacity = 52428800 (50.0MB)
  46. used = 0 (0.0MB)
  47. free = 52428800 (50.0MB)
  48. 0.0% used
  49. tenured generation:
  50. capacity = 549453824 (524.0MB)
  51. used = 45906440 (43.77979278564453MB)
  52. free = 503547384 (480.22020721435547MB)
  53. 8.354922287336743% used
  54. 16495 interned Strings occupying 2092024 bytes.
 

3.5 老年代

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

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

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

QQ截图20181104211249.png-83.7kB

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

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

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

QQ截图20181104212545.png-71.8kB

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

3.5.3 老年代内存参数调整

QQ截图20181104213226.png-192.4kB

  • 默认情况下,所有的对象都会通过新生代进行创建,而后经过不断的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 永久代内存参数调整(设置也已经没用了)

QQ截图20181104215918.png-187kB

 

3.7 元空间

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

3.7.1 元空间的内存参数调整

QQ截图20181104222827.png-365.1kB

基本上并不需要做调整

 

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):分配的物理内存不足,或者数据量高于物理内存。

猜你喜欢

转载自www.cnblogs.com/hai-better/p/10368487.html