Asking while Reading

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

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

为什么要了解垃圾回收？

　　当需要排查各种内存溢出、内存泄漏问题的时候，当垃圾回收成为了系统达到更高并行量的瓶颈的时候，我们就需要根据情况（往往是根据硬件和程序

以及它们在各种垃圾回收算法下运行的情况）选择恰当的垃圾回收方式，作出必要的监控和调节。

哪些内存需要回收？

         换一句话来说：哪些内存可以回收，哪些内存又值得回收；可以回收明确我们的执行范围，而回收价值明确我们的主要目标，当然这不是一定的，

对每个项目都可能有不同的着眼点，这也是我们要理解垃圾回收方法与过程的原因。

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

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

         　　方法区也需要回收吗？

         方法区可以不回收，因为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占用时间（增加每次间断时间而减少间断次数），这也是与客户体验和服务器处理性能相关的。我们需要做的只是针对特定情况设

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