部分属性持久化问题看似很简单，只要把不需要持久化的属性加上瞬态关键字（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（Stringargs）{
//基本工资1000元，绩效工资2500元
Salary salary=new Salary（1000，2500）；
//记录人员信息
Person person=new Person（/"张三/"，salary）；
//HR系统持久化，并传递到计税系统
SerializationUtils.writeObject（person）；
}
}
在通过网络传送到计税系统后，进行反序列化，代码如下：
public class Deserialize{
public static void main（Stringargs）{
//技术系统反序列化，并打印信息
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, Class-
NotFoundException{
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类为分布式部署的意义也不大。