当前位置: 代码迷 >> Java Web开发 >> request.getSession报java.lang.NullPointerException,该如何解决
  详细解决方案

request.getSession报java.lang.NullPointerException,该如何解决

热度:5458   发布时间:2013-02-25 21:19:54.0
request.getSession报java.lang.NullPointerException
代码如下:
Java code
      HttpSession userSession = request.getSession();      Map userMap = (Map)userSession.getAttribute("userMap");

环境:ssh+mysql。
问题描述:这是一个登录过程,正常情况下没任何问题,但是在压力测试的时候,在如上代码第二行位置报java.lang.NullPointerException
何解?

------解决方案--------------------------------------------------------
LZ一定是用了Session的延时关闭技术,或session使用后没有及时关闭,
导致连接池耗尽,取不到Session.
------解决方案--------------------------------------------------------
HttpSession userSession = request.getSession();
if (userSession != null){
Map userMap = (Map)userSession.getAttribute("userMap");
}

是没有取到HttpSession,最好做个判断先,再去取



------解决方案--------------------------------------------------------
是:HttpSession userSession = request.getSession(); 这句话抛出?
这句话的话其实是说request==null

你先确认到底哪句话仍出来的exception?

------解决方案--------------------------------------------------------
取不到值是不是没有setAttribute啊~
------解决方案--------------------------------------------------------
探讨


正常情况下可用,压力测试时偶尔异常

------解决方案--------------------------------------------------------
既然是压力测试下,出现的:


 HttpSession userSession = request.getSession();
 Map userMap = request.getSession()==null?null:(Map)request.getSession().getAttribute("userMap");

------解决方案--------------------------------------------------------
1、你的session是保存在服务器端还是保存在客户端(也就是通过cookies技术保存)。
2、session如果保存在服务器端,一般的做法,是将session对象保存在内存里。同一时间,会有很多session被保存在服务器的内存里。由于内存是有限的,较好的服务器会把session对象的数据交换到文件中,以确保内存中的session数目保持在一个合理的范围内。

你做压力测试,你的session对象有可能过多,服务器内存中无法存入更多,导致某些情况下数据丢失。
3、你是否采用集群部署服务器?
为了提高系统扩展性和可用性,我们会使用集群技术 —— 就是一组独立的机器共同运行同一个应用。对用户来讲,集群相当于一台“大型服务器”。而实际上,同一用户的两次请求可能被分配到两台不同的服务器上来处理。这样一来,怎样保证两次请求中存取的session值一致呢?

一种方法是使用session复制:当session的值被改变时,将它复制到其它机器上。这个方案又有两种具体的实现,一种是广播的方式。这种方式下,任何一台服务器都保存着所有服务器所接受到的session对象。服务器之间随时保持着同步,因而所有服务器都是等同的。可想而知,当访问量增大的时候,这种方式花费在广播session上的带宽有多大,而且随着机器增加,网络负担成指数级上升,不具备高度可扩展性。

另一种方法是TCP-Ring的方式,也就是把集群中所有的服务器看成一个环,A→B→C→D→A,首尾相接。把A的session复制到B,B的session复制到C,……,以此类推,最后一台服务器的session复制到A。这样,万一A宕机,还有B可以顶上来,用户的session数据不会轻易丢失。但这种方案也有缺点:一是配置复杂;二是每增添/减少一台机器时,ring都需要重新调整,这将成为性能瓶颈;三是要求前端的Load Balancer具有相当强的智能,才能将用户请求分发到正确的机器上。



  相关解决方案