[Reading] Asking while Reading

           Asking while Reading

          ——读Java垃圾收集器与内存分配策略java

         Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的“高墙”,墙外面的人想进去,墙里面的人却想出来。python

为何要了解垃圾回收?

  当须要排查各类内存溢出、内存泄漏问题的时候,当垃圾回收成为了系统达到更高并行量的瓶颈的时候,咱们就须要根据状况(每每是根据硬件和程序算法

以及它们在各类垃圾回收算法下运行的状况)选择恰当的垃圾回收方式,做出必要的监控和调节。数组

哪些内存须要回收?

         换一句话来讲:哪些内存能够回收,哪些内存又值得回收;能够回收明确咱们的执行范围,而回收价值明确咱们的主要目标,固然这不是必定的,服务器

对每一个项目均可能有不一样的着眼点,这也是咱们要理解垃圾回收方法与过程的缘由。多线程

Java堆和方法区与栈不一样,一个接口中的多个实现类须要的内存可能不同,一个方法中的多个分支须要的内存也可能不同,咱们只有在程序处于运性能

行期间时才能知道会建立哪些对象,这部份内存的分配和回收都是动态的,垃圾回收器关注的是这部份内存。spa

           方法区也须要回收吗?线程

         方法区能够不回收,由于Java虚拟机规范中说过不要求虚拟机在方法区中实现垃圾收集,更重要的缘由是其性价比通常较低,缘由以下:对象

         咱们知道对方法区的收集集中在对常量、无用的类的收集。

  1)  效率:常规一次垃圾收集能够回收70%~95%的空间,而根据我以往的经验,通常状况下,常量的占用空间之小和方法的调用区域之普遍让放置永

    生代的方法区的效率远低于此。

  2)  条件:虽然断定一个常量是否废弃比较简单,但Java的反射思想让类的废弃断定格外苛刻:

    a)         该类全部的实例都被回收

    b)         加载该类的ClassLoader已经被回收

    c)         该类对应的java.lang.Class对象没有在任何地方被引用,没法在任何地方经过反射访问该类的方法。

    那回收方法区还有意义吗?

    并不是存在即有意义,固然它也有本身的运用场合:尤为在WEB或用到控制反转思惟的应用中大量使用反射、动态生成JSP这类频繁自定义ClassLoader的

  场景都须要虚拟机具有类卸载的功能,以保证永生代不会溢出。

如何判断是否能够回收?

         咱们已然明确了哪些内存能够回收,可是在一个时间点具体地如何去回收呢?虽然在python中采用了引用计数算法,可是我得很遗憾地告诉你,这

 样作并不可靠,而且更关键地是Java并无采用这一算法。

        在堆里存放着Java世界里几乎全部的对象实例,垃圾收集器在对堆进行回收前,第一件事情就是要肯定这些对象之中哪些还存活着。

         引用计数算法

           方法:给对象添加一个引用计数器,每当有一个地方引用它,计数值加一;当引用失效时,计数值减一。所以,当对象的计数值为0时就能够被清除

  掉了。

           缺陷:(致命)若是两个对象互相引用,而后咱们又丢掉了对这两个对象的引用,那么引用计数算法就没法通知GC收集器回收它们的空间。

       可达性分析算法

           根据图论中可达性的思想以一些静态地点(如虚拟机栈、方法区中类静态属性、方法区中常量)引用的对象为起始点,从这些节点开始向下搜索,那

  些不可达的对象就是可回收的对象。

如何回收?

         实际上,这一部分并不会给出最好的算法,在IT行业也是这样,只有更适合问题的方法,没有适合全部问题的方案。

         标记清除算法(最基础)

           过程:      标记:标记全部须要回收的对象。(在前面已经讲述)

                              清除:在标记完成后统一回收全部被标记的对象。

           缺点:      1)效率:标记和清除两个过程的效率都不高

          2)  空间:操做完成后会产生大量内存碎片

  复制算法(解决效率问题)(新生代)

    过程:     将内存分为三块,一块较大的Eden空间和两块较小的Survivor空间。当回收时,将Eden和Survivor中存活的对象一次性复制到另外一块Survivor空间

      里,最后清理掉Eden和Survivor中的数据。

      优势:     由于大多数新生代存活时间都比较短,付出少许的内存空间(通常是8:1:1)就能够达到很好的效果(根据IBM一项调查显示,新生代的对象98%

      都是“朝生夕死”)。

    缺点:     在Survivor区域不够时,就要依赖其余区域(老生代)进行分配担保,实在不行只得进行全内存的垃圾回收。因此这不适用于一些新生代很大、

      生存周期又较长的状况。

  标记-整理算法(新生代)

    过程:     标记过程仍和“标记-清除”算法同样,但以后是让全部存活的对象都向一端移动,而后直接清理掉端边界之外的内存。

    优势:     1)不须要额外的空间闲置不用。(或称为分配担保)

        2)  有效地解决了复制算法中当对象存活周期长的缺点

    缺点:     也正如它所要解决的问题,它不能解决老生代成片地存活周期长的问题,由于正如数组的移动,低效随之而来。

  分代收集算法

    当前虚拟机都采用“分代收集”的思想,说其为思想,由于我想其中并无什么新的内容,只不过是继承前面的思想,面对不一样问题选用不一样的手段罢了。

    在新生代中,只有少许的对象存活,那就采用复制算法,只须要付出少许存活对象的复制成本就能够完成收集。

    在老生代中,由于对象存活率高、没有额外空间对它进行担保,那就必须采用“标记-清理”或者“标记-整理”的算法进行回收。

 

         现在编译器中采用的垃圾收集器:

                   新生代:Serial、ParNew、Parallel Seavenge

                   老生代:CMS、Parallel Old、Serial Old

                   以及较为综合的G1收集器都是创建在以上思想的基础之上,其中的区别也每每是是否面向多线程?是否着重考虑单次收集时间(增长次数减小

  间断)仍是着重考虑CPU占用时间(增长每次间断时间而减小间断次数),这也是与客户体验和服务器处理性能相关的。咱们须要作的只是针对特定状况设

  定合适的参数而已了。有了以上的基础知识,我相信能在处理垃圾收集问题时候会有一个清晰的方向。