JVM基础了解

最新推荐文章于 2024-07-20 21:10:30 发布

＆简白

最新推荐文章于 2024-07-20 21:10:30 发布

阅读量711

点赞数

文章标签： jvm java 开发语言

本文链接：https://blog.csdn.net/qq_50400632/article/details/130345533

版权

JVM相关

JVM内存模型

在这里插入图片描述

程序计数器

程序计数器并非广义上所指的物理寄存器，或许将其翻译为PC计数器（或者指令计数器）会更加贴切。程序计数器的作用可以看做是当前线程所执行的字节码的行号指示。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支。循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。由于JAVA虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为线程私有的内存。

注意：如果线程执行的是个java方法，那么计数器记录虚拟字节码指令的地址。如果为native[底层方法]，那么计数器为空，这块内存区域是虚拟机规范中唯一没有OutOfMemoryError的区域。（navtive方法是一个Java代码调用一个非Java代码的接口。native是与C++或其它语言联合开发的时候用的！使用native关键字说明这个方法是原生函数，也就是这个方法是用C/C++语言实现的，并且被编译成了DLL，由java去调用。这些函数的实现体在DLL中，JDK的源代码中并不包含，你应该是看不到的。对于不同的平台它们也是不同的。这也是java的底层机制，实际上java就是在不同的平台上调用不同的native方法实现对操作系统的访问的。总而言之：）

Java虚拟机栈

虚拟机栈是线程私有的内存空间，每个线程都有一个线程栈，每个方法被执行时都会创建一个栈帧，方法执行完成，栈帧弹出，线程运行结束，线程会被回收。虚拟机栈就是Java中方法执行的内存模型，每个方法执行时都会创建一个栈帧，这个栈帧用来存储局部变量表，操作数栈，指向当前方法所属的类的运行时常量池的引用，方法返回地址等信息，每个方法从调用直至执行完成的过程，就对应着栈帧在虚拟机中入栈到出栈的过程。局部变量表用来存储方法中的局部变量，包括方法中的声明变量以及函数形参。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。局部变量表的大小在编译器就可以确定其大小，而且在程序执行期间局部变量表的大小是不会改变的。程序中的所有计算过程都是借助操作数栈来完成的。指向运行时常量池的引用，因为在方法执行的过程中，有可能需要用到类中的常量，所以必须要有一个引用指向当前方法所属的类的运行时常量池。方法返回的地址是，当一个方法执行完毕后，要返回之前调用它的地方，因此栈帧中必须保存一个方法返回的地址。

在Java虚拟机规范中，对于这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），当扩展无法申请到足够的内存时就会抛出OutOfMemoryError异常。

本地方法栈

本地方法栈也是线程私有的内存空间，本地方法栈所发挥的作用与Java栈所发挥的是非常相似的，他们之间的区别不过是Java栈执行Java方法，本地方法栈执行的是本地方法，有的虚拟机直接把本地方法栈和虚拟机栈合二为一了

堆区

Java堆是Java虚拟机所管理的内存中最大的一块，在虚拟机启动时创建，此内存区域的目的就是为了存放对象实例，几乎所有的对象实例都从这里来分配内存。从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（TLAB）。Java堆可以处于物理上不连续的内存空间，只要逻辑上连续即可。在实现上，既可以实现固定大小的，也可以是扩展的。如果堆中没有足够的内存分配给实例，并且堆也无法再扩展时，将会抛出OutOfMemeryError异常。

堆是运行时动态分配内存的，对象在没有引用变量指向它的时候，才变成垃圾，但是仍然占着内存，在程序空闲的时候（没有工作线程运行，GC线程的优先级最低）或者堆内存不足时（GC线程会被触发），被垃圾回收器释放掉，由于要在运行时动态分配内存，存取速度较慢。

方法区

方法区是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息（包括类的名称，方法信息，成员变量信息）、常量、静态变量，以及编译器编译后的代码等数据。当方法区无法满足内存分配需求时，将会抛出OutOfMemeryError异常。

