JVM初探使用堆外内存减少FullGCWord文档格式.docx

1、05. */public class DirectByteBufferApp extends AbstractAppInvoker Test Override public void invoke（Object. param） Map map = createInHeapMap（SIZE）; / move in off-heap byte bytes = serializer.serialize（map）; ByteBuffer buffer = ByteBuffer.allocateDirect（bytes.length）; buffer.put（bytes）; buffer.flip（）;

2、 / for gc map = null; bytes = null; System.out.println（write down）; / move out from off-heap byte offHeapBytes = new bytebuffer.limit（）; buffer.get（offHeapBytes）; deserMap = serializer.deserialize（offHeapBytes）; for （int i = 0; i SIZE; +i） String key = key- + i; FeedDO feedDO = deserMap.get（key）; ch

3、eckValid（feedDO）; if （i % 10000 = 0） read + i）; free（buffer）; private Map createInHeapMap（int size） long createTime = System.currentTimeMillis（）; map = new ConcurrentHashMap（size）; size; FeedDO value = createFeed（i, key, createTime）; map.put（key, value）; return map;由JDK提供的堆外内存访问API只能申请到一个类似一维数组的Byte

4、Buffer, JDK并未提供基于堆外内存的实用数据结构实现（如堆外的Map、Set）, 因此想要实现Cache的功能只能在write（）时先将数据put（）到一个堆内的HashMap, 然后再将整个Map序列化后MoveIn到DirectMemory, 取缓存则反之. 由于需要在堆内申请HashMap, 因此可能会导致多次Full GC. 这种方式虽然可以使用堆外内存, 但性能不高、无法发挥堆外内存的优势. 幸运的是开源界的前辈开发了诸如Ehcache、MapDB、Chronicle Map等一系列优秀的堆外内存框架, 使我们可以在使用简洁API访问堆外内存的同时又不损耗额外的性能.其中又以

5、Ehcache最为强大, 其提供了in-heap、off-heap、on-disk、cluster四级缓存, 且Ehcache企业级产品（BigMemory Max / BigMemory Go）实现的BigMemory也是Java堆外内存领域的先驱.示例2: MapDB API实现堆外Cachepublic class MapDBApp extends AbstractAppInvoker private static HTreeMap mapDBCache; static mapDBCache = DBMaker.hashMapSegmentedMemoryDirect（） .expire

6、MaxSize（SIZE） .make（）; FeedDO feed = createFeed（i, key, System.currentTimeMillis（）; mapDBCache.put（key, feed）; FeedDO feedDO = mapDBCache.get（key）;结果 & 分析DirectByteBufferApp S0 S1 E O P YGC YGCT FGC FGCT GCT0.00 0.00 5.22 78.57 59.85 19 2.902 13 7.251 10.153the last one jstat of MapDBApp0.00 0.03 8.

7、02 0.38 44.46 171 0.238 0 0.000 0.238运行DirectByteBufferApp.invoke（）会发现有看到很多Full GC的产生, 这是因为HashMap需要一个很大的连续数组, Old区很快就会被占满, 因此也就导致频繁Full GC的产生. 而运行MapDBApp.invoke（）可以看到有一个DirectMemory持续增长的过程, 但FullGC却一次都没有了.实验: 使用堆外内存减少Full GC实验环境java -versionjava version 1.7.0_79Java（TM） SE Runtime Environment （bui

8、ld 1.7.0_79-b15）Java HotSpot（TM） 64-Bit Server VM （build 24.79-b02, mixed mode）VM Options-Xmx512M-XX:MaxDirectMemorySize=512M+PrintGC+UseConcMarkSweepGC+CMSClassUnloadingEnabledCMSInitiatingOccupancyFraction=80+UseCMSInitiatingOccupancyOnly实验数据 170W条动态（FeedDO）.实验代码第1组: in-heap、affect by GC、no serial

9、izeConcurrentHashMapApppublic class ConcurrentHashMapApp extends AbstractAppInvoker private static final Map cache = new ConcurrentHashMap（）; / write String key = String.format（key_%s, i）; FeedDO feedDO = createFeed（i, key, System.currentTimeMillis（）; cache.put（key, feedDO）; / read FeedDO feedDO = c

