开发中一个未经优化的使用tomcat提供服务的web应用在某日突然内存溢出，而该服务的缓存信息很少，于是google + code insight了一把，加以总结如下。
新用户访问tomcat下的web应用，tomcat会默认为用户创建session，即一个StandardSession实例，
protected StandardSession getNewSession() {
return new StandardSession(this);
}
StandardSession中有数十的变量，其中包括id(用于标记session)，及ArrayList、ConcurrentHashMap、Hashtable三个集合类各一。
id：tomcat是基于id来识别用户，这个sessionId在server和client（即browser）间通过ssl、cookie、url改写三种方式一直来交互id，从而保持用户信息及context。
attributes：ConcurrentHashMap，用于保存用户的各种属性设置，应用中常见的session.setAttribute()设置的各种属性即保存于此。
listeners：ArrayList，session事件监听器列表，用于sessin相关事件发生时调用。
notes：Hashtable，用于保存catalina组件及事件监听器的与session关联的一些对象，在分布式session时不序列化。
从中实际也可以看出，对于一个普通的请求，server实际是要有一定得内存开销的，尤其对于三个集合量。
对于一般有状态的web应用，这些开销当然是必须的，是b/s非常重要的交互基础，但对于一些提供无状态的data service、redirecte service等，这些确实一个要十分警惕的开销。
对于无状态的data service和跳转服务器，每次请求都是独立的，or每次请求的交互中不带任何形式的id（即前面三种方式），而默认情况下tomcat为每次请求创建一个新的sessin，每个session的过期时间默认是半小时，所以当请求量大于一定值时，tomcat的内存会急剧上升，导致内存溢出。
总结：
1 对于stateless的data service、redirect service等无需context的服务，直接设置session为false，
2 对于分布式服务，对于负载均衡、单点故障、热升级等，可以使tomcat提供等同服务，通过session复制加以解决。如一个tomcat宕机，但用户的session任然在其他服务器上保存，这样用户可以无影响的继续操作，或者服务器可以进行热升级，单台逐渐重启升级，对用户透明。