JVM：内存分配与垃圾回收机制（appending）

Java并不是最早使用动态内存分配和垃圾回收技术的语言！

内存分配需要考虑哪些问题

• 什么时候分配内存
  • 类加载时
  • 产生新常量时
  • 创建对象或者数组时
• 分配哪块内存
  • 类在方法区
  • 运行时常量在方法区或者直接内存
  • 对象和数组通常情况下在堆中，有时也可能会在栈中

垃圾回收（GC）需要考虑哪些问题

• 哪些内存要回收
  • 需要进行GC的内存区域
    • 方法区（GC成效低）：类（条件苛刻）、常量
    • Java堆（GC成效高）：对象、数组
  • 内存可回收的条件
    • 类、常量无用了
    • 对象、数组die了
• 什么时候回收
  • 需要分配内存时，内存‘暂时’不够用了（！！并不是满足回收条件立马回收)
• 怎么回收
  • 依赖于垃圾回收策略

---

垃圾回收

内存可回收条件

1.类
必须同时满足以下三个条件才可以回收，注意是可以回收而不是一定会被回收

• 不存在由该类创建的对象（无后代)
• 该类的类加载器已经不在内存中（无父母）
• 该类的Class对象没有被任何地方引用（自己也是个无用之人）

2.对象
2.1引用计数

• 一个对象有一个引用计数器
• 当有一个地方引用它时，计数器加1；少一个地方引用它时，计数器减1
• 计数器=0，表示它无用了可以被回收
• 问题：容易出现无用对象循环引用而不能被回收的情况

2.2可达性分析

• 从称作GC root的对象开始，向下搜索相关联的对象，形成引用链。
  • GC root
    • 栈帧中，局部变量表中所有引用的对象
    • 方法区中，常量引用的对象
    • 方法区中，静态变量引用的对象
  • 引用
    • reference类型，其值为内存地址
    • 内存不紧张时，无用了的内存GC时不需要立马回收吧，万一一会儿又有用了，可以先存存看，所以要对引用进行分类
    • 引用分类
      
      • 强引用：引用链上的对象，不会被回收
      • 软引用：SoftReference，总内存不够用时可被回收，一般是一些缓存对象
      • 弱引用：WeakRefence，GC时被回收
      • 虚引用：PhantomReference，GC时被回收，该对象被回收时会收到一个系统通知

• 不在任何一条引用链上的对象就认为它无用了，可以被回收
  
• 垃圾也有第二次机会
  

3.数组和常量
类似于对象

垃圾回收算法

1.标记-清除算法
标记出可以被回收的内存空间，然后对所有标记的内存清除数据
优点：简单
缺点：效率低下，易产生内存碎片

2.复制算法
内存一半一半划分：一半使用（存放对象），一半空闲（干干净净什么都不存放）。垃圾回收时，将使用的半区上还活着的对象整齐地复制到空闲的半区上，并将原使用半区当作空闲半区，原空闲半区当作使用半区。
优点：简单高效，不会产生内存碎片
缺点：内存空间利用率低，造成空间资源浪费

内存分三份：正常使用区eden+ survivor1+ survivor2。每次使用区=正常使用区和一个survivor，由于对象大多朝生夕灭，所以GC时存活的对象不会很多。将还活着的对象整齐地复制到另一个未使用地survivor中，原工作空间内全部认为是未使用空间（清空）。新的工作区=正常使用区和存对象的那个survivor。一半内存划分比例为8：1：1。
优点：简单高效，不会产生内存碎片，空间利用率高
缺点：需要内存担保，当存活对象过多时，survivor中放不下，需要有备用空间可存放（存货对象多时，复制算法效率会很低）

3.标记-整理算法
标记出可回收对象，将还活着的对象整齐地放在一起，然后清理掉余下的空间
优点：不会产生内存碎片
缺点：效率不是很高

4.分代收集算法
按照对象生存的周期来对其划分（一般为，新生代+老年代），不同代使用不同的算法回收。新生代往往采用‘复制算法’，老年代一般采用‘标记-清除’或者‘标记-整理’。

