我在用
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
与G1垃圾收集器.JVM的论点是
-server -Xss4096k -XX:MaxPermSize=512m -XX:PermSize=512m -Xms30G
-Xmx30G -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods
-XX:ReservedCodeCacheSize=48m -XX:+UseStringCache
-XX:+UseGCOverheadLimit -Duser.timezone=EET
-Xmaxf1 -XX:+UseCompressedOops -XX:+DisableExplicitGC
-XX:+AggressiveOpts -XX:CMSInitiatingOccupancyFraction=70
-XX:+ParallelRefProcEnabled -XX:+UseAdaptiveSizePolicy
-XX:MaxGCPauseMillis=500 -XX:+UseG1GC
-XX:InitiatingHeapOccupancyPercent=0
-XX:GCPauseIntervalMillis=10000 -XX:+PrintGCDetails
-XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -Xloggc:gc.log
但是,我正在经历完全GC扫描,没有任何明显的原因,如何摆脱它们？
GC日志与之前事件的尾部:
{Heap before GC invocations=206 (full 8):
garbage-first heap total 31457280K, used 18323299K [0x00007fc6eb800000, 0x00007fce6b800000, 0x00007fce6b800000)
region size 8192K, 768 young (6291456K), 31 survivors (253952K)
compacting perm gen total 524288K, used …是否可以从gc透视图标记不可收集的java对象以节省gc-sweep时间？
有关http://wwwasd.web.cern.ch/wwwasd/lhc++/Objectivity/V5.2/Java/guide/jgdStorage.fm.html的内容,特别是非垃圾收集容器(非垃圾 -收藏？).
问题是我有很多普通的临时对象,但我有更大的(几个Gigs)对象存储用于缓存目的.Java GC无缘无故地遍历所有那些试图找到要收集的内容的Cache千兆字节,因为它们包含具有自己超时的缓存数据.
通过这种方式,我可以将自定义方式的数据划分为无限期和正常生存的对象,并且希望GC非常快,因为普通对象不能存活这么长时间并且数量较少.
这个问题有一些解决方法,例如Apache DirectMemory和Commercial Terracotta BigMemory(http://terracotta.org/products/bigmemory),但java-native解决方案会更好(我的意思是免费且可能更可靠？).此外,我想避免序列化开销,这意味着它应该在相同的jvm内发生.据我所知,DirectMemory和BigMemory主要在堆上运行,这意味着必须将对象序列化/反序列化到jvm外部的内存中.简单地在jvm中标记非gc区域似乎是更好的解决方案.使用文件进行缓存也不是一种选择,它具有相同的无法承受的序列化/反序列化开销 - 用例是一个HA服务器,其中包含大量以随机(人工)顺序使用的数据,并且需要低延迟.