java开发150个建议( 九 ) _序列

其中的原理是这样的，保存到磁盘上(或网络传输)的对象文件包括两部分:
(1).类描述信息：包括类路径、继承关系、访问权限、变量描述、变量访问权限、方法签名、返回值、以及变量的关联类信息。要注意一点是，它并不是class文件的翻版，它不记录方法、构造函数、变量等的具体实现。之所以类描述会被保存，很简单，是因为能去也能回嘛，这保证反序列化的健壮运行。
(2).非瞬态(关键字)和非静态(关键字)的实体变量值
注意，这里的值如果是一个基本类型，好说，就是一个简单值保存下来；如果是复杂对象，也简单，连该对象和关联类信息一起保存，并且持续递归下去（关联类也必须实现接口，否则会出现序列化异常），也就是递归到最后，还是基本数据类型的保存。
正是因为这两个原因，一个持久化的对象文件会比一个class类文件大很多，有兴趣的读者可以自己测试一下，体积确实膨胀了不少。
总结一下：反序列化时final变量在以下情况下不会被重新赋值:
通过构造函数为final变量赋值通过方法返回值为final变量赋值final修饰的属性不是基本类型
回到顶部
建议14：使用序列化类的私有方法巧妙解决部分属性持久化问题
部分属性持久化问题看似很简单，只要把不需要持久化的属性加上瞬态关键字(关键字)即可。这是一种解决方案，但有时候行不通。例如一个计税系统和一个HR系统，通过RMI(,远程方法调用)对接，计税系统需要从HR系统获得人员的姓名和基本工资，以作为纳税的依据，而HR系统的工资分为两部分：基本工资和绩效工资，基本工资没什么秘密，绩效工资是保密的，不能泄露到外系统，这明显是连个相互关联的类，先看看薪水类的代码：
1 public class Salary implements Serializable {2private static final long serialVersionUID = 2706085398747859680L;3// 基本工资4private int basePay;5// 绩效工资6private int bonus;7 8public Salary(int _basepay, int _bonus) {9this.basePay = _basepay;10this.bonus = _bonus;11}12 //Setter和Getter方法略13 14 }
类和类是关联关系，代码如下:
1 public class Person implements Serializable {2 3private static final long serialVersionUID = 9146176880143026279L;4 5private String name;6 7private Salary salary;8 9public Person(String _name, Salary _salary) {10this.name = _name;11this.salary = _salary;12}13 14//Setter和Getter方法略15 16 }
这是两个简单的，都实现了接口，具备了序列化的条件。首先计税系统请求HR系统对一个对象进行序列化，把人员信息和工资信息传递到计税系统中，代码如下:
1 public class Serialize {2public static void main(String[] args) {3// 基本工资1000元，绩效工资2500元4Salary salary = new Salary(1000, 2500);5// 记录人员信息6Person person = new Person("张三", salary);7// HR系统持久化,并传递到计税系统8SerializationUtils.writeObject(person);9}10 }
在通过网络传输到计税系统后，进行反序列化，代码如下：
1 public class Deserialize {2public static void main(String[] args) {3Person p = (Person) SerializationUtils.readObject();4StringBuffer buf = new StringBuffer();5buf.append("姓名: "+p.getName());6buf.append("\t基本工资: "+p.getSalary().getBasePay());7buf.append("\t绩效工资: "+p.getSalary().getBonus());8System.out.println(buf);9}10 }
打印出的结果为:姓名: 张三基本工资: 1000 绩效工资: 2500
但是这不符合需求，因为计税系统只能从HR系统中获取人员姓名和基本工资，而绩效工资是不能获得的，这是个保密数据，不允许发生泄漏。怎么解决这个问题呢？你可能会想到以下四种方案:
在bonus前加上关键字：这是一个方法，但不是一个好方法，加上关键字就标志着失去了分布式部署的功能，它可能是HR系统核心的类了，一旦遭遇性能瓶颈，再想实现分布式部署就可能了，此方案否定;新增业务对象：增加一个类，完全为计税系统服务，就是说它只有两个属性：姓名和基本工资。符合开闭原则，而且对原系统也没有侵入性，只是增加了工作量而已。但是这个方法不是最优方法;请求端过滤：在计税系统获得对象后，过滤掉的bonus属性，方案可行但不符合规矩，因为HR系统中的类安全性竟然然外系统(计税系统来承担)，设计严重失职;变更传输契约：例如改用XML传输，或者重建一个服务，可以做但成本很高。