JVM

JVM主要组成部分及其作用

JVM主要包含两个子系统和两个组件

两个子系统：

• Class Loader（类加载）：根据给定的全限定类名（ 如：java.lang.Object ）来加载class文件到运行时数据区中的方法区
• Execution engine（执行引擎）：执行classes中的指令

两个组件：

• Native interface（本地接口）：与本地方法库交互，是其他编程语言的接口
• Runtime data area（运行时数据区）：我们常说的JVM内存

Java程序运行机制

总结一句话：类的加载是指将类的 .class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区中，然后在堆中创建一个 java.lang.Class对象，用来封装类在方法区中的数据结构

双亲委派机制

类加载器

双亲委派机制离不开类加载器。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立在 JVM 中的唯一性，每一个类加载器，都有一个独立的类名称空间。类加载器就是根据指定全限定名称将 class 文件加载到 JVM 内存，然后再转化为 class 对象。

类加载器分类：

• 启动类加载器（Bootstrap ClassLoader），是虚拟机自身的一部分，用来加载 Java_HOME/lib/目录中的，或者被 -Xbootclasspath 参数所指定的路径中并且被虚 拟机识别的类库；
• 其他类加载器：
  • 扩展类加载器（Extension ClassLoader）：负责加载\lib\ext目录或Java. ext. dirs系统变量指定的路径中的所有类库；
  • 应用程序类加载器（Application ClassLoader）：负责加载用户类路径（classpath）上的指定类库，我们可以直接使用这个类加载器。一般情况，如果我 们没有自定义类加载器默认就是用这个加载器。

双亲委派模型

如果一个类加载器收到了类加载的请求，它首先不会自己去加载这个类，而是把这个请求委派给父类加载器去完成，每一层的类加载器都是如此，这样所有的加载请求都会被传送到顶层的启动类加载器中，只有当父加载无法完成加载请求（它的搜索范围中没找到所需的类）时，子加载器才会尝试去加载类
当一个类收到了类加载请求时，不会自己先去加载这个类，而是将其委派给父类，由父类去加载，如果此时父类不能加载，反馈给子类，由子类去完成类的加载。类加载器之间并非继承关系
双亲委派机制是向上查找，向下加载：向上查找是因为每个加载器有一个缓存，如果向上查找的时候发现加载器里面有数据了就直接返回不需要去jar包里面查找加载了，如果没有在向上查找

双亲委派机制存在的意义

1.防止重复加载同一个.class。通过委托去向上面问一问，加载过了，就不用再加载一遍。保证数据安全。
2.保证核心.class不能被篡改。通过委托方式，不会去篡改核心.class，即使篡改也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。

举例

创建包的时候不能创建名字为Java的包，为了演示双亲委派机制的安全性（防止呗篡改代码），创建一个java.lang包下的String类

IDEA直接提醒我 new String() 时多余的

根据包名一层一层向上请求，在请求到boot加载器的时候，boot加载器发现自己可以加载java.lang包下的类，对lib下的String进行加载，类库中的String类没有main方法，所以抛出异常

栈、堆、队列

堆栈区别

物理地址
堆的物理地址分配对对象是不连续的。因此性能慢些。在GC的时候也要考虑到不连续的分配，所以有各种算法。比如，标记-消除，复制，标记-压缩，分代（即新生代使用复制算法，老年代使用标记——压缩）栈使用的是数据结构中的栈，先进后出的原则，物理地址分配是连续的。所以性能快。
内存分别

• 堆因为是不连续的，所以分配的内存是在运行期确认的，因此大小不固定。一般堆大小远远大于栈。
• 栈是连续的，所以分配的内存大小要在编译期就确认，大小是固定的。

存放的内容

• 堆存放的是对象的实例和数组。因此该区更关注的是数据的存储
• 栈存放：局部变量，操作数栈，返回结果。该区更关注的是程序方法的执行。

PS：

1. 静态变量放在方法区
2. 静态的对象还是放在堆。

程序的可见度

• 堆对于整个应用程序都是共享、可见的。
• 栈只对于线程是可见的。所以也是线程私有。他的生命周期和线程相同。

队列跟栈区别

队列和栈都是被用来预存储数据的。

