java学习之路----内存的分析

java内存分析

          在java中，java语言对程序员做了一个美好的承诺，就是程序员无需去管理内存，因为有GC，其实不然;

          

          1.垃圾回收并不会按照程序员的要求，进行垃圾回收

          2.垃圾回收并不会及时的清理内存，即使你需要额外的内存

          3.程序员不能对垃圾回收进行控制

一：内存区域的划分

   1.程序计数器

       每一个java线程都有一个程序计数器来保存程序执行到了那一步，对于非Native方法，这个区域记录就是字节码的指令的地址，如果是Native方法，这个区域就为空， 此内存区是唯一一个在Java规范中没有任何OutOfMemoryError情况的区域。

   2.jvm虚拟机栈

     我们通常粗略的把内存分为两个部分，一个就是栈，一个就是堆。而这里jvm虚拟机栈就是我们常说的栈，它和程序计数器一样，也是线程私有的，随着线程的产生而产生，灭亡而灭亡，声明周期和线程一样。每个方法执行的时候都会产生一个栈帧，用来存储局部变量表，动态链表，操作数，方法出入口等。方法的执行就是栈帧在JVM中出栈和入栈的过程。局部变量表存储的是各种基本数据类型，boolean,int ,char,long.float,double,byte,short，还有对象的引用（不是对象本身，仅仅是一个引用指针），方法返回地址等。 其中 long 和 double 会占用 2 个本地变量空间（ 32bit ），其余占用 1 个。本地变量表在进入方法时进行分配，当进入一个方法时，这个方法需要在帧中分配多大的本地变量是一件完全确定的事情，在方法运行期间不改变本地变量表的大小。这个区域可能会抛出两种异常， 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常；如果 VM 栈可以动态扩展（ VM Spec 中允许固定长度的 VM 栈），当扩展时无法申请到足够内存则抛出 OutOfMemoryError 异常。

  

  3.本地方法栈

      本地方法栈与J VM 栈所发挥作用是类似的，只不过J VM 栈为虚拟机运行J VM 原语服务，而本地方法栈是为虚拟机使用到的 Native 方法服务。它的实现的语言、方式与结构并没有强制规定，甚至有的虚拟机（譬如 Sun Hotspot 虚拟机）直接就把本地方法栈和 VM 栈合二为一。和 VM 栈一样，这个区域也会抛出 StackOverflowError 和 OutOfMemoryError 异常。

  4.堆

      堆内存是内存中最重要的一块，也是最有必要进行深究的一部分。因为Java性能的优化，主要就是针对这部分内存的。所有的对象实例及数组都是在堆上面分配的（随着JIT技术的逐渐成熟，这句话视乎有些绝对，不过至少目前还基本是这样的），可 通过-Xmx和-Xms来控制堆的大小。 JIT技术的发展产生了新的技术，如栈上分配和标量替换，也许在不久的几年里，即时编译会诞生及成熟，那个时候，“所有的对象实例及数组都是在堆上面分配的”这句话就应该稍微改改了。堆内存是垃圾回收的主要区域，所以在下文垃圾回收板块会重点介绍，此处只做概念方面的解释。在32位系统上最大为2G，64位系统上无限制。可通过-Xms和-Xmx控制，-Xms为JVM启动时申请的最小Heap内存，-Xmx为JVM可申请的最大Heap内存。

  5.方法区

      叫“方法区”可能认识它的人还不太多，如果叫永久代（ Permanent Generation ）它的粉丝也许就多了。它还有个别名叫做 Non-Heap （非堆），但是 VM Spec 上则描述方法区为堆的一个逻辑部分（原文： the method area is logically part of the heap ），这个名字的问题还真容易令人产生误解，我们在这里就不纠结了。

方法区中存放了每个 Class 的结构信息，包括常量池、字段描述、方法描述等等。 VM Space 描述中对这个区域的限制非常宽松，除了和 Java 堆一样不需要连续的内存，也可以选择固定大小或者可扩展外，甚至可以选择不实现垃圾收集。相对来说，垃圾收集行为在这个区域是相对比较少发生的，但并不是某些描述那样永久代不会发生 GC （至少对当前主流的商业 JVM 实现来说是如此），这里的 GC 主要是对常量池的回收和对类的卸载，虽然回收的“成绩”一般也比较差强人意，尤其是类卸载，条件相当苛刻。   

