JVM

2021-02-25  本文已影响0人  upup果
JVM的内存布局？
image.png
Java虚拟机主要包含几个区域：
堆：Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。堆区细分为Yound区年轻代和Old区老年代，其中年轻代又分为Eden、S0、S1 3个部分，他们默认的比例是8:1:1的大小。

虚拟机栈：虚拟机栈是线程私有的内存区域，每个方法执行的时候都会在栈创建一个栈帧，方法的调用过程就对应着栈的入栈和出栈的过程。每个栈帧的结构又包含局部变量表、操作数栈、动态连接、方法返回地址。
局部变量表用于存储方法参数和局部变量。
操作数栈用于一些字节码指令从局部变量表中传递至操作数栈，也用来准备方法调用的参数以及接收方法返回结果。
动态连接用于将符号引用表示的方法转换为实际方法的直接引用。
方法区：方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。在Java1.7之前，永久代包含方法区，常量池就存在于方法区（永久代）中，而方法区本身是一个逻辑上的概念，在1.7之后则是把常量池移到了堆内，为了更容易管理方法区，从 JDK 1.8 开始，移除永久代，并把方法区移至元空间，它位于直接内存中，而不是虚拟机内存中。方法区是一个 JVM 规范，永久代与元空间都是其一种实现方式。在 JDK 1.8 之后，原来永久代的数据被分到了堆和元空间中。元空间存储类的元信息，静态变量和常量池等放入堆中。
本地方法栈：类似于虚拟机栈，主要用于执行本地native方法的区域
程序计数器：也是线程私有的区域，用于记录当前线程下虚拟机正在执行的字节码的指令地址。

类加载过程？
image.png
加载：通过全类名获取定义此类的二进制字节流，并将字节流所代表的静态存储结构转换为方法区的运行时数据结构，在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的访问入口
验证：校验Class文件是否符合虚拟机规范
准备：为类变量分配内存并设置类变量初始值
解析：虚拟机将常量池内的符号引用替换为直接引用的过程，也就是得到类或者字段、方法在内存中的指针或者偏移量。
初始化：执行初始化方法 <clinit> ()方法进行初始化，如果存在父类，先对父类进行初始化
一个对象的创建过程(new)？
image.png
类加载检查：虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过。如果没有，那必须先执行相应的类加载过程。
分配内存：在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来（分配方式有 “指针碰撞” 和 “空闲列表” 两种）。
初始化零值：将对象的实例字段初始化为0
设置对象头：虚拟机要对对象进行必要的设置，哈希码、 GC 分代年龄、元数据信息等。
执行init方法：执行构造函数(init)初始化。
双亲委派模型？

类加载器自顶向下分为：
Bootstrap ClassLoader启动类加载器：默认会去加载JAVA_HOME/lib目录下的jar
Extention ClassLoader扩展类加载器：默认去加载JAVA_HOME/lib/ext目录下的jar
Application ClassLoader应用程序类加载器：当前应用classpathClassPath下的类
User ClassLoader用户自定义类加载器：由用户自己定义
双亲委派模型：
1、先检查类是否已经被加载过
2、若没有加载则调用父加载器的loadClass()方法进行加载
3、若父加载器为空则默认使用启动类加载器作为父加载器。
4、如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

