不诗意的女程序媛不是好厨师~
转载请注明出处，From李诗雨---https://blog.csdn.net/cjm2484836553/article/details/103842357
1.GC（Garbage Collection垃圾回收）
1.1 谁需要GC？
堆：重点！
方法区/元空间：(只需要知道这里 也有垃圾回收 即可)
栈：不需要 。线程私有的，随线程消亡而消亡，不需要过多考虑垃圾回收问题。
1.2 GC 触发的条件：内存不够了
新生代不够了 → Minor GC
老年代不够了 → Full GC
补充：堆的进一步划分
▶新生代（PSYoungGen）
又分为：
•Eden空间
•From Survivor空间
•To Survivor空间
▶老年代（ParOldGen）
2. GC如何判断对象是否存活？
2.1 引用计数算法
引用计数法 即 给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1。当计数器为0时，就认为该对象就是不可能再被使用的。
▶优点：
快、方便、实现简单。
▶缺点：
对象互相引用时很难判断对象是否该回收
2.2 可达性分析 （面试重点）▲▲▲
这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
作为GC Roots的对象包括下面几种：
♦ 1.虚拟机栈（栈帧中的本地变量表）中的对象。（方法中的参数，方法体中的局部变量）
♦ 2.方法区中 类静态属性的对象。 （static)
♦ 3.方法区中 常量的对象。 （final static）
♦ 4.本地方法栈中 JNI（即一般说的Native方法）的对象。
来个栗子： ☛
public class GCRoots {
Object o =new Object(); //o不是GCRoots,方法运行完以后，o可回收。
static Object GCRoot1 =new Object(); //GC Roots---方法区中 类静态属性的对象
final static Object GCRoot2 =new Object();//GCRoots---方法区中 常量的对象
public static void main(String[] args) {
//可达
Object object1 = GCRoot1; //注意：“ = ” 不是赋值，在对象中是引用，传递的是右边对象的地址
Object object2 = object1;
Object object3 = object1;
Object object4 = object3;
}
public void method1(){
//不可达（方法运行完后可回收）
Object object5 = o;//o不是GCRoots
Object object6 = object5;
Object object7 = object5;
}
//本地变量表中引用的对象
public void stack(){
Object ostack =new Object(); //本地变量表的对象
Object object9 = ostack;
//以上object9 在方法没有(运行完)出栈前都是可达的
}
}
我们来画个图理解一下上面的代码：
2.3 再谈引用
无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判断对象是否存活都与引用有关，那么就让我们再次来谈一谈引用。
▶强引用
强引用就是指在程序代码中普遍存在的，类似于“Object obj = new Object() ”这类的就是强引用。
只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象
▶软引用
软引用是用来描述 一些有用但是并非必需 的对象。
用软引用关联的对象，系统将要发生OOM之前，这些对象就会被回收。
联想记忆顺序：只有男人吃软饭一说，没有男人吃弱饭一说，如果女强人排第一，那吃软饭的男人可以排第二，吃弱饭都不是男人了，所以排第三，最后是虚引用。
☛用一个栗子来说明软引用的使用（PS: VM参数配置为 -Xms10m -Xmx10m -XX:+PrintGC）：
public class TestSoftRef {
public static class User{
public int id = 0;
public String name = "";
public User(int id, String name) {
super();
this.id = id;
this.name = name;
}
@Override
public String toString() {
return "User [id=" + id + ", name=" + name + "]";
}
}
public static void main(String[] args) {
User u = new User(1,"郑爽"); //new是强引用
//软引用的使用示例：
SoftReference<User> userSoft = new SoftReference<User>(u);
u = null;//干掉强引用，确保这个实例只有userSoft的软引用
//--- 如果是 SoftReference<User> userSoft = new SoftReference<User>(new User()); 就没法干掉强引用
System.out.println(userSoft.get());
System.gc();//进行一次GC垃圾回收
System.out.println("After gc");
System.out.println(userSoft.get());
//往堆中填充数据，导致OOM
List<byte[]> list = new LinkedList<>();
try {
for(int i=0;i<100;i++) {
System.out.println("*************"+userSoft.get());
list.add(new byte[1024*1024*1]); //1M的对象
}
} catch (Throwable e) {
//抛出了OOM异常时打印软引用对象
System.out.println("Exception*************"+userSoft.get());
}
}
}
看下打印结果：
软引用的使用场景：
例如，一个程序用来处理用户提供的图片。
如果将所有图片读入内存，这样虽然可以很快的打开图片，但内存空间使用巨大，一些使用较少的图片浪费内存空间，需要手动从内存中移除。
如果每次打开图片都从磁盘文件中读取到内存再显示出来，虽然内存占用较少，但一些经常使用的图片每次打开都要访问磁盘，代价巨大。
这个时候就可以用软引用构建缓存。
▶弱引用
一些有用（程度比软引用更低）但是并非必需，用弱引用关联的对象，只能生存到下一次垃圾回收之前，GC发生时，不管内存够不够，都会被回收。
☛ Talk is cheap,show me the code!
public class TestWeakRef {
public static class User{
public int id = 0;
public String name = "";
public User(int id, String name) {
super();
this.id = id;
this.name = name;
}
@Override
public String toString() {
return "User [id=" + id + ", name=" + name + "]";
}
}
public static void main(String[] args) {
User u = new User(1,"小爽");
WeakReference<User> userWeak = new WeakReference<User>(u);
u = null;//干掉强引用，确保这个实例只有userWeak的弱引用
System.out.println(userWeak.get());
System.gc();//进行一次GC垃圾回收
System.out.println("After gc");
System.out.println(userWeak.get());
}
}
打印结果分析：
注意：
软引用 SoftReference和弱引用 WeakReference，可以用在内存资源紧张的情况下以及创建不是很重要的数据缓存。当系统内存不足的时候，缓存中的内容是可以被释放的。
实际运用（WeakHashMap、ThreadLocal）
▶虚引用
幽灵引用，最弱，被垃圾回收的时候收到一个通知
3. 垃圾收集算法
3.1复制算法（Copying）
将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。
▶特点
▪ 实现简单、运行高效
▪ 内存复制、没有内存碎片
▪ 利用率只有一半
▶注意事项：
▪ 新生代 使用该算法
▪ 新生代中3个区的比例8:1:1
▪ 空间担保
对8:1:1比例的说明：
新生代中的对象98%是“朝生夕死”的，所以并不需要按1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor，当回收时将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上,最后清除掉Eden和刚才用过的Survivor空间。
HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%)，只有10%的内存会被浪费。
对空间担保的说明：
当然，98%的对象可回收，只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保(Handle Promotion)。
内存的分配担保就好比我们去银行贷款，如果我们信誉良好，在98%的情况下都能按时偿还，于是银行可能会默认我们下一次也能按时按量的偿还贷款。只需要有一个担保人能保证如果我们不能还款时，可以从他的账户扣钱，那银行就认为没有风险了，内存的分配担保也一样，如果另一块survival空间没有足够空间存放，上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。
3.2标记-清除算法（Mark-Sweep）
算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
它的主要不足空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
▶特点
▪ 利用率百分之百
▪ 不需要内存复制
▪ 有内存碎片
3.3标记-整理算法（Mark-Compact）
首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
▶特点
▪ 利用率百分之百
▪ 没有内存碎片
▪ 需要内存复制
▪ 效率一般般
4.堆内存分配策略
▶对象优先在Eden分配
如果Eden内存空间不足，就会发生Minor GC
▶大对象直接进入老年代
大对象：需要大量连续内存空间的Java对象，比如很长的字符串和大型数组，
大对象对虚拟机的内存分配来说是一个坏消息（∵1、大对象容易导致内存还有不少空间时，就提前触发垃圾收集以获取足够的连续空间来“安置”它们）。
比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”（∵ 2、会进行大量的内存复制）。
虚拟机提供了一个 -XX:PretenureSizeThreshold 参数 ，
大于这个数量直接在老年代分配，缺省为0 ，表示绝不会直接分配在老年代。
▶长期存活的对象将进入老年代
默认15岁，-XX:MaxTenuringThreshold 参数可调整
▶动态对象年龄判定
为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
▶空间分配担保
新生代中有大量的对象存活，survivor空间不够，当出现大量对象在MinorGC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代.只要老年代的连续空间大于新生代对象的总大小或者历次晋升的平均大小，就进行Minor GC，否则FullGC。
所以，新生代一般不会内存溢出，因为有老年代做担保。
