你这个问题其实分两种情况：
1. 100同时使用?
2. 总共100人使用，使用频度不高，如果是这个没有问题。
下面讨论第一种情况：
关键不在于你的CPU有多强，这里要了解一下Java运行原理。
Java有一个垃圾回收机制，总是在内存剩余大概5%才启动，因为它中断权限最高，它运行，其他全部停止，因此，我们不希望垃圾回收机制频繁启动，那么就要控制内存不要触碰剩余5%底线。
而在普通JavaBeans系统中，每一次客户端请求访问时，系统总是new一个javabeans或Java Class，如果并发访问量很大，比如并发10人或100人，再加上你的系统复杂，有很多JavaBeans，假设有30个，那么这下子100个并发请求来，就有3000个Java对象创建，然后下一批有来一次100个请求，这象潮水一样。
每次请求产生的3000个对象会继续占用内存，不会被垃圾回收机制回收，因为垃圾回收机制只有等到内存剩余5%才启动，这样，你的内存无论多大，取决于访问量，总会被耗光，最后垃圾回收出来收拾残局，你的业务系统被暂停甚至缓慢。
所以，这里需要有资源控制，将内存能够控制住，不要被无限消耗，最后导致垃圾回收启动，造成系统好像死机。
控制资源就是使用Pool或Cache来控制，Spring/JdonFramework下可自行加入； EJB已经默认加入了。
这也是我一直反对使用Jsp+JavaBeans来写复杂或大访问量的系统，至于如何控制服务器资源，只有数据库连接池是不够的，因为Bean才是真正的资源消耗重点。 继续补充：
经过前面基本原理以后，楼主问题可以知道一些答案，我再详细回答如下：
能够满足同时100人访问，关键在于每个请求耗费的资源是否多，这也是相对的，如果你的CPU够强，内存够多，那么可以这个值相对来说低，这也就是可以解释这种情况：你的系统可能经常发生死机，你就采取提高硬件的办法，提高CPU，增大内存，原来系统是每3小时死机，那么现在提高硬件后，可能是不会每3小时死机了，但是会每天或两天死机，因为你根本问题没有解决，硬件提高只是苟延残喘。
这就象以前SAS一样，当初得SAS的人只能靠名贵呼吸机延长寿命，病毒源没有找到啊。
当然，也有侥幸的，虽然每天死机，但是，每天我可以重新启动了，你可以躲避每天死机了，但是注意，如果访问量比以前增加了，那你可能又回到每3小时死机的老路。
这些解决方案都是可以称为没有可伸缩性的,no scalable，我们软件架构一定要注重可伸缩性，这是软件架构重要内容，以前为什么没有架构这个词语，现在特别重视，这也是一个原因，都是失败经验教训，那些不重视架构的人，必然会重蹈覆辙，这些都是因为无知产生的可悲结果。
这也是2003年/2004年极力推荐EJB原因，因为EJB机制本身已经包含了资源控制和优化，如果你理论上对于前面原理不熟悉，选择EJB还能避免你架构方向错误。
如果你理论上属于无知，又狂热追求Spring这些新玩艺（当初），那么，即使你使用Spring，性能还是和Jsp+JavaBeans一样，在大访问量情况下经常死机，因为Spring里面需要手工配置Pool或Cache这些资源控制机制。
所幸，JdonFramework只需你实现一个Poolable接口就可以了。
回到可伸缩性话题上，不但架构要考虑单机，还要考虑单机不够怎么办？一味提高单机性能，在不断增长的访问量情况下，还是有单点风险，这是过去集中式主机思维的毛病。
我们需要廉价的，无单点风险的、多机的、集群的软件架构。这才是真正有伸缩性的。>我们不能通过赋null的方式取消它的引用么?
是否取消引用之后它仍然占用系统的内存?
清除JavaBeans占用的系统内存一定要通过Java的回收机制才能实现么
垃圾回收机制的原理是：只回收那些不被引用的对象。内存不通过垃圾回收机制回收，还会其他方式吗？Java不需要象C那样，用完对象后，需要进行清理，所以你的对象赋null只是防止其他地方象这个对象里嵌入新的对象，否则，根本不起任何作用，有点掩耳盗铃。
我以前说过，如果说Java比C方便，因为对象使用之后不需要清理，那么有了Ioc/DI依赖注射以后，Java中对象使用之前也不需要创建了。
对象在一般语言中，如果需要使用，必须首先创建，使用完成后，必须清理，这些琐碎的事务困扰开发者的开发效率，现在在Java中无需了。
这些都是因为Java是容器概念的语言，对于容器这个概念，很多不容易接受，而且也很难处理与其互动，从对象清理这个问题就可以看出，所以，使用Java的企业系统缓慢，死机，这些都怪罪Java语言，而不从自己设计思维架构思路上寻找，正是睡不着觉怪床歪啊。发表于 @ 2006年12月29日 21:01:00|评论(loading...)|编辑