UseAdaptiveSizePolicy与CMS垃圾回收同时使用导致的JVM报错

   系统在灰度环境上变更时发现JVM启动报错，详细检查JVM配置参数，发现新境了如下配置：

   -XX:+UseAdaptiveSizePolicy和-XX:+UseConcMarkSweepGC

   初步猜想是JVM参数配置的问题，于是通过jmap -heap查看系统堆栈使用情况，如下：

Heap Configuration:  
   MinHeapFreeRatio = 40  
   MaxHeapFreeRatio = 70  
   MaxHeapSize      = 10737418240 (10240.0MB)  
   NewSize          = 2147483648 (2048.0MB)  
   MaxNewSize       = 2147483648 (2048.0MB)  
   OldSize          = 5439488 (5.1875MB)  
   NewRatio         = 2  
   SurvivorRatio    = 4  
   PermSize         = 21757952 (20.75MB)  
   MaxPermSize      = 134217728 (128.0MB)  

Heap Usage:  
unknown generation type:  
   capacity = 0 (0.0MB)  
   used     = 0 (0.0MB)  
   free     = 0 (0.0MB)  
   NaN% used  
unknown generation type:  
   capacity = 0 (0.0MB)  
   used     = 0 (0.0MB)  
   free     = 0 (0.0MB)  
   NaN% used  
Perm Generation:  
   capacity = 60878848 (58.05859375MB)  
   used     = 37927152 (36.17015075683594MB)  
   free     = 22951696 (21.888442993164062MB)  
   62.29939173619054% used 

从打印的堆栈信息上看已发现异常

一、JVM分析

1、源码查看

  分析jdk的management.cpp代码，发现在计算堆内存区大小的时候，对commit都进行了累加，但是在max_size没有定义（无效，从MemoryPool获取）的情况下，total_max没有累加，导致commited比max大。

  修复后的代码见：  http://hg.openjdk.java.net/hsx/hsx25/hotspot/file/a70566600baf/src/share/vm/services/management.cpp的方法JVM_ENTRY中。 

 对比： 
   原来只处理： 

if (!has_undefined_max_size) {  
  total_max += u.max_size();  
}  

修复该问题的方式：增加代码处理没有定义init和max的情况  

if (has_undefined_init_size) {  
     total_init = (size_t)-1;  
  }  
if (has_undefined_max_size) {  
      total_max = (size_t)-1;  
  }  

 2、jmap不能获取数据原因

  jmap出现不能获取的原因：（UseAdaptiveSizePolicy + CMS同时使用会出现） （该状况源码： sun/jvm/hotspot/memory/GenerationFactory.java ）：  

try {  
     return (Generation) ctor.instantiateWrapperFor(addr);  
} catch (WrongTypeException e) {  
     return new Generation(addr) {  
     public String name() {  
     return "unknown generation type";  
……  

 二、问题产生原因

    目前确认是jvm的bug，初步确认版本为1.6_u30以上，包括1.7都存在该问题.jdk6.30以下版本还未确认（使用1.6_u25版本后，目前还没有复现问题）---1.6.30以上到1.7的全部版本已经确认有该问题，jdk8修复，其他版本待验证

   简要原因分析请参见: http://blog.csdn.net/axman/article/details/8667351       

   在使用cms算法下，如果开启参数UseAdaptiveSizePolicy，则每次minor gc后会重新计算eden，from和to的大小，计算过程依据的是gc过程统计的一些数据，计算后的eden+from+to不会超过Xmx，同时from和to一般是不相等（初始化的时候from和to是相等的）。主要问题在于计算完后，如果eden变大，ContiguousSpacePool里面的max_eden_size并没有被更新，还是最开始时候的值，这样导致jvm在通过call_special调用java.lang.management. MemoryUsage的构造函数的时候会产生exception，产生exception的原因是eden的committed 大于 eden的max_size，导致返回java.lang.management. MemoryUsage对象失败，最终导致产生显示异常。 

三、解决办法

  可以先设置 –XX:-UseAdaptiveSizePolicy来workaround，JDK的版本：sun jdk出问题后的版本目前看是只有jdk8修复；openjdk是hs25修复。