二：垃圾回收

    1.我们为什么要进行垃圾的回收？

     因为如果我们不进行垃圾的回收，随着对象的越来越多的创建，内存会越来越小，这样会带来程序性能下降，甚至出现异常

     2.哪些垃圾需要回收

        有三个是不需要进行垃圾回收的：程序计数器、JVM栈、本地方法栈。因为它们的生命周期是和线程同步的，随着线程的销毁，它们占用的内存会自动释放，所以只有方法区和堆需要进行GC。具体到哪些对象的话，简单概况一句话：如果某个对象已经不存在任何引用，那么它可以被回收。通俗解释一下就是说，如果一个对象，已经没有什么作用了，就可以被当废弃物被回收了。

   3.什么时候进行垃圾回收

 

      根据一个经典的引用计数算法，每个对象添加一个引用计数器，每被引用一次，计数器加1，失去引用，计数器减1，当计数器在一段时间内保持为0时，该对象就认为是可以被回收得了。但是，这个算法有明显的缺陷：当两个对象相互引用，但是二者已经没有作用时，按照常规，应该对其进行垃圾回收，但是其相互引用，又不符合垃圾回收的条件，因此无法完美处理这块内存清理，因此Sun的JVM并没有采用引用计数算法来进行垃圾回收。而是采用一个叫：根搜索算法，如下图：

基本思想就是：从一个叫GC Roots的对象开始，向下搜索，如果一个对象不能到达GC Roots对象的时候，说明它已经不再被 引用，即可被进行垃圾回收（此处 暂且这样理解，其实事实还有一些不同，当一个对象不再被引用时，并没有完全“死亡”，如果类重写了finalize()方法，且没有被系统调用过，那么系统会调用一次finalize()方法，以完成最后的工作，在这期间，如果可以将对象重新与任何一个和GC Roots有引用的对象相关联，则该对象可以“重生”，如果不可以，那么就说明彻底可以被回收了），如上图中的Object5、Object6、Object7，虽然它们3个依然可能相互引用，但是总体来说，它们已经没有作用了，这样就解决了引用计数算法无法解决的问题。

4.如何进行垃圾回收

     这里只说算法，不去研究实现

           最基础的搜集算法是“标记－清除算法”（Mark-Sweep），如它的名字一样，算法分层“标记”和“清除”两个阶段，首先标记出所有需要回收的对象，然后回收所有需要回收的对象，整个过程其实前一节讲对象标记判定的时候已经基本介绍完了。说它是最基础的收集算法原因是后续的收集算法都是基于这种思路并优化其缺点得到的。它的主要缺点有两个，一是效率问题，标记和清理两个过程效率都不高，二是空间问题，标记清理之后会产生大量不连续的内存碎片，空间碎片太多可能会导致后续使用中无法找到足够的连续内存而提前触发另一次的垃圾搜集动作。   

为了解决效率问题，一种称为“复制”（Copying）的搜集算法出现，它将可用内存划分为两块，每次只使用其中的一块，当半区内存用完了，仅将还存活的对象复制到另外一块上面，然后就把原来整块内存空间一次过清理掉。这样使得每次内存回收都是对整个半区的回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存就可以了，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。  

现在的商业虚拟机中都是用了这一种收集算法来回收新生代，IBM有专门研究表明新生代中的对象98%是朝生夕死的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的eden空间和2块较少的survivor空间，每次使用eden和其中一块survivor，当回收时将eden和 survivor还存活的对象一次过拷贝到另外一块survivor空间上，然后清理掉eden和用过的survivor。Sun Hotspot虚拟机默认eden和survivor的大小比例是8:1，也就是每次只有10%的内存是“浪费”的。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有10%以内的对象存活，当survivor空间不够用时，需要依赖其他内存（譬如老年代）进行分配担保（Handle Promotion）。   

复制收集算法在对象存活率高的时候，效率有所下降。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保用于应付半区内存中所有对象都 100%存活的极端情况，所以在老年代一般不能直接选用这种算法。因此人们提出另外一种“标记－整理”（Mark-Compact）算法，标记过程仍然一样，但后续步骤不是进行直接清理，而是令所有存活的对象一端移动，然后直接清理掉这端边界以外的内存。   

当前商业虚拟机的垃圾收集都是采用“分代收集”（Generational Collecting）算法，这种算法并没有什么新的思想出现，只是根据对象不同的存活周期将内存划分为几块。一般是把Java堆分作新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法，譬如新生代每次GC都有大批对象死去，只有少量存活，那就选用复制算法只需要付出少量存活对象的复制成本就可以完成收集。   

引用文章： http://blog.csdn.net/zhangerqing/article/details/8214365

                http://hllvm.group.iteye.com/group/wiki/2857-JVM