• 操作的名称不同。队列的插入称为入队，队列的删除称为出队。栈的插入称为进 栈，栈的删除称为出栈。
• 可操作的方式不同。队列是在队尾入队，队头出队，即两边都可操作。而栈的进 栈和出栈都是在栈顶进行的，无法对栈底直接进行操作。
• 操作的方法不同。队列是先进先出（FIFO），即队列的修改是依先进先出的原 则进行的。新来的成员总是加入队尾（不能从中间插入），每次离开的成员总是队列 头上（不允许中途离队）。而栈为后进先出（LIFO）,即每次删除（出栈）的总是当前栈中新的元素，即后插入（进栈）的元素，而先插入的被放在栈的底部，要到后才能删除。

Java垃圾回收

在java中，程序员是不需要显示的去释放一个对象的内存的，而是由虚拟机自行执行。在JVM中，有一个垃圾回收线程，它是低优先级的，在正常情况下是不会执行的，只有在虚拟机空闲或者当前堆内存不足时，才会触发执行，扫面那些没有被任何引用的对象，并将它们添加到要回收的集合中，进行回收。

GC 是垃圾收集的意思（Garbage Collection）,内存处理是编程人员容易出现问题的地方，忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃，Java 提供的 GC 功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的，Java 语言没有提供释放已分配内存的显示操作方法。

现有的主流JVM分别是HotSpot和JRockit，主要研究对象也是这两个。这篇文章里，我们只研究HotSpot，也就是所谓的Sun JVM。

当前商业虚拟机都采用分代收集的垃圾收集算法。分代收集算法，顾名思义是根据对象的存活周期将内存划分为几块。一般包括年轻代、老年代 和 永久代，如图所示：

方法区是在堆里面吗？

三种情况：
1、 JDK 1.6之前，常量池是存放在方法区（永久代）中的，永久代和堆相互隔离
2、 JDK 1.7中，常量池从永久代移到堆中；
3、 JDK 1.8之后，取消永久代，方法存放于元空间(Metaspace)，元空间仍然与堆不相连，但与堆共享物理内存，逻辑上可认为在堆中。运行时常量池和静态常量池存放在元空间中，而字符串常量池依然存放在堆中

JVM中的永久代中不会发生垃圾回收

垃圾回收不会发生在永久代，如果永久代满了或者是超过了临界值，会触发完全垃圾回收(Full GC)。如果仔细查看垃圾收集器的输出信息，就会发现永久代也是被回收的

堆和非堆（元空间）的内存模型和调优参数

堆大小 = 新生代 + 老年代

其中，堆的大小可以通过参数 –Xms、-Xmx 来指定

JVM调优工具

JDK 自带
位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具

• jconsole：用于对 JVM 中的内存、线程和类等进行监控
• jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等

需安装

• MAT（eclipse专用）
• Jprofiler

GC

多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发起一次 Minor GC。如果本次 GC后还是没有足够的空 间，则将启用分配担保机制在老年代中分配内存。
这里我们提到 Minor GC，如果你仔细观察过 GC 日常，通常我们还能从日志中发现 Major GC/Full GC

• Minor GC 是指发生在新生代的 GC，因为 Java 对象大多都是朝生夕死，所有 Minor GC 非常频繁，一般回收速度也非常快；
• Major GC/Full GC 是指发生在老年代的 GC，出现了 Major GC 通常会伴随至少一次 Minor GC。Major GC 的速度通常会比 Minor GC 慢 10 倍以上。

GC算法

标记-清除算法

标记-清除算法（Mark-Sweep）是一种常见的基础垃圾收集算法，它将垃圾收集分为两个阶段：

• 标记阶段：标记出可以回收的对象。
• 清除阶段：回收被标记的对象所占用的空间。

标记-清除算法之所以是基础的，是因为后面讲到的垃圾收集算法都是在此算法的基础上进行改进的。

• 优点：实现简单，不需要对象进行移动。
• 缺点：标记、清除过程效率低，产生大量不连续的内存碎片，提高了垃圾回收的频率。

标记-清除算法的执行的过程

复制算法

