按照"资源晚申请，早释放"的原则，java的垃圾回收机制是一个败笔，如果java支持手动释放，和自动回收机制结合起来，就既可以提高资源利用率也可以防止内存泄露了。
GC的触发频率与jvm heap capacity大小有关！
如果设置过大，则GC频率会很低，大量内存会被垃圾对象占满，超出内存后，又频繁写入硬盘虚拟内存！且GC的时间也会很长，占用CPU时间过多，给于性能上很大的影响！
而减低堆大小会导致JVM 频繁GC！虽然性能上，设置较小可能成本控制会比较好！
但设置过小，则会导致，GC成为CPU占用大户！
合理设置GC,是性能优化的关键之一！
galaxystar 非常有道理，这些取决于JVM参数设置。
据说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都要自己写算法，是不是太烦了一些？
我不同意ThreadPool和Bean的Pool就能改善GC, 这是天方夜谭
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修改过]
>ThreadPool和Bean的Pool就能改善GC
这不是一回事。
Pool是为控制资源，特别是极其恶劣访问量起伏巨大时，对服务器资源是一种保护，另外，Pool只对大巨大的Bean有性能优化。
关于楼上说的"OutputStream, InputStream, String, byte[]数量以10到100计"，这些都是GC能够回收的，如果诸位使用Borland optimizet等profiler工具可以看到这些对象，随着并发访问增大，这些基本类型占用内存很大，但是GC可以迅速启动收拾它们。
关键问题是：你需要让GC能够从容启动；而且启动后，能够收拾干净，这两点就是你的应用程序设计艺术了，当然，通过使用Jdon框架，可以减少这方面的负担，这也是使用框架的好处，具体可以看看JiveJdon3的运行，可以测试一下。
大家最好动手做做，自己有一个直觉认识，不至于走极端。
大家谈到BEAN使用CACHE问题能提高性能,BANQ在前面提到3000对象同时创建的问题,并不会在5%剩余时回收.那请问用了CACHE就能回收了吗?CACHE不就是把大的,多次访问的资源缓存起来吗?没谈到对象释放的问题上来.难道要手动调用GC?给我的感觉是这3000对象好像都不会在内存用完时回收.这不是用JSP+JAVABEAN的问题,即使用STRUTS,SPRING问题也是一样
think in java书中讲到:JAVA对象在程序停止时一起返还给操作系统
[该贴被leoyu于2007年02月02日 10:29修改过]
可以把gc开开，看看到底是不是5%才回收，从哪里听来的？
不能回收是因为你的无用对象还有被引用。要优化你的程序，释放无用对象，根据不同的垃圾回收算法，到时候没用对象就被收走了。不要经常建立特别大的数据buf，或者申请n多的对象。
从大家的回复中可以得出结论,JSP+JAVABEAN的组合能否满足100人使用的主要问题要资源的控制上--pool和cache等.这和现有的框架没多大关系,不是说你用了框架(struts,spring等)就比JSP+JAVABEAN强悍了.而是要在资源管理和控制上做好工作
[该贴被leoyu于2007年02月05日 09:09修改过]
pool如何控制
我们公司的一个网站用的都是jsp写的逻辑，有一部分的插入数据的操作用的是SERVLET，基本没有用javabean,本来用的SERVELT后来鉴于编译和修改的频繁就把有些操作都写到了JSP页面上，为了不重新启动TOMCAT，现在网站的流量还是很小每天有2-3000人的流量，有20多了个注册用户，现在还在长，估计到过完年会流量大，现在我正在愁如何优化程序哪，看了这篇文章，我感觉到用STRUTS的必要不是很大了，因为我们的网站都是上传，发表文章等的动态数据也是和楼主的一样，但是前一段出现了，JVM HEAP SPACE的错误，两三天就当机，后来我给改了JVM的heap为256M就解决了，但是我查资料这样不是根本的问题，还是在程序上修改，我的JSP页面上基本都是while(rs.next){},我该如何做哪，至于说得资源控制该如何做哪，就是用架构，我也要到2，3个月后才能够用呀。希望banq给与答复，急！不要熊我啊，谁让咱当初不懂那么多那，以后要好好学习呀，给治标的方法也行，只要能撑个2-3个月，我把程序给做一下，就行，谢谢了，
>主要是信息的录入.修改,查询的话
只要查询写好了，肯定没问题
用各种所谓架构，基本都是赶时髦，配来配去麻烦要命
还不如写好扎实高效的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。
说的有道理，架构的目的是为了复杂的系统便于扩展用的，我想对于资源占用应该不是她的主要目的吧，应该遮掩说不是一个级别的问题。如果架构的好了整体性肯定就好了，所以资源遮掩的问题肯定也就不是问题了。如果采用了好的架构遮掩的问题就不存在了，因为实现功能方式有很多中，如果遮掩实现的不好就要换别的方式去实现，所以没有必要去做什么的讨论了，现在我想说的是如何在知道不多的情况下去做好现在程序的优化，因为现在修改已经不可能了，那就是要返工的，现在只想大家在用JSP和JAVABEAN的情况下到底性能如何？因为我搞不懂JSP的遮掩做的目的，开发出来的东西竟然有这么的漏洞，就是不能够解决多少人的访问？那当初为什么要做遮掩的设计那，如果遮掩的话就可以把JSP这个语言给删除掉因为他有很大的麻烦，我们直接学架构不久好了吗！干吗要从JSP学起那，学了有发现她是个垃圾！！还要去学架构，这时搞不懂了，遮掩也不便于推广吧，如何体现出它的优势如何和微软争天下，还不如自己死掉算了，