好处：双亲委派模型保证了Java程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类）。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。另外，通过双亲委派的方式，还保证了安全性。因为Bootstrap ClassLoader在加载的时候，只会加载JAVA_HOME/lib中的jar包里面的类，如java.lang.Integer，那么这个类是不会被随意替换的，除非有人跑到你的机器上， 破坏你的JDK。那么，就可以避免有人自定义一个有破坏功能的java.lang.Integer被加载。这样可以有效的防止核心Java API被篡改。
如何破坏双亲委派模型？
因为双亲委派过程都是在loadClass方法中实现的，那么想要破坏这种机制，那么就自定义一个类加载器，重写其中的loadClass方法，使其不进行双亲委派即可。如果你想定义一个自己的类加载器，并且要遵守双亲委派模型，那么可以继承ClassLoader，并且在findClass中实现你自己的加载逻辑即可。
破坏双亲委派机制的场景：
第一种被破坏的情况是在双亲委派出现之前。由于双亲委派模型是在JDK1.2之后才被引入的，而在这之前已经有用户自定义类加载器在用了。所以，这些是没有遵守双亲委派原则的。
第二种，是JNDI、JDBC等需要加载SPI接口实现类的情况：DriverManager.getConnection
若按照双亲委任模型的话， DriverManager被Bootstrap类加载器加载，其内部引用到的connection也理应由Bootstrap类加载器加载，但Driver.class的实现类不在Bootstrap类加载器所能扫描到的范围里，所以交由Bootstrap类加载器是加载不了的，而双亲委任模型规定是先交由父类去加载，加载不了再由自己加载，而Bootstrap类加载器是最顶层的类加载器了，没有父类了，所以交由自己加载，但是自己也加载不了，所以为了能够加载到Driver.class的实现类，只能打破双亲委任模型了【使用子类加载器去加载Driver.class的实现类】，通过Thread.currentThread().getContextClassLoader()的方式，得到ApplicationClassLoader，而ApplicationClassLoader就能够扫描到添加进来的jar包【依赖的jar包都是在ClassPath下】，所以Driver.class的实现类就能够被加载到。
第三种是为了实现热插拔热部署工具。为了让代码动态生效而无需重启，实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。
第四种是tomcat等web容器的出现：
一个web容器可能需要部署多个应用程序。不同的应用程序可能会依赖同一个第三方类库的不同版本，但是不同版本的类库中某一个类的全路径名可能是一样的。如多个应用都要依赖xxx.jar，但是A应用需要依赖1.0.0版本，但是B应用需要依赖1.0.1版本。这两个版本中都有一个类是com.xxx.Test.class。如果采用默认的双亲委派类加载机制，那么是无法加载多个相同的类。所以，Tomcat破坏双亲委派原则，提供隔离的机制，为每个web容器单独提供一个WebAppClassLoader加载器。Tomcat的类加载机制：为了实现隔离性，优先加载 Web 应用自己定义的类，所以没有遵照双亲委派的约定，每一个应用自己的类加载器——WebAppClassLoader负责加载本身的目录下的class文件，加载不到时再交给CommonClassLoader加载，这和双亲委派刚好相反。
第五种是OSGI、Jigsaw等模块化技术的应用

如何判断对象是否死亡（可回收）？

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加 1；当引用失效，计数器就减 1；任何时候计数器为 0 的对象就是不可能再被使用的。这个方法实现简单，效率高，但是它很难解决对象之间相互循环引用的问题。

Java通过可达性分析算法来达到标记存活对象的目的，定义一系列的GC ROOT为起点，从起点开始向下开始搜索，搜索走过的路径称为引用链，当一个对象到GC ROOT没有任何引用链相连的话，则对象可以判定是可以被回收的。
可作为 GC Roots 的对象包括下面几种:
虚拟机栈(栈帧中的本地变量表)中引用的对象
本地方法栈(Native 方法)中引用的对象
方法区中静态变量引用的对象
方法区中常量引用的对象
所有被同步锁持有的对象

一次标记：当可达性分析确认该对象没有引用链与GC Roots相连，则对其进行第一次标记和筛选，筛选的条件是重写了finalize()方法并没有执行过，对于重写了且并没有执行finalize()方法的对象这将其放置在一个F-Queue队列中，并在稍后由一个由虚拟机自动建立的低优先级的Finalizer线程去执行它。此处执行只保证执行该方法，但是不保证等待该方法执行结束，之所以这样子设计是为了系统的稳定性和健壮性考虑，以免该方法执行时间较长或者死循环导致系统崩溃。在此之后，系统会对对象进行第二次标记，如果在第一次标记之后的对象在执行finalize()方法时没有被引用到一个新的变量，这该对象将被回收掉。

垃圾回收算法？

先根据可达性算法统一标记出需要回收的对象，标记完成之后统一回收所有被标记的对象，而由于标记的过程需要遍历所有的GC ROOT，清除的过程也要遍历堆中所有的对象，所以标记-清除算法的效率低下，同时也带来了内存碎片的问题

