以NIO通信例子结合Jconsole解释JVM内存分配机制
JAVA的内存分配机制，在很多地方都已经解析很多次了，个人如何方便的来直观的了解，还有很多人不是很清楚，或者没有这样的机会，在这里我结合一个小例子，采用JDK自带的JConsole来说一下JVM的内存分配机制。
案例
首先解释下场景，服务端是一个通信服务器，接受客户端发过来的通信信息，并做业务处理；服务端采用JAVA中的MINA2框架，客户端可以任意，C++也好，JAVA也好，只要符合服务端规定的消息结构，发给通信服务器都能处理。
为了让大家更清楚，可以用MINA2框架中的时间服务器的例子来稍作修改模拟这个场景。系统环境，APACHE MINA2.0.4 + JDK1.6 + Eclipse3.7。
服务端代码如下：
业务处理器（这里当作一个时间服务器，接受到信息之后就立刻返回服务器当前时间）
客户端JAVA代码:
客户端处理类：
JAVA内存模型简介
我们知道：JAVA的内存模型是这样的，简单的来说，可以分为堆和非堆内存，下面的著名的这个图大家经常会看到：
内存由 Perm 和 Heap 组成. 其中
Heap（堆内存） = {Old + NEW = { Eden , from, to } }
NEW 也叫年轻代（Young Gen）:
这里解释下，也有人说上图中的from,to是suvivor space a,survivor b
而且这两个区会交换的：
NEW:年轻代(Young Gen)：年轻代主要存放新创建的对象，内存大小相对会比较小，垃圾回收会比较频繁。年轻代分成1个Eden Space和2个Suvivor Space（命名为A和B）
?当对象在堆创建时，将进入年轻代的Eden Space。
?垃圾回收器进行垃圾回收时，扫描Eden Space和A Suvivor Space，如果对象仍然存活，则复制到B Suvivor Space，如果B Suvivor Space已经满，则复制 Old Gen
?扫描A Suvivor Space时，如果对象已经经过了几次的扫描仍然存活，JVM认为其为一个Old对象，则将其移到Old Gen。
?扫描完毕后，JVM将Eden Space和A Suvivor Space清空，然后交换A和B的角色（即下次垃圾回收时会扫描Eden Space和BSuvivor Space。
我们可以看到：Young Gen垃圾回收时，采用将存活对象复制到到空的Suvivor Space的方式来确保不存在内存碎片，采用空间换时间的方式来加速内存垃圾回收。
JConsole使用
JConsole是一个基于JMX的GUI工具，用于连接正在运行的JVM，不过此JVM需要使用可管理的模式启动。JConsole从java5开始，在JDK中提供。用于对JVM中内存，线程和类等的监控。
其使用很简单，JDK在你的环境变量之后，就可以在命令行中输入：
jconsole
如果弹出窗口，说明配置可用。
弹出窗口如下：
上图中的Eden Space就是JAVA对象初始进入的地方，
Survivor Space是A Suvivor Space空间
Tenured Gen 是Old Gen也就是大家说的养老区,
垃圾回收描述：
在New Generation块中，垃圾回收一般用Copying的算法，速度快。这里面的截图表示新生代已经执行了300多次的垃圾回收。
每次GC的时候，存活下来的对象首先由Eden拷贝到某个Survivor Space, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到Old Generation中去。因此，每次GC后，Eden内存块会被清空。在Old Generation块中，垃圾回收一般用mark-compact的算法，速度慢些，但减少内存要求.
还是上图
说明采用mark-compact算法的养老区还没有执行GC，(0项收集)；
回到这个例子，在堆内存的JCONSOLE面板中，有三个子项,分别是：
（一）Eden Space
其截图如下：
这个是新生代内存，从图上来看，整体的运行内存还是比较稳定的。
（二）A Suvivor Space
这个也是相当的稳定
（三)OLD
OLD养老区的内存一直呈现上升趋势，而且在这5个多小时里面，一直没有下降的趋势。这个是为什么呢？大家知道, 内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。那么这个现象会不会出现内存溢出呢？我们在前面了解到，OLD养老区的内存回收mark-compact，一般是比较慢的，所以这5个小时，没有发生过一次养老区的垃圾回收。当OLD去的空间不够时，JVM会在OLD区进行完全的垃圾收集（0级），这样就会避免出现OLD区的OOM错误。
因为堆内存是上述三张图的内存集合，那么下张图中，堆内存的线性增长也就有合理的解释了，由于OLD还没有进行垃圾回收，里面的对象越来越多，占用内存越来越大，也就影响了整体堆内存
JCONSOLE还能看到什么呢？
第三个TAB页签，能看到当前的线程数
第四个TAB页签，能够看到当前的JVM信息
最有一个线程数能够看到当前JMX暴露出现的JVM运行的整体信息，比如说GC的次数，GC的类型，时间等等；
后续
这个模拟程序会随着时间的推迟而OLD去内存线性增长，也就意味着堆区内存线性增长，难道一直等着OLD区来做mark-compact的算法的GC?
当然也是有方法去改进GC的算法的，先来了解一下基本的知识：
垃圾回收策略
评估垃圾回收策略的两个重要度量是：
?吞吐量(Throughput )：JVM花费在垃圾回收上的时间越长，则吞吐量越低
?暂停时间(Pause time)：JVM垃圾回收过程当中有一个暂停期，在暂停期间，应用程序不能运行，暂停时间是暂停期的长度
非常遗憾的是，一般这两个指标是相互冲突的，改善其中一个会影响到另外一个，根据情景的不同我们决定是优先考虑吞吐量还是暂停时间，对于需要实时响应的应用，我们需要优先考虑暂停时间，对于后台运行应用，我们需要优先考虑吞吐量。
在考察各种垃圾回收器之前，我们需要了解一下几个重要的策略
?并行(Parallel)：并行表示使用多个线程同时进行垃圾回收的工作，此策略一般会从同时改善暂停时间和吞吐量，在有多CPU内核的服务器上，这是基本上我们要使用的策略。
?并发(Concurrent)：并行表示垃圾回收器的一些工作（譬如垃圾标记）与应用程序同时进行，这将更进一步缩短暂停时间，需要注意的是，同时垃圾回收器的复杂性会大大增大，基本上是会降低吞吐量，
?内存碎片处理：有不压缩、压缩和拷贝三种策略，从空间上讲，拷贝将花费更多的内存（譬如如上内存管理的Young Gen，需要维持一个额外的Suvivor空间），从时间上来讲，不压缩会减低创建对象时的内存分配效率，在垃圾回收上，拷贝策略会比压缩策略更高效。
Sun JVM有4垃圾回收器：
?Serial Collector：序列垃圾回收器，垃圾回收器对Young Gen和Tenured Gen都是使用单线的垃圾回收方式，对Young Gen，会使用拷贝策略避免内存碎片，对Old Gen，会使用压缩策略避免内存碎片。基本上，在对内核的服务器上应该避免使用这种方式。在JVM启动参数中使用-XX:+UseSerialGC启用Serial Collector。
?Parallel Collector：并发垃圾回收器，垃圾回收器对Young Gen和Tenured Gen都是使用多线程并行垃圾回收的方式，对Young Gen，会使用拷贝策略避免内存碎片，对Old Gen，会使用压缩策略避免内存碎片。
在JVM启动参数中使用-XX:+UseParallelGC启用Parallel Collector。
?Parallel Compacting Collector：并行压缩垃圾回收器，与Parallel Collector垃圾回收类似，但对Tenured Gen会使用一种更有效的垃圾回收策略，此垃圾回收器在暂停时间上会更短。
在JVM启动参数中使用-XX:+UseParallelOldGC启用Parallel Compacting Collector。
?Concurrent Mark-Sweep (CMS) Collector：并发标志清除垃圾回收器，对Young Gen会使用与Parallel Collector同样的垃圾回收策略，对Tenured Gen，垃圾回收的垃圾标志线程与应用线程同时进行，而垃圾清除则需要暂停应用线程，但暂停时间会大大缩减，需要注意的是，由于垃圾回收过程更加复杂，会降低总体的吞吐量。
在JVM启动参数中使用：-XX:+UseConcMarkSweepGC启动
具体的CMS方式，有个哥们解释的更加清楚：
http://softbeta.iteye.com/blog/1315103
