jsp+javabean能否满足100人使用?
jsp+javabean能否满足100人使用?
http://www.jdon.com/jivejdon/thread/30437.html
Java有一个垃圾回收机制，总是在内存剩余大概5%才启动，因为它中断权限最高，它运行，其他全部停止，因此，我们不希望垃圾回收机制频繁启动，那么就要控制内存不要触碰剩余5%底线。
控制资源就是使用Pool或cache来控制，Spring/JdonFramework下可自行加入； EJB已经默认加入了。
这也是2003年/2004年极力推荐EJB原因，因为EJB机制本身已经包含了资源控制和优化，如果你理论上对于前面原理不熟悉，选择EJB还能避免你架构方向错误。
如果你理论上属于无知，又狂热追求Spring这些新玩艺（当初），那么，即使你使用Spring，性能还是和Jsp+JavaBeans一样，在大访问量情况下经常死机，因为Spring里面需要手工配置Pool或cache这些资源控制机制。
所幸，JdonFramework只需你实现一个Poolable接口就可以了。
垃圾回收机制的原理是：只回收那些不被引用的对象。内存不通过垃圾回收机制回收，还会其他方式吗？Java不需要象C那样，用完对象后，需要进行清理，所以你的对象赋null只是防止其他地方象这个对象里嵌入新的对象，否则，根本不起任何作用，有点掩耳盗铃。
我以前说过，如果说Java比C方便，因为对象使用之后不需要清理，那么有了IOC/DI依赖注射以后，Java中对象使用之前也不需要创建了。
对象在一般语言中，如果需要使用，必须首先创建，使用完成后，必须清理，这些琐碎的事务困扰开发者的开发效率，现在在Java中无需了。
关于控制资源，前面提到Pool和cache，当然单例也是一种方式，不过这种方式在J2EE多线程环境下要时刻注意线程安全性，后者是Spring和JdonFramework等IOC容器采取的方式，但是仅仅将业务逻辑Bean使用单例有时不够，还需要Pool支持；除了业务逻辑Bean要控制其资源，数据Bean也要控制，使用cache，每次数据Bean对象获得都从数据库获得，虽然连接池水平再好，也是不具备伸缩性的，Cache才是真正根本解决之道。
按照"资源晚申请，早释放"的原则，java的垃圾回收机制是一个败笔，如果java支持手动释放，和自动回收机制结合起来，就既可以提高资源利用率也可以防止内存泄露了。
GC的触发频率与jvm heap capacity大小有关！
如果设置过大，则GC频率会很低，大量内存会被垃圾对象占满，超出内存后，又频繁写入硬盘虚拟内存！且GC的时间也会很长，占用CPU时间过多，给于性能上很大的影响！
而减低堆大小会导致JVM 频繁GC！虽然性能上，设置较小可能成本控制会比较好！
但设置过小，则会导致，GC成为CPU占用大户！
合理设置GC,是性能优化的关键之一！
非常有道理，这些取决于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/jivejdon/thread/30437.html
Java有一个垃圾回收机制，总是在内存剩余大概5%才启动，因为它中断权限最高，它运行，其他全部停止，因此，我们不希望垃圾回收机制频繁启动，那么就要控制内存不要触碰剩余5%底线。
控制资源就是使用Pool或cache来控制，Spring/JdonFramework下可自行加入； EJB已经默认加入了。
这也是2003年/2004年极力推荐EJB原因，因为EJB机制本身已经包含了资源控制和优化，如果你理论上对于前面原理不熟悉，选择EJB还能避免你架构方向错误。
如果你理论上属于无知，又狂热追求Spring这些新玩艺（当初），那么，即使你使用Spring，性能还是和Jsp+JavaBeans一样，在大访问量情况下经常死机，因为Spring里面需要手工配置Pool或cache这些资源控制机制。
所幸，JdonFramework只需你实现一个Poolable接口就可以了。
垃圾回收机制的原理是：只回收那些不被引用的对象。内存不通过垃圾回收机制回收，还会其他方式吗？Java不需要象C那样，用完对象后，需要进行清理，所以你的对象赋null只是防止其他地方象这个对象里嵌入新的对象，否则，根本不起任何作用，有点掩耳盗铃。
我以前说过，如果说Java比C方便，因为对象使用之后不需要清理，那么有了IOC/DI依赖注射以后，Java中对象使用之前也不需要创建了。
对象在一般语言中，如果需要使用，必须首先创建，使用完成后，必须清理，这些琐碎的事务困扰开发者的开发效率，现在在Java中无需了。
关于控制资源，前面提到Pool和cache，当然单例也是一种方式，不过这种方式在J2EE多线程环境下要时刻注意线程安全性，后者是Spring和JdonFramework等IOC容器采取的方式，但是仅仅将业务逻辑Bean使用单例有时不够，还需要Pool支持；除了业务逻辑Bean要控制其资源，数据Bean也要控制，使用cache，每次数据Bean对象获得都从数据库获得，虽然连接池水平再好，也是不具备伸缩性的，Cache才是真正根本解决之道。
按照"资源晚申请，早释放"的原则，java的垃圾回收机制是一个败笔，如果java支持手动释放，和自动回收机制结合起来，就既可以提高资源利用率也可以防止内存泄露了。
GC的触发频率与jvm heap capacity大小有关！
如果设置过大，则GC频率会很低，大量内存会被垃圾对象占满，超出内存后，又频繁写入硬盘虚拟内存！且GC的时间也会很长，占用CPU时间过多，给于性能上很大的影响！
而减低堆大小会导致JVM 频繁GC！虽然性能上，设置较小可能成本控制会比较好！
但设置过小，则会导致，GC成为CPU占用大户！
合理设置GC,是性能优化的关键之一！
非常有道理，这些取决于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集群原理