JVM垃圾回收相关问题整理

哪些引用对象可以作为GC ROOT?

JVM垃圾回收的根对象的范围有以下几种：

• 虚拟机栈中的引用对象
• 方法区中的类静态属性引用对象
• 方法区中常量引用的对象（final的常量值）
• 本地方法栈JNI（Java本地接口/Java Native Interface）的引用对象

JVM垃圾回收过程关于堆内存的结构划分？

在JVM中堆空间划分如下图所示

上图中，刻画了Java程序运行时的堆空间,可以简述成如下2条

1.JVM中堆空间可以分成三个大区，新生代、老年代、永久代

2.新生代可以划分为三个区，Eden区，两个幸存区

在JVM运行时，可以通过配置以下参数改变整个JVM堆的配置比例

1.JVM运行时堆的大小

-Xms堆的最小值

-Xmx堆空间的最大值

2.新生代堆空间大小调整

-XX:NewSize新生代的最小值

-XX:MaxNewSize新生代的最大值

-XX:NewRatio设置新生代与老年代在堆空间的大小

-XX:SurvivorRatio新生代中Eden所占区域的大小

3.永久代大小调整

-XX:MaxPermSize

4.其他

 -XX:MaxTenuringThreshold,设置将新生代对象转到老年代时需要经过多少次垃圾回收，但是仍然没有被回收

在上面的配置中，老年代所占空间的大小是由-XX:SurvivorRatio这个参数进行配置的,看完了上面的JVM堆空间分配图，可能会奇怪，为啥新生代空间要划分为三个区Eden及两个Survivor区？有何用意？为什么要这么分？要理解这个问题，就得理解一下JVM的垃圾收集机制（复制算法也叫copy算法),步骤如下:

复制（Copying）算法

将内存平均分成A、B两块，算法过程：

1. 新生对象被分配到A块中未使用的内存当中。当A块的内存用完了， 把A块的存活对象对象复制到B块。
2. 清理A块所有对象。
3. 新生对象被分配的B块中未使用的内存当中。当B块的内存用完了， 把B块的存活对象对象复制到A块。
4. 清理B块所有对象。
5. goto 1。

优点：简单高效。缺点：内存代价高，有效内存为占用内存的一半。

图解说明如下所示:（图中后观是一个循环过程）

对复制算法进一步优化：使用Eden/S0/S1三个分区

平均分成A/B块太浪费内存，采用Eden/S0/S1三个区更合理，空间比例为Eden:S0:S1==8:1:1，有效内存（即可分配新生对象的内存）是总内存的9/10。

算法过程：

1. Eden+S0可分配新生对象；
2. 对Eden+S0进行垃圾收集，存活对象复制到S1。清理Eden+S0。一次新生代GC结束。
3. Eden+S1可分配新生对象；
4. 对Eden+S1进行垃圾收集，存活对象复制到S0。清理Eden+S1。二次新生代GC结束。
5. goto 1。

默认Eden:S0:S1=8:1:1,因此，新生代中可以使用的内存空间大小占用新生代的9/10,那么有人就会问，为什么不直接分成两个区，一个区占9/10,另一个区占1/10，这样做的原因大概有以下几种

1.S0与S1的区间明显较小，有效新生代空间为Eden+S0/S1，因此有效空间就大，增加了内存使用率
2.有利于对象代的计算，当一个对象在S0/S1中达到设置的XX:MaxTenuringThreshold值后，会将其分到老年代中，设想一下，如果没有S0/S1,直接分成两个区，该如何计算对象经过了多少次GC还没被释放,你可能会说，在对象里加一个计数器记录经过的GC次数，或者存在一张映射表记录对象和GC次数的关系，是的，可以，但是这样的话，会扫描整个新生代中的对象,有了S0/S1我们就可以只扫描S0/S1区了

原理

JVM堆内存分为2块：Permanent Space和 Heap Space。

• Permanent 即 持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。
• Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代（Old Generation），New 即 年轻代（Young Generation）。年老代和年轻代的划分对垃圾收集影响比较大。

（1）.年轻代

所有新生成的对象首先都是放在年轻代。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代一般分3个区，1个Eden区，2个Survivor区（from和 to）。

大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当一个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当另一个Survivor区也满了的时候，从前一个Survivor区复制过来的并且此时还存活的对象，将可能被复制到年老代。

