jvm 知识点整理
内存划分(虚拟机内存的各个区域)
- 虚拟机栈(stack)
栈是方法调用的内存模型,作用是存放方法调用时的数据,比如本地变量表。每调用一个java方法,就会在栈顶放入一个栈帧(stack frame)。方法的调用与退出分别对应的栈帧的入栈与出栈操作。
下图是idea调试的一个场景,左边的Frames就是当前线程的栈,选中顶层的栈帧,右边Variables区域显示的就是本地变量表,是在方法中申明的变量。
每个线程都有各自的栈空间,各自独立。因此栈内的数据不存在线程安全问题。java中的八大基础类型变量,以及reference类型变量会在栈内分配空间。 - 堆(heap)
堆的作用就是存放对象,占用很大一部分的虚拟机内存。可以使用Xmx、Xms参数来设定堆的最大最小值,虚拟机根据运行情况自动调节堆大小。java程序运行中会创建大量生命周期很短的对象,因此需要虚拟机提供垃圾回收机制及时地清理内存空间。 - 元数据区域(方法区)。
存放类的信息、运行时常量池。 - 本地方法栈。用来调用本地方法(native方法)。本地方法由外部的c++代码库提供实现。
- 程序计数器。
垃圾回收
什么样的对象是垃圾?(如何确定对象是否存活)
不再被使用的对象就是垃圾,需要被回收。有2中垃圾判定方法:
- 引用计数器。用一个引用计数器保存对象被引用的次数,如果引用计数器=0,则说明没有被引用。可惜,当2个对象相互持有对方的引用,这种方法就存在漏洞。
- 可达性判断方法。既然无法被使用的对象就是垃圾,那么只需判断从Root到对象否可达就行了。什么是Root?栈帧内的本地变量表、类的静态引用变量、运行时常量池,从这些地方出发,所有可达的对象都是存活对象。
如何回收?(垃圾的收集算法)
垃圾收集算法
-
复制回收算法。每次只是使用一半的空间,回收策略是将存活对象移动到另一边,然后对剩余区域进行一次性的回收。这种方法效率高,但是要消耗2倍的内存。分代算法中的年轻代一般使用这种策略,因为新生代中大部分对象生命周期短,垃圾的命中率很高,只需copy少量仍然存活的对象,就可以完成gc工作。
-
标记清除。2个步骤:1)判断对象是否是垃圾,并打上垃圾标记;2)将垃圾对象清除。这种算法容易产生内存碎片,连续的内存逐渐变少,可能会导致无法为对象分配空间。
-
标记整理。在标记清除的基础上,再加上一个整理的过程,使内存变得规整。
-
分代回收。分代就是根据对象的生命周期长短,将对象划分在不同的内存区域,对区域采取不同的垃圾回收方法。不同年代的命名很形象,新生代、老年代,新创建的对象在新生代,经历几次minor gc后仍存活的对象则进入老年代。当然也有其他情况,可以使对象提前进入老年代。年轻代的对象特征是生命周期短,垃圾的命中率很高,因此一般采用复制回收算法,只需copy少量仍然存活的对象,就可以完成gc工作。
垃圾回收器
新生代垃圾收集器
- Serial 单线程回收器。适用于单cpu场景下。
- Parnew 多线程回收器。提高垃圾回收时的cpu的利用率
- Parallel Scavenge 更关注cpu吞吐量收集器。可以指定目标吞吐量,由jvm实现内存管理调优的工作。
老年代垃圾收集器
- serial old 老年代单线程收集器
- parallel old 老年代并行收集器
- cms 老年代的并发收集器
各个年代通用的垃圾收集器
G1 1)初始标记:标记GC ROOT对象;2)并发标记;从gc root开始,标记存活对象;3)最终标记:遍历第二步中引用发生变化的内存区域,更新存活标记;4)筛选回收:将region排序,回收价值高的区域。
为什么需要停顿?
在标记存活对象的过程中,为什么需要将用户线程会挂起?因为如果用户线程不挂起,那么对象间的引用时刻发生变化(新对象被创建),那么最终的标记结果就不准确。
问题排查
虚拟机常见的问题有:OOM、频繁的full gc导致应用停顿时间过长、线程死锁。为了排查问题,我们需要一些工具来查看虚拟机内部的运行状态。
命令行工具
- jps
java process status,即java虚拟机进程状态。返回进程id与MainClass的名字。如下图
主要是为了获得进程id,这在后面的命令中会用到。 - jmap
内存印象工具。常用的是jmap -histo 6
,会将堆中的对象数量、占用空间大小按照降序排列,可以帮助我们分析哪些对象是最多的,有助于定位问题代码。 - jstat
常用命令是jstat -gcutil 6 1500 10
,作用是打印gc情况,打印间隔为1500ms,打印10次。我们可以看到各个年代垃圾回收的次数、时间,以及内存占用率。 - jstack
查看线程状态。用于分析线程死锁。
gc日志
-XX:+PrintGCDetails 参数会让jvm打印gc日志,通过gc日志显示了每次gc运行的情况。以下是一条gc日志。第一个()内的Allocation Failure是gc的原因,是新生代无法分配内存导致了这次gc。后面紧跟着的[]内则显示了gc前后的内存占用变化,86656k到128k,以及新生代总空间(87040k)。0.0096899 secs则是这次gc耗费的时间。
[GC (Allocation Failure) [PSYoungGen: 86656K->128K(87040K)] 1526972K->1440444K(1720320K), 0.0096899 secs] [Times: user=0.03 sys=0.00, real=0.00 secs]
总结
gc日志可以作为问题分析的依据,如果gc时间过长,则需要调整堆内存,增大新生代空间,让对象在新生代就能被回收。发生了oom,可以使用jmap查看内存对象的分布状况,来确定导致oom的代码。也可以用参数-XX:+HeapDumpOnOutOfMemoryError ,在发生oom时,导出dump文件,用于还原当时的内存状态。
以上内容来自《深入理解java虚拟机》一书