为了解决上面的问题，复制算法应运而生，它将内存分为大小相等的两块区域，每次使用其中的一块，当一块内存使用完之后，将还存活的对象拷贝到另外一块内存区域中，然后把当前内存清空，这样性能和内存碎片的问题得以解决。但是同时带来了另外一个问题，可使用的内存空间缩小了一半。

前面两步和标记清除法一样，不同的是它在标记清除法的基础上添加了一个整理的过程 ，即将所有的存活对象都往一端移动,紧邻排列，再清理掉另一端的所有区域，这样的话就解决了内存碎片的问题。

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样就可以根据各个年代的特点选择合适的垃圾收集算法。比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

垃圾收集器
image.png
内存分配策略
  1. 多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间，则将启用分配担保机制在老年代中分配内存(这里是把已经在的对象转移到老年代，要分配的新对象还是在会存在Eden)。

  1. 大对象直接进入老年代
    所谓大对象是指需要大量连续内存空间的对象(虚拟机提供参数-XX：PretenureSizeThreshold参数（这个参数只在serial和ParNew起作用），当对象比这个值大，就直接存入老年代)，频繁出现大对象是致命的，会导致在内存还有不少空间的情况下提前触发 GC 以获取足够的连续空间来安置新对象。新生代使用的是复制算法来处理垃圾回收的，如果大对象直接在新生代分配就会导致 Eden 区和两个 Survivor 区之间发生大量的内存复制。因此对于大对象都会直接在老年代进行分配。

  2. 长期存活对象将进入老年代
    虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须判断哪些对象应该放在新生代，哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器，如果对象在 Eden 区出生，并且能够被 Survivor 容纳，将被移动到 Survivor 空间中，这时设置对象年龄为 1。对象在 Survivor 区中每「熬过」一次 Minor GC 年龄就加 1，当年龄达到一定程度（默认 15，可以通过参数 -XX:MaxTenuringThreshold 来设置） 就会被晋升到老年代。

  1. 动态对象年龄判定
    虚拟机并不是永远要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄。

  2. 空间分配担保
    在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的。如果不成立的话虚拟机会查看 HandlePromotionFailure 的值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC；如果小于，或者 HandlePromotionFailure 的值不允许冒险，那么就要进行一次 Full GC。

Full GC 的触发条件

对于 Minor GC，其触发条件非常简单，当 Eden 空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，有以下条件：

  1. 调用 System.gc()
    只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。

  2. 老年代空间不足
    老年代空间不足的常见场景为大对象直接进入老年代、长期存活的对象进入老年代等。为了避免以上原因引起的 Full GC，应当尽量不要创建过大的对象以及数组。除此之外，可以通过 -Xmn 虚拟机参数调大新生代的大小，让对象尽量在新生代被回收掉，不进入老年代。还可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间。

  3. 空间分配担保失败
    使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果担保失败会执行一次 Full GC。

  4. JDK 1.7 及以前的永久代空间不足
    在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 Class 的信息、常量、静态变量等数据。当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么虚拟机会抛出 java.lang.OutOfMemoryError。为避免以上原因引起的 Full GC，可采用的方法为增大永久代空间或转为使用 CMS GC。

  5. Concurrent Mode Failure
    执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（可能是 GC 过程中浮动垃圾过多导致暂时性的空间不足），便会报 Concurrent Mode Failure 错误，并触发 Full GC。

JVM调优
JDK 监控和故障处理工具总结

[JDK 命令行工具]
这些命令在 JDK 安装目录下的 bin 目录下：

JDK可视化分析工具
JConsole 是基于 JMX 的可视化监视、管理工具。可以很方便的监视本地及远程服务器的 java 进程的内存使用情况。可以在控制台输出入console命令启动或者在 JDK 目录下的 bin 目录找到jconsole.exe然后双击启动。JConsole 可以显示当前内存的详细信息。不仅包括堆内存/非堆内存的整体信息，还可以细化到 eden 区、survivor 区等的使用情况

