auto commit
This commit is contained in:
CyC2018
parent
299d08eeaa
commit
4a58b4a43d
32
notes/JVM.md
32
notes/JVM.md
|
|
@ -197,6 +197,8 @@ PhantomReference<Object> pf = new PhantomReference<Object>(obj);
|
|||
|
||||
### 1.3 方法区的回收
|
||||
|
||||
因为方法区主要存放永久代对象，而永久代对象的回收率比新生代差很多，因此在方法区上进行回收性价比不高。
|
||||
|
||||
在方法区主要是对常量池的回收和对类的卸载。
|
||||
|
||||
常量池的回收和堆中对象回收类似。
|
||||
|
|
@ -213,10 +215,10 @@ PhantomReference<Object> pf = new PhantomReference<Object>(obj);
|
|||
|
||||
### 1.4 finalize()
|
||||
|
||||
当一个对象可被回收时，如果该对象有必要执行 finalize() 方法，那么就有可能可能通过在该方法中让对象重新被引用，从而实现自救。
|
||||
|
||||
finalize() 类似 C++ 的析构函数，用来做关闭外部资源等工作。但是 try-finally 等方式可以做的更好，并且该方法运行代价高昂，不确定性大，无法保证各个对象的调用顺序，因此最好不要使用。
|
||||
|
||||
当一个对象可被回收时，如果需要执行该对象的 finalize() 方法，那么就有可能可能通过在该方法中让对象重新被引用，从而实现自救。
|
||||
|
||||
## 2. 垃圾收集算法
|
||||
|
||||
### 2.1 标记-清除算法
|
||||
|
|
@ -240,7 +242,7 @@ finalize() 类似 C++ 的析构函数，用来做关闭外部资源等工作。
|
|||
|
||||
主要不足是只使用了内存的一半。
|
||||
|
||||
现在的商业虚拟机都采用这种收集算法来回收新生代，但是并不是将内存划分为大小相等的两块，而是分为一块较大的 Eden 空间和两块较小的 Survior 空间，每次使用 Eden 空间和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上，最后清理 Eden 和 Survivor。HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1，保证了内存的利用率达到 90 %。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 空间就不够用了，需要依赖于老年代进行分配担保，也就是借用老年代的空间。
|
||||
现在的商业虚拟机都采用这种收集算法来回收新生代，但是并不是将内存划分为大小相等的两块，而是分为一块较大的 Eden 空间和两块较小的 Survior 空间，每次使用 Eden 空间和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上，最后清理 Eden 和 使用过的那一块 Survivor。HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1，保证了内存的利用率达到 90 %。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 空间就不够用了，此时需要依赖于老年代进行分配担保，也就是借用老年代的空间。
|
||||
|
||||
### 2.3 标记-整理算法
|
||||
|
||||
|
|
@ -250,12 +252,12 @@ finalize() 类似 C++ 的析构函数，用来做关闭外部资源等工作。
|
|||
|
||||
### 2.4 分代收集算法
|
||||
|
||||
现在的商业虚拟机采用分代收集算法，它使用了前面介绍的几种收集算法，根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。
|
||||
现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。
|
||||
|
||||
一般将 Java 堆分为新生代和老年代。
|
||||
|
||||
1. 新生代使用：复制算法
|
||||
2. 老年代使用：标记 - 清理 或者 标记 - 整理 算法。
|
||||
2. 老年代使用：标记-清理 或者 标记-整理 算法。
|
||||
|
||||
## 3. 垃圾收集器
|
||||
|
||||
|
|
@ -316,7 +318,7 @@ Serial Old 是 Serial 收集器的老年代版本，也是给 Client 模式下
|
|||
|
||||
<div align="center"> <img src="../pics//62e77997-6957-4b68-8d12-bfd609bb2c68.jpg"/> </div><br>
|
||||
|
||||
CMS（Concurrent Mark Sweep），从 Mark Sweep 可以知道它是基于 标记 - 清除 算法实现的。
|
||||
CMS（Concurrent Mark Sweep），从 Mark Sweep 可以知道它是基于标记-清除算法实现的。
|
||||
|
||||
特点：并发收集、低停顿。
|
||||
|
||||
|
|
@ -335,7 +337,7 @@ CMS（Concurrent Mark Sweep），从 Mark Sweep 可以知道它是基于 标记
|
|||
|
||||
2. 无法处理浮动垃圾。由于并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生。这一部分垃圾出现在标记过程之后，CMS 无法在当次收集中处理掉它们，只好留到下一次 GC 时再清理掉，这一部分垃圾就被称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此它不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。可以使用 -XX:CMSInitiatingOccupancyFraction 的值来改变触发收集器工作的内存占用百分比，JDK 1.5 默认设置下该值为 68，也就是当老年代使用了 68% 的空间之后会触发收集器工作。如果该值设置的太高，导致浮动垃圾无法保存，那么就会出现 Concurrent Mode Failure，此时虚拟机将启动后备预案：临时启用 Serial Old 收集器来重新进行老年代的垃圾收集。
|
||||
|
||||
3. 标记 - 清除算法导致的空间碎片，给大对象分配带来很大麻烦，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象，不得不提前出发一次 Full GC。
|
||||
3. 标记-清除算法导致的空间碎片，给大对象分配带来很大麻烦，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象，不得不提前出发一次 Full GC。
|
||||
|
||||
### 3.7 G1 收集器
|
||||
|
||||
|
|
@ -368,22 +370,30 @@ Region 不可能是孤立的，一个对象分配在某个 Region 中，可以
|
|||
| 收集器 | 串行、并行 or 并发 | 新生代 / 老年代 | 算法 | 目标 | 适用场景 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| **Serial** | 串行 | 新生代 | 复制算法 | 响应速度优先 | 单 CPU 环境下的 Client 模式 |
|
||||
| **Serial Old** | 串行 | 老年代 | 标记 - 整理 | 响应速度优先 | 单 CPU 环境下的 Client 模式、CMS 的后备预案 |
|
||||
| **Serial Old** | 串行 | 老年代 | 标记-整理 | 响应速度优先 | 单 CPU 环境下的 Client 模式、CMS 的后备预案 |
|
||||
| **ParNew** | 并行 | 新生代 | 复制算法 | 响应速度优先 | 多 CPU 环境时在 Server 模式下与 CMS 配合 |
|
||||
| **Parallel Scavenge** | 并行 | 新生代 | 复制算法 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
|
||||
| **Parallel Old** | 并行 | 老年代 | 标记 - 整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
|
||||
| **CMS** | 并发 | 老年代 | 标记 - 清除 | 响应速度优先 | 集中在互联网站或 B/S 系统服务端上的 Java 应用 |
|
||||
| **G1** | 并发 | both | 标记 - 整理 + 复制算法 | 响应速度优先 | 面向服务端应用，将来替换 CMS |
|
||||
| **Parallel Old** | 并行 | 老年代 | 标记-整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
|
||||
| **CMS** | 并发 | 老年代 | 标记-清除 | 响应速度优先 | 集中在互联网站或 B/S 系统服务端上的 Java 应用 |
|
||||
| **G1** | 并发 | both | 标记-整理 + 复制算法 | 响应速度优先 | 面向服务端应用，将来替换 CMS |
|
||||
|
||||
## 4. 内存分配与回收策略
|
||||
|
||||
对象的内存分配，也就是在堆上分配。主要分配在新生代的 Eden 区上，少数情况下也可能直接分配在老年代中。
|
||||
|
||||
### 4.1 优先在 Eden 分配
|
||||
|
||||
大多数情况下，对象在新生代 Eden 区分配，当 Eden 区空间不够时，发起 Minor GC；
|
||||
|
||||
关于 Minor GC 和 Full GC：
|
||||
|
||||
- Minor GC：发生在新生代上，因为新生代对象存活时间很短，因此 Minor GC 会频繁执行，执行的速度一般也会比较快。
|
||||
- Full GC：发生在老年代上，老年代对象和新生代的相反，其存活时间长，因此 Full GC 很少执行，而且执行速度会比 Minor GC 慢很多。
|
||||
|
||||
### 4.2 大对象直接进入老年代
|
||||
|
||||
提供 -XX:PretenureSizeThreshold 参数，大于此值的对象直接在老年代分配，避免在 Eden 区和 Survivor 区之间的大量内存复制；
|
||||
|
||||
### 4.3 长期存活的对象进入老年代
|
||||
|
||||
JVM 为对象定义年龄计数器，经过 Minor GC 依然存活且被 Survivor 区容纳的，移动到 Survivor 区，年龄加 1，每经历一次 Minor GC 不被清理则年龄加 1，增加到一定年龄则移动到老年区（默认 15 岁，通过 -XX:MaxTenuringThreshold 设置）；
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user