不过SunJDK6.0以后提高也很大。而且JRocket垃圾回收方面，本文说的都是SunJDK目前罕见的JDK还有JRocket和IBMJDK其中JRocketIO方面比Sun高很多。也具有优势，其可设置垃圾回收的最大暂停时间也是很吸引人的不过，系统SunG1实现以后，这方面会有一个质的飞跃。为开发带来了便当。但是一些高性能、高并发的情况下，所谓“成也萧何败萧何”Java垃圾回收确实带来了很多好处。垃圾回收确成为了制约Java应用的瓶颈。目前JDK垃圾回收算法，始终无法解决垃圾回收时的暂停问题，因为这个暂停严重影响了顺序的相应时间，造成拥塞或堆积。这也是后续JDK增加G1算法的一个重要原因。

需要分配如此大的内存空间给应用吗？否能够通过有效使用内存而不是通过扩大内存的方式来设计我系统呢？内存中需要放的应用需要在不久的将来再次用到东西。想想看，内存中需要放什么呢？个人认为。如果你将来不用这些东西，何必放内存呢？放文件、数据库不是更好？这些东西一般包括：

1.系统运行时业务相关的数据，比方web应用中的session即时消息的session等。这些数据一般在一个用户访问周期或者一个使用过程中都需要存在

2.缓存就比较多了所要快速访问的都可以放这里面。其实上面的业务数据也可以理解为一种缓存。

3.线程，不是可以这么认为，因此。如果我不把业务数据和缓存放在JVM中，或者把他独立进去，那么Java应用使用时所需的内存将会大大减少，同时垃圾回收时间也会相应减少。

这是一种最为简单的方式。这种方式下，把所有数据都放入数据库或者文件系统。Java应用的内存基本上等于处置一次峰值并发请求所需的内存。数据的获取都在每次请求时从数据库和文件系统中获取。也可以理解为，一次业务访问以后，所有对象都可以进行回收了，但是从应用角度来说，这是一种内存使用最有效的方式。这种方式很低效，而是写内存的话效率将会提高很多。上面的问题是因为我使用了文件系统带来了低效。但是如果我不是读写硬盘。

但是当我并不需要这样耐久化的时候，数据库和文件系统都是实实在进行了耐久化。可以做一些变通—把内存当硬盘使。

既用了缓存又对Java应用的内存使用又没有影响。Java应用还是Java应用，内存-硬盘映射很好很强大。只知道读写的还是文件，但是实际上是内存。可以分为纵拆和横拆。纵拆可以理解为把Java应用划分为不同模块，这也是一种很好的方式。各个模块使用一个独立的Java进程。而横拆则是同样功能的应用布置多个JVM，其额外带来的复杂性也是需要评估的另外，通过布置多个JVM可以把每个JVM内存控制一个垃圾回收可以忍受的范围内即可。但是这相当于进行了分布式的处置。也有支持分布式的这种JVM可以考虑，不要要钱哦

目前的虚拟机还没有，这种方式是理想当中的方式。纯属假设。即：考虑由编程方式配置哪些对象在垃圾收集过程中可以直接跳过，减少垃圾回收线程遍历标记的时间。这种方式相当于在编程的时候告诉虚拟机某些对象你可以在*时间后在进行收集或者由代码标识可以收集了类似CC++这之前你即便去遍历他也是没有效果的肯定是还在被引用的，个人认为将是一个飞跃，这种方式如果JVM可以实现。Java即有了垃圾回收的优势，又有了CC++对内存的可控性。

而NIO则可以转换成为常数线程。因此，Java阻塞式的线程模型基本上可以抛弃了目前幼稚的NIO框架也比较多了阻塞式IO带来的问题是线程数量的线性增长。对于服务端的应用而言，NIO还是唯一选择。不过，JDK7中为我带来的AIO否能让人眼前一亮呢？拭目以待。