文章目录
每个栈分配多少内存,基本上在类结构确定的时,就已知了
所以栈,本地方法栈和计数器随着方法结束和线程结束而消亡,内存也就回收了
所以这些都是回收和内存分配都是已知的,
需要考虑的时未知的,也就是创建多少对象,存储被虚拟机加载的类信息(如静态变量,方法,字段)之类的,
而这些只有在运行时才知道创建那些对象,
以及存储已被虚拟机加载的类信息,
所以动态调整内存回收,主要在方法区和堆
5种对象引用机制
强引用
1：强引用:类似Object obj=new Object()这类引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象
Object strongReference = new Object();
当内存空间不足时，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
如果强引用对象不使用时，需要弱化从而使GC能够回收，如下：
strongReference = null;
软引用
如果一个对象只具有软引用，则内存空间充足时，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。
通过SoftReference实现
弱引用
弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
通过WeakReference实现
虚引用
也称为幽灵引用或者幻影引用，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，
也无法通过虚引用来取得一个对象实例
为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时受到一个系统通知
jdk1.2之后，提供了PhantomReference类来实现虚引用
netty的ResourceLeakDetector就是基于此类
FinalReference(jvm管理)
Minor GC和Full GC含义
·部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集，其中又分为：
■新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
■老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。目前只有CMS收集器会有单
独收集老年代的行为。
■混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收
集器会有这种行为。
·整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。
垃圾回收算法
引用计数算法
判断对象是否存活常用算法
引用计数算法：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值+1，当引用失效时，计数器值-1.
任何时刻计数器都为0的对象就是不可能在被使用。
效率高，但很难解决对象之间的相互循环引用的问题
根搜索算法
通过一系列名为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链
当一个对象到GC Roots没有任何引用链相连(用图论的话来说就是从GC Roots到这个对象不可达)时，
则证明此对象是不可用的，
java语言中，作为GC Roots的对象包括下面几种
1:虚拟机栈(栈帧中的本地变量表)中的引用的对象
2：方法去中的类静态属性引用的对象
3：方法区中的常量引用的对象
4：本地方法栈中jni(即一般说的native方法)的引用的对象
5所有被同步锁（synchronized关键字）持有的对象。
6:·反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
也就是使用搜索算法,从对象A搜索到GC Roots,如果搜索到,则存活,否则dead
搜索算法
标记二次在清除
一般不采用,采用try-finally关闭对象
任何一个对象只会调用一次finalize,如果对象面临下一次回收,则不会执行
在跟搜索算法中不可达的对象，并非"非死不可"，判断其死亡需要至少经历2次标记
1：没有与GC Roots相连接的引用链，标记一次，并且进行一次筛选。
筛选的条件是此对象是否有必要执行finalize()方法，
对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用过，则虚拟机判定为没有必要执行：、
判定又必要执行后，对象会被放置在一个名为F-Queue的队列中，
并在稍后虚拟机自动创建一条低优先级的Finalizer线程去执行
执行是指虚拟机会触发这个方法，但并不会等待它运行结束
目的避免对象在finalize方法中执行缓慢或者死循环，导致F-Queue队列中的其他对象永久处于等待状态
甚至整个内存回收系统崩溃。
2:GC对F-Queue中的对象进行第二次标记
生存：对象与引用链上任何一个对象建立关联，如把自己赋值给某个类变量或对象的成员变量。
否则死亡
垃圾收集算法
标记-清除算法
算法分为标记和清除2个阶段，首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象
缺点：效率不高，标记和清除过程的效率都不高，
空间问题：标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致，
当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而
不得不提前触发另一次垃圾收集动作
标记-复制算法
解决碎片化问题
将可用内存按容量划分为大小相等的2块，每块只使用其中的一块，当这一块的内存用完了，
就将还存活着的对象复制到另外一块上面，然后在把已使用过的内存空间一次清理掉。
这样使得每次都是对其中一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，
优点，只需要移动堆订指针，按顺序分配内存即可，实现简单，运行高效，
代价：内存缩小到原来的一半。
优化版：将内存分为一块较大的Eden空间和2块较小的Survivor空间，每次使用Eden和其中一块Survivor。
当回收时，将Eden和Survivor中还存活这的对象一次性地拷贝到另外一个Survivor中，最后清理
Eden和刚才用过的Survivor。HotSpot虚拟机默认Eden和Survivor比例为8：1。
当Survivor不够用时，需要依赖其他内存(老年代)进行分配担保
缺点：在对象存活率较高时，需要执行较多的复制操作，效率会很低。其次，如果不想浪费50%空间就需要
额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，在老年代一般不能直接使用此算法
标记-整理算法
与标记-清除算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存
分代收集算法
当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”（Generational Collection）[1]的理论进
行设计，分代收集名为理论，实质是一套符合大多数程序运行实际情况的经验法则，它建立在两个分
代假说之上：
1）弱分代假说（Weak Generational Hypothesis）：绝大多数对象都是朝生夕灭的。
2）强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消
亡。
3）跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极少数。
依据这条假说，我们就不应再为了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录
每一个对象是否存在及存在哪些跨代引用，只需在新生代上建立一个全局的数据结构（该结构被称
为“记忆集”，Remembered Set），这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会
存在跨代引用。此后当发生Minor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GC
Roots进行扫描。虽然这种方法需要在对象改变引用关系（如将自己或者某个属性赋值）时维护记录数
据的正确性，会增加一些运行时的开销，但比起收集时扫描整个老年代来说仍然是划算的。
根据对象的存活周期的不同将内存划分为几块，
java堆分成新生代和老年代，根据各个年代的特点采用最适当的收集算法
在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集
老年代中因为对象存活率高没有额外空间对他进行分配担保，就必须使用标记-清理或标记-整理算法进行回收
垃圾收集器
标记的就是可以相互配合使用的新生代老年代垃圾收集器
Serial收集器
单线程的收集器，进行垃圾收集时，必须暂停其他所有的工作线程。直到他收集结束。
优点：简单高效，没有线程交互的开销，
新生代采用复制算法暂停所有线程，老年代采取标记-整理算法暂停所有用户线程
Serial Old收集器
Serial收集器的老年代版本，单线程，使用标记-整理算法
ParNew收集器
Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余Serial收集器可用的所有控制参数，收集算法,对象分配都一样
多个新生代采取复制算法暂停所有用户线程，老年代同上。
使用-XX:+UseConcMarkSweepGC设置默认新生代收集器
-XX+UseParNewGC强制指定它
-XX:ParallelGCThreads限制垃圾收集的线程数
Parallel Scavenge收集器(吞吐量优先收集器)
新生代收集器，使用复制算法，并行的多线程收集器
作用：达到一个可控制的吞吐量，吞吐量值得是CPU用于运行用户代码的时间与CPU总消耗时间的比值
即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)，
虚拟机总运行了100分钟，垃圾收集花费1分钟，吞吐量就是99%
停顿时间越短就越适合需要与用户交互的程序，提交用户体验
高吞吐量则可以最高效率的利用cpu时间，尽快完成程序的运行任务，适合在后台运算而不需要太多交互的任务
-XX：MaxGCPauseMillis:控制最大垃圾收集停顿时间
允许值大于0的毫秒数，收集器将尽力保证内存回收花费不超过此设定时间值
-XX:GCTimeRatio：设置吞吐量大小
0~100之前，垃圾收集时间占总时间的比率，相当于吞吐量的倒数，
设置为19，则允许最大GC时间就占总时间的1/(1+19),
默认值为99，就是允许最大的1%,1/(1+99)
-XX:+UseAdaptiveSizePolicy：开关参数
开启后不需要手动指定新生代的大小(-Xmn),Eden与Survivor区的比例(-XX:SurvivorRatio)
晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数，虚拟机会动态调整参数，以提供最合适的停顿时间或最大吞吐量
这种调节方式称为GC自适应的调节策略，
只需要设置基本数据即可，如最大堆(0Xmx)，最大停顿时间(MaxGCPauseMillis)，吞吐量(GCTimeRatio)
Parallel Old收集器
是Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法，
适用注重CPU资源，和吞吐连的场合
CMS收集器
以获得最短回收停顿时间为目标的收集器，标记-清除算法
运行过程
1：初始标记(暂停其他进程)：标记GC Roots能直接关联到的对象，速度快
2：并发标记:进行GC Roots Tracing的过程，
3：重新标记(暂停其他进程):修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录
4：并发清除
缺点：1：cpu资源敏感
因为并发线程与CPU有关,当CPU核心很少的时候,还分配CPU资源给垃圾回收,就会造成访问很慢情况
2：无法处理浮动垃圾，-XX:CMSInitiatingOccupancyFraction配置老年化触发百分比
并发清理过程中,依旧产生了其他垃圾,只能留待下次清理,这称之为浮动垃圾,但因此需要预留给浮动垃圾足够的内存
3：产生大量碎片,-XX:UseCmScompactAtFullCollection：碎片整理
-XX:CMSFullGCsBeforeCompaction:设置执行多少次不压缩的FullGC后，压缩
因为基于标记清理,所以会造成碎片化,当存储大对象的时候失败,不得不提前full GC
G1收集器
JDK 9G1取代Parallel Scavenge加Parallel Old组合，成为服务端模式下的默认垃圾收集器，而CMS则沦落至被声明为不推荐使用（Deprecate）的收集器[
标记-整理,精确控制停顿(在垃圾上清理的时间不超过N毫秒)，
不牺牲吞吐量的前提下完成低停顿的内存回收，因为它能够极力避免全区域的垃圾收集。
原理：G1将整个JAVA堆(包括新生代，老年代)划分为多个大小固定的独立区域(Region)，
并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间
G1收集器去跟踪各个Region里面的垃
圾堆积的“价值”大小，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一
个优先级列表，每次根据用户设定允许的收集停顿时间（使用参数-XX：MaxGCPauseMillis指定，默
认值是200毫秒），优先处理回收价值收益最大的那些Region，这也就是“Garbage First”名字的由来。
这种使用Region划分内存空间，以及具有优先级的区域回收方式，保证了G1收集器在有限的时间内获
取尽可能高的收集效率。
Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个
Region容量一半的对象即可判定为大对象。每个Region的大小可以通过参数-XX：G1HeapRegionSize设
定，取值范围为1MB～32MB，且应为2的N次幂。而对于那些超过了整个Region容量的超级大对象，
将会被存放在N个连续的Humongous Region之中，G1的大多数行为都把Humongous Region作为老年代
的一部分来进行看待
回收方法区
回收2部分：废弃常量和无用的类
回收废弃常量与java堆中的对象类似，
如：字符串进入常量池，但是当前系统没有任何一个String对象引用常量池中的abc常量。
常量池中的其他类(接口)，方法，字段的符号引用类似
回收无用的类，要满足以下3条件,才可以被回收
1：该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例
2：加载该类的ClassLoader已经被回收
3：该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
仅仅时可以被回收，具体回收需要看参数配置
HotSpot虚拟机
-Xnoclassgc:是否对类进行回收
-verbose:class
-XX:+TraceClassLoading:查看类的加载信息
-XX:+TraceClassUnloading:查看类的卸载信息(需要fastdebyg版的虚拟机支持)
-verbose:class，-XX:+TraceClassLoading可以在Product版的虚拟机使用
-XX:+TraceClassUnloading需要fastdebyg版的虚拟机支持
建议：在大量使用反射，动态代理，CGLib等bytecode框架的场景，
以及动态生成jsp和OSGi这类频繁自定义的ClassLoader的场景
都需要虚拟机具备类卸载的功能，以保证永久代不会溢出
内存分配与回收策略例子
/*
* 测试新生代
* -XX:+PrintGCDetails -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC
* -Xms20M -Xmx20M:限制堆大小20M
* -Xmn10M ：分配给新生代,剩余的10M分配给老年代
* -XX:SurvivorRatio=8：决定了新生代中的Eden区与Survivor区的空间比例时8：1
* -XX:+UseSerialGC:使用Serial+Serial Old的收集器组合进行内存回收
*
* 自动内存管理
解决2个问题：给对象分配内存，回收分配对象的内存
对象优先在Eden分配，当Eden没有足够的空间进行分配时，虚拟机发起一次Minor GC
GC期间虚拟机将对象全部放入Survivor空间，如果不能放入，则通过分配担保机制提前转移到老年代区。
新生代GC(Minor GC)：指发生在新生代的垃圾收集动作，因为java对象大多具备朝生夕灭的特征，MinorGC非常频繁，回收速度也快
老年代GC(Major GC/Full GC)：指发生在老年代的GC，出现了Major GC经常会伴随至少一次的Minor GC，速度比MinOr GC慢10倍以上
以下运行过程为:堆大小设置20M，分配10M给新生代和老年代，新生代的Eden和Survivor区的比例为8：1，新生代总可用空间为9M
allocation1,2,3存入新生代Eden区域
，当执行到allocation4时，因为可用空间不足，所以执行Minor GC，
发现allocation1,2,3无法放入Survivor空间，
提前allocation1,2,3存入老年代，在在Eden放入allocation4
新生代占用4M
老年代占用6M
*
*/
public class E_TestMinorGC {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) {
byte[] allocation1, allocation2, allocation3, allocation4;
allocation1 = new byte[2 * _1MB];
allocation2 = new byte[2 * _1MB];
allocation3 = new byte[2 * _1MB];
allocation4 = new byte[4 * _1MB];// 出现一次Minor GC
//jdk8,莫名其妙回收对象了,所以这里赋值证明存活看看
allocation1[0]=1;
allocation2[0]=1;
allocation3[0]=1;
allocation4[0]=1;
}
}
设置大对象直接进入老年代
/*
* 大对象直接进入老年代
* -XX:+PrintGCDetails -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=3145728 -XX:+UseSerialGC
*
* 大对象：需要大量连续内存空间的java对象，例如：很长字符串及数组，byte[]
-XX:PretenureSizeThreshold:大于这个设定值的对象直接在老年代中分配，
目的避免在Eden区和2个Survivor区之间发生大量的内存拷贝
[只对Serial和ParNew收集器有效]
*/
public class F_BigObjectMajorGC {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) {
byte[] allocation = new byte[4 * _1MB];//直接分配到老年代
}
}
长期存活对象进入老年代
/*
*
* 动态对象年龄判定以及长期存活的对象将进入老年代
*
* 虚拟机采用分代收集的思想管理内存，
虚拟机给每个对象定义一个对象年龄(Age)计数器，用来识别哪些对象应该放在老年代还是新生代
对象在Eden出生并且经过一次Minor GC后依然存活，并且能被Survivor容纳的话，被移动到此空间，并将对象年龄设为1
对象在Survivor区中每熬过一次Minor GC，年龄增加一岁，当他的年龄达到一定程度(默认15)，晋升到老年代。
*
* -XX:MaxTenuringThreshold:设置晋升老年代的年龄阀值
* -XX:+PrintTenuringDistribution:打印年龄详细信息
*/
public class G_MajorGC {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) {
//testTenuringThreshold();
testTenuringThreshold2();
}
/*动态对象年龄判定
如果在Survivor空间中相同年龄所有对象大小的总和大于Suvivor空间的一半，
年龄大于或者等于该年龄的对象就可以直接进入老年代，无需等待MaxTenuringThreshold中要求的年龄*/
//-XX:+PrintGCDetails -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution
@SuppressWarnings("unused")
private static void testTenuringThreshold2() {
byte[] allocation1, allocation2, allocation3, allocation4;
allocation1 = new byte[_1MB / 4];
allocation2 = new byte[_1MB / 4];
//执行第一次Minor GC
// allocation1+allocation2容量大于Suvivor空间的一半
allocation3 = new byte[4 * _1MB];
allocation4 = new byte[4 * _1MB];
allocation4 = null;
// 执行第二次Minor GC,allocation1进入老年代
allocation4 = new byte[4 * _1MB];
//jdk8,莫名其妙回收对象了,所以这里赋值证明存活看看
allocation1[0]=1;
allocation2[0]=1;
allocation3[0]=1;
allocation4[0]=1;
}
// 长期存活的对象将进入老年代
@SuppressWarnings("unused")
//-XX:+PrintGCDetails -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution
public static void testTenuringThreshold() {
byte[] allocation1, allocation2, allocation3;
// 执行第一次Minor GC
allocation1 = new byte[_1MB / 4];
allocation2 = new byte[4 * _1MB];
allocation3 = new byte[4 * _1MB];
allocation3 = null;
// 执行第二次Minor GC,allocation1进入老年代
allocation3 = new byte[4 * _1MB];
//jdk8,莫名其妙回收对象了,所以这里赋值证明存活看看
allocation1[0]=1;
allocation2[0]=1;
allocation3[0]=1;
}
}
空间分配担保
/*
*空间分配担保
*
* * -XX:+PrintGCDetails -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
* -XX:+UseSerialGC -XX
*
* 由于新生代使用复制算法，当Minor GC时如果存活对象过多，无法完全放入Survivor区，就会向老年代借用内存存放对象，以完成Minor GC
* 在触发Minor GC时，虚拟机会先检测之前晋升到老年代内存的平均大小是否大于老年代的剩余内存，
* 如果大于，则将Minor GC变为一次Full GC，如果小于，则查看虚拟机是否允许担保失败
* （-XX:+/-HandlePromotionFailure。从jdk6.0开始，允许担保失败已变为HotSpot虚拟机所有收集器默认设置，
* 虚拟机将不再识别该参数设置，详见JDK-6990095 : Deprecate and eliminate -XX:-HandlePromotionFailure），
* 如果允许担保失败，则只执行一次Minor GC，否则也要将Minor GC变为一次Full GC
* （直到GC结束时才能确定到底有多少对象需要被移动至老年代，所以在GC前，只能使用粗略的平均值进行判断）
*/
public class H_SpaceAllocationGuarantee {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) {
byte[] allocation1, allocation2, allocation3, allocation4, allocation5, allocation6, allocation7;
allocation1 = new byte[_1MB * 2];
allocation2 = new byte[_1MB * 2];
allocation3 = new byte[_1MB * 2];
allocation1 = null;
allocation4 = new byte[_1MB * 2];
allocation5 = new byte[_1MB * 2];
allocation6 = new byte[_1MB * 2];
allocation4 = null;
allocation5 = null;
allocation6 = null;
allocation7 = new byte[_1MB * 2];
}
}
内存分配执行过程
-XX:+PrintGCDetails -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC
- -Xms20M -Xmx20M:限制堆大小20M
- -Xmn10M ：分配给新生代,剩余的10M分配给老年代
- -XX:SurvivorRatio=8：决定了新生代中的Eden区与Survivor区的空间比例时8：1
- -XX:+UseSerialGC:使用Serial+Serial Old的收集器组合进行内存回收
存储对象时,先存储到Eden+Survivor中,也就是容量9/10*10M,存储容量超过Eden+Survivor,进行一次Minor GC,
将对象存储另外一个Survivor中,如果存储成功对象年龄设为1,对象在Survivor区中每熬过一次Minor GC，年龄增加一岁,当他的年龄达到一定程度(默认15)，晋升到老年代。
无法完全放入Survivor区，就会向老年代借用内存存放对象，以完成Minor GC,在触发Minor GC时，虚拟机会先检测之前晋升到老年代内存的平均大小是否大于老年代的剩余内存，如果大于，则将Minor GC变为一次Full GC，如果小于，则查看虚拟机是否允许担保失败
如果允许担保失败则Minor GC,否则Full GC
1038
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
