认识达内从这里开始

Java序列化之Serializable

昆明IT培训的老师提醒注意：并不是所有类都需要进行序列化，主要原因有两个

1）安全问题。Java中有的类属于敏感类，此类的对象数据不便对外公开，而序列化的对象数据很容易进行破解，无法保证其数据的安全性，因此一般这种类型的对象不会进行序列化。

2）资源问题。可以使用序列化字节流创建对象，而且这种创建时不受限制的，有时过多地创建对象会造成很大的资源问题，因此此类对象也不适宜进行序列化。

Serializable

Serializable是Java提供的一个序列化接口，它是一个空接口，专门为对象提供标准的序列化跟反序列化操作。

序列化过程：

1 Person p = new Person("name","id");

2        File file = new File("cache.txt");

3        FileOutputStream output = new FileOutputStream(file);

4        ObjectOutputStream objectOutputStream = new ObjectOutputStream(output);

5        objectOutputStream.writeObject(p);

6        output.close();

7        objectOutputStream.close();

反序列化过程：

1File file = new File("cache.txt");

2        FileInputStream input= new FileInputStream(file);

3        ObjectInputStream objectInputStream = ew ObjectInputStream(input);

4        Person p = (Person)objectInputStream.readObject();

5        System.out.println(p.getName()+"---"+p.getId());

6        input.close();

7        objectInputStream.close();

需要序列化的类成员

对象序列化时并不是所有成员都要转换成二进制的字节序列，因为为了节省存储或传输空间以及提高序列化效率，有些不必要的成员是无需序列化的。其中包括：

静态变量。因为静态变量属于类的属性，并不属于某个具体实例，因此在序列化的时候无须进行序列化，反序列化时，可以直接获取类的静态成员引用。

方法。方法只是一系列的操作集合，方法不会依赖对象，不会因为对象的不同，而操作不同，反序列化时，也可以从类中直接获取方法信息。

继承关系的序列化

父类实现Serializable时，子类被序列化，父类也会被序列化。

父类没有实现Serializable时，子类被序列化，父类不会被序列化

引用关系的序列化

如果对一个实现了Serializable的类进行序列化操作，则同时对它的引用类进行序列化操作。如果引用类没有实现Serializable接口，JVM会抛出java.io.NotSerializableExeception.

1 class Person implements Serializable{

2    private String name;

3    private Tool tool = new Tool();

4 }

5

6 class Tool implements Serializable{

7    

8 }

此时对Person类进行序列化操作，则会同时对Tool类进行序列化操作。若Tool类没有实现Serializable接口，则会抛出异常。

保护敏感数据：

一个类加上序列化标识后，该类对象的所有属性信息将被序列化，然后进行本地存储或网络传输。然后有时对象中的某些字段属于敏感信息，不应暴露出来。如果对其也进行序列化，容易被破解，从而  造成安全隐患，例如常见的密码字段。

Java提供一个关键字transient，即瞬时关键字。该关键字关闭字段的序列化，这样受保护的信息就不会因为序列化而对外暴露。

序列化标识ID

试想一下这样的情景：两端进行网络传输序列化对象，由于某种原因，导致两端使用的类的版本不同，假设接收方的类被删除了几个字段。当发送发将对象的序列化字节流发送到接收方时，由于接收方的类少了几个字段，而无法解析。 

Java要求实现序列化接口的类都必须声明一个serialVersionUID静态属性，如果没有该属性JVM也会自动声明该属性，并为该属性赋值（当类发生改变时会赋予不同的值）。该属性的值是唯一的，用于标识不同的序列化类。只有类的序列化标识完全相同，Java才会进行反序列化工作，这就是序列化标识的作用。

对于前面提到的情景，假设没有手动声明serialVersionUID，则JVM对发送方跟接收方使用的类中的serialVersionUID赋予不同的值，则反序列化失败。当手动给serialVersionUID赋值时，即使类的字段发生改变，也能够反序列化成功。

自定义序列化策略

定制序列化策略    

Java提供了一套有效的机制，允许在序列化和反序列化时，使用定制的方法进行相应的处理。当传输双方协定好序列化策略后，只需要在需要传输的序列化类中添加一组方法来实现这组策略，在序列化时会自动调用这些规定好的方法进行序列化和反序列化。方法如下：

1）private void writeObject(ObjectOutputSteam out) throws IOException

在方法的内部有重要的代码：out.defaultWriteObject() //将对象数据以默认方式写入到输出流中

2）private void readObject(ObjectInputStream in) throws IOException,ClassNotFoundException

同样的，此方法内部也有相似代码：in.defaultReadObject();//以默认方式从输入流中恢复对象

这两个方法的作用分别是将特定的对象写入到输出流中以及从输入流中恢复特定的对象，通过这两个方法，用户即可实现自定义的序列化。当在实现Serializable接口的类中写了上面两个方法之后，序列化或反序列化该类时则会通过反射来调用这两个方法，从而实现自定义序列化。

限制序列化对象的数量    

我们看下面的单例模式：

1 public class Singleton implements Serializable {

2

3    private volatile static Singleton mInstance;

4    private Singleton() {

5    }

6

7    public static Singleton getInstance() {

8        if (mInstance == null) {

9            synchronized (Singleton.class) {

10                if (mInstance == null) {

11                    mInstance = new Singleton();

12                }

13            }

14        }

15        return mInstance;

16    }

17 }

此时通过反序列化获取实例，则单例模式会失效。那该如何解决这个问题呢？

Java有一种机制，可以让我们在序列化和反序列化时，可以根据自己的需要，写入或读取指定的实例。使用这种机制，需要在实现Serializable接口的类中添加两个方法：

private Object readResolve()//如果用户在序列化类中添加了该方法，则在进行反序列化时，使用该方法返回的对象，作为反序列化对象。

private Object writeReplace()//如果用户在序列化类中添加了该方法，则在进行序列化时，序列化该类返回的对象。

再看使用了该机制的单例模式：

1 1 public class Singleton implements Serializable {

2 2

3 3    private volatile static Singleton mInstance;

4 4    private Singleton() {

5 5    }

6 6

7 7    public static Singleton getInstance() {

8 8        if (mInstance == null) {

9 9            synchronized (Singleton.class) {

10 10                if (mInstance == null) {

11 11                    mInstance = new Singleton();

12 12                }

13 13            }

14 14        }

15 15        return mInstance;

16 16    }

17 17

18 18    private Object readResolve() {

19 19        return getInstance();

20 20    }

21 21

22 22    private Object writeReplace() {

23 23        return getInstance();

24 24    }

25 25 }