使用序列化类的私有方法巧妙解决部分属性持久化问题-优快云博客

来源：http://book.51cto.com/art/201202/317465.htm

部分属性持久化问题看似很简单，只要把不需要持久化的属性加上瞬态关键字（transient关键字）即可。这是一种解决方案，但有时候行不通。例如一个计税系统和人力资源系统（HR系统）通过RMI（Remote Method Invocation，远程方法调用）对接，计税系统需要从HR系统获得人员的姓名和基本工资，以作为纳税的依据，而HR系统的工资分为两部分：基本工资和绩效工资，基本工资没什么秘密，根据工作岗位和年限自己都可以计算出来，但绩效工资却是保密的，不能泄露到外系统，很明显这是两个相互关联的类。先来看薪水类Salary类的代码：

public class Salary implements Serializable{  
     private static final long serialVersionUID = 44663L;     
    //基本工资  
     private int basePay;  
     //绩效工资  
     private int bonus;  

     public Salary(int _basePay,int _bonus){  
           basePay = _basePay;  
           bonus = _bonus;  
     }  
     /*getter/setter方法省略*/  

}

Peron类与Salary类是关联关系，代码如下：

public class Person implements Serializable{  
     private static final long serialVersionUID =60407L;  
     //姓名  
     private String name;  
     //薪水  
     private Salary salary;  

     public Person(String _name,Salary _salary){  
           name=_name;  
           salary=_salary;  
     }    
     /*getter/setter方法省略*/  
}

这是两个简单的JavaBean，都实现了Serializable接口，都具备了持久化条件。首先计税系统请求HR系统对某一个Person对象进行序列化，把人员和工资信息传递到计税系统中，代码如下：

public class Serialize {  
     public static void main(String[] args) {  
           //基本工资1000元,绩效工资2500元  
           Salary salary = new Salary(1000,2500);  
           //记录人员信息  
           Person person = new Person("张三",salary);  
           //HR系统持久化，并传递到计税系统  

           SerializationUtils.writeObject(person);  
    }  
}

在通过网络传送到计税系统后，进行反序列化，代码如下：

public class Deserialize {  
     public static void main(String[] args) {  
           //技术系统反序列化，并打印信息  
           Person p = (Person)SerializationUtils.readObject();  
           StringBuffer sb = new StringBuffer();  
           sb.append("姓名:" + p.getName());  
           sb.append("\t基本工资：" + p.getSalary().getBasePay());  
           sb.append("\t绩效工资：" + p.getSalary().getBonus());  
           System.out.println(sb);  
     }  
}

打印出的结果很简单：

姓名：张三基本工资：1000 绩效工资：2500。

但是这不符合需求，因为计税系统只能从HR系统中获得人员姓名和基本工资，而绩效工资是不能获得的，这是个保密数据，不允许发生泄露。怎么解决这个问题呢？你可能马上会想到四种方案：

（1）在bonus前加上transient关键字

这是一个方法，但不是一个好方法，加上transient关键字就标志着Salary类失去了分布式部署的功能，它可是HR系统最核心的类了，一旦遭遇性能瓶颈，想再实现分布式部署就不可能了，此方案否定。

（2）新增业务对象

增加一个Person4Tax类，完全为计税系统服务，就是说它只有两个属性：姓名和基本工资。符合开闭原则，而且对原系统也没有侵入性，只是增加了工作量而已。这是个方法，但不是最优方法。

（3）请求端过滤

在计税系统获得Person对象后，过滤掉Salary的bonus属性，方案可行但不合规矩，因为HR系统中的Salary类安全性竟然让外系统（计税系统）来承担，设计严重失职。

（4）变更传输契约

例如改用XML传输，或者重建一个 Web Service服务。可以做，但成本太高。

可能有读者会说了，你都在说别人的方案不好，你提供个优秀的方案看看！好的，这就展示一个优秀的方案。其中，实现了Serializable接口的类可以实现两个私有方法：writeObject和readObject，以影响和控制序列化和反序列化的过程。我们把Person类稍做修改，看看如何控制序列化和反序列化，代码如下：

public class Person implements Serializable{  
     private static final long serialVersionUID =60407L;  
     //姓名  
     private String name;  
     //薪水  
     private transient Salary salary;  
     public Person(String _name,Salary _salary){  
           name=_name;  
           salary=_salary;  
     }    
     //序列化委托方法  
     private void writeObject(java.io.ObjectOutputStream out)
                  throws IOException {  
           out.defaultWriteObject();  
           out.writeInt(salary.getBasePay());  
     }  
     //反序列化时委托方法  
     private void readObject(java.io.ObjectInputStream in) 
                          throws IOException,ClassNotFoundException {  
        in.defaultReadObject();  
        salary = new Salary(in.readInt(),0);  
    }  
}

其他代码不做任何改动，我们先运行看看，结果为：

姓名：张三基本工资：1000 绩效工资：0 。

我们在Person类中增加了writeObject和readObject两个方法，并且访问权限都是私有级别，为什么这会改变程序的运行结果呢？其实这里使用了序列化独有的机制：序列化回调。Java调用ObjectOutputStream类把一个对象转换成流数据时，会通过反射（Reflection）检查被序列化的类是否有writeObject方法，并且检查其是否符合私有、无返回值的特性。若有，则会委托该方法进行对象序列化，若没有，则由ObjectOutputStream按照默认规则继续序列化。同样，在从流数据恢复成实例对象时，也会检查是否有一个私有的readObject方法，如果有，则会通过该方法读取属性值。此处有几个关键点要说明：

（1）out.defaultWriteObject()

告知JVM按照默认的规则写入对象，惯例的写法是写在第一句话里。

（2）in.defaultReadObject()

告知JVM按照默认规则读入对象，惯例的写法也是写在第一句话里。

（3）out.writeXX和in.readXX

分别是写入和读出相应的值，类似一个队列，先进先出，如果此处有复杂的数据逻辑，建议按封装Collection对象处理。

可能有读者会提出，这似乎不是一种优雅的处理方案呀，为什么JDK没有对此提供一个更好的解决办法呢？比如访问者模式，或者设置钩子函数（Hook），完全可以更优雅地解决此类问题。我查阅了大量的文档，得出的结论是：无解，只能说这是一个可行的解决方案而已。

再回到我们的业务领域，通过上述方法重构后，其代码的修改量减少了许多，也优雅了许多。可能你又要反问了：如此一来，Person类也失去了分布式部署的能力啊。确实是，但是HR系统的难点和重点是薪水计算，特别是绩效工资，它所依赖的参数很复杂（仅从数量上说就有上百甚至上千种），计算公式也不简单（一般是引入脚本语言，个性化公式定制），而相对来说Person类基本上都是“静态"属性，计算的可能性不大，所以即使为性能考虑，Person类为分布式部署的意义也不大。