gc -jstat

这个文章超牛

GC机制

gc的分类

jvm内存中堆的内容

JVM内存 ≈ Java永久代 ＋ Java堆(新生代和老年代) ＋ 线程栈＋ Java NIO
新生代和老年代才是Java程序真正使用的堆空间，主要用于内存对象的存储

老年代：

1. 大对象或者长期存活的对象进入老年代，典型的大对象就是很长的字符串或者数组，它们在被创建后会直接进入老年代，
2. 原本在新生代中，但是频繁gc后仍然存活的数据进入老年代（一次清理仍存活，则计数器加一，默认值15后进入老年代）

gc的分类

• Minor GC/Young GC
  从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor G
• Major GC 是清理老年代。
• Full GC 是清理整个堆空间—包括年轻代和老年代。
• 

深入理解Java-GC机制

回收算法

如何判断类可以被回收的

（1）引用计数算法（Reference Counting）
给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的，这就是引用计数算法的核心。
但是Java虚拟机并没有采用这个算法来判断何种对象为死亡对象，因为它很难解决对象之间相互循环引用的问题。

（2）可达性分析算法（Reachability Analysis）
这是Java虚拟机采用的判定对象是否存活的算法。通过一系列的称为“GC Roots"的对象作为起始点，从这些结点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

在上图可以看到GC Roots左边的对象都有引用链相关联，所以他们不是死亡对象，而在GCRoots右边有几个零散的对象没有引用链相关联，所以他们就会别Java虚拟机判定为死亡对象而被回收。

目前主流的商用虚拟机用的都是类似的方法。

在java中，GCRoot 是：所有Java线程当前活跃的栈帧里指向GC堆里的对象的引用；换句话说，当前所有正在被调用的方法的引用类型的参数/局部变量/临时值。VM的一些静态数据结构里指向GC堆里的对象的引用，例如说HotSpot VM里的Universe里有很多这样的引用。
  
  有四种对象可以作为“GC Roots”
验证哪些对象可以作为GC Roots

1. java虚拟机栈中的引用的对象。
2. 方法区中的类静态属性引用的对象。 （一般指被static修饰的对象，加载类的时候就加载到内存中。）
3. 方法区中的常量引用的对象(常量:static final)。
4. 本地方法栈中的JNI（native方法）引用的对象

何为死亡对象

对象最后一次自我救赎：finalize()
在根搜索算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”finalize()方法，（所以finalize()如果有就只能被调用一次）。如果方法没有被进行筛选，那么这个方法将被回收。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去执行对象的finalize()方法。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。

这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。

finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己—只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那它就真的离死不远了。从代码清单中我们可以看到一个对象的finalize()被执行，但是它仍然可以存活。

类的回收方法

• 标记-清除算法（Mark-Sweep）

用在老生代中， 先对对象进行标记，然后清除。标记过程就是提到的标记过程。值得注意的是，使用该算法清楚过后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
标记分配空间的算法以及碎片遍历清理

• 标记-复制算法（mark-copy ）

将内存对半分，总是保留一块空着，标记-清除算法（Mark-Sweep）之后，把为标记的对象按顺序压缩到堆的其中一块。避免了内存碎片问题，但是内存浪费很严重，相当于只能使用50%的内存。

• 标记-压缩算法（mark-compact ）-- 老年代
  避免了上述两种算法的缺点，将垃圾对象清理掉后，同时将剩下的存活对象进行整理挪动（类似于windows的磁盘碎片整理），保证它们占用的空间连续，这样就避免了内存碎片问题，但是整理过程也会降低GC的效率。
  如果老年代，最终也放满了，就会发生major GC（即Full GC），由于老年代的的对象通常会比较多，因为标记-清理-整理（压缩）的耗时通常会比较长，会让应用出现卡顿的现象，这也是为什么很多应用要优化，尽量避免或减少Full GC的原因。

• 复制算法（Copying）–新生代