10、ache.get（key）;GuavaCacheApp类似, 详细代码可参考完整项目.第2组: off-heap、not affect by GC、need serializeEhcacheApppublic class EhcacheApp extends AbstractAppInvoker private static Cache cache; ResourcePools resourcePools = ResourcePoolsBuilder.newResourcePoolsBuilder（） .heap（1000, EntryUnit.ENTRIES） .offheap（480, M

11、emoryUnit.MB） .build（）; CacheConfiguration configuration = CacheConfigurationBuilder .newCacheConfigurationBuilder（String.class, FeedDO.class, resourcePools） cache = CacheManagerBuilder.newCacheManagerBuilder（） .withCache（cacher, configuration） .build（true） .getCache（, String.class, FeedDO.class）; O

12、bject o = cache.get（key）; checkValid（o）;MapDBApp与前同.第3组: off-process、not affect by GC、serialize、affect by process communicationLocalRedisApppublic class LocalRedisApp extends AbstractAppInvoker private static final Jedis cache = new Jedis（localhost, 6379）; private static final IObjectSerializer seri

13、alizer = new Hessian2Serializer（）; byte value = serializer.serialize（feedDO）; cache.set（key.getBytes（）, value）;write byte value = cache.get（key.getBytes（）; FeedDO feedDO = serializer.deserialize（value）;结果分析对比前面几组数据, 可以有如下总结:将长生命周期的大对象（如cache）移出heap可大幅度降低Full GC次数与耗时;使用off-heap存储对象需要付出serialize/deser

14、ialize成本;将cache放入分布式缓存需要付出进程间通信/网络通信的成本（UNIX Domain/TCP IP）附:off-heap的Ehcache能够跑出比in-heap的HashMap/Guava更好的成绩确实是我始料未及的O（_）O, 但确实这些数据和堆内存的搭配导致in-heap的Full GC太多了, 当heap堆开大之后就肯定不是这个结果了. 因此在使用堆外内存降低Full GC前, 可以先考虑是否可以将heap开的更大. 性能测试框架在main函数启动时, 扫描com.vdian.se.apps包下的所有继承了AbstractAppInvoker的类, 然后使用Javass

15、ist为每个类生成一个代理对象: 当invoke（）方法执行时首先检查他是否标注了Test注解（在此, 我们借用junit定义好了的注解）, 并在执行的前后记录方法执行耗时, 并最终对比每个实现类耗时统计.依赖 monsartifactIdcommons-proxyversion$commons.proxy.version/dependencyorg.javassistjavassist$javassist.versioncom.cauchohessian$hessian.versioncom.google.guavaguava$guava.versionjunit$junit.version

16、 STATISTICS_MAP = new HashMap public static void main（String args） throws IOException, IllegalAccessException, InstantiationException SetClass? classes = PackageScanUtil.scanPackage（com.vdian.se.apps for （Class clazz : classes） AbstractAppInvoker invoker = createProxyInvoker（clazz.newInstance（）; inv

17、oker.invoke（）; /System.gc（）;* statistics * for （Map.Entry entry : STATISTICS_MAP.entrySet（） method + entry.getKey（） + total cost + entry.getValue（） + ms private static AbstractAppInvoker createProxyInvoker（Object invoker） ProxyFactory factory = w JavassistProxyFactory（）; Class superclass = invoker.g

18、etClass（）.getSuperclass（）; Object proxy = factory .createInterceptorProxy（invoker, new ProfileInterceptor（）, new Classsuperclass）; return （AbstractAppInvoker） proxy; private static class ProfileInterceptor implements Interceptor public Object intercept（Invocation invocation） throws Throwable clazz = invocation.getProxy（）.getClass（）; Method method = clazz.getMethod（invocation.getMethod（）.getName（）, Object.class）; Object result = null; if （method.isAnnotationPresent（Test.class） & method.getName（）.equals（invoke）