VisualVM是到目前为止随 JDK 发布的功能最强大的运行监视和故障处理程序，官方在 VisualVM 的软件说明中写上了“All-in-One”的描述字样，预示着他除了运行监视、故障处理外，还提供了很多其他方面的功能，如性能分析（Profiling）。VisualVM 的性能分析功能甚至比起 JProfiler、YourKit 等专业且收费的 Profiling 工具都不会逊色多少，而且 VisualVM 还有一个很大的优点：不需要被监视的程序基于特殊 Agent 运行，因此他对应用程序的实际性能的影响很小，使得他可以直接应用在生产环境中。这个优点是 JProfiler、YourKit 等工具无法与之媲美的。

JVM参数

  1. 标准参数（-），所有的 JVM 实现都必须实现这些参数的功能，而且向后兼容；例如 -verbose:gc（输出每次GC的相关情况)

  2. 非标准参数（-X），默认 JVM 实现这些参数的功能，但是并不保证所有 JVM 实现都满足，且不保证向后兼容，栈，堆大小的设置都是通过这个参数来配置的,用得最多的如下
    参数示例 表示意义
    -Xms512m JVM 启动时设置的初始堆大小为 512M
    -Xmx512m JVM 可分配的最大堆大小为 512M
    -Xmn200m 设置的年轻代大小为 200M
    -Xss128k 设置每个线程的栈大小为 128k

  3. 非Stable参数（-XX），此类参数各个 jvm 实现会有所不同，将来可能会随时取消，需要慎重使用, -XX:-option 代表关闭 option 参数，-XX:+option 代表要打开 option 参数,例如要启用串行 GC，对应的 JVM 参数即为 -XX:+UseSerialGC。非 Stable 参数主要有三大类行为参数（Behavioral Options）：用于改变 JVM 的一些基础行为，如启用串行/并行 GC
    参数示例 表示意义
    -XX:+DisableExplicitGC 禁止调用System.gc()；但jvm的gc仍然有效
    -XX:+UseConcMarkSweepGC 对老生代采用并发标记交换算法进行GC
    -XX:+UseParallelGC 启用并行GC
    -XX:+UseParallelOldGC 对Full GC启用并行，当-XX:-UseParallelGC启用时该项自动启用
    -XX:+UseSerialGC 启用串行GC
    性能调优（Performance Tuning）：用于 jvm 的性能调优，如设置新老生代内存容量比例
    参数示例 表示意义
    -XX:MaxHeapFreeRatio=70 GC后java堆中空闲量占的最大比例
    -XX:NewRatio=2 新生代内存容量与老生代内存容量的比例
    -XX:NewSize=2.125m 新生代对象生成时占用内存的默认值
    -XX:ReservedCodeCacheSize=32m 保留代码占用的内存容量
    -XX:ThreadStackSize=512 设置线程栈大小，若为0则使用系统默认值
    调试参数（Debugging Options）：一般用于打开跟踪、打印、输出等 JVM 参数，用于显示 JVM 更加详细的信息
    参数示例 表示意义
    -XX:HeapDumpPath=./java_pid.hprof 指定导出堆信息时的路径或文件名
    -XX:-HeapDumpOnOutOfMemoryError 当首次遭遇OOM时导出此时堆中相关信息
    -XX:-PrintGC 每次GC时打印相关信息
    -XX:-PrintGC Details 每次GC时打印详细信息

参数设置

1、首先 Oracle 官方推荐堆的初始化大小与堆可设置的最大值一般是相等的，即 Xms = Xmx，因为起始堆内存太小（Xms），会导致启动初期频繁 GC，起始堆内存较大（Xmx）有助于减少 GC 次数

2、调试的时候设置一些打印参数，如-XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log，这样可以从gc.log里看出一些端倪出来

3、系统停顿时间过长可能是 GC 的问题也可能是程序的问题，多用 jmap 和 jstack 查看，或者killall -3 Java，然后查看 Java 控制台日志，能看出很多问题

4、 采用并发回收时，年轻代小一点，老年代要大，因为老年代用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿

5、仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定

上一篇 下一篇

猜你喜欢

热点阅读