垃圾收集器

• 垃圾收集器可以看作是垃圾回收算法的具体实现
• 以下讲的垃圾收集器都是分代收集器

1.新生代垃圾收集器（复制算法）

• serial

  • 单线程
  • stop the world（STW），垃圾回收线程工作时，所有用户线程全部停止工作
  • client模式下默认使用
  • 简单高效
  • 参数
    • -XX :SurvivorRatio
    • -XX:PretenureSizeThreshold

• parnew

  • 多线程，serial的多线程版本， 除了多线程之外与serial无差别
  • stop the world
  • server模式下默认使用
  • 在只有单cpu的情况下它还没有serial效率高，因为多线程会涉及到线程切换
  • 默认垃圾收集线程数与cpu数量一样，也可以通过参数调节
  • 参数
    • -XX:ParallelGCThreads 设置垃圾回收线程数
    • -XX:+UseParNewGC 选择使用parnew收集器

• parallel scavenge

  • 多线程
  • 以最大化吞吐量为目标，吞吐量=用户线程时间/（用户线程时间+垃圾回收线程时间）
  • 对停顿时间关注较少，不适用于交互式的程序，适用于后台不交互的程序
  • 可以自适应调整参数，如新生代大小、Eden survivor占比……
  • ca
    • -XX:MaxGCPauseMillis 设置最大停顿时间，但是并不保证一定能小于这个时间
    • -XX:GCTimeRatio 设置吞吐量（0-100之间），99表示用户线程占99%，垃圾回收线程占1%
    • -XX:+UseAdaptiveSizePolicy 使用自适应策略

2.老年代垃圾收集器

• serial old
  • 单线程
  • stop the world
  • serial的老年代版本
  • client模式下
  • 如果用于server模式下，则是为了配合parallel scavenge使用，或者是在CMS崩溃的时候用
  • 标记-整理算法
• parallel old
  • 多线程
  • parallel scavenge的老年代版本
  • 标记-整理算法
• CMS（concurrent mark sweep）
  • 多线程
  • 标记-清除算法
  • 真正意义上的并发（用户和垃圾线程可并发执行）
  • 以最小化停顿时间为目标
  • 四个阶段
    • 初始标记：STW，时间短，标记与GC root直接关联的对象
    • 并发标记：时间长，进行GC root向下搜索
    • 重新标记：STW，比初始标记时间略长，修改因与用户线程并发而导致标记变动的部分
    • 并发清理：时间长
    • (重置线程：为下次GC做准备)
  • 优点：高并发低停顿
  • 缺点：
    • 对cpu数量敏感
      • 垃圾回收线程至少要占用计算机资源的25%，当有4个cpu时，至少要占用1个cpu
      • 当cpu数量很少时，并发过程中会极大的影响用户线程，导致吞吐量很低，即使采用抢占式的方式多分配给用户线程避免GC线程独占时间太长的方法效果也不是很好，因为这样垃圾回收的时间会变得很长
    • 无法处理浮动垃圾
      • 在并发标记得过程中本来活着的对象死了，这样的垃圾本次GC无法回收，它们为浮动垃圾
      • 由于浮动垃圾的缘故，所以CMS不能等到老年代满之后再回收，需要设置一个保守的老年代使用内存占用值来进行full GC的启动 -XX:CMSInitiatingOccupancyFraction
      • 当老年代增长不是很快时可以适当调高这个比值
      • 这个值过高容易引发并发模式的失败，需要切换使用serial old来拯救，这样会导致停顿时间过长
    • 会产生内存碎片
      • 空间够用却因不连续导致提前进行full GC
      • -XX:+UseCMSCompactAtFullCollection，默认开启，在full GC之前进行一次压缩
      • -XX：CMSFullGCBeforeCompaction 多少次不压缩直接full GC之后，进行一次压缩后full GC

3.G1（老年代和新生代都回收）

内存分配**