欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

java web开发,bean数据放在request、response还是servletcontext中? 博客分类: 技术及貌似 BeanWebJava应用服务器JVM 

程序员文章站 2024-02-21 18:08:16
...

就servlet规范本身,数据可以放在3个地方:request、session、servletContext.

request:
好处:用完就仍,不会导致资源占用的无限增长。
弊处:每次要用都从数据库中抓,多做操作,自然会对性能有一些影响。

session:
好处:不用每次都去数据库抓,少做操作。
弊处:每个客户都有一个session,只能自己使用,不同session可能保存大量重复数据;
可能耗费大量服务器内存;
另外session构建在cookie和url重写的基础上,所以用session实现会话跟踪,会用掉一点点服务器带宽和客户端保持联络,
当然session越多,耗费的带宽越多,理论上也会对性能造成影响。
集群的session同步会是个问题。

servletContext:
好处:不用每次都去数据库抓,少做操作。
存储的数据所有客户都可以用。
可减少重复在内存中存储数据造成的开销。
弊处:很多时候相同的数据可能不多(相当于cache的命中率很低)。


其实以上3中方法都有利有弊,各自的好处在某种条件下,也都会转变为弊处。所以不妨综合使用,相当于一个“第三方用法”(只讲一下思路,否则太过繁琐,涉及到的相关技术点请参考有关技术资料):

request不说了,重点说说session和servletContext:

--session的可控应用
session的最大问题是资源回收,两类回收方法:
主动回收:浏览器被关闭,而为提交触发清理动作的请求时,该方法失效,而且很常见。
超时回收:设置session的setMaxInactiveInterval属性或在web.xml中配置超时时间,然后交给jvm的垃圾处理器处理。
不过不要报太大希望,jvm的垃圾收集器并不灵光。
可以用另一种替代方法缓解该问题,比如限制session的数量,可以用HttpSessionListener实现,这样可以缓解session带来的吃内存问题,当然这种做法每次都需要判断session数量,当session达到限定数量时还必须用其他方法处理了,这些细节繁琐,而且要谨慎处理。

--servletContext
如果说session是一个“局部缓存”,那servletContext就是一个“全局缓存”了,不妨把它当作cache(这里不讲究用词的严谨性,仅为了更好说明问题)。cache的大小是当前应用可使用的最大内存。cache的最大问题是提高命中率,命中率高,内存占用少,效率高,命中率低,则内存占用多而且效率低。这种应用的技术实现比“session的可空应用”要简单,适用于相同数据多的地方,这个要事先有所判断,如果用不好则有弊无利。

如果仅使用servlet规范给出的3种机制,任何一种都达不到好处兼收的效果,所以要发挥3种方法的好处、摒弃弊处,必须综合运用,做一些技术框架的构建工作,而且有些地方还比较繁琐(还好框架是可重用的)。
 

有时候寻求或实现“平衡”(或者说尽取其利而摒其害),要付出很大代价,根据不同的情况,这些代价或是值得,或是不值得。也可以“两害相权取其轻”,或许是最便捷的方法。