我们公司一个系统大量使用session，请问这样会有什么后果影响？

在单机(JVM)环境下性能不会受影响, 如果你的业务访问量比较大, 需要集群环境/分布式时, session复制会导致网络风暴, 也就是说依赖session会使得应用un-scalable

可以考虑SNA-share nothing architecture. (业务)机器与(业务)机器之间应该是相互独立的, 平等的, 彼此不应该通信, 不共享信息.

所以，你这样做的问题不会带来单机性能问题，会带来可伸缩性问题，就是楼上un-scalable，会使得一个客户端总是粘住一个服务器方法，无法真正实现负载平衡。尽管你硬件用L5或用apache做平衡器。

能不能具体点。或给个测试方法
集群环境/分布式下为什么就不行了

其实是因为Session + 状态是不可伸缩的。

详细点是这样：如果你在Session中保存一个与该客户端有关的状态，比如状态数值为1,下次该客户端再发一个请求时，需要到自己的Session中寻找这个数值为1的状态。

在分布式环境中有两种办法：
1.如果下次该客户端发出的请求不是访问的是上次请求的服务器，那么他在新服务器中就找不到数值为1的状态，因为被负载平衡器随机分配到新服务器上了。

2.为了让他找到数值1的状态，那么就在这两台服务器之间拷贝Session中的状态，数值1的状态从原来服务器拷贝到新服务器，第二次请求就能在新服务器上找到这个数值为1的状态。但来这样做的问题是：服务器就会耗费负载来处理服务器之间的拷贝，根本没有全心全意处理客户端发出的请求，严重发生风暴堵塞。

弄个session分配服务器，具体的逻辑再由各自服务器管理就行了，只要保证session不要分布就没关系了，至于你所说的性能，3个人的应用也有性能，3000个人也有性能，30000000也有性能，全世界都同时访问的那也有性能～
跟大量使用session的关系不算太大的，不过不太建议使用session管理业务数据，毕竟上述的技术还是需要做一些处理的～session是保存在服务器上的，大量臃肿的session会导致内存膨胀的厉害～所以session一般只有来保存必须保存的key信息

从解耦设计角度考虑，Session一般能尽量不用就不用，要从对象的生命周期 状态管理周期这个角度认识Session和Cache，Session其实也是一种缓存，不过不是应用全局级别，而是随着某个客户端开始和离去有关，象你这个案例，完全可以用全局性的Cache来实现。

现在都是RIA富客户端和RESTful架构，其精神目的就是将和客户有关的状态缓存迁移到客户端，使用JS或AJAX来实现，通过这些措施，可以减少Session的使用。

如果你在Session中放一些可幂等方法的结果，也就是这个方法能够反复运行，这也是可以的，在分布式环境就不必同步Session，因为可以即时生成，作为特殊缓存使用。

总之：忘记Session，不倚重Session，复杂的界面渲染不要依赖服务器端Session，而是迁移到客户端，这样才能真正利用http无状态特性，Session实际就是因为http无状态，而强加给服务器的一个状态容器，这不符合自然之道，不符合巧妙之道，是简单问题复杂化，必然会被遗弃。

大多数程序都没利用好session，基本就存放一个购物车或者登陆用户id，或者其他全局性的变量。
所以，传统mvc程序都把session荒废了。
因为session存放容易，清除却找不到良好时机。
你们把点一个菜单作为清除的时机还算不错了，说明这些状态的生命和菜单项挂钩。
最好是有一个框架来自动管理状态。
目前“有状态的”web框架有：JSF,Wicket,Click,ASP.net，。。。
这些框架要么是把状态直接保存在服务器内存里，要么是用一个隐藏字段viewstate传给客户端。
[该贴被jackhatedance于2010-06-11 07:23修改过]

传统的web应用只在客户端进行显示工作，这样的结果是必须要在服务器端实现一个客户端的实例，在这个实例中进行客户端业务过程的维护。

本质上“服务--使用者”是任何分布式系统所共同的结构；但是在传统web应用环境下这个结构再次被细分成为“服务--使用者--显示者”，“服务--使用者”被一起集成到了服务器端。很多程序在实现的过程中却没有清晰的认识到这一点，真的将他们融合了进而造成了一些混乱。

其实web是一种很好的方式，非常便于应用系统的部署和维护。RIA是一种好的方向，通过职责的划分帮助我们更清晰和容易的建立起应用环境，浏览器端还需要提供相应的支撑环境来满足这种需求。

又想起来前些天看到有人在这里问如何进行系统划分，说起来很简单其实就是：找到必要的人，同时将每个人的职责归还给自己。在这里也是一样的。

相关讨论：
使用RabbitMQ使得Tomcat Sessions 变得更加云化

设计可伸缩系统的第一要点就是：不要使用Session
这样你才可能通过简单地堆服务器来扩展系统

简单分析：
1.session里面保存的信息是否能够得到及时的更新，比如你登录的时候取得列表，但是你又新增加了一条记录，是否会因为延迟导致问题。
2.大量的放在里面如果访问量大的话，那当然很占内存了，所以可以预见，一旦访问量高的话，很容易产生内存溢出了。
3.做负载均衡很不方便，对扩展有影响。