运行时常量池是方法区的一部分，此区域会在两种情况下存储数据：

（1）class文件的常量池中的数据

class文件中的常量池用于存放编译器生成的各种字面值和常量，这部分内容在类被加载后存放到方法区的运行时常量池中。

字面值：private String name=“zhangSan”；private int age = 23+3；

常量：private final String TAG = “MainActivity”；private final int age = 26;

（2）运行期间生成的常量

运行时常量池相当于class文件常量池的另外一个重要特征是具备动态性。，Java不要求常量一定只能在编译器产生，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可以将新的常量放入池中，这种特性被开发人员利用的较多的就是String类的intern方法。String =”abd“.intern()。此时当运行时常量池中存在abc时，将该字符串的引用返回，赋值给str，否则创建字符串”abc“,加入运行时常量池中，并返回引用赋值给str。既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时就会抛出OutOfMemoryError异常。

GC算法

1：标记–清除（Mark–Sweep）

标记–清除（Mark-Sweep）算法，分为标记和清除两个阶段：首先标记处所有要回收的对象，在标记完成之后统一回收掉所有被标记的对象。

在这里插入图片描述

标记–清除算法主要问题是：1、效率问题，标记清除过程的效率很低。2、空间问题，标记-清除之后会产生大量的不连续内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连线内存而不得不提取触发另一次垃圾收集。

2：复制（Copyong）算法

复制算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后把已使用过的内存空间一次清理掉。这样使得每次都是只对其中一块进行内存回收，内存分配时也就不用考虑内存碎片等复制情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

在这里插入图片描述

复制算法的主要问题就是：1：将内存划分为一半，过于浪费:2：对象存活率较高时就要执行较多的复制操作，造成频繁的GC,效率将会变低。

3：标记整理（Mark–Compact）算法

标记整理算法的标记过程仍然与标记–清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存，这样连续的内存空间就多了起来。

在这里插入图片描述

如上图所示，所有存活的对象依次向左上角移动，（0,4）移动到（0,2），（1,0）移动到（0,3），依次类推，当所有的存活对象移动完成后，把剩余的所有空间清空，也就是清空（1,1）后的所有空间。

4：分代回收

程序创建的大部分对象的生命周期都很短，只有一小部分对象的生命周期比较长，根据这样的规律，一般把Java堆分为新生代，老生代和持久代，上面几种算法是通过分代回收混合在一起的，这样就可以根据各个年代的特点采用最适当的回收算法。

在这里插入图片描述

1：新生代

在新生代中，有一个叫Eden Space的空间，主要用来存放新生的对象，还有两个Survivor Spaces（from,to）,这两个区域大小相同，相当于Copying算法中的两个区域，它们用来存放每次垃圾回收后存活下来的对象，在新生代中，垃圾回收一般用于4Copying的算法，速度快。
当新建对象无法放入eden区时，将触发minor collection(minorGc是清理新生代的GC线程，eden的清理，form,to的清理都有MinorGC线程完成)，将eden与from区的存活对象复制到to区，经过一次垃圾回收，eden区和from区被清空，to区中则紧密的存放着存活对象，当eden区再次满时，minor collection将eden区和to区的存活对象放到from区，eden和to区被清空，from区存放eden区和to的存活对象，就这样在from区和to区来回切换。如果进行minor collection的时候发现to区放不下，则将eden区和from区的部分对象放入成熟代。另一方面，即使to区没有满，JVM依然会移动世代足够久远的对象到成熟代。

2：老年代

在成熟代中主要存放应用程序中生命周期长的内存对象，垃圾回收一般是用mark-compact的算法，速度慢些，但减少内存要求。如果老年代中放满对象，无法从新生代中移入新的对象，那么就会触发major collection(major GC清理整合OldGen的内存空间)。

3：永久代

