把该字节序列保存起来(例如:保存在一个文件里),以后可以随时将该字节序列恢复为原来的对象。甚至可以将该字节序列放到其他计算机上或者通过网络传输到其他计算机上恢复,只有该计算机平台存在相应的类就可以正常恢复为原来的对象。
一个对象实现Serializable接口序列化,先要创建某些OutputStream对象,然后将其封装在一个ObjectOutputStream对象内,再调用writeObject()方法,即可序列化一个对象,反序列化,InputStream,再调用readObject()方法。(writeObject和readObject本身就是线程安全的,传输过程中是不允许被并发访问的,所以对象只能一个一个接连不断的传过来)。
如果某个类能够被序列化,其子类也可以被序列化。声明为static和transient类型的成员数据不能被序列化。因为static代表类的状态,transient代表对象的临时数据,static对象变量在反序列化时取得的值为当前jvm中对应类中对应static变量的值,而transient(瞬态)关键字则一般用于标识那些在序列化时不需要传递的状态变量。
序列化时为了保持版本的兼容性,即在版本升级时反序列化仍保持对象的唯一性。
有两种生成方式:
一个是默认的1L,比如:private static final long serialVersionUID = 1L;
一个是根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段,比如:
private static final long serialVersionUID = xxxxL;
当你一个类实现了Serializable接口,如果没有定义serialVersionUID,Eclipse会提供这个提示功能告诉你去定义 。在Eclipse中点击类中warning的图标一下,Eclipse就会自动给定两种生成的方式。如果不想定义它,在Eclipse的设置中也
可以把它关掉的,设置如下:
Window ==> Preferences ==> Java ==> Compiler ==> Error/Warnings ==>
Potential programming problems
将Serializable class without serialVersionUID的warning改成ignore即可。
如果你没有考虑到兼容性问题时,就把它关掉,不过有这个功能是好的,只要任何类别实现了Serializable这个接口的话,如果没有加入serialVersionUID,Eclipse都会给你warning提示,这个serialVersionUID为了让该类别Serializable向后兼容。
如果你的类Serialized存到硬盘上面后,可是后来你却更改了类的field(增加或减少或改名),当你Deserialize时,就会出现Exception的,这样就会造成不兼容性的问题。
但当serialVersionUID相同时,它就会将不一样的field以type的预设值Deserialize,可避开不兼容性问题。
注意以下几点:
1、若继承的父类没有实现Serializable接口,但是又想让子类可序列化,子类实现Serializable接口,子类必须有可访问的无参构造方法,用于保存和恢复父类的public或protected或同包下的package字段的状态,否则在序列化或反序列化时会抛出RuntimeException异常,对于序列化后的子类,在进行反序列化时,理论上无法初始化父类中private(不可访问)对象变量的状态或值。
2、在对可序列化类中的属性进行序列化时,如果遇到不可序列化的对象变量,此时会针对不可序列化的类抛出NotSerializableException异常
3、对于可序列化的非数组类,强烈建议显示声明static型、long型、final型serialVersionUID字段用于标识当前序列化类的版本号,否则在跨操作系统、跨编译器之间进行序列化和反序列化时容易出现InvalidClassException异常
ps:java对象在内存中的状态
可以把JVM内存中的对象的引用理解成一种有向图,把引用变量、对象都当作有向图的顶点,将引用关系当作图的有向边,有向边总是从引用端指向被引用的Java对象。因为Java的所有对象都是由一条条线程创建出来的,因此可以把线程对象当作有向图的起始顶点(对于单线程,miain线程作为起点)。
1、可达状态
当一个对象被创建后,有一个以上的引用变量引用它。在有向图中可以从起始顶点导航到该对象,那么它就出于可达状态,程序可以通过引用变量来调用该对象的属性和方法。
2、可恢复状态
如果程序中某个对象不再有任何引用变量引用它,他将进入可恢复状态,此时从有向图的起始顶点不能导航到该对象。在这种状态下,系统的垃圾回收机制转变回收该对象所占用的内存。在回收该对象之前,系统会调用可恢复状态的对象的finalize方法进行资源清理,如果系统调用finalize方法重新让一个以上的引用变量引用该对象,则该对象会再次编程可达状态;否则,该对象将进入不可达状态。
3、不可达状态
当对象的所有关联都被切断,且系统调用所有对象的finalize方法依然没有使该对象变成可达状态后,这个对象将永久性地失去引用,最后变成不可达状态。只有当一个对象出于不可达状态,系统才会真正回收该对象所占用的资源。
Q:什么情况下会有线程安全问题
A:当某个实现多线程的线程类中有实例变量时
ps:有状态,无状态对象是什么概念
有状态就是有数据存储功能。有状态对象(Stateful Bean),就是有实例变量的对象 ,可以保存数据,是非线程安全的。在不同方法调用间不保留任何状态。
无状态就是一次操作,不能保存数据。无状态对象(Stateless Bean),就是没有实例变量的对象 .不能保存数据,是不变类,是线程安全的。
代码更好理解:
public class StatefulBean {
public int state;
// 由于多线程环境下,user是引用对象,是非线程安全的
public User user;
public int getState() {
return state;
}
public void setState( int state) {
this .state = state;
}
public User getUser() {
return user;
}
public void setUser(User user) {
this .user = user;
}
}
public class StatelessBeanService {
// 虽然有billDao属性,但billDao是没有状态信息的,是Stateless Bean.
BillDao billDao;
public BillDao getBillDao() {
return billDao;
}
public void setBillDao(BillDao billDao) {
this .billDao = billDao;
}
public List<User> findUser(String Id) {
return null ;
}
}
单例模式中的有状态和无状态:
单例类可以是有状态的(stateful),一个有状态的单例对象一般也是可变(mutable)单例对象 。 有状态的可变的单例对象常常当做状态库(repositary)使用。比如一个单例对象TaskCache(Spring中配为singleton)可以 持有一个AtomicLong类型的属性,用来给一个系统提供一个数值惟一的序列号码,作为任务通迅管理的ID生成器。同时,一个单例类也可以持有一个聚 集,从而允许存储多个状态,如示例中的ExpiringMap缓存任务列表。
代码示例:
import java.util.concurrent.atomic.AtomicLong;
import org.apache.mina.util.ExpiringMap;
public class TaskCache {
// 请求超时
private short requestTimeout;
// 这个缓存Map是线程安全,并且有定时超时功能
private ExpiringMap<String, Object> tasksMap = new ExpiringMap<String, Object>();
// 线程安全的原子类,示例有状态的单例类
private static AtomicLong seqNo = new AtomicLong( 1 );
// 示例有状态的单例类
public Long nextSeqNo() {
return seqNo.getAndIncrement();
}
public void setRequestTimeout( short requestTimeout) {
this .requestTimeout = requestTimeout;
}
// 启动过期检测
public void startExpiring() {
tasksMap.getExpirer().setTimeToLive(requestTimeout);
tasksMap.getExpirer().startExpiringIfNotStarted();
}
// 停止过期检测
public void stopExpiring() {
tasksMap.getExpirer().stopExpiring();
}
// 取任务列表.
public Object getTasks(String key) {
return tasksMap.get(key);
}
// 去除任务列表.
public Object removeTasks(String key) {
return tasksMap.remove(key);
}
// 添加任务列表.
public void addTasks(String key, Object value) {
tasksMap.put(key, value);
}
}
单例类也可以是没有状态的(stateless) ,仅用做提供工具性函数的对象。既然是为了提供工具性函数,也就没有必要创建多个实例,因此使用单例模式很合适。平常的单例类都是没有状态的,这里就不示例了。一个没有状态的单例类也就是不变(Immutable)单例类。关于不变模式,请参考 http://www.javaeye.com/topic/959751
EJB中的有状态与无状态:
1.Stateful session bean的每个用户都有自己的一个实例,所以两者对stateful session bean的操作不会影响对方。另外注意:如果后面需要操作某个用户的实例,你必须在客户端缓存Bean的Stub对象(JSP通常的做法是用Session缓存),这样在后面每次调用中,容器才知道要提供相同的bean实例。
2.Stateless Session Bean不负责记录使用者状态,Stateless Session Bean一旦实例化就被加进会话池中,各个用户都可以共用。如果它有自己的属性(变量),那么这些变量就会受到所有调用它的用户的影响。
3.从内存方面来看,Stateful Session Bean与Stateless Session Bean比较,Stateful Session Bean会消耗J2EE Server 较多的内存,然而Stateful Session Bean的优势却在于他可以维持使用者的状态
Spring中的有状态(Stateful)和无状态(Stateless)
1.通过上面的分析,相信大家已经对有状态和无状态有了一定的理解。无状态的Bean适合用不变模式,技术就是单例模式,这样可以共享实例,提高性能。有状态的Bean,多线程环境下不安全,那么适合用Prototype原型模式。Prototype: 每次对bean的请求都会创建一个新的bean实例。
2.默认情况下,从Spring bean工厂所取得的实例为singleton(scope属性为singleton),容器只存在一个共享的bean实例。
3.理解了两者的关系,那么scope选择的原则就很容易了:有状态的bean都使用prototype作用域,而对无状态的bean则应该使用singleton作用域。
4.如Service层、Dao层用默认singleton就行,虽然Service类也有dao这样的属性,但dao这些类都是没有状态信息的,也就是 相当于不变(immutable)类,所以不影响。Struts2中的Action因为会有User、BizEntity这样的实例对象,是有状态信息 的,在多线程环境下是不安全的,所以Struts2默认的实现是Prototype模式。在Spring中,Struts2的Action中,scope 要配成prototype作用域。
Servlet、Struts中的有状态和无状态:
1.Servlet体系结构是建立在Java多线程机制之上的,它的生命周期是由Web 容器负责的。一个Servlet类在Application中只有一个实例存在,也就是有多个线程在使用这个实例。这是单例模式的应用。无状态的单例是线 程安全的,但我们如果在Servlet里用了实例变量,那么就变成有状态了,是非线程安全的。如下面的用法就是不安全的,因为user,out都是有状态 信息的。
public class UnSafeServlet HttpServlet{
User user;
PrintWriter out;
public void doGet (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{
//do something...
}
}
Out,Request,Response,Session,Config,Page,PageContext是线程安全的,Application在整个系统内被使用,所以不是线程安全的.
2.Struts1也是基于单例模式实现,也就是只有一个Action实例供多线程使用。默认的模式是前台页面数据通过actionForm传入,在 action中的excute方法接收,这样action是无状态的,所以一般情况下Strunts1是线程安全的。如果Action中用了实例变量,那 么就变成有状态了,同样是非线程安全的。像下面这样就是线程不安全的。
public class UnSafeAction1 extends Action {
// 因为Struts1是单例实现,有状态情况下,对象引用是非线程安全的
User user;
public void execute() {
// do something...
}
public User getUser() {
return user;
}
public void setUser(User user) {
this .user = user;
}
}
3.Struts2默认的实现是Prototype模式。也就是每个请求都新生成一个Action实例,所以不存在线程安全问题。需要注意的是,如果由Spring管理action的生命周期, scope要配成prototype作用域。
4.如何解决Servlet和Struts1的线程安全问题,当我们能比较好的理解有状态和无状态的原理,自然很容易得出结论:不要使用有状态的bean,也就是不要用实例变量 。如果用,就要用prototype模式。Struts1 user guide里有: Only Use Local Variables - The most important principle that aids in thread-safe coding is to use only local variables, not instance variables , in your Action class.
总结:
Stateless无状态用单例Singleton模式,Stateful有状态就用原型Prototype模式。
Stateful 有状态是多线程编码的天敌,所以在开发中尽量用Stateless无状态,无状态是不变(immutable)模式的应用,有很多优点:不用管线程和同步的问题 ,如果值是不可变的,程序不用担心多个线程改变共享状态,所以可以避免线程竞争的bugs. 因为没有竞争,就不用用locks等机制,所以无状态的不变机制,也可以避免产生死锁现象。
国外一些哥们的观点:
Immutable objects may not be altered after their creation. So: Yes, they are some kind of stateless.As immutable objects can not be changed, there is no need for locking - reading access to objects is always threadsafe (when not modifying variables). Therefore, real immutable objects are always threadsafe.
Rod Johnson大叔的观点:
Stateless or Stateful?
Service objects will usually be stateless. Stateless service layers are highly scalable: They pose no replication issues and there is no need to allocate additional resources for every client. (Remember that one of
the key motivations of a middle tier is to share resources between multiple clients.) It is also much easier for stateless service layers to support remote clients, if necessary. A stateless service layer is one concession of object orientation that I find not too painful.
此处省去N个字。
If possible, design applications to use a stateless service layer. Hold state in the web tier, rather than in the business logic tier, if possible.
简单说就是为了保存在内存中的各种对象的状态(也就是实例变量,不是方法),并且可以把保存的对象状态再读出来。虽然你可以用你自己的各种各样的方法来保存object states,但是Java给你提供一种应该比你自己好的保存对象状态的机制,那就是序列化。
2、什么情况下需要序列化
a)当你想把的内存中的对象状态保存到一个文件中或者数据库中时候;
b)当你想用套接字在网络上传送对象的时候;
c)当你想通过RMI传输对象的时候;
3、当对一个对象实现序列化时,究竟发生了什么?
在没有序列化前,每个保存在堆(Heap)中的对象都有相应的状态(state),即实例变量(instance ariable)比如:
Foo myFoo = new Foo();
myFoo .setWidth(37);
myFoo.setHeight(70);
当 通过下面的代码序列化之后,MyFoo对象中的width和Height实例变量的值(37,70)都被保存到foo.ser文件中,这样以后又可以把它 从文件中读出来,重新在堆中创建原来的对象。当然保存时候不仅仅是保存对象的实例变量的值,JVM还要保存一些小量信息,比如类的类型等以便恢复原来的对 象。
FileOutputStream fs = new FileOutputStream("foo.ser");
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(myFoo);
4、实现序列化(保存到一个文件)的步骤a)Make a FileOutputStream
FileOutputStream fs = new FileOutputStream("foo.ser");
b)Make a ObjectOutputStream
ObjectOutputStream os = new ObjectOutputStream(fs);
c)write the object
os.writeObject(myObject1);
os.writeObject(myObject2);
os.writeObject(myObject3);
d) close the ObjectOutputStream
os.close();
5、举例说明import java.io.*;
public class Box implements Serializable
{
private int width;
private int height;
public void setWidth(int width){
this.width = width;
}
public void setHeight(int height){
this.height = height;
}
public static void main(String[] args){
Box myBox = new Box();
myBox.setWidth(50);
myBox.setHeight(30);
try{
FileOutputStream fs = new FileOutputStream("foo.ser");
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(myBox);
os.close();
}catch(Exception ex){
ex.printStackTrace();
}
}
}
6、相关注意事项a)序列化时,只对对象的状态进行保存,而不管对象的方法;
b)当一个父类实现序列化,子类自动实现序列化,不需要显式实现Serializable接口;
c)当一个对象的实例变量引用其他对象,序列化该对象时也把引用对象进行序列化;
d)并非所有的对象都可以序列化,,至于为什么不可以,有很多原因了,比如:
1.安全方面的原因,比如一个对象拥有private,public等field,对于一个要传输的对象,比如写到文件,或者进行rmi传输 等等,在序列化进行传输的过程中,这个对象的private等域是不受保护的。
2. 资源分配方面的原因,比如socket,thread类,如果可以序列化,进行传输或者保存,也无法对他们进行重新的资源分 配,而且,也是没有必要这样实现。