2个Survivor区是对称的，没有先后关系，所以同一个Survivor区中可能同时存在从Eden区复制过来对象，和从另一个Survivor区复制过来的对象；而复制到年老区的只有从另一个Survivor区过来的对象。而且，因为需要交换的原因，Survivor区至少有一个是空的。特殊的情况下，根据程序需要，Survivor区是可以配置为多个的（多于2个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

针对年轻代的垃圾回收即Young GC。

（2）.年老代

在年轻代中经历了N次（可配置）垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

针对年老代的垃圾回收即Full GC。

（3）.持久代

用于存放静态类型数据，如Java Class, Method等。持久代对垃圾回收没有显著影响。但是有些应用可能动态生成或调用一些Class，例如Hibernate CGLib等，在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。

OOM会发生在堆内存的哪个区域

当一组对象生成时，内存申请过程如下：

1. JVM会试图为相关Java对象在年轻代的Eden区中初始化一块内存区域。
2. 当Eden区空间足够时，内存申请结束。否则执行下一步。
3. JVM试图释放在Eden区中所有不活跃的对象（Young GC）。释放后若Eden空间仍然不足以放入新对象，JVM则试图将部分Eden区中活跃对象放入Survivor区。
4. Survivor区被用来作为Eden区及年老代的中间交换区域。当年老代空间足够时，Survivor区中存活了一定次数的对象会被移到年老代。
5. 当年老代空间不够时，JVM会在年老代进行完全的垃圾回收（Full GC）。
6. Full GC后，若Survivor区及年老代仍然无法存放从Eden区复制过来的对象，则会导致JVM无法在Eden区为新生成的对象申请内存，即出现“Out of Memory”。

OOM（“Out of Memory”）异常一般主要有如下2种原因：

1. 年老代溢出，表现为：java.lang.OutOfMemoryError:Javaheapspace

这是最常见的情况，产生的原因可能是：设置的内存参数Xmx过小或程序的内存泄露及使用不当问题。

例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序、打印堆内存等方法排查，还可以借助一些内存分析工具，比如MAT就很不错。
2. 持久代溢出，表现为：java.lang.OutOfMemoryError:PermGenspace

通常由于持久代设置过小，动态加载了大量Java类而导致溢出，解决办法唯有将参数 -XX:MaxPermSize调大（一般256m能满足绝大多数应用程序需求）。将部分Java类放到容器共享区（例如Tomcatshare lib）去加载的办法也是一个思路，但前提是容器里部署了多个应用，且这些应用有大量的共享类库。

内存泄漏与内存溢出的区别

1.1内存溢出：（Out Of Memory---OOM）

 系统已经不能再分配出你所需要的空间，比如你需要100M的空间，系统只剩90M了，这就叫内存溢出

1.2内存泄漏：  (Memory Leak)----》强引用所指向的对象不会被回收，可能导致内存泄漏，虚拟机宁愿抛出OOM也不会去回收他指向的对象

意思就是你用资源的时候为他开辟了一段空间，当你用完时忘记释放资源了，这时内存还被占用着，一次没关系，但是内存泄漏次数多了就会导致内存溢出

例子：你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。就相当于你租了个带钥匙的柜子，你存完东西之后把柜子锁上之后，把钥匙丢了或者没有将钥匙还回去，那么结果就是这个柜子将无法供给任何人使用，也无法被垃圾回收器回收，因为找不到他的任何信息。

一般我们所说的内存泄漏指的是堆内存的泄露，堆内存是指程序从堆中分配的，大小随机的用完后必须显示释放的内存，C++/C中有free函数可以释放内存，java中有垃圾回收机制不用程序员自己手动调用释放

如果这块内存不释放，就不能再用了，这就叫这块内存泄漏了

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

2.以发生的方式来分类，内存泄漏可以分为4类： 

• 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。 
•  偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。 
• 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。 
•  隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

3.内存溢出的原因及解决方法：

1. 内存溢出原因： 
   1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据； 
   2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收； 
   3.代码中存在死循环或循环产生过多重复的对象实体； 
   4.使用的第三方软件中的BUG； 
   5.启动参数内存值设定的过小
2. 内存溢出的原因及解决方法：
   1. 修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
   2. 检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。
   3. 对代码进行走查和分析，找出可能发生内存溢出的位置。
   4.  使用内存查看工具动态查看内存使用情况　　

　对代码分析找出可能发生内存溢出的位置， 可能出现的几种情况：

• 检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
• 检查代码中是否有死循环或递归调用。
• 检查是否有大循环重复产生新对象实体。
• 检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

参考博客：

https://www.cnblogs.com/rgever/p/8899758.html

https://blog.csdn.net/samyang1/article/details/80531206