Java入门：状态对象--数据库的替代者

这是一个实战中非常重要但是容易被忽视的概念，说它重要，是因为它比数据库重要；说它容易被忽视也是同样的原因，它经常被数据库概念替代。

　　如果你经验和经历中没有状态这个概念，极端地说：可能你的Java系统经验还未积累到一定程度，状态是每个Java程序员深入Java系统后必然碰到的问题。

　　本文我想试图表达的是：状态分两种：活动的状态对象和持久化的状态。而数据库中的数据只是状态的一种持久化结果，而Java系统 运行时，我们更多的可能是和一种活动的状态打交道，这种活动的状态存在内存中，而不是持久化到硬盘上，当然，需要时你可以通过数据库/文件持久化到硬盘上。

　　但是，如果你以数据库数据替代状态，那么就可能导致数据库的频繁访问，而且 你的系统会变成一个非对象化的、紧耦合、到处是分散数据块的糟糕系统。这样的系统并不比传统的两层结构好到哪里！也不会比Jsp里嵌入Java代码伪三层系统高明到什么地方。

什么是状态？

　　只要有对象就可能有状态，任何一个对象活动时，都有自己的状态属性，类的 字段属性极有可能成为状态，我们现在经常使用的Domain model其实就是一种 包含状态的对象，如果你对状态没有深入掌握，就不可能真正掌握对象系统特点，或者是Domain Model的执行情况。

　　对于初学者，经常会疑问：我是将数据放在HttpSession中还是Request中，这里 其实已经开始接触状态，一旦你接触状态，你就要开始小心，因为你可能会将内存泄漏的恶魔导引进来。

　　内存泄漏的恶魔爆发时刻取决于你状态的生存周期和系统并发访问量。

　　状态的生存周期也就是包含这个状态的对象的生命周期，在简单系统中，我们只 需要通过new创建对象，然后它的消亡就会依靠JVM垃圾回收机制回收，但是事情会这么简单吗？

　　状态的危险还会发生在多线程环境下，当多个线程对同一个内存中状态写操作时，这时怎么办？如果这个状态持久化在数据库中，我们会依赖数据库提供的强大事务机制防止这种并发死锁，但是如果是在内存中，你就很难办，因此，我们就尽量避免发生这种多线程同时访问一个状态的现象，而Singleton单例模式极容易发生这种现象，因此实践中，单例模式是J2EE开发中需要避免的，相关帖子讨论见：
http://www.jdon.com/jive/article.jsp?forum=91&thread=17578

　　我们接触的Web容器或Jsp/Servlet本质就是一个多线程，这也是很多初学者不知道的， 因为多线程编程是复杂或困难的，因此才有jsp/Servlet这样的上层封装，但是我们使用他们
时，实际在进行多线程编程。

　　生命周期和多线程并发使得我们简单的面向对象系统变得异常复杂和难以掌握起来。下面我从这个两个角度，给出两种模式思维解决之道。

生命周期(Scope)

　　生命周期(Scope)就是指状态的活动周期，状态对象是什么时候被创建；然后什么时候被销毁，很显然，如果状态对象还没有被创建或已经被销毁，你再访问这个状态对象可能失败，而状态的生命周期控制是可能散落在运行程序的各个地方，如果不象状态模式那样进行统一控制，有可能整个系统是危机四伏的。

　　状态的生命周期其实就是对象生命周期，更加细化地说：是Domain Model这个对象的生命周期。这在一个以领域模型为驱动的设计概念中不可回避的课题，而领域模型实战的复杂性就复杂在此。

　　状态的生命周期在J2EE中目前有三种：Request/Session和Application，Request是每个客户端发出的一次请求，这是 J2EE系统中最基本的事件激活单元，当服务器端推出一个页面到客户端时，意味着这个Request的结束。那么如果我们的状态保存在Request中，意味着在request结束之前，这个请求经历的任何一个环节都可以对这个状态（对象）进行操作。（掌握这个原理，对于你学习Struts和JSF很有帮助）

　　如果是Session，则一直和该客户端有关，只要是该客户端发出的每次request的任何环节都可以对这个状态（对象）进行操作。

　　如果是Application，则意味着这个状态是当前Web项目的全局状态。

　　这三种状态形式都是以将状态保存在内存中形式存在的，是和持久化状态相对的。是一种内存活动状态。

　　生命周期的选取当然是越短越好，这样，这个状态对象就可以被自动销毁，从而避免了
大访问量下的内存泄漏，但是在大访问量下，对象频繁创建和销毁是耗费性能的。

　　那么，我们可能经常使用HttpSession来保存状态，这时你极有可能造成内存泄漏，我经常在Jdon论坛上看到将很多数据库数据暂时保存在 HttpSession中想法，这是相当危险的，因为一旦并发用户很多，相当多的HttpSession包含了状态，而状态中有可能有更多其他引用，因此内存很快会爆满，或者垃圾回收机制频繁启动，造成应用系统运行暂停或缓慢。

　　当你将状态放入HttpSession时，难道没有考虑将其手工消除吗？你要知道所有Web容器（Tomcat/Weblogic等）都不会自动替你清除那些你可能不用的状态对象啊。如果每个人只管新增元素，不管重整或管理，这个系统能不变得混乱吗？代码上这种现象我们是通过Refactoring等结构/行为模式来解决，那么在运行时的状态管理呢？

　　状态管理模式或者说对象管理模式正是解决这种问题的。

　　 按照该模式，你必须手工自己管理放在HttpSession的状态，比如你为每个HttpSession
设立一个状态容器最大尺寸，当超过这个尺寸时，你需要将不用的状态从容器去除， 但是如果这个客户端在Session失效期内又来访问这个状态怎么办？那么你可能需要先临时将状态序列化保存到硬盘上，等Session失效期到达后再真正删除。

　　是不是觉得很麻烦？
　　捷径是有：
　　1. 尽量少使用HttpSession保存状态，这对集群环境也是有利的，见该贴讨论：
http://www.jdon.com/jive/article.jsp?forum=121&thread=22282
那么这些状态放在哪里？使用Application的缓存中，

　　2. 使用状态管理中间件，目前有几个选择：EJB的有态Bean；NanoContainer之类状态相关的微容器。那么Spring可以吗？目前没有发现有该功能，甚至在Spring容器内无法直接使用Session性质的状态，只能通过线程级别的ThreadLocal来实现(对不起，你又要开始回到远古的汇编线程时代了)；而Jdon框架则可以。