为了解决标记-清除算法的效率不高的问题，产生了复制算法。它把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾收集时，遍历当前使用的区域，把存活对象复制到另外一个区域中，最后将当前使用的区域的可回收的对象进行回收

• 优点：按顺序分配内存即可，实现简单、运行高效，不用考虑内存碎片。
• 缺点：可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。

复制算法的执行过程

标记-整理算法/标记压缩算法

在新生代中可以使用复制算法，但是在老年代就不能选择复制算法了，因为老年代的对象存活率会较高，这样会有较多的复制操作，导致效率变低。标记-清除算法可以应用在老年代中，但是它效率不高，在内存回收后容易产生大量内存碎片
因此就出现了一种标记-整理算法（Mark-Compact）算法，与标记-清除算法不同的是，在标记可回收的对象后将所有存活的对象压缩到内存的一端，使他们紧凑的排列在一起，然后对端边界以外的内存进行回收。回收后，已用和未用的内存都各自一边

• 优点：解决了标记-清理算法存在的内存碎片问题
• 缺点：仍需要进行局部对象移动，一定程度上降低了效率

标记-整理算法的执行过程

三种算法总结

内存效率：复制算法 > 标记清除算法 > 标记压缩算法
内存整齐度：复制算法 = 标记压缩算法 > 标记清除算法
内存利用率：标记压缩算法 = 标记清除算法 > 复制算法

没有最好的算法，只有最适合的算法！！！

垃圾回收器

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现

7种作用于不同分代的收集器

不同收集器之间的连线表示它们可以搭配使用

• Serial收集器（复制算法): 新生代单线程收集器，标记和清理都是单线程，优点是简单高效
• ParNew收集器 (复制算法): 新生代收并行集器，实际上是Serial收集器的多线程版本，在多核CPU环境下有着比Serial更好的表现；
• Parallel Scavenge收集器 (复制算法): 新生代并行收集器，追求高吞吐量，高效利用 CPU。吞吐量 = 用户线程时间/(用户线程时间+GC线程时间)，高吞吐量可以高效率的利用CPU时间，尽快完成程序的运算任务，适合后台应用等对交互相应要求不高的场景；
• Serial Old收集器 (标记-整理算法): 老年代单线程收集器，Serial收集器的老年代版本；
• Parallel Old收集器 (标记-整理算法)： 老年代并行收集器，吞吐量优先， Parallel Scavenge收集器的老年代版本；
• CMS(Concurrent Mark Sweep)收集器（标记-清除算法）： 老年代并行收集器，以获取最短回收停顿时间为目标的收集器，具有高并发、低停顿的特点，追求最短GC回收停顿时间。
• G1(Garbage First)收集器 (标记-整理算法)： Java堆并行收集器，G1收集器是 JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。此外，G1收集器不同于之前的收集器的一个重要特点是：G1回收的范围是整个Java堆(包括新生代，老年代)，而前六种收集器回收的范围仅限于新生代或老年代

CMS

CMS（Concurrent Mark-Sweep）是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。
在启动 JVM 的参数加上“-XX:+UseConcMarkSweepGC”来指定使用 CMS 垃圾回收器。 CMS 使用的是标记-清除算法实现的，所以在GC的时候回产生大量的内存碎片，当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure（并发模式故障），临时 CMS 会采用 Serial Old 回收器进行垃圾清除，此时的性能将会被降低

G1

G1（Garbage First）设计目标是为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。G1回收器和CMS比起来，有以下不同：

• G1垃圾回收器是紧实的，因此其回收得到的空间是连续的。这避免了CMS回收器因为不连续空间所造成的问题
• G1回收器的内存与CMS回收器要求的内存模型有极大的不同。G1将内存划分一个个固定大小的区域，每个区域可以是新生代、老年代的一个。内存的回收是以区域作为基本单位的

G1还有一个及其重要的特性：软实时（soft real-time）。所谓的实时垃圾回收，是指在要求的时间内完成垃圾回收。“软实时”则是指，用户可以指定垃圾回收时间的限时，G1会努力在这个时限内完成垃圾回收，但是G1并不担保每次都能在这个时限内完成垃圾回收。通过设定一个合理的目标，可以让达到90%以上的垃圾回收时间都在这个时限内