java判断系统在线人数_普通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接口就可以了。

回到可伸缩性话题上，不但架构要考虑单机，还要考虑单机不够怎么办？一味提高单机性能，在不断增长的访问量情况下，还是有单点风险，这是过去集中式主机思维的毛病。

我们需要廉价的，无单点风险的、多机的、集群的软件架构。这才是真正有伸缩性的。