JVM垃圾收集时间的问题

Question

jvm

Answer 1

引用计数算法（Reference Counting） 　　最初的想法，也是很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，当有一个地方引用它，计数器加1，当引用失效，计数器减1，任何时刻计数器为0的对象就是不可能再被使用的。 　　客观的说，引用计数算法实现简单，判定效率很高，在大部分情况下它都是一个不错的算法，但引用计数算法无法解决对象循环引用的问题。举个简单的例子：对象A和B分别有字段b、a，令A.b=B和B.a=A，除此之外这2个对象再无任何引用，那实际上这2个对象已经不可能再被访问，但是引用计数算法却无法回收他们。 根搜索算法（GC Roots Tracing） 　　在实际生产的语言中（Java、C#、甚至包括前面提到的Lisp），都是使用根搜索算法判定对象是否存活。算法基本思路就是通过一系列的称为“GC Roots”的点作为起始进行向下搜索，当一个对象到GC Roots没有任何引用链（Reference Chain）相连，则证明此对象是不可用的。在Java语言中，GC Roots包括： 　　1.在VM栈（帧中的本地变量）中的引用 
　　2.方法区中的静态引用 
　　3.JNI（即一般说的Native方法）中的引用 

Answer 2

学习了，objectC就是引用计数器，所以很多地方要自行回收避免溢出。

Answer 3

鱼与熊掌不能兼得
内存越大，JVM内存回收时挂起的时间就越长，还是要看具体需求，设置的旧生代空间要比常用旧生代所需内存大
可以先把内存设置到最大，然后运行系统一段时间，回收垃圾，看内存稳定在哪个值上，再大个1/3我觉得就差不多了
我个人倾向于无中断的垃圾收集，虽然性能有影响，但是不会有停止服务的时间

Answer 4

Parallel Scavenge收集器（下称PS收集器）也是一个多线程收集器，也是使用复制算法，但它的对象分配规则与回收策略都与ParNew收集器有所不同，它是以吞吐量最大化（即GC时间占总运行时间最小）为目标的收集器实现。 
Parallel Scavenge收集器提供了两个参数用于精准控制吞吐量：
a.-XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间，是一个大于0的毫秒数。
b.-XX:GCTimeRatio：直接设置吞吐量大小，是一个大于0小于100的整数，也就是程序运行时间占总时间的比率，默认值是99，即垃圾收集运行最大1%（1/(1+99)）的垃圾收集时间。
Parallel Scavenge是吞吐量优先的垃圾收集器，它还提供一个参数：-XX:+UseAdaptiveSizePolicy，这是个开关参数，打开之后就不需要手动指定新生代大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRation)、新生代晋升年老代对象年龄(-XX:PretenureSizeThreshold)等细节参数，虚拟机会根据当前系统运行情况收集性能监控信息，动态调整这些参数以达到最大吞吐量，这种方式称为GC自适应调节策略，自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。

Answer 5

内存设置问题还是要根据自己系统情况来，分配比例需要自己慢慢调试，观察GC日志找到GC高峰期，同时追踪此时是什么对象占用内存回收不掉。实在不行，就让程序定期自杀重启~~！

Answer 6

jvm虚拟机采取的是比较懒散的方式，当一个对象的引用数目为0的时候，虚拟机的垃圾回收机制也不一定立刻回收的，
一般会跟你的内存有关系的，所以就不要盼望着它会立即回收，感觉新老版本都差不多吧