update

Author: daishengda2018

性能优化/1、内存/0.内存管理 — 虚拟内存.md

@@ -41,7 +41,7 @@
 
 <img src="../images/997341ed0fa9018561c7120c19cfa2a7.jpg" alt="img" style="zoom: 33%;" />
 
-在 Linux 系统下使用的是一种名叫 ELF（Execuatable and Linkable File Format） 的文件格式，他的中文名叫做可执行和执行文件格式。
+在 Linux 系统下使用的是一种名叫 ELF（Execuatable and Linkable File Format） 的文件格式，他的中文名叫做可执行和链接文件格式。
 
 
 

性能优化/1、内存/3. 垃圾收集器与内存分配策略.md

@@ -89,15 +89,15 @@ Object object = new Object();
 
 软引用是用来描述一些还有用，但非必须的对象。<font color=red>只存在</font>软引用的对象会在内存不足即将 OOM 之前全部回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在 JDK 1.2版之后提供了`SoftReference`类来实现软引用。
 
-这里要注意，**所有的SoftReference必定会在OOM发生前被回收** 这意味着，GC 在扫描到仅存在软引用的对象时存在回收和不回收两种选择。此时虚拟机没有足够的信息去判断如何抉择。所以只存在弱引用的对象存在一段接近玄学的存活期。这也就是我们在日常开发中不常用软饮用的主要原因：生死边界很模糊。
+这里要注意，**所有的SoftReference必定会在OOM发生前被回收** 这意味着，GC 在扫描到仅存在软引用的对象时存在回收和不回收两种选择。此时虚拟机没有足够的信息去判断如何抉择。所以只存在软引用的对象存在一段接近玄学的存活期。这也就是我们在日常开发中不常用软饮用的主要原因：生死边界很模糊。
 
 ### 弱引用
 
 弱引用是用来描述可有可无的对象，它比软引用要弱一些。<font color=red>只存在</font>弱引用的对象只能存活到下一次 GC。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2版之后提供了`WeakReference`类来实现弱引用。
 
 ### 虚引用
 
-虚引用是最弱的一种存在，一个对象是否存在虚引用不会对其生命周期造成任何影响，通过虚引用也获取不到对象的实例。他的作用仅仅实在对象回收的时候得到一个通知。在JDK 1.2版之后提供了`PhantomReference`类来实现虚引用。
+虚引用是最弱的一种存在，一个对象是否存在虚引用不会对其生命周期造成任何影响，通过虚引用也获取不到对象的实例。==他的作用仅仅实在对象回收的时候得到一个通知==。在JDK 1.2版之后提供了`PhantomReference`类来实现虚引用。
 
 ## Java 多引用类型实验
 
@@ -191,7 +191,7 @@ phantom queue:java.lang.ref.PhantomReference@3764951d
 真正要回收一个对象的内存至少要经历两个过程：
 
 1. GC Roots 到对象不可达时, 对象将会被第一次标记。
-2. 随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。**如果对象没有重写 finalize() 方法或者 finalize() 已经执行过者视为没必要执行。**
+2. 随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。**如果对象没有重写 finalize() 方法或者 finalize() 已经执行过则视为没必要执行。**
 
 
 
@@ -219,7 +219,7 @@ finalize 是对象自我救赎的最后一次机会，稍后收集器会对  F-Q
 
 ```java
 /**
- * 通过 finalize() 方法躲避GC
+ * 通过 finalize() 方法躲避 GC
  * Create by im_dsd 2020/8/3 16:31
  */
 class FinalizeEscapeGC {
@@ -335,7 +335,7 @@ class FinalizeEscapeGC {
 
 ![img](images/640.gif)
 
-在1989年，Andrew Appel 针对具备“朝生夕灭”特点的对象，提出了一种更优化的半区复制分代策略，现在称为“Appel式回收”。他将年轻代的内存划分成了一个较大的 Eden 区域和两个较小的 Survivor 区。每次分配内存时只会同时使用 Eden 和一个 Survivor 区域。每次创建对象的时候优先使用 Eden 区域，在垃圾回收时，将 Eden 与 Survivor 中存活的对象统一复制到另外一个 Survivor 区域中。然后直接清理 Eden 和已经使用过的 Survivor 区域。在 HotSot 中 Eden 与 Survivor 的默认比例为 8 ：1 ：1。即每次新生代中只有 90% 的内存时可用的，另外的 10% 处于空闲状态。
+在1989年，Andrew Appel 针对具备“朝生夕灭”特点的对象，提出了一种更优化的半区复制分代策略，现在称为“Appel式回收”。他将年轻代的内存划分成了一个较大的 Eden 区域和两个较小的 Survivor(涩歪沃儿) 区。每次分配内存时只会同时使用 Eden 和一个 Survivor 区域。每次创建对象的时候优先使用 Eden 区域，在垃圾回收时，将 Eden 与 Survivor 中存活的对象统一复制到另外一个 Survivor 区域中。然后直接清理 Eden 和已经使用过的 Survivor 区域。在 HotSot 中 Eden 与 Survivor 的默认比例为 8 ：1 ：1。即每次新生代中只有 90% 的内存时可用的，另外的 10% 处于空闲状态。
 
 但当存活的对象大于了 10% 的空间即超越了 Survivor 的大小，会怎样呢？对此 Appel 回收设计了一个 ”逃生门“的方式来应对：当此情况发生时，存活的对象直接放到老年代进行担保。