用在新生代中，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活的对象复制到另外一块上，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可。
注：这里其实已经综合运用了“【标记-清理eden】 + 【标记-复制 eden->s0】”算法。

GC产生原因

Full GC产生原因

Full GC产生原因

• System.gc()方法的调用
  在代码中调用System.gc()方法会建议JVM进行Full GC，但是注意这只是建议，JVM执行不执行是另外一回事儿，不过在大多数情况下会增加Full GC的次数，导致系统性能下降，一般建议不要手动进行此方法的调用，可以通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

• 老年代（Tenured Gen）空间不足
  在Survivor区域的对象满足晋升到老年代的条件时，晋升进入老年代的对象大小大于老年代的可用内存，这个时候会触发Full GC。

• Metaspace区内存达到阈值
  从JDK8开始，永久代(PermGen)的概念被废弃掉了，取而代之的是一个称为Metaspace的存储空间。Metaspace使用的是本地内存，而不是堆内存，也就是说在默认情况下Metaspace的大小只与本地内存大小有关。-XX:MetaspaceSize=21810376B（约为20.8MB）超过这个值就会引发Full GC，这个值不是固定的，是会随着JVM的运行进行动态调整的，与此相关的参数还有多个，详细情况请参考这篇文章jdk8 Metaspace 调优

• 统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间
  Survivor区域对象晋升到老年代有两种情况：

1.一种是给每个对象定义一个对象计数器，如果对象在Eden区域出生，并且经过了第一次GC，那么就将他的年龄设置为1，在Survivor区域的对象每熬过一次GC，年龄计数器加一，等到到达默认值15时，就会被移动到老年代中，默认值可以通过-XX:MaxTenuringThreshold来设置。
2.另外一种情况是如果JVM发现Survivor区域中的相同年龄的对象占到所有对象的一半以上时，就会将大于这个年龄的对象移动到老年代，在这批对象在统计后发现可以晋升到老年代，但是发现老年代没有足够的空间来放置这些对象，这就会引起FullGC。

GC触发的原因

堆中产生大对象超过阈值

这个参数可以通过-XX:PretenureSizeThreshold进行设定，大对象或者长期存活的对象进入老年代，典型的大对象就是很长的字符串或者数组，它们在被创建后会直接进入老年代，虽然可能新生代中的Eden区域可以放置这个对象，在要放置的时候JVM如果发现老年代的空间不足时，会触发GC。

老年代连续空间不足

JVM如果判断老年代没有做足够的连续空间来放置大对象，那么就会引起Full GC，例如老年代可用空间大小为200K，但不是连续的，连续内存只要100K，而晋升到老年代的对象大小为120K，由于120＞100的连续空间，所以就会触发Full GC。

• CMS GC时出现promotion failed和concurrent mode failure
  这个原因引发的Full GC可以参考这篇文章，下面也摘抄自这篇文章：JVM 调优 —— GC 长时间停顿问题及解决方法

1.提升失败（promotion failed），在 Minor GC 过程中，Survivor Unused 可能不足以容纳 Eden和另一个 Survivor 中的存活对象， 那么多余的将被移到老年代， 称为过早提升（Premature Promotion）。这会导致老年代中短期存活对象的增长， 可能会引发严重的性能问题。 再进一步， 如果老年代满了， Minor GC 后会进行 FullGC， 这将导致遍历整个堆， 称为提升失败（Promotion Failure）。
2.在 CMS启动过程中，新生代提升速度过快，老年代收集速度赶不上新生代提升速度。在 CMS启动过程中，老年代碎片化严重，无法容纳新生代提升上来的大对象，这是因为CMS采用标记清理，会产生连续空间不足的情况，这也是CMS的缺点 总结

可以发现其实堆内存的Full GC一般都是两个原因引起的，要么是老年代内存过小，要么是老年代连续内存过小。无非是这两点，而元数据区Metaspace引发的Full GC可能是阈值引起的

