我们比来的一个 Java 项目在大年夜开辟情况迁徙到测试情况之后，碰到了一个异常诡异的问题——在将一个 Java 对象存储到 SESSION 会话中而后大年夜中掏出时，这个对象的部分属性在 SESSION 会话刚创建的一段时光内是精确的，然则一段时光过后，固然SESSION没有掉效，然则这部分属性的值却变成NULL了。更令人奇怪的是，无论是变成NULL的属性，照样未变成NULL的属性，都是最简单的String类型变量，实袈溱让人看不明白他们之间到底有何不合。
为了将问题表述清跋扈，下面我举个例子来具体颂峦宦。我们定义的类信息大年夜概如下图所示：
下面我结合上文以及我对 Tomcat 办事器SESSION会话治理道理的分析，来给大年夜家解释锫，为什么仅仅少持续了一个可序列化接口(Serializable)，就会出现如斯诡异的问题。
个中，SessionBean是我们将要放到SESSION中的对象，而BaseBean则是SessionBean持续的父类。无论是在开辟照样测试情况，SessionBean对象都可以不抛出任何异常地存取值，然则个中的属性则不必定：属性a和属性b在SESSION创建之后，只要SESSION没有掉效，就一向可以正常攫取其值;然则个中的属性c，只在SESSION创建不久的一段时光内有效，如不雅一段时光后另娶值，属性c的值就变成NULL了。没有任何认为操作，变量值却改变了，是不是很神奇?
【问题根源】
中心的具体排查过程我就不匠了棘反正经由好长一段时光的分析和排查，问题的根源终于找到了—— BaseBean没有持续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进行了合法性校验，这个神奇的问题还说不定什么时刻才能发明呢。所以说，防御性编程很重要。
【编辑推荐】
- 64％的Java开辟者应用Tomcat
- 网站办事器集群构建之：共享session篇
- Linux下Tomcat与Apache办事器的┞符合
- 主动化运维—tomcat办事起停（mysql+shell+django+bootstrap+jquery）
- PHP跳转后Session损掉值的处理办法
推荐阅读
笔者认为，人工智能范畴虽已迎来新的家当爆发期，但总体来看，人工智能仍是以特定应用范畴的弱人工智能为主。今朝绝大年夜多半的体系，包含深度进修神经收集，机械智能，仍没有达到可以或许思虑的程度。若要持续攀升>>>详细阅读
本文标题：Tomcat中Session对象部分属性值丢失问题的分析与解决
地址：http://www.17bianji.com/lsqh/38482.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示