灵璧哪有做网站的,网站建设服务哪家,兰溪企业网站搭建地址,无锡做网站公司在哪里图片大小 媒体大小自适应在改进测试平台以改进Plumbr GC问题检测器的同时 #xff0c;我最终编写了一个小型测试用例#xff0c;我认为这对于更广泛的读者来说可能很有趣。 我追求的目标是测试JVM在eden#xff0c;survivor和Tenured空间之间如何分割堆方面的自适应性。 测… 图片大小 媒体大小自适应 在改进测试平台以改进Plumbr GC问题检测器的同时 我最终编写了一个小型测试用例我认为这对于更广泛的读者来说可能很有趣。 我追求的目标是测试JVM在edensurvivor和Tenured空间之间如何分割堆方面的自适应性。 测试本身正在成批生成对象。 批次每秒生成一次每个批次的大小为500KB。 这些对象被引用了五秒钟此后将删除引用并且该特定批处理中的对象可以进行垃圾收集。 该测试是使用ParallelGC在Mac OS X上的Oracle Hotspot 7 JVM上运行的具有30MB的可用堆空间。 了解了平台我们可以预期JVM将使用以下堆配置启动 JVM将以Young的10MB和Tenured空间的20MB开头因为没有显式配置JVM将使用12的比率在Young和Tenured的空间之间分配堆。 在我的Mac OS X中在Eden和两个Survivor空间之间进一步分配了10MB的年轻空间分别为8MB和2x1MB。 同样这些是所使用的特定于平台的默认值。 的确当启动测试并使用jstat在后台进行窥视时我们看到以下内容证实了我们的餐后估计 My Precious:gc-pressure me$ jstat -gc 2533 1sS0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
1024.0 1024.0 0.0 0.0 8192.0 5154.4 20480.0 0.0 21504.0 2718.9 0 0.000 0 0.000 0.000
1024.0 1024.0 0.0 0.0 8192.0 5502.1 20480.0 0.0 21504.0 2720.1 0 0.000 0 0.000 0.000
1024.0 1024.0 0.0 0.0 8192.0 6197.5 20480.0 0.0 21504.0 2721.0 0 0.000 0 0.000 0.000
1024.0 1024.0 0.0 0.0 8192.0 6545.2 20480.0 0.0 21504.0 2721.2 0 0.000 0 0.000 0.000
1024.0 1024.0 0.0 0.0 8192.0 7066.8 20480.0 0.0 21504.0 2721.6 0 0.000 0 0.000 0.000
1024.0 1024.0 0.0 0.0 8192.0 7588.3 20480.0 0.0 21504.0 2722.1 0 0.000 0 0.000 0.000 从这里我们还可以对即将发生的情况给出下一组预测 伊甸园中的8MB内存将在16秒内填满–请记住我们每秒生成500KB的对象 在每一刻中我们都有大约2.5MB的活动对象-每秒生成500KB并将对象的引用保持五秒钟这大约等于我们的数量 每当Eden充满时都会触发次要GC这意味着我们应该每16秒左右看到一次次要GC。 在进行次要的GC之后我们将以过早的升级而告终-生存空间只有1MB的大小而2.5MB的实时设置将无法容纳我们的任何1MB生存空间。 因此清理伊甸园的唯一方法是将1.5MB2.5MB-1MB的不适合生存者的活动物体传播到Tenured空间。 查看日志也使我们对这些预测充满信心 My Precious:gc-pressure me$ jstat -gc -t 2575 1s
Time S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT 6.6 1024.0 1024.0 0.0 0.0 8192.0 4117.9 20480.0 0.0 21504.0 2718.4 0 0.000 0 0.000 0.0007.6 1024.0 1024.0 0.0 0.0 8192.0 4639.4 20480.0 0.0 21504.0 2718.7 0 0.000 0 0.000 0.000... cut for brevity ...14.7 1024.0 1024.0 0.0 0.0 8192.0 8192.0 20480.0 0.0 21504.0 2723.6 0 0.000 0 0.000 0.00015.6 1024.0 1024.0 0.0 1008.0 8192.0 963.4 20480.0 1858.7 21504.0 2726.5 1 0.003 0 0.000 0.00316.7 1024.0 1024.0 0.0 1008.0 8192.0 1475.6 20480.0 1858.7 21504.0 2728.4 1 0.003 0 0.000 0.003... cut for brevity ...29.7 1024.0 1024.0 0.0 1008.0 8192.0 8163.4 20480.0 1858.7 21504.0 2732.3 1 0.003 0 0.000 0.00330.7 1024.0 1024.0 1008.0 0.0 8192.0 343.3 20480.0 3541.3 21504.0 2733.0 2 0.005 0 0.000 0.00531.8 1024.0 1024.0 1008.0 0.0 8192.0 952.1 20480.0 3541.3 21504.0 2733.0 2 0.005 0 0.000 0.005... cut for brevity ...45.8 1024.0 1024.0 1008.0 0.0 8192.0 8013.5 20480.0 3541.3 21504.0 2745.5 2 0.005 0 0.000 0.00546.8 1024.0 1024.0 0.0 1024.0 8192.0 413.4 20480.0 5201.9 21504.0 2745.5 3 0.008 0 0.000 0.00847.8 1024.0 1024.0 0.0 1024.0 8192.0 961.3 20480.0 5201.9 21504.0 2745.5 3 0.008 0 0.000 0.008 不是在16秒内而是每隔15秒左右垃圾收集就会启动清理Eden并将约1MB的活动对象传播到其中一个Survivor空间并将剩余空间溢出到Old space。 到目前为止一切都很好。 JVM确实表现出我们所期望的方式。 JVM监视了一段时间之后有趣的部分开始了并开始了解正在发生的事情。 在我们的测试案例中这发生在大约90秒内 My Precious:gc-pressure me$ jstat -gc -t 2575 1s
Time S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT 94.0 1024.0 1024.0 0.0 1024.0 8192.0 8036.8 20480.0 8497.0 21504.0 2748.8 5 0.012 0 0.000 0.01295.0 1024.0 3072.0 1024.0 0.0 4096.0 353.3 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.01496.0 1024.0 3072.0 1024.0 0.0 4096.0 836.6 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.01497.0 1024.0 3072.0 1024.0 0.0 4096.0 1350.0 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.01498.0 1024.0 3072.0 1024.0 0.0 4096.0 1883.5 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.01499.0 1024.0 3072.0 1024.0 0.0 4096.0 2366.8 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.014
100.0 1024.0 3072.0 1024.0 0.0 4096.0 2890.2 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.014
101.0 1024.0 3072.0 1024.0 0.0 4096.0 3383.7 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.014
102.0 1024.0 3072.0 1024.0 0.0 4096.0 3909.7 20480.0 10149.6 21504.0 2748.8 6 0.014 0 0.000 0.014
103.0 3072.0 3072.0 0.0 2720.0 4096.0 323.0 20480.0 10269.6 21504.0 2748.9 7 0.016 0 0.000 0.016 我们在这里看到的是JVM的惊人适应性。 在了解了应用程序的行为之后JVM调整了幸存者空间的大小使其足以容纳所有活动对象。 现在Young空间的新配置为 伊甸园4MB 幸存者空间每个3MB 此后GC频率增加–伊甸园现在减小了50而不是大约16秒现在大约需要8秒左右的时间。 但是好处也显而易见因为幸存者空间现在足够大可以在任何给定时间容纳活动物。 再加上没有对象的生存时间超过一个较小的GC周期记住在任何给定时间只有2.5MB的生存对象这一事实我们不再将对象提升到旧空间。 继续监视JVM我们发现采用后旧空间使用率是恒定的。 没有更多的对象传播到旧的对象但是由于没有触发大型GC因此在进行适配之前设法传播的约10MB垃圾将永远存在于旧的空间中。 如果您确定自己在做什么也可以选择“惊人的适应性”。 在JVM参数中指定-XX-UseAdaptiveSizingPolicy将指示JVM坚持在启动时给定的参数而不是试图超越您。 谨慎使用此选项现代JVM通常非常擅长为您预测合适的配置。 翻译自: https://www.javacodegeeks.com/2014/10/adaptive-heap-sizing.html图片大小 媒体大小自适应
