如果设置过大，则GC频率会很低，大量内存会被垃圾对象占满，超出内存后，又频繁写入硬盘虚拟内存！且GC的时间也会很长，占用CPU时间过多，给于性能上很大的影响！
而减低堆大小会导致JVM 频繁GC！虽然性能上，设置较小可能成本控制会比较好！
但设置过小，则会导致，GC成为CPU占用大户！
合理设置GC,是性能优化的关键之一！
据说JDK6.0出来后，提出了无需JVM参数设置的out-of-box性能解决方案，
>在的WEB容器本身就带有Thread POOL支持
只有Thread Pool不够，需要Bean Pool，使用依赖Thread Pool，很重的Bean将会延长线程的执行时间，而且某个线程访问某个业务Bean时，需要临时创建业务Bean，耗费内存，使用Pool控制Bean的资源，Thread Pool只能控制Servlet/Jsp的资源。
相关帖子：J2EE集群原理
http://www.jdon.com/jive/thread.jsp?forum=121&thread=22282
现在才知道自己原来是这么的无知。
不过这里有个问题想请教一下：
如果是jsp＋bean的话，如果在jsp内部创建了bean并且生命周期被设定为pege/request的话，那么是否页面一旦被关闭/reqeust请求完成，bean就会被立即回收呢？
能不能举个简单的例子，来说明如何尽量控制bean的产生很如何加快bean的释放？
（我指采用jsp＋bean的方式）
如果采用bean pool来管理bean，每个bean都要自己写算法，是不是太烦了一些？
banq讲对了一半, 光对webserver进行pooling不会改善GC, 但是, 加上所谓的Bean Pool就能大大改善GC了么? 打上一个大大的疑问
看一个具体例子:
从web发request返回当前论坛的主题列表, 看看有多少Java对象被创建:
首先看看web层: ServletRequest, ServletResponse, 加上很多的OutputStream, InputStream, String, byte[]数量以10到100计, 这些Java对象都不可能被Pooling
再看DB层, Pooling可以重用Connection和Statement, 但是不能省数以百计的ResultSet中包含的JavaObject
再看业务层, Jdon的Pooling可以省下StatelessBean业务对象, 但是数以百计的Domain Java Object(论坛Subject)的开销是不可避免的
请问banq, 这么多java object其中有多少百分比可以实现你的Pool接口?
真要考虑效率, 可以考虑生成static Html page
[该贴被ing于2007年02月01日 05:19修改过]
这不是一回事。
Pool是为控制资源，特别是极其恶劣访问量起伏巨大时，对服务器资源是一种保护，另外，Pool只对大巨大的Bean有性能优化。
关于楼上说的"OutputStream, InputStream, String, byte[]数量以10到100计"，这些都是GC能够回收的，如果诸位使用Borland optimizet等profiler工具可以看到这些对象，随着并发访问增大，这些基本类型占用内存很大，但是GC可以迅速启动收拾它们。
关键问题是：你需要让GC能够从容启动；而且启动后，能够收拾干净，这两点就是你的应用程序设计艺术了，当然，通过使用Jdon框架，可以减少这方面的负担，这也是使用框架的好处，具体可以看看JiveJdon3的运行，可以测试一下。
大家最好动手做做，自己有一个直觉认识，不至于走极端。
think in java书中讲到:JAVA对象在程序停止时一起返还给操作系统
[该贴被leoyu于2007年02月02日 10:29修改过]
[该贴被leoyu于2007年02月05日 09:09修改过]
只要查询写好了，肯定没问题
用各种所谓架构，基本都是赶时髦，配来配去麻烦要命
还不如写好扎实高效的sql，
很多老的asp应用，逻辑全写在页面里照样很快
最快的办法是全写存储过程
原来不想说什么
现在忍不住说几句
首先我尚未使用java做过任何的大型项目，基本都是自己为了学习写着玩的
看java的目的主要是现在很多流行的设计方法都是以java为例子的
但是如果一个java做的架构或者程序尚不能满足100人同时在线
我真的要怀疑java的架构设计了
一个出色的容器设计难道会造成内存不足？？
一个好的服务只能满足不足100人的同时使用？？
也许一开始java的诞生是为了卖出sun那昂贵的硬件
但是到了今天难道你们还要用这个做借口么？？
如果一台P4，512M内存的PC不能对付500人同时在线，那我现在就说一定是你程序的问题。这已经是十分的宽容的环境了。我5年前就见过用asp调用作为证券行情服务器的，高峰的时候同时满足上万人实时刷新使用。七台dell的pc server集群，每台cpu 2个，主频400，内存512M。
更多的时候我是作为一个客户来倾听来我们这里推销的厂商介绍的，作为厂商大多数会说自己应用了什么技术，使用了何种架构，如何如何先进。可是对于我们老总来说他听这些基本是昏昏欲睡，他关心的是成本！！购买了该软件给公司带来多大效益，投资需要多少，为了满足需要我们还需要购买什么。动辄就是多少CPU，多少内存的要求，难道真的需要么？？作为用户我不关心你是否容易修改，我要的是高效的实现，快速的反映，很低的故障率，易维护而健壮的程序。所以请程序员们清醒起来，不要因为架构而沾沾自喜，不要因为技术领先而自我欣赏，对用户而言没有任何的打动之处。用户很少在架构上进行二次开发，即使开发也不可能真的理解了架构再去，他们只需要一个接口就OK。