Java垃圾回收工作原理

Java垃圾回收工作原理

  (2014-02-14 15:45:30)

转载▼

标签：  java   垃圾回收   gc

分类： 笔试面试题

转自： http://blog.csdn.net/chj97/article/details/6769226

垃圾回收器是如何工作的？我现在就简单的介绍一下

首先要明确几点：

Java是在堆上为对象分配空间的

垃圾回收器只跟内存有关，什么IO啊，网络连接啊，管它P事

当可用内存数量较低时，Sun版本的垃圾回收器才会被激活

在垃圾回收器回收垃圾之前，我们先来了解一下Java分配对象的方式，Java的堆更像一个传送带，每分配一个新对象，它就往前移动一格。这意味着对象存储空间的分配速度相当快。Java的“堆指针”只是简单地移动到尚未分配的领域。也就是说，分配空间的时候，“堆指针”只管依次往前移动而不管后面的对象是否还要被释放掉。如果可用内存耗尽之前程序就退出就再好不过了，这样的话垃圾回收器压根就不会被激活。

但是由于“堆指针”只管依次往前移动，那么你肯定会想，总有一天内存会被耗尽，垃圾回收器就开始释放内存。这里有人肯定会问：怎么判断某个对象该被回收呢？答案就是当堆栈或静态存储区没有对这个对象的引用时，就表示程序（员）对这个对象没有兴趣了，它就应该被回收了。有两种方法来知道这个对象有没有被引用：第一种是遍历堆上的对象找引用；第二种是遍历堆栈或静态存储区的引用找对象。前者的实现叫做“引用计数法”，意思就是当有引用连接至对象时，引用计数加1，当引用离开作用域或被置为null时，引用计数减1，这种方法有个缺陷，如果对象之间存在循环引用，可能会出现“对象应该被回收，但引用计数却不为零”的情况。

Java采用的是后者，在这种方式下，Java虚拟机采用一种“自适应”的垃圾回收技术，如何处理找到的存活对象（也就是说不是垃圾），Java有两种方式：

一种是“停止-复制”：理论上是先暂停程序的运行（所以它不属于后台回收模式），然后将所有存活的对象从当前堆复制到另一个堆，没有被复制的全是垃圾。当对象被复制到新堆上时，它们是一个挨着一个的，所以新堆保持紧凑排列（这也是为什么分配对象的时候“堆指针”只管依次往前移动）。然后就可以按前述方法简单、直接地分配内存了。这将导致大量内存复制行为，内存分配是以较大的“块”为单位的。有了块之后，垃圾回收器就可以不往堆里拷贝对象了，直接就可以往废弃的块里拷贝对象了。

另一种是“标记-清扫”：它的思路同样是从堆栈和静态存储区出发，遍历所有的引用，进而找出所有存活的对象。每当它找到一个存活对象，就会给对象一个标记。这个过程中不会回收任何对象。只有全部标记完成时，没有标记的对象将被释放，不会发生任何复制工作，所以剩下的堆空间是不连续的，然后垃圾回收器重新整理剩余的对象，使它们是连续排列的。

当垃圾回收器第一次启动时，它执行的是“停止-复制”，因为这个时刻内存有太多的垃圾。然后Java虚拟机会进行监视，如果所有对象都很稳定，垃圾回收器的效率降低的话，就切换到“标记-清扫”方式；同样，Java虚拟机会跟踪“标记-清扫”效果，要是堆空间出现很多碎片，就会切换到“停止-复制”方式。这就是所谓的“自适应”技术。

其实仔细想一下，“停止-复制”和“标记-清扫”无非就是：“在大量的垃圾中找干净的东西和在大量干净的东西里找垃圾”。不同的环境用不同的方式，这样做完全是为了提高效率，要知道，无论哪种方式，Java都会先暂停程序的运行，所以，垃圾回收器的效率其实是很低的。Java用效率换回了C++没有的垃圾回收器和运行时的灵活，我认为这是明智的选择（虽然它只跟内存有关），随着硬件的飞速发展，我相信，开发时间要比运行效率重要得多！

========================================

http://yale.iteye.com/blog/1013322

JAVA垃圾回收简介
java中的内存java虚拟机自己去管理的,java的内存分配分为两个部分，一个是数据堆，一个是栈。
 堆是给开发人员用的，是在JVM启动时创建，程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系，在堆中分配的内存由java虚拟机的自动垃圾回收器来管理，堆内存用来存放由new创建的对象和数组。

 

 栈是留给JVM自己用的，用来存放类的信息的，它和堆不同，运行期内GC不会释放空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间：
1、如果程序声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。
2、在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配

 

java中有垃圾回收机制：System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。
如果你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。

堆的优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的。缺点就是要在运行时动态分配内存，存取速度较慢。
栈的优势是存取速度比堆要快，缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。

JAVA垃圾回收原理
　　在Java虚拟机规范中，提及了如下几种类型的内存空间：
      栈内存（Stack）：每个线程私有的。
      堆内存（Heap）：所有线程公用的。
      方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。
      原生方法栈（Native Method Stack）：主要用于JNI中的原生代码，平时很少涉及。
　　而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存（Heap）有关。
　　垃圾回收的概念就是JAVA虚拟机（JVM）回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”,而没有被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于应用运行当中，自动回收。

JVM的垃圾回收器采用的是一种分代（generational ）回收策略，共分为三个代：
1.Young（年轻代） 
年 轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区 （两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一 个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关 系，所以同一个区中可能同时存在从Eden复制过来 对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。
2.Tenured（年老代） 
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。 
3.Perm（持久代） 
用 于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等， 在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

 

虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。 当进行 minor GC的时候，VM会把剩下的没有释放的对象从Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured generation 被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象，old generation的大小等于Xmx减去-Xmn(Xmx、-Xmn下面有介绍)

 

GC类型 
GC有两种类型：Scavenge GC和Full GC。 
Scavenge GC 
一般情况下，当新对象生成，并且在Eden申请空间失败时，就好触发Scavenge GC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。 
Full GC 
对整个堆进行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此应该尽可能减少Full GC。有如下原因可能导致Full GC： 
Tenured被写满 
Perm域被写满 
System.gc()被显示调用 
上一次GC之后Heap的各域分配策略动态变化 
用较高的频率对年轻的对象(young generation)进行扫描和回收，而对老对象(old generation)的检查回收频率要低很多。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。
一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。
另外一些对象被创建是拥有很长的生命周期，比如 高持久化对象等。

各代内存回收规则
　　Eden Space (heap)： 内存最初从这个线程池分配给大部分对象。
　　Survivor Space (heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。
　　Tenured Generation (heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。
　　Permanent Generation (non-heap): 保存虚拟机自己的静态(refective)数据，例如类（class）和（method）对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的。
　　Code Cache (non-heap):HotSpot Java虚拟机包括一个用于编译和保存本地代码（native code）的内存，叫做“代码缓存区”（code cache）

JVM如何设置虚拟内存
     提示：在JVM中如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。
     提示：Heap Size 最大不要超过可用物理内存的80%，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
     提示：JVM初始分配的内存由-Xms指定，默认是物理内存的1/64;JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。
     默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制;空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC

后调整堆的大小。
     提示：假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。
     简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，
     这个限制一般是2GB-3GB(一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G)，而64bit以上的处理器就不会有限制了
     提示：注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
     提示：设置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old区如果不够大会频繁的触发 Full GC ，大大降低了性能
     JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64;
     由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
     解决方法：手动设置Heap size
      set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

内存溢出产生
  1、java.lang.OutOfMemoryError: PermGen space
    如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者服务器热部署时侯不会清理前面

加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
     PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中

，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen

space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
     配置方式参见JVM如何设置虚拟内存
    

 2、java.lang.OutOfMemoryError: Javaheap space
     JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：
     当应用程序线程空闲;另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。因为这个异常根据系统运行环境决

定，所以无法预期它何时出现。
     根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。
     为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，
     一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。
     配置方式参见JVM如何设置虚拟内存

堆大小设置 
JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统 下，一般限制在1.5G~2G；64

为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。 
设置内容：
1.-Xms:初始堆大小 
2.-Xmx:最大堆大小 
3.-XX:NewSize=n:设置年轻代大小 
4.-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4 
5.-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5 
6.-XX:MaxPermSize=n:设置持久代大小 
典型设置： 
1.java -Xmx3550m -Xms3550m -Xmn2g -Xss128k 
-Xmx3550m：设置JVM最大可用内存为3550M。 
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。 
-Xss128k： 设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内 存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

2.java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0 
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5 
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6 
-XX:MaxPermSize=16m:设置持久代大小为16m。 
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

调优总结 
年轻代大小选择 
1.响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。 
2.吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。 
年老代大小选择 
1.响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率

以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得： 
1.并发垃圾收集信息 
2.持久代并发收集次数 
3.传统GC信息 
4.花在年轻代和年老代回收上的时间比例 
减少年轻代和年老代花费的时间，一般会提高应用的效率 
2.吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存

活对象。 
较小堆引起的碎片问题 
因 为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间 较小时，运行

一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出 现“碎片”，可能需要进行如

下配置： 
1.-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。 
2.-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩 
性能检测工具使用
  利用JDK自带的JControl(图形化监测工具)、JMap(类似于win操作系统中的任务管理器的结果),可以看出哪些个对象实例化次数、以及内存使用情况来进行调优。

通过代码来提高效率,不健壮代码的特征及解决办法
     1、尽早释放无用对象的引用。好的办法是使用临时变量的时候，让引用变量在退出活动域后，自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。
     对于仍然有指针指向的实例，jvm就不会回收该资源,因为垃圾回收会将值为null的对象作为垃圾，提高GC回收机制效率;
     2、我们的程序里不可避免大量使用字符串处理，避免使用String，应大量使用StringBuffer，每一个String对象都得独立占用内存一块区域;
     String str = "aaa";
     String str2 = "bbb";
     String str3 = str + str2;//假如执行此次之后str ,str2以后再不被调用,那它就会被放在内存中等待Java的gc去回收,程序内过多的出现这样的情况就会报上面的那个错误,建

议在使用字符串时能使用StringBuffer就不要用String,这样可以省不少开销;
     3、尽量少用静态变量，因为静态变量是全局的，GC不会回收的;
     4、避免集中创建对象尤其是大对象，JVM会突然需要大量内存，这时必然会触发GC优化系统内存环境;显示的声明数组空间，而且申请数量还极大。
     5、尽量运用对象池技术以提高系统性能;生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大**对象拥有大数据量的业务对象的时候，可以考虑分块进行处理

，然后解决一块释放一块的策略。
     6、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用hashtable，vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之

后又丢弃
     7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成 Out Of Memory Error 的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最

大的内存空间值。

调优总结 
年轻代大小选择 
1.响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。

请教：为什么说年轻代越大，响应时间越长？  是说，年轻代越大，gc越耗时？导致响应降低？这个应该是某个很短时间段内的吧