JVM的堆大小设置是一趟很深的水，既要有对架构高度认识和落地，也要有对语言内部机制深入理解和掌握。
首先，需要对JVM的Heap大小有一个预设和监测，见这篇文章选择合适Java堆大小的五个建议(5 Tips for Proper Java Heap Size)，其实文中主要普及了一些JVM设置基础知识，强调需要了解的几个知识点和一般经验，也没有给出实战中具体可行的操作办法，其实每个系统是不一样的，就象病人因人而异一样，需要根据自己的系统和自己的经济条件能力找出适合自己的Heap大小。
堆主要分年轻态和老生态两种，刚刚创建的对象在年轻态，如果这个对象引用被容器或静态或其他对象Hold住，或者经常使用，反正不是那种用完就丢等死那种，那么JVM会将其逐步类似复制粘贴到老生态，如果你使用缓存，那么缓存的对象将大部分在老生态这个区域中，比如Jdonframework或Jivejdon缺省都有缓存，是一种基于内存的计算模式，也就是内存状态管理，那么对于堆的这两个区域大小设置就比较讲究了，下面以jivejdon设置的经验谈谈：
在生产环节，需要对年轻态和老生态两个区域大小进行监测，根据访问量不同和CMS设置不同，特别是老生态大小会经常变化，监测使用PSI-Probe。
初期JVM的大小按照年轻态:老生态=1:3进行配置，当然也和缓存中空闲失效期设置有关，缓存对其中对象如果空闲多长时间没有被使用，将实现清除，类似HttpSession机制。
如果缓存失效期设置过短，老生态利用率不高，比如1.3G的老生态只使用了300M，当然，也可以延缓CMS的启动比例，比如在接近1.3G的70%开始CMS垃圾收集，但是这样碰上尖峰访问可能来不及收集就撑死了(OME:OutOfMemoryError )。
如果缓存失效期设置过长，老生态会被撑满，频繁启动CMS也是徒劳无益，增加系统暂停响应时间，增加了系统延迟。
这样，缓存失效期或者说缓存大小就需要根据JVM老生态在长时间生产环境运行下进行不断微调，Probe起到了关键作用，主要是其图形化直观显示，比起JDK的JConsole等等工具要方便。
上面讨论了堆的大小设置和缓存的关系，因为我们的应用是基于DDD，实体包含状态常驻内存，所以，堆大小对于应用系统是至关重要的。
权衡堆的大小还和两个架构指标有关：延迟和吞吐量，我们总是想通过低延迟获得高吞吐量，堆越大，无疑吞吐量越大，但又不能频繁触发垃圾回收，否则引起暂停，提高了延迟，这是一对矛盾，当然，堆的垃圾回收我们已经设定了新生代是并发回收，老生态采取CMS。
首先，我们要获得关于我们系统的延迟和吞吐量确切指标：使用javamelody对http请求响应时间监测是必要的，其实是对系统重要指标延迟latency进行监测，JVM的微调成绩最终会反映这个指标上。
另外一个微调衡量指标是吞吐量，可以通过jsvnstat + SNMP来获得每天吞吐量，假设是400M，那么，对于JVM的老生态大小至少要大于400M，能撑过一天访问量，缓存失效期为24小时。
上文谈了如何观察堆的大小，特别是老生态的大小，下面谈谈对堆内部更细节的观察，特别是对老生态内部最关心的是哪个类占据内存最多，或者容易发生内存泄漏memory leak导致OME。
工具比较多，包括在线取样Jprofiler或visualvm和离线取样两种，对于生产环境，通过Probe和javamelody发现问题后，如老生态不断增加，垃圾回收好像失效，响应延迟不断增加等等，这时进行离线取样比较合适。
离线取样有几个工具，见这篇文章:Java heap dump触发和分析，关键是在生产服务器下使用jmap -heap:format=b PID 获得heap.bin文件，执行取样时可能耗CPU，对系统延迟有重大影响，挑在空闲时刻取样。
下载heap.bin，使用取样分析工具，推荐使用eclipse 的MAT，其他工具好像没有随着JDK更新而更新，都有些小问题。
至于如何发现导致老生态突然增大甚至OME的罪魁祸首，可借鉴这篇文章：hprof :memory leak analysis tutorial。
总结：当我们通过以上工具和思路掌握监控我们系统的JVM后，应用系统的运维关键也就掌握心中，通过不断微调提供7x24几乎不停机的不间断服务成为可能，高可用性也即将成为现实。