内存泄漏的分析和避免

分析：

如果对象持有强引用，垃圾回收无法在内存中回收这个对象,从而导致内存溢出

堆内存中存放着对象和数组的实例，在Java中堆内存不会随着方法的结束而清空，所以在方法中定义了局部变量，在方法结束后变量依然存活在堆中。如果我们不停地创建新对象，堆(heap)的内存就会被耗尽。所以Java引入了垃圾回收(garbage collection，简称GC)去处理堆内存，但如果对象一直被引用无法被回收，造成内存的浪费，无法再被使用。所以对象无法被GC回收就是造成内存泄漏的原因。

• 一般内存泄漏(traditional memory leak)：由忘记释放分配的内存导致的。(例如：Cursor忘记关闭等)。
• 逻辑内存泄漏(logical memory leak)：当应用不再需要这个对象，但仍未释放该对象的所有引用。

Android

问题排查实例

• 检测JVM堆的情况
  可以使用JDK的bin目录下的jvisualvm.exe工具来进行实时监测，这个是图形化界面，最为直观，这是一个强大的工具。
  采用jps找到进行id，然后使用jstat -gc pid来实时进行检测。
  运行程序前设置-XX:+PrintGCDetails，-XX:+PrintGCDateStamps参数打印GC的详细信息进行分析。

【 gc空间及占用】

• 解决策略
  如果是发现由于老年代内存过小频繁引起的Full GC，那么可以适当增加老年代的内存大小，如果是发现是由于老年代没有连续空间来让初生代的对象晋升，如果是采用CMS，那么可以设置进行 n 次 CMS 后进行一次压缩式 Full GC，参数如下：

-XX:+UseCMSCompactAtFullCollection：允许在 Full GC 时，启用压缩式 GC

-XX:CMSFullGCBeforeCompaction=n 在进行 n 次，CMS 后，进行一次压缩的 Full GC，用以减少 CMS 产生的碎片。

除此之外，尽量少创建大对象，不要在代码里调用System.gc()，什么时候进行Full GC这种事情还是交给JVM来做。在读取文件后记得释放资源，不要让JVM无法回收垃圾，造成内存泄漏。

排除事例

jstat命令命令格式：
jstat [Options] vmid [interval] [count]
参数说明：
Options，选项，我们一般使用 -gcutil 查看gc情况
vmid，VM的进程号，即当前运行的java进程号
interval，间隔时间，单位为秒或者毫秒
count，打印次数，如果缺省则打印无数次

常见gc问题事例排查步骤：

jstat -gc 12538 5000
即会每5秒一次显示进程号为12538的java进成的GC情况
jstat使用
使用jstat的JVM统计信息

jvisualvm

JVM 与 Linux 的内存关系详解

案例分析

内存分配问题

物理内存中包括各种jvm内存和未使用区

JVM向操作系统申请一整段内存区域（具体大小可以在JVM参数调节）作为Java程序的堆（分为新生代和老年代）；当Java程序申请内存空间，比如执行new操作，JVM将在这段空间中按所需大小分配给Java程序，并且Java程序不负责通知JVM何时可以释放这 个对象的空间，垃圾对象内存空间的回收由JVM进行。
未使用区是分配新内存空间的预备区域。对于普通进程来说，这个区域被可用于堆和栈空间的申请及释放，每次堆内存分配都会使用这个区 域，因此大小变动频繁；对于JVM进程来说，调整堆大小及线程栈时会使用该区域，而堆大小一般较少调整，因此大小相对稳定。操作系统会动态调整未使用区域的大小，并且这个区域通常并没有被分配实际的物理内存，只是允许进程在这个区域申请堆或栈空间。

Linux和Java NIO（PageCache，nio buffer）在内核内存上开辟空间给程序使用，主要是减少不要的复制，以减少IO操作系统调用的开销。例如，将磁盘文件的数据发送网卡，使用普通方法和NIO时，数据流动比较下图所示：

