Java内存模型

总的来说就分为两个区域，堆内存(Heap)和非堆内存(No-Heap)，非堆内存又称为永久代(Permanent)，永久的意思其实是针对于垃圾回收器来说的，表示这部分内容不需要回收。在新的JDK8中，这部分的名称已经不叫Permanent了，改成更好理解的Metaspace了。这部分是用来存储JVM工作的相关数据的，比如Load下来的class定义、静态变量、用于调度的方法和线程栈。

为什么要分为这两个区域呢？其实也是为了垃圾回收器用的，堆内存用来存储Java对象实例，因此这部分才需要进行回收。而非堆内存是JVM自己的工作空间，属于JVM实现的一部分，JVM在实现的时候已经自己实现了内存回收。

值得注意的是，在GC日志中，你会发现PSPermGen也在其中：

[GC-- [PSYoungGen: 569856K->569856K(617472K)] 773089K->928306K(976896K), 0.3285123 secs] [Times: user=0.66 sys=0.08, real=0.33secs]

[Full GC [PSYoungGen: 569856K->0K(617472K)] [ParOldGen: 358450K->359349K(499712K)] 928306K->359349K(1117184K) [PSPermGen: 64652K->64650K(131072K)], 1.4693823 secs] [Times: user=4.09 sys=0.02, real=1.47secs]

[Full GC [PSYoungGen: 569856K->0K(617472K)] [ParOldGen: 359349K->488638K(672768K)] 929205K->488638K(1290240K) [PSPermGen: 65041K->65041K(131072K)], 2.4092196 secs] [Times: user=6.75 sys=0.11, real=2.41 secs]

意思是No-Heap(永久代)也需要垃圾回收？

确实是这样的，因为在永久代中还存储着ClassLoader、Class的元信息(Metadata)、指向Heap区域对象的指针以及字符串池(Internal String)。这些数据其实也需要垃圾回收。

这样看来，把内存区域划分为年轻代(Young Gen)、老年代(Old Gen)和永久代(Permanent Gen)其实是有道理的，虽然老年代的数据不会提升到永久代中。但是这三个区域的数据都是需要垃圾回收的。

Heap(堆内存)

堆内存是垃圾回收器工作的地方，堆内存又分为Eden和两个大小一样的Survivor区，即From和To。

最开始的对象都会存储在Eden中(如果有些大对象无法存入到年轻代，则会直接存入老年代)，然后经过Minor GC之后会被提升到Survivor区，然后再提升到老年代。

Stack(栈内存)

Thread Stack 用来存放栈信息，每个线程栈信息里各自有自己的方法栈(包括本地方法栈)，在方法栈的每一帧里存储着方法调用的相关信息，比如参数值、局部变量、返回值等。

Program Counter：记录着当前语句执行到哪儿了。

下图中，其实Stack可以归并到No-Heap中。

垃圾回关注的指标

吞吐量

定义：用户代码执行时间  / ( 用户代码执行时间 + 垃圾回收时间)

越高越好，越高表示执行垃圾回收时间越少。

暂停时间

回收时可能需要暂停用户线程，暂停时间越短越好。

执行频率

单位时间垃圾回收执行的次数。

堆内存大小

比如G1回收器就要去比较大的Heap内存。

敏感度(Promptness)

对象变成垃圾到被回收的时间，时间越短表示回收器越敏感。

垃圾回收类型

串行搜集器(Serial)

年轻代(Young Gen)回收

老年代(Old Gen)回收

来年代的回收很简单，步骤是“标记-清除-压缩”：

串行回收器的使用场景

一般引用于不要求“低暂停”的client模式。这里参考server和client的区别。j2se5的client模式下默认使用串行回收器进行垃圾回收。

使用串行回收器的参数：-XX:+UseSerialGC

并行回收器(Paraller)

并行回收器可以利用多个CPU进行并行的垃圾回收。(在多个CPU场景下，使用Serial回收器时，其实只有一个CPU在工作，其他CPU相当于闲置状态)

并行回收器在年轻地啊和老年代进行垃圾回收的操作是一样的，都是标记、转移、压缩，只是它启用了多个CPU并发执行。串行和并行都需要stop-the-world。

并行回收器的使用场景

应用于多CPU场景下，但是没有太大的暂停时间要求，因为还是有可能会发生长时间的老年代垃圾回收。

适用于批处理、账单、财务、科学计算等场景。

j2se5的server模式下默认使用该回收器。

使用并行回收器的参数：-XX:+UseParallelGC

ParNew

这是一个加强版的Parallel回收器。它可以与下面提到的CMS回收器进行配合。

并行压缩回收器(Parallel Compacting)

年轻代使用并行回收器一样的算法(多CPU并行回收)。(stop-the-world)

-XX:+UseParallelOldGC.

对于老年代，回收过程分为三个阶段

并行标记(Marking)

标记出每个区域的活动数据。标记动作其实是和用户线程一起跑的。

计算总结(Summary)

计算各个区域的稠密程度，得出移动数据的方案。(稀疏的往稠密位置移动，压缩速度肯定比相反方向要快)

压缩(Compaction)

把数据移动到一端，保证另外一端空白。

并行压缩回收器的使用场景

多CPU，它相对于并行回收器感觉没有什么区别(谁知道吗？？？)，因为在官方文档中是这样说的：

使用该回收器的参数：-XX:-UseParallelOldGC

并发标记清理回收器(Concurrent Mark-Sweep (CMS))

低延迟的回收器。

一般而言，年轻代的回收不会有太大的暂停。而老年代的回收不会经常执行，所以老年代的回收暂停时间长一点儿也没事。CMS的回收步骤如下：

年轻代还是使用并发回收器(Parallel)。

对于老年代：

初始标记(init mark)：单线程stop-the-world执行，短暂停，确定出直接和程序关联的活动对象集合。

并发标记(concurrent marking)：根据上一步标记出来的集合，并发找出与集合中元素关联的其他活动对象。这一步的执行是和用户线程并发执行的。

重新标记(remark)：由于用户线程也在运行，所以上一步标记出来的对象还有可能又参数了垃圾，所以这里再次stop-the-world，重新找出活动数据。这一步对现场并发执行。很容易理解，这里的stop-the-world也是非常短的。

清理(sweep)：根据上一步标记结果，清理内存。

从CMS的执行步骤可以看出，它的核心思想其实就是把事情分成多个步骤来做，不要一次把事情做完，且尽量和用户线程一起执行，从而实现对用户线程的低延迟。

CMS回收器使用场景

任何需要低延迟的应用。甚至在单CPU上都运行良好。

使用CMS回收器参数：-XX:+UseConcMarkSweepGC

G1(Gargage First)回收器

G1回收器是用于server模式下，多处理器、大内存的环境。其目标是高吞吐量、高可用性。在JDK7 update4以后的版本中都支持。长期计划中G1是用来代替CMS回收器的。

G1不像其他回收器那样，把内存明确地划分为三个固定大小的区域。而是把heap看成一个整体。

更多细节详见参考连接。

垃圾收集器参数总结

收集器设置：

-XX:+UseSerialGC:年轻串行(Serial)，老年串行(Serial Old)

-XX:+UseParNewGC:年轻并行(ParNew)，老年串行(Serial Old)

-XX:+UseConcMarkSweepGC:年轻并行(ParNew)，老年串行(CMS)，备份(Serial Old)

-XX:+UseParallelGC:年轻并行吞吐(Parallel Scavenge)，老年串行(Serial Old)

-XX:+UseParalledlOldGC:年轻并行吞吐(Parallel Scavenge)，老年并行吞吐(Parallel Old)

收集器参数：

-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

参考：