JVM
是Java
设计者用于屏蔽多平台差异,基于操作系统之上的一个"小型虚拟机"
,正是因为JVM
的存在,使得Java
应用程序运行时不需要关注底层操作系统的差异。使得Java程序
编译只需编译一次,在任何操作系统都可以以相同的方式运行。
这里的方法区指的不是存放Java方法的区域,它主要存放的是元数据信息,例如:类信息、常量、静态变量、以及class文件在类加载时也会数据也会存放到方法区中。
堆区存储的则是对象实例,数组等。例如我们日常的new
操作就是在堆区分配一个空间存放对象实例。因为堆区是线程共享区域的,所以多线程情况下操作相同对象可能存在线程安全问题。
我们日常对象实例的方法调用都是在虚拟机栈上运行的,它是Java
方法执行的内存模型,存储着被执行方法的局部变量表、动态链表、方法入口、栈的操作用(入栈和出栈)。
由于虚拟机栈是栈结构所以方法调用按顺序压入栈中,就会倒序弹出虚拟机栈,例如我们的下面这段代码:
public void a(){
b();
}
public void b(){
c();
}
public void c(){
}
当线程调用a方法时,优先为a产生一个栈帧A压入栈中,发现a方法调用了b方法,再为b产生一个栈帧B压入栈中,然后b再调用c方法,再为c产生一个栈帧C方法压入栈中。
c执行结束,优先弹出栈,然后是b,最后是a。
由上可以在Java
中方法是可以嵌套调用的,但这并不意味方法可以无线层次的嵌套调用,当方法嵌套调用深度超过了虚拟机栈规定的最大深度,就会抛出StackOverflowError
,而这个错误也常常发生在我们编写的无终止条件的递归代码中。
虚拟机栈属于线程独享,所以也就没有什么生命周期的概念,每个方法随着调用的结束栈空间也随之释放,所以栈的生命周期也可以理解为和线程生命周期是一致的。
这就使得我们虚拟机栈中的局部变量表可以被复用,例如某个虚拟机栈当前局部变量表被使用的索引为0-n
,一旦虚拟栈执行的代码超过n位置,那么n之前的内存空间就可以被再次复用。
小结一下虚拟栈的特点:
StackOverflowError
。下面这个带有native关键字的方法就是在本地方法,它就是本地方法栈管理的方法,其工作机制和特点是虚拟机栈是差不多的,所以这里就不多做介绍了。
private native void start0();
程序计数器和我们操作系统学习的程序计数器概念差不多,记录着当前线程下一条要执行的指令的地址,因为是线程独享的,所以程序计数器也是线程安全的。
需要注意的是程序计数器只有在记录虚拟机栈的方法时才会有值,对于native
方法,程序计数器是不工作的。
上文对运行时数据区域做了一个简单的介绍,这里我们就用一张图总结一下JVM
运行时区域的结构。
类加载器实现将编译后的class
文件加载到内存,并转为为运行时区域划分的运行时数据结构,注意类加载器只能决定类加载,至于能不能运行则是由 Execution Engine
来决定。
类加载器工作顺序为:加载、验证、准备、解析、初始化、使用、卸载。其中验证、准备、解析这三个步骤统称为连接。
class
文件加载到内存。java.lang.Class
对象作为数据访问的入口。class
的类的方法是否会做出危害JVM
的事情。private static int a=3;
,在此阶段就会在方法区完成创建,并初始默认值0。import java.util.ArrayList
在此阶段就会直接转为指针或者对象地址。将方法区中准备好的值,通过调用<cinit>
完成初始化工作。<cinit>
会收集好所有的赋值动作,例如上文的private static int a=3
就是这时候完成赋值的。
当对象使用完成后,GC
将无用对象从内存中卸载。
其实类加载器并非只有一个,按照分类我们可以将其分为:
BootStrap ClassLoader:rt.jar
Extention ClassLoader: 加载扩展的jar包
App ClassLoader:指定的classpath下面的jar包
Custom ClassLoader:自定义的类加载器
所以,为了保证JDK
自带rt.jar
的类能够正常加载,就出现了一种名为双亲委派的类加载机制。
举个例子,JDK
自带的包中有一个名为String
的类,而我们自定义的代码中也有一个String
类,我们自己的类肯定是由App ClassLoader
完成加载,如果我们的类加载器优先执行,那么JDK
自带的String
类就无法被使用到。
所以双亲委派机制就规定了类加载优先由BootStrap ClassLoader
先加载,只有根加载器加载不到需要的类,才会交由下层类完成加载。
正是因为双亲委派机制的存在,jdk
自带的String
类才能够正常的使用,而我们也无法通过自定义String
类进行重写。
类加载器的工作流程为:
如下所示,我们编写一个Student
类,他有name
这个成员属性。
/**
* 学生类
*/
public class Student {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
然后我们编写一个main
方法,调用student
类,完成属性赋值。
public class Main {
public static void main(String[] args) throws InterruptedException {
Student student = new Student();
student.setName("小明");
}
}
Main.class
文件后,系统会启动一个JVM进程
,从classpath
中找到这个class
的二进制文件,将在到方法区的运行时数据区域。然后发现有个主入口main方法,将main方法压入栈中。
main方法中需要new Student();
,JVM
发现方法区中没有Student
类的信息,于是开始加载这个类,将这个类的信息存放到方法区,并在堆区创建一个Class对象作为方法区信息的入口。
new Student();
在此时就会根据类元信息获取创建student对象所需要的空间大小,在堆区申请并开辟一个空间调用构造函数创建Student
实例。
main
方法调用setName
,student
的引用找到堆区的Student
,通过其引用找到方法区中Student
类的方法表得到方法的字节码地址,从而完成调用。
上述步骤完成后,方法按照入栈顺序后进先出的弹出,虚拟机栈随着线程一起销毁。
JVM
将堆内存分为年轻代和老年代。以及非堆内存区域,我们称为永久代,这里所说的永久代只有在Java8
之前才会出现。在Java8
之后因为兼容性原因,永久代的东西都被放置到元空间,元空间所使用的内存都是本地内存,这里的本地内存说的就是我们物理机上的内存,所以理论上物理机内存多大,元空间内存就可以分配多大,元空间大小分配和JVM
从物理机上分配的内存大小没有任何关系。
补充元空间两个参数:
MetaspaceSize:初始化元空间大小,控制发生GC
MaxMetaspaceSize:限制元空间大小上限,防止占用过多物理内存。
了解整体空间之后,我们再来聊聊年轻代,年轻又可以分为Eden
和Survivor
区,Survivor
区又被平均分为两块。所以年代整体比例为8:1:1
。当然这个值也可以通过-XX:+UsePSAdaptiveSurvivorSizePolicy
来调整。
任何对象刚刚创建的时候都会放在Eden
区。我们都知道堆区内存是共享的,所以Eden
区的空间也是多线程共享的,但是为了确保多线程彼此之间相对独立(注意是线程之间彼此独立而不是操作Eden
区对象独立),Eden
区会专门划出一块连续的空间给每个线程分配一个独立空间,这个空间叫做TLAB
空间。每个线程都可以操作自己的TLAB
空间和读取其他线程的TLAB
空间。
一旦Eden区满了之后,就会触发第一次Minor GC,就会将存活的对象从Eden区放到Survivor区。
Survivor区就比较特别了,它分为Survivor0和Survivor1区。JVM使用from和to两个指针管理这两块区域,其中from指针指向有对象的区域空间,to指针指向空闲区域的Survivor空间。
从Eden区中存活下来首先会在Survivor0区(此时from指针在Survivor0),一旦下一次Eden区空间满了之后就再次触发 Minor GC 将Eden区和Survivor0区存活的对象复制到Survivor1区,然后from指针指向Survivor1,结束一次minor GC。
经过15
次之后还活着的对象就会被存放到老年代,这里是15是由-XX:MaxTenuringThreshold
指定的, -XX:MaxTenuringThreshold
占4位,默认配置为15
。
这里补充一下,同样会将Survivor
存放到老年代的第2个条件,当Survivor
区对象比例达到XX:TargetSurvivorRatio
时,也会将存活的对象放到老年区。
老年代存放的都是经历过无数次GC
的老对象,一旦这个空间满了之后就会出现一次Full GC
,Full GC
期间所有线程都会停止手头工作等待Full GC
完成,所以在此期间,系统可能会出现卡顿现象。
这就意味着在高并发多对象创建场景的情况下,我们需要合理分配老年区的内存。一旦Full GC
后还是无法容纳新对象,就会报OOM
问题。
这种了解就好了,一个对象被引用时+1,被解除引用时-1。我们根据引用计数结果决定是否GC,但是这种方式无法解决两个对象互相引用的情况。例如我们栈区没有一个引用指向当前两个对象,可堆区两个对象却互相引用对方。
将一系列的GC ROOTS
作为起始的存活对象集,查看是否有任意一个GC ROOTS
可以到达这个对象,都不可达就说明这个对象要被回收了。
而以下几种可以作为GC ROOTS
:
判断对象是否被回收需要经过两个阶段:
finalize()
方法,若确定则将其存到F-Queue
中。F-Queue
中的对象调用finalize()
,若此时还是没有任何引用链引用,则说明这个对象要被回收了。如下图,这种算法很简单,标记出需要被回收的对象的空间,然后直接清除。同样的缺点也很明显,容易造成内存碎片,内存碎片也很好理解,回收的对象空间都是一小块一小块的,当我们需要创建一个大对象时就没有一块连续大空间供其使用。
这种算法和上文说的survivor
一样,将空间一分为二,from
存放当前活着的对象,to作为空闲空间。在进行回收时,将没有被标记回收的对象挪到另一个空间,然后from指向另一个空间。这种算法缺点也很明显,可利用空间就一半。
这种算法算是复制算法的改良版,将存活对象全部挪动到一段,确保空闲和对象空间都是连续的,且空间利用率100%。
这种算法就是上面算法的组合,即年轻代存活率低,采用复制算法。老年代存活率高,采用标记清除算法或者标记整理算法。
查看Java
应用程序配置参数或者JVM
系统属性,相关命令详情我们可以使用-help
或者man
命令查看,如下所示:
[root@xxxxxtmp]# jinfo -help
Usage:
jinfo [option] <pid>
(to connect to running process)
jinfo [option] <executable <core>
(to connect to a core file)
jinfo [option] [server_id@]<remote server IP or hostname>
(to connect to remote debug server)
where <option> is one of:
-flag <name> to print the value of the named VM flag
-flag [+|-]<name> to enable or disable the named VM flag
-flag <name>=<value> to set the named VM flag to the given value
-flags to print VM flags
-sysprops to print Java system properties
<no option> to print both of the above
-h | -help to print this help message
为了演示,笔者在服务器上开启了一个Java应用,我们可以使用jps
命令查看其进程id
,可以看到笔者服务器中有一个pid
为19946
的Java进程。
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]# jps
20104 Jps
19946 jar
查看当前应用所有的配置参数以及系统配置属性命令为jinfo pid
如下所示:
[root@xxxxx tmp]# jinfo 19946
Attaching to process ID 19946, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08
Java System Properties:
java.runtime.name = Java(TM) SE Runtime Environment
java.vm.version = 25.202-b08
sun.boot.library.path = /root/jdk8/jre/lib/amd64
java.protocol.handler.pkgs = org.springframework.boot.loader
java.vendor.url = http://java.oracle.com/
java.vm.vendor = Oracle Corporation
path.separator = :
file.encoding.pkg = sun.io
java.vm.name = Java HotSpot(TM) 64-Bit Server VM
sun.os.patch.level = unknown
sun.java.launcher = SUN_STANDARD
user.country = US
user.dir = /tmp
......
如果我们希望查看当前Java应用是否有配置某些信息,可以使用命令jinfo -flag 配置选项 pid
,例如我们想查看当前应用是否有开启gc选项
,可以使用下面这段命令
可以看到输出结果为-XX:-PrintGC
,因为PrintGC
前面是减号,这说明该选项并没有开启。
[root@xxx tmp]# jinfo -flag PrintGC 19946
-XX:-PrintGC
如果我们希望将这个选项开启,我们只需在参数前面加个+号即可,例如我们希望开启gc选项
,我们只需键入如下命令
[root@xxxxxtmp]# jinfo -flag +PrintGC 19946
再次查看可以发现,选项生效了
[root@xxxx tmp]# jinfo -flag PrintGC 19946
-XX:+PrintGC
有些参数是键值对的形式,例如我们想配置dump日志的路径,我们也可以使用jinfo进行配置,命令格式为jinfo -flag 参数=值 Java进程id
jinfo -flag HeapDumpPath=/tmp/dump.log 19946
打印JVM选项信息
jinfo -flags 4854
Attaching to process ID 4854, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08
Non-default VM flags: -XX:CICompilerCount=2 -XX:HeapDumpPath=null -XX:InitialHeapSize=33554432 -XX:MaxHeapSize=511705088 -XX:MaxNewSize=170524672 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=11141120 -XX:OldSize=22413312 -XX:+PrintGC -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps
Command line:
查看应用属性,命令格式jinfo -sysprops Java进程id
jinfo -sysprops 2341
jmap
作用:
查看堆内存使用情况 jmap -heap Java进程id
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]# jmap -heap 25534
Attaching to process ID 25534, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08
using thread-local object allocation.
Mark Sweep Compact GC
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 511705088 (488.0MB)
NewSize = 11141120 (10.625MB)
MaxNewSize = 170524672 (162.625MB)
OldSize = 22413312 (21.375MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
查看存活的Java
对象(文档说明:to print histogram of java object heap; if the “live” suboption is specified, only count live objects),命令格式: jmap -histo:live Java进程id
[root@xxxtmp]# jmap -histo:live 25534
num #instances #bytes class name
----------------------------------------------
1: 48676 7974952 [C
2: 7762 1873312 [I
3: 47785 1146840 java.lang.String
4: 12737 1120856 java.lang.reflect.Method
5: 8773 968912 java.lang.Class
6: 25572 818304 java.util.concurrent.ConcurrentHashMap$Node
7: 14108 564320 java.util.LinkedHashMap$Entry
8: 2712 509536 [B
9: 9308 494936 [Ljava.lang.Object;
10: 6345 493128 [Ljava.util.HashMap$Node;
11: 7001 392056 java.util.LinkedHashMap
12: 11255 360160 java.util.HashMap$Node
13: 15946 354528 [Ljava.lang.Class;
14: 18176 290816 java.lang.Object
15: 3447 248184 java.lang.reflect.Field
16: 124 192320 [Ljava.util.concurrent.ConcurrentHashMap$Node;
jmap -finalizerinfo Java进程id
[root@xxxtmp]# jmap -finalizerinfo 25534
Attaching to process ID 25534, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08
Number of objects pending for finalization: 0
将存活的对象的信息存到二进制文件中
jmap -dump:live,format=b,file=/tmp/heap.bin 25534
Dumping heap to /tmp/heap.bin ...
Heap dump file created
此时就可以使用jhat
打开该文件,如下所示jhat 文件名
,这时候我们就可以通过7000
端口查看详情了。
[root@xxxtmp]# jhat heap.bin
Reading from heap.bin...
Dump file created Wed Nov 02 20:21:18 CST 2022
Snapshot read, resolving...
Resolving 346825 objects...
Chasing references, expect 69 dots.....................................................................
Eliminating duplicate references.....................................................................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.
jstat用于监控虚拟机各种运行状态信息,显示虚拟机进程中装在、内存、垃圾收集、JIT编译等运行数据。
查看类加载信息,命令格式jstat -class Java进程id
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]# jstat -class 2341
Loaded Bytes Unloaded Bytes Time
8221 14604.3 1 0.9 12.74
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]#
查看编译统计信息jstat -compiler Java进程id
[root@xxxtmp]# jstat -compiler 2341
Compiled Failed Invalid Time FailedType FailedMethod
4177 0 0 17.68 0
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]#
查看gc
统计信息
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]# jstat -gc 2341
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
1408.0 1408.0 0.0 1020.3 11840.0 7493.1 29268.0 22168.5 42840.0 40613.5 5760.0 5311.9 65 0.401 2 0.213 0.613
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]#
每个表头的含义如下
1. S0C :年轻代中第一个survivor(幸存区)的容量 (字节)
2. S1C :年轻代中第二个survivor(幸存区)的容量 (字节)
3. S0U:年轻代中第一个survivor(幸存区)目前已使用空间 (字节)
4. S1U:年轻代中第二个survivor(幸存区)目前已使用空间 (字节)
5. EC:年轻代中Eden(伊甸园)的容量 (字节)
6. EU:年轻代中Eden(伊甸园)目前已使用空间 (字节)
7. OC:Old代的容量 (字节)
8. OU:Old代目前已使用空间 (字节)
9. PC:Perm(持久代)的容量 (字节)
10. PU:Perm(持久代)目前已使用空间 (字节)
11. YGC:从应用程序启动到采样时年轻代中gc次数
12. YGCT:从应用程序启动到采样时年轻代中gc所用时间(s)
13. FGC:从应用程序启动到采样时old代(全gc)gc次数
14. FGCT:从应用程序启动到采样时old代(全gc)gc所用时间(s)
15. GCT:从应用程序启动到采样时gc用的总时间(s)
查看gc内存容量和元空间容量
[root@xxxtmp]# jstat -gccapacity 2341
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC
10880.0 166528.0 14656.0 1408.0 1408.0 11840.0 21888.0 333184.0 29268.0 29268.0 0.0 1087488.0 42840.0 0.0 1048576.0 5760.0 65 2
查看年轻代统计信息
[root@xxxxtmp]# jstat -gcnew 2341
S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT
1408.0 1408.0 0.0 1020.3 2 15 704.0 11840.0 7652.5 65 0.401
[root@iZ8vb7bhe4b8nhhhpavhwpZ tmp]#
参数详情
1. S0C:年轻代中第一个survivor(幸存区)的容量 (字节)
2. S1C:年轻代中第二个survivor(幸存区)的容量 (字节)
3. S0U:年轻代中第一个survivor(幸存区)目前已使用空间 (字节)
4. S1U:年轻代中第二个survivor(幸存区)目前已使用空间 (字节)
5. TT:持有次数限制
6. MTT:最大持有次数限制
7. EC:年轻代中Eden(伊甸园)的容量 (字节)
8. EU:年轻代中Eden(伊甸园)目前已使用空间 (字节)
9. YGC:从应用程序启动到采样时年轻代中gc次数
10. YGCT:从应用程序启动到采样时年轻代中gc所用时间(s)
Minor GC、Major GC 和 Full GC 之间的区别
minor gc 会发生stop the world 现象吗? - 红色的红的回答 - 知乎
https://www.zhihu.com/question/29114369/answer/2287094858