将数据在内核内存和用户内存之间拷贝是比较消耗资源和时间的事情，而从上图我们可以看到，通过NIO的方式减少了2次内核内存和用户内存之间的数据拷贝。这是Java NIO高性能的重要机制之一（另一个是异步非阻塞）。

从上面可以看出，内核内存对于Java程序性能也非常重要，因此，在划分系统内存使用时候，一定要给内核留出一定可用空间。
通过上面的分析，省略比较小的区域，可以总结JVM占用的内存：
JVM内存 ≈ Java永久代 ＋ Java堆(新生代和老年代) ＋ 线程栈＋ Java NIO
新生代和老年代才是Java程序真正使用的堆空间，主要用于内存对象的存储
回到文章开头提出的问题，原来的内存分配是：6g(java堆) ＋ 600m(监控) ＋ 800m(系统)，剩余大约600m内存未分配。

现在分析这600m内存的分配情况：

Linux保留大约200m，这部分是Linux正常运行的需要，
Java服务的线程数量是160个，JVM默认的线程栈大小是1m，因此使用160m内存，
Java NIO buffer，通过JMX查到最多占用了200m，
Java服务使用NIO大量读写文件，需要使用PageCache，正如前面分析，这个暂时不好定量估算大小。
前三项加起来已经560m，因此可以断定Linux物理内存不够使用。

细心的人会发现，引言中给出两个服务器，一个SWAP最多占用了2.16g，另外一个SWAP最多占用了871m；但是，似乎我们的内存缺口没有那么大。事实上，这是由于SWAP和GC同时进行造成的，从下图可以看到，SWAP的使用和长时间的GC在同一时刻发生。

SWAP和GC同时发生会导致GC时间很长，JVM严重卡顿，极端的情况下会导致服务崩溃。原因如下：JVM进行GC时，时需要对相应堆分区的已用 内存进行遍历；假如GC的时候，有堆的一部分内容被交换到SWAP中，遍历到这部分的时候就需要将其交换回内存，同时由于内存空间不足，就需要把内存中堆 的另外一部分换到SWAP中去；于是在遍历堆分区的过程中，(极端情况下)会把整个堆分区轮流往SWAP写一遍。Linux对SWAP的回收是滞后的，我 们就会看到大量SWAP占用。上述问题，可以通过减少堆大小，或者增加物理内存解决。

因此，我们得出一个结论：部署Java服务的Linux系统，在内存分配上，需要避免SWAP的使用；具体如何分配需要综合考虑不同场景下JVM对Java永久代 、Java堆(新生代和老年代)、线程栈、Java NIO所使用内存的需求。

内存泄漏问题

另一个案例是，8g内存的服务器，Linux使用800m，监控进程使用600m，堆大小设置4g；系统可用内存有2.5g左右，但是也发生了大量的SWAP占用。

分析这个问题如下：

在这个场景中， Java永久代 、Java堆(新生代和老年代)、线程栈所用内存基本是固定的，因此，占用内存过多的原因就定位在Java NIO上。
根据前面的模型，Java NIO使用的内存主要分布在Linux内核内存的System区和PageCache区。查看监控的记录，如下图，我们可以看到发生SWAP之前，也就是 物理内存不够使用的时候，PageCache急剧缩小。因此，可以定位在System区的Java NIO Buffer发生内存泄漏。

由于NIO的DirectByteBuffer需要在GC的后期被回收，因此连续申请DirectByteBuffer的程序，通常需要调用 System.gc()，避免长时间不发生FullGC导致引用在old区的DirectByteBuffer内存泄漏。分析到此，可以推断有两种可能的 原因：第一，Java程序没有在必要的时候调用System.gc()；第二，System.gc()被禁用。
最后是要排查JVM启动参数和Java程序的DirectByteBuffer使用情况。在本例中，查看JVM启动参数，发现启用了-XX:+DisableExplicitGC导致System.gc()被禁用。