目录
一.内存分配
1.1 空间分配（担保机制）
在发生 Minor gc之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立,那么 Minor gc可以确保是安全的。当大量对象在 Minor GC后仍然存活，Survivor区中无法容纳那么多的对象，那么就需要老年代进行空间分配担保，把 Survivor无法容纳的对象提前直接进入老年代；但是如果老年代判断到剩余空间不足(根据以往每一次回收晋升到老年代对象容量的平均值作为经验值)，则进行一次Full GC。
1.2 大对象直接进入老年代
大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。
为什么要这样呢？
为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率（参考1.1）。
1.3 长期存活的对象将进入老年代
既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1，对象在 Survivor 中每熬过一次 MinorGC，年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
1.4 动态对象年龄判定
“Hotspot遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了survivor区的一半时，取这个年龄和MaxTenuringThreshold中更小的一个值，作为新的晋升年龄阈值”。
二 垃圾回收
2.1 垃圾判断算法
引用计数算法（Refesrence Counting）
当对象添加一个引用计数器，当有一个地方以用它，计数器加1，当引用失效，计数器减一，任何时刻计数器为0的对象j就是不可能再被使用。弊端：引用计数器可能无法解决循环引用的问题：例如 A引用B，B引用A。
根搜索算法( Root Tracing)
在实际生产语言中（java，C#等）都使用根搜索算法判断对象是否存活。算法的基本思路就是通过一系列被称作“GC ROOTS “ 的点作为起始进行向下搜索，当一个对象到GC ROOTS 没有任何引用链相连，则证明此对象是不可用的。
其中的GC ROOTS 包括
-
在VM栈中（帧中的本地变量）中的引用
-
方法区中的静态引用
-
JNI（即一般所说的Native方法）中的引用
2.2 垃圾回收期的选择和实现
引用类型
GC要做的是将那些dead对象所占的内存回收掉，hotsopt认为没有引用的对象就是dead。hotspot将引用分成四种，strong，soft，weak，phantom。strong引用是我们最常用到的引用，即默认通过Object o = new Object() 这种方式进行的引用；soft，weak，Phantom这三种都是继承reference。
强引用就是我们经常运用的new：当强引用和对象之间的关联被中断了，就可以被回收了，比如上面的Object o ，只需要令o = null 即可。
soft reference 软引用： 当内存不足，会触发JVM的GC，如果GC后，内存还是不足，就会把软引用的包裹的对象给干掉，也就是只有在内存不足，JVM才会回收该对象。
weak reference 弱引用：弱引用的特点是不管内存是否足够，只要发生GC，都会被回收。
phantom reference 虚引用：通常跟ReferenceQueue结合使用，当发生gc之后，虚引用的对象对加入ReferenceQueue中。
关于四种引用的具体用法可以参考这篇文章：
在 Full GC时会对 Reference类型的引用进行特殊处理 Soft:内存不够时一定会被GC，长期不用也会被GC Weak:一定会被GC Phantom:本来就没引用,当从 jvm 堆中释放时会通知。
2.3 GC时机-线程角度
GC的时机
在分代模型的基础上,GC从时机上分为两种: Scavenge GC和Full GC：
Scavenge GC (Minor GC）：对新生代，触发时机是在新对象生成时，Eden空间满了，理论上Eden区大多数对象会在 Scavenge GC回收，复制算法的执行效率会很高， Scavenge GC时间比较短。
Full GC：对整个JVM进行整理，包括 Young、Old和Perm（永久代，jdk8没有，jdk为元空间），主要的触发时机:1)Old满了2)Perm满了3) system.gc() Full GC的执行效率很低，尽量减少 Full GC
安全点
枚举根节点：当执行系统停顿下来后,并不需要一个不漏地检查完所有执行上下文和全局的引用位置,虚拟机应当是有办法直接得知哪些地方存放着对象引用。在 HotSpot的实现中,是使用一组称为 OopMap的数据结构来达到这个目的的
安全点的部分比较抽象(不是很懂)
安全点在 OopMap的协助下， Hotspot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来:很多指令可能导致引用关系变化，或者说引起 OopMap内容变化的指令非常多，如果为每一条指令都生成对应的 OopMap，那将会要大量的额外空间，这样GC的空间成本将会变得更高实际上, Hotspot并没有为每条指令都生成 OopMap，只是在“特定的位置”记录了这些信息,这些位置称为安全点( Safepoint)，即程序执行时并非在所有地方都能停顿下来开始GC，只有在达到安全点时才能暂停。
Safepoint的选定既不能太少以至于让GC等待时间太长，也不能过于频繁以至于过分增大运行时的负载。所以，安全点的选定基本上是以“是否具有让程序长时间执行的特征”为标准进行选定的，因为每条指令执行的时间非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令オ会产生 Safepoint。
对于 Safepoint，另一个需要考虑的问题是如何在GC发生时让所有线程(这里不包括执行JNI调用的线程)都“跑”到最近的安全点再停顿下来:抢占式中断( Preemptive Suspension)和主动式中断(Voluntary Suspension)。
抢占式中断
抢占式中断:它不需要线程的执行代码主动去配合,在GC发生时,首先把所有线程全部中断,如果有线程中断的地方不在安全点上,就恢复线程,让它“跑”到安全点上。
主动式中断
主动式中断:当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。注意：这个轮询也只是在轮询也只是在指定的地方才进行轮询，标志的地方和安全点是重合的。现在几乎没有虚拟机采用抢占式中断来暂停线程从而响应GC事件。
安全区域
在使用安全点之后，大多数进程都可以在安全的时机进行GC，但是还有一些意外情况，比如某一些线程阻塞之后，或者sleep之后，这时候这些线程并不会区获取CPU的使用权，他们就无法运行到安全点，从而无法进行GC，所以这时候就需要安全区域(SafeRegion)来解决了。
在线程执行到 Safe Region中的代码时，首先标识自己已经进入了 Safe Region，那样,当在这段时间里JVM要发起GC时,就不用管标识自己为 Safe Region状态的线程了。在线程要离开 Safe Region时，它要检査系统是否已经完成了根节点枚举(或者是整个GC过程)，如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开 Safe Region的信号为止。
3.3 一些经典的内存泄漏的原因
1.对象定义位置过大：
比如Foo类中 ids这个对象只是一个临时变量，而把他定义到了Foo的属性中，这样ids这个对象的生命周期会跟随Foo一样一直存在。
class Foo{
private int[] ids;
public void fool(int length){
ids = new int[length];
doSomething(ids);
return;
}
}修改：
class Smart{
public void smart(int length){
int[] ids = new int[length];
doSomething(ids);
return;
}
}这样修改后的ids对象会在smart调用完成后的GC中回收掉，而不会一直跟随类对象一直存在。
2.异常处理资源关闭不当
总结一句话：所有资源的关闭都在finally中实现，否则可能会导致资源关闭失败，从而一直占用内存。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
