Java 序列化

Java 序列化

---

标记接口

 public interface Serializable{}

正如你看到的，序列化就是这么简单，这个简单的外观，却隐藏着巨大的知识点

什么是序列化

Java的”对象序列化”能让你将一个实现了Serializable接口的对象转换成byte流，这样日后要用这个对象时候，你就能把这些byte数据恢复出来，并据此重新构建那个对象了。

为什么要序列化

简单说就是为了保存在内存中的各种对象的状态，并且可以把保存的对象状态再读出来。虽然你可以用你自己的各种各样的方法来保存Object States，但是Java给你提供一种应该比你自己好的保存对象状态的机制,那就是序列化。

什么情况下需要序列化

• 当你想把的内存中的对象保存到一个文件中或者数据库中时候；
• 当你想用套接字在网络上传送对象的时候；
• 当你想通过RMI传输对象的时候；
• Android中通过Intent传递数据的时候；

序列化发生了什么

• Make a FileOutputStream

FileOutputStream fs = new FileOutputStream("foo.ser");

• Make a ObjectOutputStream

ObjectOutputStream os = new ObjectOutputStream(fs);

• Write the object

os.writeObject(myObject1);

• Close the ObjectOutputStream

os.close();

Foo myFoo = new Foo();
myFoo .setWidth(37);
myFoo.setHeight(70);

当通过下面的代码序列化之后，MyFoo对象中的width和Height实例变量的值（37，70）都被保存到foo.ser文件中，这样以后又可以把它从文件中读出来，重新在堆中创建原来的对象。当然保存时候不仅仅是保存对象的实例变量的值，JVM还要保存一些小量信息，比如类的类型等以便恢复原来的对象。

要想序列化对象，你必须先创建一个OutputStream，然后把它嵌进ObjectOutputStream。这时，你就能用writeObject()方法把对象写入OutputStream了。

writeObject()方法负责写入特定类的对象的状态，以便相应的 readObject()方法可以还原它。通过调用 out.defaultWriteObject 可以调用保存 Object 的字段的默认机制。该方法本身不需要涉及属于其超类或子类的状态。状态是通过使用 writeObject 方法或使用 DataOutput 支持的用于基本数据类型的方法将各个字段写入 ObjectOutputStream 来保存的。

读的时候，你得把InputStream嵌到ObjectInputStream里面，然后再调用readObject()方法。不过这样读出来的，只是一个Object的reference，因此在用之前，还得先下传。readObject() 方法负责从流中读取并还原类字段。它可以调用 in.defaultReadObject 来调用默认机制，以还原对象的非静态和非瞬态字段。　 defaultReadObject()方法使用流中的信息来分配流中通过当前对象中相应命名字段保存的对象的字段。这用于处理类发展后需要添加新字段的情形。该方法本身不需要涉及属于其超类或子类的状态。状态是通过使用 writeObject 方法或使用 DataOutput 支持的用于基本数据类型的方法将各个字段写入 ObjectOutputStream 来保存的。

Demo

public class Box implements Serializable {
    private static final long serialVersionUID = -3450064362986273896L;

    private int width;
    private int height;

    public static void main(String[] args) {
        Box myBox=new Box();
        myBox.setWidth(50);
        myBox.setHeight(30);
        try {
            FileOutputStream fs=new FileOutputStream("F:\\foo.ser");
            ObjectOutputStream os=new ObjectOutputStream(fs);
            os.writeObject(myBox);
            os.close();
            FileInputStream fi=new FileInputStream("F:\\foo.ser");
            ObjectInputStream oi=new ObjectInputStream(fi);
            Box box=(Box)oi.readObject();
            oi.close();
            System.out.println(box.height+","+box.width);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public int getWidth() {
        return width;
    }
    public void setWidth(int width) {
        this.width = width;
    }
    public int getHeight() {
        return height;
    }
    public void setHeight(int height) {
        this.height = height;
    }
}

为什么有些类不会序列化

• 安全方面的原因，比如一个对象拥有private，public等field，对于一个要传输的对象，比如写到文件，或者进行rmi传输 等等，在序列化进行传输的过程中，这个对象的private等域是不受保护的。
• 资源分配方面的原因，比如socket，thread类，如果可以序列化，进行传输或者保存，也无法对他们进行重新的资源分配，而且，也是没有必要这样实现。

注意事项

• 当一个对象被序列化时，只保存对象的非静态成员变量（包括声明为private的变量），不能保存任何的成员方法和静态的成员变量。
• 如果一个对象的成员变量是一个对象，那么这个对象的数据成员也会被序列化。
• 如果一个可序列化的对象包含对某个不可序列化的对象的引用，那么整个序列化操作将会失败，并且会抛出一个NotSerializableException。我们可以将这个引用标记为transient，那么对象仍然可以序列化。
• 当一个父类实现序列化，子类自动实现序列化，不需要显式实现Serializable接口；
• 当一个对象的实例变量引用其他对象，序列化该对象时也把引用对象进行序列化；

serialVersionUID

序列化运行时使用一个称为 serialVersionUID 的版本号与每个可序列化类相关联，该序列号在反序列化过程中用于验证序列化对象的发送者和接收者是否为该对象加载了与序列化兼容的类。如果接收者加载的该对象的类的 serialVersionUID 与对应的发送者的类的版本号不同，则反序列化将会导致 InvalidClassException。可序列化类可以通过声明名为 “serialVersionUID” 的字段（该字段必须是静态 (static)、最终 (final) 的 long 型字段）显式声明其自己的 serialVersionUID：

 ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

如果可序列化类未显式声明 serialVersionUID，则序列化运行时将基于该类的各个方面计算该类的默认 serialVersionUID 值，如“Java(TM) 对象序列化规范”中所述。不过，强烈建议 所有可序列化类都显式声明 serialVersionUID 值，原因是计算默认的 serialVersionUID 对类的详细信息具有较高的敏感性，根据编译器实现的不同可能千差万别，这样在反序列化过程中可能会导致意外的 InvalidClassException。因此，为保证 serialVersionUID 值跨不同 java 编译器实现的一致性，序列化类必须声明一个明确的 serialVersionUID 值。还强烈建议使用 private 修饰符显示声明 serialVersionUID（如果可能），原因是这种声明仅应用于直接声明类 – serialVersionUID 字段作为继承成员没有用处。数组类不能声明一个明确的 serialVersionUID，因此它们总是具有默认的计算值，但是数组类没有匹配 serialVersionUID 值的要求。

此篇博文参考并修改自：http://www.cnblogs.com/gw811/archive/2012/10/10/2718331.html