就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种方法的好处、摒弃弊处，必须综合运用，做一些技术框架的构建工作，而且有些地方还比较繁琐（还好框架是可重用的）。
有时候寻求或实现“平衡”（或者说尽取其利而摒其害），要付出很大代价，根据不同的情况，这些代价或是值得，或是不值得。也可以“两害相权取其轻”，或许是最便捷的方法。