在永久代中，主要用来放JVM自己的反射对象，比如类对象，方法对象，成员变量对象，构造方法对象等。
此外，垃圾回收一般是在程序空闲的时候（没有工作线程，GCx线程的优先级比较低）或者堆内存不足时自动触发的，也可以调用System.gc()主动通知Java虚拟机进行垃圾回收，但这只是个建议，Java虚拟机不一定马上执行，启动时机的选择由JVM自己决定，并且取决于堆内存中Eden区是否可用。

JVM调优

（1）JVM调优目标

JVM调优目标：使用较少的内存占用来获得比较高的吞吐量或者比较低的延迟。

程序在上线前的测试或运行中优势会出现大大小小的JVM问题，比如cpu load过高，请求延迟，TPS降低等，甚至出现内存泄露（每次垃圾回收的时间越来越长，垃圾回收的频率越来越高，每次垃圾回收收集清理掉的内存越来越少等等）、内存溢出导致系统崩溃，因此需要对JVM进行调优，使得程序在正常情况下能够获得较好的用户体验和较高的运行效率。

JVM调优的几个重要的指标：

内存占用：程序正常运行需要的内存大小
延迟：由于垃圾收集而引起的程序停顿的时间
吞吐量：用户程序运行时间占用户程序和垃圾收集总时间的比值

和CAP原则一样，一个程序同时满足内存占用小，延迟低，同时保证较高的吞吐量是不可能的，否则无所谓什么调优了。在程序调优之前需要结合实际场景，找出优化的目标，找出性能瓶颈，对瓶颈进行针对性的优化，最后进行测试，通过相关优化工具查看调优后的结果是否符合预期。

（2）JVM调优工具

①用 jps（JVM process Status）可以查看虚拟机启动的所有进程、执行主类的全名、JVM启动参数，比如当执行了JPSTest类中的main方法后（main方法持续执行），执行 jps -l可看到下面的JPSTest类的pid为31354，加上-v参数还可以看到JVM启动参数。

②用jstat（JVM Statistics Monitoring Tool）监视虚拟机信息 jstat -gc pid 500 10 ：每500毫秒打印一次Java堆状况（各个区的容量、使用容量、gc时间等信息），打印10次

