状态对象：数据库替代者文库.docVIP

状态对象：数据库替代者文库 状态对象：数据库的替代者文库.txt铁饭碗的真实含义不是在一个地方吃一辈子饭，而是一辈子到哪儿都有饭吃。就算是一坨屎，也有遇见屎壳郎的那天。所以你大可不必为今天的自己有太多担忧。状态对象：数据库的替代者 板桥里人 2006/1/2（转载请保留） 　　这是一个实战中非常重要但是容易被忽视的概念，说它重要，是因为它比数据库重要；说它容易被忽视也是同样的原因，它经常被数据库概念替代。 　　如果你经验和经历中没有状态这个概念，极端地说：可能你的Java系统经验还未积累到一定程度，状态是每个Java程序员深入Java系统后必然碰到的问题。 　　本文我想试图表达的是：状态分两种：活动的状态对象和持久化的状态。而数据库中的数据只是状态的一种持久化结果，而Java系统 运行时，我们更多的可能是和一种活动的状态打交道，这种活动的状态存在内存中，而不是持久化到硬盘上，当然，需要时你可以通过数据库/文件持久化到硬盘上。 　　但是，如果你以数据库数据替代状态，那么就可能导致数据库的频繁访问，而且 你的系统会变成一个非对象化的、紧耦合、到处是分散数据块的糟糕系统。这样的系统并不比传统的两层结构好到哪里！也不会比Jsp里嵌入Java代码伪三层系统高明到什么地方。 什么是状态？ 　　只要有对象就可能有状态，任何一个对象活动时，都有自己的状态属性，类的 字段属性极有可能成为状态，我们现在经常使用的Domain model其实就是一种 包含状态的对象，如果你对状态没有深入掌握，就不可能真正掌握对象系统特点，或者是Domain Model的执行情况。 　　对于初学者，经常会疑问：我是将数据放在HttpSession中还是Request中，这里 其实已经开始接触状态，一旦你接触状态，你就要开始小心，因为你可能会将内存泄漏的恶魔导引进来。 　　内存泄漏的恶魔爆发时刻取决于你状态的生存周期和系统并发访问量。 　　状态的生存周期也就是包含这个状态的对象的生命周期，在简单系统中，我们只 需要通过new创建对象，然后它的消亡就会依靠JVM垃圾回收机制回收，但是事情会这么简单吗？ 　　状态的危险还会发生在多线程环境下，当多个线程对同一个内存中状态写操作时，这时怎么办？如果这个状态持久化在数据库中，我们会依赖数据库提供的强大事务机制防止这种并发死锁，但是如果是在内存中，你就很难办，因此，我们就尽量避免发生这种多线程同时访问一个状态的现象，而Singleton单例模式极容易发生这种现象，因此实践中，单例模式是J2EE开发中需要避免的，相关帖子讨论见： /jive/article.jsp?forum=91thread=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项目的全局状态。 　　这三种状态形式都是以将状态保存在内存中形式存在的，是和持久化状态相对的。是一种内存活动状态。 　　生命周期的选取当然是越短越好，这样，这个状态对象就可以被自动销毁，从而避免了 大访问量下的内存泄漏，但是在大访问量下，对象频繁创建和销毁是耗费性能的。