- 堆结构及对象分代
什么是分代，分代的必要性是什么
Java 虚拟机根据对象存活的周期不同，把堆内存划分为几块，一般分为新生代、老年代和永久代 （对 HotSpot 虚拟机而言），这就是 JVM 的内存分代策略。堆内存是虚拟机管理的内存中最大的一块，也是垃圾回收最频繁的一块区域，我们程序所有的对象实例都存放在堆内存中。给堆内存分代是为了提高对象内存分配和垃圾回收的效率。
试想一下，如果堆内存没有区域划分，所有的新创建的对象和生命周期很长的对象放在一起，随着程序的执行， 堆内存需要频繁进行垃圾收集，而每次回收都要遍历所有的对象，遍历这些对象所花费的时间代价是巨大的，会严重影响我们的 GC 效率。有了内存分代，情况就不同了，新创建的对象会在新生代中分配内存，经过多次回收仍然存活下来的对象存放在老年代中，静态属性、类信息等存放在永久代中，新生代中的对象存活时间短，只需要在新生代区域中频繁进行 GC，老年代中对象生命周期长，内存回收的频率相对较低，不需要频繁进行回收，永久代中回收效果太差，一般不进行垃圾回收，还可以根据不同年代的特点采用合适的垃圾收集算法。分代收集大大提升了收集效率，这些都是内存分代带来的好处。
新生代和老年代是垃圾回收的主要区域
- 新生代（Young Generation ）
新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低，在新生代中，常规应用进行一次垃圾收集一般可以回收 70% ~ 95% 的空间，回收效率很高。
HotSpot 将新生代划分为三块，一块较大的 Eden（伊甸）空间和两块较小的 Survivor（幸存者）空间，默认比例为 8：1：1。划分的目的是因为 HotSpot 采用复制算法来回收新生代，设置这个比例是为了充分利用内存空间，减少浪费。新生成的对象在 Eden 区分配（大对象除外，大对象直接进入老年代），当 Eden 区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。
GC 开始时，对象只会存在于 Eden 区和 From Survivor 区，To Survivor 区是空的（作为保留区域）。GC 进行时，Eden 区中所有存活的对象都会被复制到 To Survivor 区，而在 From Survivor 区中，仍存活的对象会根据它们的年龄值决定去向，年龄值达到年龄阀值（默认为15，新生代中的对象每熬过一轮垃圾回收，年龄值就加 1，GC 分代年龄存储在对象的 header中）的对象会被移到老年代中，没有达到阀值的对象会被复制到 To Survivor 区。接着清空Eden 区和 From Survivor 区，新生代中存活的对象都在 To Survivor 区。
接着， From Survivor区和 To Survivor 区会交换它们的角色，也就是新的 To Survivor 区就是上次 GC 清空的 From Survivor 区，新的 From Survivor 区就是上次 GC 的 To Survivor 区，总之，不管怎样都会保证To Survivor 区在一轮 GC 后是空的。GC 时当 To Survivor 区没有足够的空间存放上一次新生代收集下来的存活对象时，需要依赖老年代进行分配担保，将这些对象存放在老年代中.
- 老年代（Old Generationn ）
在新生代中经历了多次（具体看虚拟机配置的阀值）GC 后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长，存活率比较高，在老年代中进行 GC 的频率相对而言较低，而且回收的速度也比较慢。
- 永久代（Permanent Generationn ）
永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据，对这一区域而言，Java 虚拟机规范指出可以不进行垃圾收集，一般而言不会进行垃圾回收.
- 垃圾收集器的分类
- 次收集器
Scavenge GC，指发生在新生代的 GC，因为新生代的 Java 对象大多都是朝生夕死，所以Scavenge GC 非常频繁，一般回收速度也比较快。当 Eden 空间不足以为对象分配内存时，会触发 Scavenge GC。
一般情况下，当新对象生成，并且在 Eden 申请空间失败时，就会触发 Scavenge GC，对Eden 区域进行 GC，清除非存活对象，并且把尚且存活的对象移动到 Survivor 区。然后整理Survivor 的两个区。这种方式的 GC 是对年轻代的 Eden 区进行，不会影响到年老代。因为大部分对象都是从 Eden 区开始的，同时 Eden 区不会分配的很大，所以 Eden 区的 GC 会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使 Eden 去能尽快空闲出来。当年轻代堆空间紧张时会被触发相对于全收集而言，收集间隔较短。
- 全收集器
Full GC，指发生在老年代的 GC，出现了 Full GC 一般会伴随着至少一次的 Minor GC（老年代的对象大部分是 Scavenge GC 过程中从新生代进入老年代），比如：分配担保失败。FullGC 的速度一般会比 Scavenge GC 慢 10 倍以上。当老年代内存不足或者显式调用 System.gc()方法时，会触发 Full GC。当老年代或者持久代堆空间满了，会触发全收集操作可以使用 System.gc()方法来显式的启动全收集全收集一般根据堆大小的不同，需要的时间不尽相同，但一般会比较长。
- 常见 垃圾回收算法
–引用计数 （Reference Counting)
比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为 0 的对象。此算法最致命的是无法处理循环引用的问题。
– 复制（Copying ）
此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间.
- 标记- 清除（Mark-Sweep ）
此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。
- 标记- 整理（Mark-Compact ）
此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题.
- 分代垃圾 收集
- 串行收集器（Serial ）
Serial 收集器是 Hotspot 运行在 Client 模式下的默认新生代收集器, 它的特点是：只用一个 CPU（计算核心）/一条收集线程去完成 GC 工作, 且在进行垃圾收集时必须暂停其他所有的工作线程(“Stop The World” -后面简称 STW)。可以使用-XX:+UseSerialGC 打开。虽然是单线程收集, 但它却简单而高效, 在 VM 管理内存不大的情况下(收集几十 M~一两百 M 的新生代), 停顿时间完全可以控制在几十毫秒~一百多毫秒内.
- 并行收集器（ParNew)
ParNew 收集器其实是前面 Serial 的多线程版本, 除使用多条线程进行 GC外, 包括 Serial可用的所有控制参数、收集算法、STW、对象分配规则、回收策略等都与 Serial 完全一样(也是 VM 启用 CMS 收集器-XX: +UseConcMarkSweepGC 的默认新生代收集器)。由于存在线程切换的开销, ParNew 在单 CPU 的环境中比不上 Serial, 且在通过超线程技术实现的两个 CPU 的环境中也不能 100%保证能超越 Serial. 但随着可用的 CPU 数量的增加,收集效率肯定也会大大增加(ParNew 收集线程数与 CPU 的数量相同, 因此在 CPU 数量过大的环境中, 可用-XX:ParallelGCThreads=参数控制 GC 线程数)。
- Parallel Scavenge 收集器
与 ParNew 类似, Parallel Scavenge 也是使用复制算法, 也是并行多线程收集器. 但与其他收集器关注尽可能缩短垃圾收集时间不同, Parallel Scavenge 更关注系统吞吐量:系统吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)停顿时间越短就越适用于用户交互的程序-良好的响应速度能提升用户的体验;而高吞吐量则适用于后台运算而不需要太多交互的任务-可以最高效率地利用CPU时间,尽快地完成程序的运算任务. Parallel Scavenge 提供了如下参数设置系统吞吐量:
- Serial Old 收集器
Serial Old 是 Serial 收集器的老年代版本, 同样是单线程收集器,使用“标记-整理”算法
- Parallel Old 收集器
Parallel Old 是 Parallel Scavenge 收集器的老年代版本, 使用多线程和“标记－整理”算法, 吞吐量优先, 主要与 Parallel Scavenge 配合在注重吞吐量及 CPU 资源敏感系统内使用；
- CMS 收集器 （Concurrent Mark Sweep)
CMS(Concurrent Mark Sweep)收集器是一款具有划时代意义的收集器, 一款真正意义上的并发收集器, 虽然现在已经有了理论意义上表现更好的 G1 收集器, 但现在主流互联网企业线上选用的仍是 CMS(如 Taobao、微店).
CMS是一种以获取最短回收停顿时间为目标的收集器(CMS又称多并发低暂停的收集器),
基于”标记-清除”算法实现, 整个 GC 过程分为以下 4 个步骤:
- 初始标记(CMS initial mark)
- 并发标记(CMS concurrent mark: GC Roots Tracing 过程)
- 重新标记(CMS remark)
- 并发清除(CMS concurrent sweep: 已死对象将会就地释放, 注意:此处没有压缩)
其中 1，3 两个步骤(初始标记、重新标记)仍需 STW. 但初始标记仅只标记一下 GC Roots能直接关联到的对象, 速度很快; 而重新标记则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录, 虽然一般比初始标记阶段稍长, 但要远小于并发标记时间.
CMS 特点： - CMS 默认启动的回收线程数=(CPU 数目+3)4
当 CPU 数>4 时, GC线程一般占用不超过 25%的 CPU 资源, 但是当 CPU 数<=4 时, GC线程可能就会过多的占用用户 CPU 资源, 从而导致应用程序变慢, 总吞吐量降低.
2.无法处理浮动垃圾, 可能出现 Promotion Failure、Concurrent Mode Failure 而导致另一次 Full GC 的产生: 浮动垃圾是指在 CMS 并发清理阶段用户线程运行而产生的新垃圾. 由于在 GC 阶段用户线程还需运行, 因此还需要预留足够的内存空间给用户线程使用, 导致 CMS不 能 像 其 他收 集 器那 样 等到 老 年 代几 乎 填满 了 再进 行 收 集. 因此 CMS 提 供 了
-XX:CMSInitiatingOccupancyFraction 参 数 来 设 置 GC 的 触 发 百 分 比 ( 以 及-XX:+UseCMSInitiatingOccupancyOnly 来启用该触发百分比), 当老年代的使用空间超过该比例后 CMS 就会被触发(JDK 1.6 之后默认 92%). 但当 CMS 运行期间预留的内存无法满足程序需要, 就会出现上述 Promotion Failure 等失败, 这时 VM 将启动后备预案: 临时启用 Serial Old
收集器来重新执行Full GC(CMS通常配合大内存使用, 一旦大内存转入串行的Serial GC, 那停顿的时间就是大家都不愿看到的了).
3.最后, 由于 CMS 采用”标记-清除”算法实现, 可能会产生大量内存碎片. 内存碎片过多 可 能 会 导 致 无 法 分 配 大 对 象 而 提 前 触 发 Full GC. 因 此 CMS 提 供 了-XX:+UseCMSCompactAtFullCollection 开关参数, 用于在 Full GC 后再执行一个碎片整理过程.但内存整理是无法并发的, 内存碎片问题虽然没有了, 但停顿时间也因此变长了, 因此 CMS还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction 用于设置在执行 N 次不进行内存整
理的 Full GC 后, 跟着来一次带整理的(默认为 0: 每次进入 Full GC 时都进行碎片整理).
- jstat
jstat -参数 线程 id 执行时间（单位毫秒） 执行次数
jstat -gc 4488 30 10
S0C S1C S0U S1U EC EU
10752.0 10752.0 0.0 0.0 65536.0 18351.3
OC OU PC PU YGC YGCT FGC FGCT GCT
173568.0 0.0 21504.0 2659.6 0 0.000 0 0.000 0.000
SXC - survivor 初始空间大小，单位字节。
SXU - survivor 使用空间大小， 单位字节。
EC - eden 初始空间大小
EU - eden 使用空间大小
OC - old 初始空间大小
OU - old 使用空间大小
PC - permanent 初始空间大小
PU - permanent 使用空间大小
YGC - youngGC 收集次数
YGCT - youngGC 收集使用时长， 单位秒
FGC - fullGC 收集次数
FGCT - fullGC 收集使用时长
GCT - 总计收集使用总时长 YGCT+FGCT
- JVM 常见参数
配置方式：java [options] MainClass [arguments]
options - JVM 启动参数。 配置多个参数的时候，参数之间使用空格分隔。
参数命名： 常见为 -参数名
参数赋值： 常见为 -参数名=参数值 | -参数名:参数值 - 内存设置
-Xms:初始堆大小，JVM 启动的时候，给定堆空间大小。
-Xmx:最大堆大小，JVM 运行过程中，如果初始堆空间不足的时候，最大可以扩展到多
少。
-Xmn：设置年轻代大小。整个堆大小=年轻代大小+年老代大小+持久代大小。持久代一
般固定大小为 64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，
Sun 官方推荐配置为整个堆的 3/8。
-Xss： 设置每个线程的 Java 栈大小。JDK5.0 以后每个线程 Java 栈大小为 1M，以前每
个线程堆栈大小为 256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减
小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限
生成，经验值在 3000~5000 左右。
-XX:NewSize=n:设置年轻代大小
-XX:NewRatio=n:设置年轻代和年老代的比值。如:为 3，表示年轻代与年老代比值为 1：
3，年轻代占整个年轻代+年老代和的 1/4
-XX:SurvivorRatio=n:年轻代中 Eden 区与两个 Survivor 区的比值。注意 Survivor 区有两个。
如：3，表示 Eden：Survivor=3：2，一个 Survivor 区占整个年轻代的 1/5
-XX:MaxPermSize=n:设置持久代大小
-XX:MaxTenuringThreshold：设置垃圾最大年龄。如果设置为 0 的话，则年轻代对象不经
过 Survivor 区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设
置为一个较大值，则年轻代对象会在 Survivor 区进行多次复制，这样可以增加对象再年轻代
的存活时间，增加在年轻代即被回收的概率
JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt 还是 64-bit）限制；
系统的可用虚拟内存限制；系统的可用物理内存限制。32 位系统 下，一般限制在 1.5G~2G；
64 为操作系统对内存无限制。
Tomcat 配置方式： 编写 catalina.bat|catalina.sh ，增加 JAVA_OPTS 参数设置。 windows
和 linux 配置方式不同。 windows - set “JAVA_OPTS=%JAVA_OPTS% 自定义参数 " ； linux -
JAVA_OPTS=”$JAVA_OPTS 自定义参数 "
常见设置：
-Xmx3550m -Xms3550m -Xmn2g -Xss128k 适合开发过程的测试应用。要求物理内存大于
4G。
-Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4
-XX:MaxPermSize=160m -XX:MaxTenuringThreshold=0 适合高并发本地测试使用。且大数据对
象相对较多（如 IO 流）
环境： 16G 物理内存，高并发服务，重量级对象中等（线程池，连接池等），常用对象
比例为 40%（运行过程中产生的对象 40%是生命周期较长的）
-Xmx10G -Xms10G -Xss1M -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:MaxPermSize=2048m
-XX:MaxTenuringThreshold=5
- 收集器设置
收集器配置的时候，次收集器和全收集器必须匹配。具体匹配规则参考 3.1.3
-XX:+UseSerialGC:设置串行收集器，年轻带收集器， 次收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParNewGC:设置年轻代为并行收集。可与 CMS 收集同时使用。JDK5.0 以上，JVM
会根据系统配置自行设置，所以无需再设置此值。
-XX:+UseParallelOldGC:设置并行年老代收集器，JDK6.0 支持对年老代并行收集。
-XX:+UseConcMarkSweepGC:设置年老代并发收集器，测试中配置这个以后，-XX:NewRatio
的配置失效，原因不明。所以，此时年轻代大小最好用-Xmn 设置。
-XX:+UseG1GC:设置 G1 收集器。
- 垃圾回收统计信息
类似日志的配置信息。会有控制台相关信息输出。 商业项目上线的时候，不允许使用。
一定使用 loggc
-XX:+PrintGC
-XX:+Printetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
- 并行收集器设置
-XX:ParallelGCThreads=n:设置并行收集器收集时最大线程数使用的 CPU 数。并行收集线程数。
-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间，单位毫秒。可以减少 STW 时间。
-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为 1/(1+n)并发收集器设置
-XX:+CMSIncrementalMode:设置为增量模式。适用于单 CPU 情况。
-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的 Survivor 区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。
-XX:CMSFullGCsBeforeCompaction=n：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次 GC 以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片
关于收集器的选择 JVM 给了三种选择：串行收集器、并行收集器、并发收集器，但是
串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。
默认情况下，JDK5.0 以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0 以后，JVM 会根据当前系统配置进行判断。
常见配置：
并行收集器主要以到达一定的吞吐量为目标，适用于科学计算和后台处理等。
-Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
使用 ParallelGC 作为并行收集器， GC 线程为 20（CPU 核心数>=20 时），内存问题根据硬件配置具体提供。建议使用物理内存的 80%左右作为 JVM 内存容量。
-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelOldGC
指定老年代收集器，在JDK5.0之后的版本，ParallelGC对应的全收集器就是ParallelOldGC。
可以忽略
-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
指定 GC 时最大暂停时间。单位是毫秒。每次 GC 最长使用 100 毫秒。可以尽可能提高工作线程的执行资源。
-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:+UseAdaptiveSizePolicy
UseAdaptiveSizePolicy 是提高年轻代 GC 效率的配置。次收集器执行效率。
并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域、互联网领域等。
-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
指定年轻代收集器为 ParNew，年老代收集器 ConcurrentMarkSweep，并发 GC 线程数为
20（CPU 核心>=20），并发 GC 的线程数建议使用（CPU 核心数+3）/4 或 CPU 核心数【不推
荐使用】。
-Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC
-XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
CMSFullGCsBeforeCompaction=5 执行 5 次 GC 后，运行一次内存的整理。
UseCMSCompactAtFullCollection 执行老年代内存整理。可以避免内存碎片，提高 GC 过程中的效率，减少停顿时间。
- 获取垃圾收集器的信息
import java.io.IOException;
import java.lang.management.GarbageCollectorMXBean;
import java.lang.management.ManagementFactory;
import java.util.List;
public class Test {
public static void main(String[] args) {
List<GarbageCollectorMXBean> l =
ManagementFactory.getGarbageCollectorMXBeans();
for(GarbageCollectorMXBean b : l) {
System.out.println(b.getName());
}
try {
System.in.read();
} catch (IOException e) {
e.printStackTrace();
}
}
}
扫一扫
1183
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