③用jmap（Memory Map for Java）查看堆内存信息执行jmap -histo pid可以打印出当前堆中所有每个类的实例数量和内存占用，如下，class name是每个类的类名（[B是byte类型，[C是char类型，[I是int类型），bytes是这个类的所有示例占用内存大小，instances是这个类的实例数量：
在这里插入图片描述

执行 jmap -dump 可以转储堆内存快照到指定文件，比如执行 jmap -dump:format=b,file=/data/jvm/dumpfile_jmap.hprof 3361 可以把当前堆内存的快照转储到dumpfile_jmap.hprof文件中，然后可以对内存快照进行分析。

④利用jconsole、jvisualvm分析内存信息(各个区如Eden、Survivor、Old等内存变化情况)，如果查看的是远程服务器的JVM，程序启动需要加上如下参数：

"-Dcom.sun.management.jmxremote=true" 
"-Djava.rmi.server.hostname=12.34.56.78" 
"-Dcom.sun.management.jmxremote.port=18181" 
"-Dcom.sun.management.jmxremote.authenticate=false" 
"-Dcom.sun.management.jmxremote.ssl=false"

⑤分析堆转储快照

前面说到配置了 “-XX:+HeapDumpOnOutOfMemory” 参数可以在程序发生内存溢出时dump出当前的内存快照，也可以用jmap命令随时dump出当时内存状态的快照信息，dump的内存快照一般是以.hprof为后缀的二进制格式文件。可以直接用 jhat（JVM Heap Analysis Tool）命令来分析内存快照，它的本质实际上内嵌了一个微型的服务器，可以通过浏览器来分析对应的内存快照，比如执行 jhat -port 9810 -J-Xmx4G /data/jvm/dumpfile_jmap.hprof 表示以9810端口启动 jhat 内嵌的服务器：

Reading from /Users/dannyhoo/data/jvm/dumpfile_jmap.hprof...
Dump file created Fri Aug 03 15:48:27 CST 2018
Snapshot read, resolving...
Resolving 276472 objects...
Chasing references, expect 55 dots.......................................................
Eliminating duplicate references.......................................................
Snapshot resolved.
Started HTTP server on port 9810
Server is ready.

（3）JVM调优经验

JVM配置方面，一般情况可以先用默认配置（基本的一些初始参数可以保证一般的应用跑的比较稳定了），在测试中根据系统运行状况（会话并发情况、会话时间等），结合gc日志、内存监控、使用的垃圾收集器等进行合理的调整，当老年代内存过小时可能引起频繁Full GC，当内存过大时Full GC时间会特别长。

那么JVM的配置比如新生代、老年代应该配置多大最合适呢？答案是不一定，调优就是找答案的过程，物理内存一定的情况下，新生代设置越大，老年代就越小，Full GC频率就越高，但Full GC时间越短；相反新生代设置越小，老年代就越大，Full GC频率就越低，但每次Full GC消耗的时间越大。建议如下：

-Xms和-Xmx的值设置成相等，堆大小默认为-Xms指定的大小，默认空闲堆内存小于40%时，JVM会扩大堆到-Xmx指定的大小；空闲堆内存大于70%时，JVM会减小堆到-Xms指定的大小。如果在Full GC后满足不了内存需求会动态调整，这个阶段比较耗费资源。
新生代尽量设置大一些，让对象在新生代多存活一段时间，每次Minor GC 都要尽可能多的收集垃圾对象，防止或延迟对象进入老年代的机会，以减少应用程序发生Full GC的频率。
老年代如果使用CMS收集器，新生代可以不用太大，因为CMS的并行收集速度也很快，收集过程比较耗时的并发标记和并发清除阶段都可以与用户线程并发执行。
方法区大小的设置，1.6之前的需要考虑系统运行时动态增加的常量、静态变量等，1.7只要差不多能装下启动时和后期动态加载的类信息就行。

代码实现方面，性能出现问题比如程序等待、内存泄漏除了JVM配置可能存在问题，代码实现上也有很大关系：

避免创建过大的对象及数组：过大的对象或数组在新生代没有足够空间容纳时会直接进入老年代，如果是短命的大对象，会提前出发Full GC。
避免同时加载大量数据，如一次从数据库中取出大量数据，或者一次从Excel中读取大量记录，可以分批读取，用完尽快清空引用。
当集合中有对象的引用，这些对象使用完之后要尽快把集合中的引用清空，这些无用对象尽快回收避免进入老年代。
可以在合适的场景（如实现缓存）采用软引用、弱引用，比如用软引用来为ObjectA分配实例：SoftReference objectA=new SoftReference(); 在发生内存溢出前，会将objectA列入回收范围进行二次回收，如果这次回收还没有足够内存，才会抛出内存溢出的异常。避免产生死循环，产生死循环后，循环体内可能重复产生大量实例，导致内存空间被迅速占满。
尽量避免长时间等待外部资源（数据库、网络、设备资源等）的情况，缩小对象的生命周期，避免进入老年代，如果不能及时返回结果可以适当采用异步处理的方式等。

(4) JVM调优参数

参数	说明	实例
-Xms	初始堆大小，默认物理内存的1/64	-Xms512M
-Xmx	最大堆大小，默认物理内存的1/4	-Xms2G
-Xmn	新生代内存大小，官方推荐为整个堆的3/8	-Xmn512M
-Xss	线程堆栈大小，jdk1.5及之后默认1M，之前默认256k	-Xss512k
-XX:NewRatio=n	设置新生代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4	-XX:NewRatio=3
-XX:SurvivorRatio=n	年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:8，表示Eden：Survivor=8:1:1，一个Survivor区占整个年轻代的1/8	-XX:SurvivorRatio=8
-XX:PermSize=n	永久代初始值，默认为物理内存的1/64	-XX:PermSize=128M
-XX:MaxPermSize=n	永久代最大值，默认为物理内存的1/4	-XX:MaxPermSize=256M
-verbose:class	在控制台打印类加载信息
-verbose:gc	在控制台打印垃圾回收日志
-XX:+PrintGC	打印GC日志，内容简单
-XX:+PrintGCDetails	打印GC日志，内容详细
-XX:+PrintGCDateStamps	在GC日志中添加时间戳
-Xloggc:filename	指定gc日志路径	-Xloggc:/data/jvm/gc.log
-XX:+UseSerialGC	年轻代设置串行收集器Serial
-XX:+UseParallelGC	年轻代设置并行收集器Parallel Scavenge
-XX:ParallelGCThreads=n	设置Parallel Scavenge收集时使用的CPU数。并行收集线程数。	-XX:ParallelGCThreads=4
-XX:MaxGCPauseMillis=n	设置Parallel Scavenge回收的最大时间(毫秒)	-XX:MaxGCPauseMillis=100
-XX:GCTimeRatio=n	设置Parallel Scavenge垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)	-XX:GCTimeRatio=19
-XX:+UseParallelOldGC	设置老年代为并行收集器ParallelOld收集器
-XX:+UseConcMarkSweepGC	设置老年代并发收集器CMS
-XX:+CMSIncrementalMode	设置CMS收集器为增量模式，适用于单CPU情况。

什么时候触发GC线程

System.gc();
老年代满了,从年轻代去往老年代的复制
JDK7或JDK6中永久区满了得看是否还会有分配，如果没有就不会进行FGC,不过CMS GC下会看到不停CMS GC。DUMP内存可以看到大概的情况，不仅仅是heap（这是阿里JVM团队的同学跟我讲的应该靠谱
统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间
堆中分配很大的对象
- 所谓大对象，是指需要大量连续内存空间的java对象，例如很长的数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。
- 为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程，内存整理的过程无法并发的，空间碎片问题没有了，但提顿时间不得不变长了，JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。

OOM排查

OOM的原因：

为什么会没有内存了呢？原因不外乎有两点：

1）分配的少了：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。

2）应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。

内存泄露：申请使用完的内存没有释放，导致虚拟机不能再次使用该内存，此时这段内存就泄露了，因为申请者不用了，而又不能被虚拟机分配给别人用。

内存溢出：申请的内存超出了JVM能提供的内存大小，此时称之为溢出。

最常见的OOM情况有以下三种：

java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出，此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。
java.lang.OutOfMemoryError: PermGen space 或 java.lang.OutOfMemoryError：MetaSpace ------>java方法区，（java8 元空间）溢出了，一般出现于大量Class或者jsp页面，或者采用cglib等反射机制的情况，因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决，使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外，过多的常量尤其是字符串也会导致方法区溢出。
java.lang.StackOverflowError ------> 不会抛OOM error，但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出，一般是由于程序中存在死循环或者深度递归调用造成的，栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。

排查手段：

一般手段是：先通过内存映像工具对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏还是内存溢出。

如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。这样就能够找到泄漏的对象是通过怎么样的路径与GC Roots相关联的导致垃圾回收机制无法将其回收。掌握了泄漏对象的类信息和GC Roots引用链的信息，就可以比较准确地定位泄漏代码的位置。

如果不存在泄漏，那么就是内存中的对象确实必须存活着，那么此时就需要通过虚拟机的堆参数（ -Xmx和-Xms）来适当调大参数；从代码上检查是否存在某些对象存活时间过长、持有时间过长的情况，尝试减少运行时内存的消耗。

CPU使用率特别高，怎么排查，通用方法，定位代码，CPU使用率高的原因？

案例1：CPU占用过高定位