189 8069 5689

Tomcat中Session对象部分属性值丢失问题的分析与解决是怎样的

本篇文章为大家展示了Tomcat中Session对象部分属性值丢失问题的分析与解决是怎样的,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。

新民网站建设公司创新互联,新民网站设计制作,有大型网站制作公司丰富经验。已为新民近千家提供企业网站建设服务。企业网站搭建\成都外贸网站建设要多少钱,请找那个售后服务好的新民做网站的公司定做!

我们最近的一个 Java 项目在从开发环境迁移到测试环境之后,遇到了一个非常诡异的问题——在将一个 Java 对象存储到 SESSION  会话中而后从中取出时,这个对象的部分属性在 SESSION  会话刚创建的一段时间内是正确的,但是一段时间过后,虽然SESSION没有失效,但是这部分属性的值却变成NULL了。更令人奇怪的是,无论是变成NULL的属性,还是未变成NULL的属性,都是最简单的String类型变量,实在让人看不明白他们之间到底有何不同。

为了将问题表述清楚,下面我举个例子来详细说明下。我们定义的类信息大概如下图所示:

Tomcat中Session对象部分属性值丢失问题的分析与解决是怎样的

其中,SessionBean是我们将要放到SESSION中的对象,而BaseBean则是SessionBean继承的父类。无论是在开发还是测试环境,SessionBean对象都可以不抛出任何异常地存取值,但是其中的属性则不一定:属性a和属性b在SESSION创建之后,只要SESSION没有失效,就一直可以正常读取其值;但是其中的属性c,只在SESSION创建不久的一段时间内有效,如果一段时间后再取值,属性c的值就变成NULL了。没有任何认为操作,变量值却改变了,是不是很神奇?

【问题根源】

中间的具体排查过程我就不讲了,反正经过好长一段时间的分析和排查,问题的根源终于找到了—— BaseBean没有继承Serializable接口!

【原因剖析】

下面我结合上文以及我对 Tomcat  服务器SESSION会话管理原理的分析,来给大家解释下,为什么仅仅少继承了一个可序列化接口(Serializable),就会出现如此诡异的问题。

首先,在SESSION创建的时候,SessionBean对象中的所有属性(a、b、c),都可以正常写入到SESSION会话中,这点是没有问题的。对于刚刚创建的SESSION,此时其内容都保存在服务器的内存当中,如果这时候读取SEESION,  Tomcat 直接把内存中的内容返回给调用者就OK了,所以返回的属性值都是正确的。

而后,无论是因为Tomcat占用内存超出了阈值也好,还是Tomcat定期保存SESSION现场也罢,反正都会引起接下来的操作——将SESSION会话持久化。在将数据从内存写入硬盘的过程中,就涉及了一个非常重要的问题:数据要写入硬盘,应该以什么样的格式存储,又应该怎样把它变成相应的格式?这就是——序列化!

通过观察上图中的代码我们不难发现,SessionBean对象已经实现了Serializable接口,所以在将SessionBean对象保存到磁盘的过程中,也就是对对象进行序列化操作的时候,是不会报任何错误的,这也是我们难以通过跟踪错误日志来定位问题的根本原因。但是因为SessionBean的基类BaseBean没有实现Serializable接口,所以BaseBean中的属性c在进行序列化的时候就没能保存下来,进而在反序列化的时候,属性c的值就变成NULL了。所以我们读出的值也莫名其妙变成了NULL也就不难理解了。

【解决方案】

至于解决方案,很简单,给基类BaseBean加个Serializable接口就搞定了嘛。

【问题反思】

此次问题带给我们的反思主要有两个:

第一,对于SESSION会话中保存的类,一定要确保该类以及该类的父类实现了Serializable接口,否则无法将类中的属性序列化。

第二,在进行业务逻辑操作之前,一定要对所有具有不确定性的值的合法性进行安全校验(防御性编程),此次若不是我“多此一举”,在业务逻辑前对这个基本可以认定正确(因为写入完全可控可信)的属性c进行了合法性校验,这个神奇的问题还说不定什么时候才能发现呢。

上述内容就是Tomcat中Session对象部分属性值丢失问题的分析与解决是怎样的,你们学到知识或技能了吗?如果还想学到更多技能或者丰富自己的知识储备,欢迎关注创新互联行业资讯频道。


网站题目:Tomcat中Session对象部分属性值丢失问题的分析与解决是怎样的
文章来源:http://cdxtjz.cn/article/ggodii.html

其他资讯