深入理解JVM 第三章垃圾收集器与内存分配策略

引用计数算法：为每个对象添加一个引用计数器，每次被引用就加一，这样做需要额外的处理才能解决循环引用等问题

可达性分析算法：以GC Roots为起使点集，如果某个对象不可达则证明此对象不再被引用

 

之前一直搞不明白软和弱的区别

软引用：在系统发生内存溢出之前会对软引用进行回收

弱引用：比软引用更弱一点，被弱引用关联的对象只能存活到下次垃圾回收

虚引用：无法使用虚引用得到对象实例，只能在其对象被回收时收到一个系统通知

 

对象收集：当一个对象被判定GC Roots不可达时会被第一次标记，之后如果对象覆盖了finalize()方法且此方法是第一次执行，就将对象放入F-Queue队列，否则对象被回收。在F-Queue队列中的对象被Finalizer线程执行finalize()，如果在finalize()结束后对象重新引用可达，则会被移除即将回收的集合，之后垃圾收集器会真正开始回收                注：每个对象finalize()只执行一次，也就是说只有一次重新进入引用链的机会。此外finalize()已被弃用，它代价高昂不确定性大，可以用它做的事如果用try-finally或其他方式都可以做的更好

 

分代收集理论：

      弱分代假说：绝代多数对象都是朝生夕灭的

      强分代假说：熬过多次垃圾收集过程的对象就难以消亡

      跨代引用假说：跨代引用只占极少数。推论：存在互相引用关系的两个对象应该倾向于同时生存或同时消亡（如果一个新生代被一个老年代引用，由于老年代难以消亡，就会让新生代慢慢成长为老年代，跨代引用也就消失了）

 

标记-清除算法：长期运行会出现很多内存碎片

标记-复制算法：Survivor空间可能不足以容纳上次新生代存活下来的对象

标记-整理算法：效率较低

对比：复制算法一般用于新生代，基于朝生夕灭的特点每次需要复制的对象不会太多，所以Survivor区不需要太大。清除和整理算法一般用于老年代，通常是多次使用清除算法后发现内存碎片过多再使用整理算法

对比 2：刚开始一直想不明白为什么复制算法效率最高，仔细想之后发现复制算法只需要一趟操作，顺着引用链把每个遇到的对象都复制过去就可以。而清除和整理算法需要两趟，第一趟先标记，第二趟再进行清除或复制

 

根节点枚举：准确式垃圾收集中可以使用OopMap记录全局引用，栈里和寄存器上引用的位置

安全点：如果每个节点都记录OopMap代价会相当高昂，所以只在特定位置设定安全点记录，程序必须运行到安全点才能进行垃圾收集

安全区域：一个变长了的安全点，垃圾收集器不会管在安全区域中的线程

记忆集：当针对新生代进行垃圾回收时会遇到跨代引用的问题，如果因此将整个老年代都加入到搜索中分代回收优势也就不存在了。因此使用一个字节数组来记录老年代的每个区域是否有跨代引用，在扫描时把存在跨代引用的老年代区域加入搜索，这个字节数组就是记忆集

写屏障：可以看作是对“引用类型字段赋值”这个动作的AOP切面。JDK7之前使用的是无条件写屏障，但这样会出现伪共享，即多个线程同时修改一个缓存行内的互相独立的变量时会出现冲突。因此之后的写屏障更改为只当记忆集元素未被标记脏时才改变他。

并发可达性分析：对应书中88页表3-1，会出现对象消失问题。

 

 

这里记录一个问题，Serial收集器的实验时书上说如果Survivor区装不下对象时会通过分配担保提前转移到老年区，网上也是这么讲的。但是如图，在我做的时候from区是满的，按理来说from区放不下2M的数据。我的猜测是新版本Serial收集器把一部分数组放入了from区剩下放不下的部分放入了老年区，但是也没找到相关的解释

应该是我弄混了，新生代的数据是新加入的4M的数组，前三个数据已经移到老年代了

 

另一个问题，-XX:MaxTenuringThreshold=1 设置了没有效果

经过了解以后得知，当Survivor空间中同一年龄的对象大于等于Survivor空间的一半时，年龄大于等于该年龄的对象可以直接进入老年代，在我的实验中虽然创建的对象还不到大小的一半，但是由于这几年JVM越来越复杂，可能自身所需的空间变多导致达到了一半触发了提前进入老年代，当我把第二个数组大小缩小后就可以观察到结果了

经查证好像是低于等于某一年龄的对象和大于TargetSurvivorRatio时会进入老年代  https://blog.csdn.net/u014493323/article/details/82921740