jvm 知识点整理（内存区域、垃圾回收）

内存划分（虚拟机内存的各个区域）

• 虚拟机栈（stack）
  栈是方法调用的内存模型，作用是存放方法调用时的数据，比如本地变量表。每调用一个java方法，就会在栈顶放入一个栈帧（stack frame）。方法的调用与退出分别对应的栈帧的入栈与出栈操作。
  下图是idea调试的一个场景，左边的Frames就是当前线程的栈，选中顶层的栈帧，右边Variables区域显示的就是本地变量表，是在方法中申明的变量。
  
  每个线程都有各自的栈空间，各自独立。因此栈内的数据不存在线程安全问题。java中的八大基础类型变量，以及reference类型变量会在栈内分配空间。
• 堆（heap）
  堆的作用就是存放对象，占用很大一部分的虚拟机内存。可以使用Xmx、Xms参数来设定堆的最大最小值，虚拟机根据运行情况自动调节堆大小。java程序运行中会创建大量生命周期很短的对象，因此需要虚拟机提供垃圾回收机制及时地清理内存空间。
• 元数据区域（方法区）。
  存放类的信息、运行时常量池。
• 本地方法栈。用来调用本地方法（native方法）。本地方法由外部的c++代码库提供实现。
• 程序计数器。

垃圾回收

什么样的对象是垃圾？（如何确定对象是否存活）

不再被使用的对象就是垃圾，需要被回收。有2中垃圾判定方法：

1. 引用计数器。用一个引用计数器保存对象被引用的次数，如果引用计数器=0，则说明没有被引用。可惜，当2个对象相互持有对方的引用，这种方法就存在漏洞。
2. 可达性判断方法。既然无法被使用的对象就是垃圾，那么只需判断从Root到对象否可达就行了。什么是Root？栈帧内的本地变量表、类的静态引用变量、运行时常量池，从这些地方出发，所有可达的对象都是存活对象。

如何回收？（垃圾的收集算法）

垃圾收集算法

1. 复制回收算法。每次只是使用一半的空间，回收策略是将存活对象移动到另一边，然后对剩余区域进行一次性的回收。这种方法效率高，但是要消耗2倍的内存。分代算法中的年轻代一般使用这种策略，因为新生代中大部分对象生命周期短，垃圾的命中率很高，只需copy少量仍然存活的对象，就可以完成gc工作。

2. 标记清除。2个步骤：1）判断对象是否是垃圾，并打上垃圾标记；2）将垃圾对象清除。这种算法容易产生内存碎片，连续的内存逐渐变少，可能会导致无法为对象分配空间。

3. 标记整理。在标记清除的基础上，再加上一个整理的过程，使内存变得规整。

4. 分代回收。分代就是根据对象的生命周期长短，将对象划分在不同的内存区域，对区域采取不同的垃圾回收方法。不同年代的命名很形象，新生代、老年代，新创建的对象在新生代，经历几次minor gc后仍存活的对象则进入老年代。当然也有其他情况，可以使对象提前进入老年代。年轻代的对象特征是生命周期短，垃圾的命中率很高，因此一般采用复制回收算法，只需copy少量仍然存活的对象，就可以完成gc工作。

垃圾回收器

新生代垃圾收集器

1. Serial 单线程回收器。适用于单cpu场景下。
2. Parnew 多线程回收器。提高垃圾回收时的cpu的利用率
3. Parallel Scavenge 更关注cpu吞吐量收集器。可以指定目标吞吐量，由jvm实现内存管理调优的工作。

老年代垃圾收集器

1. serial old 老年代单线程收集器
2. parallel old 老年代并行收集器
3. 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虚拟机》一书