你的位置:首页 > Java教程

[Java教程]编写高质量代码:改善Java程序的151个建议(第1章:JAVA开发中通用的方法和准则___建议11~15)


建议11:养成良好习惯,显示声明UID

我们编写一个实现了Serializable接口(序列化标志接口)的类,Eclipse马上就会给一个黄色警告:需要添加一个Serial Version ID。为什么要增加?他是怎么计算出来的?有什么用?下面就来解释该问题。

  类实现Serializable接口的目的是为了可持久化,比如网络传输或本地存储,为系统的分布和异构部署提供先决条件支持。若没有序列化,现在我们熟悉的远程调用、对象数据库都不可能存在,我们来看一个简单的序列化类:

 1 import java.io.Serializable; 2 public class Person implements Serializable { 3   private String name; 4  5   public String getName() { 6     return name; 7   } 8  9   public void setName(String name) {10     this.name = name;11   }12 13 }

这是一个简单的JavaBean,实现了Serializable接口,可以在网络上传输,也可以在本地存储然后读取。这里我们以java消息服务(Java Message Service)方式传递对象(即通过网络传递一个对象),定义在消息队列中的数据类型为ObjectMessage,首先定义一个消息的生产者(Producer),代码如下:

1 public class Producer {2   public static void main(String[] args) {3     Person p = new Person();4     p.setName("混世魔王");5     // 序列化,保存到磁盘上6     SerializationUtils.writeObject(p);7   }8 }

这里引入了一个工具类SerializationUtils,其作用是对一个类进行序列化和反序列化,并存储到硬盘上(模拟网络传输),其代码如下:

 1 import java.io.FileInputStream; 2 import java.io.FileNotFoundException; 3 import java.io.FileOutputStream; 4 import java.io.IOException; 5 import java.io.ObjectInputStream; 6 import java.io.ObjectOutputStream; 7 import java.io.Serializable; 8  9 public class SerializationUtils {10   private static String FILE_NAME = "c:/obj.bin";11   //序列化12   public static void writeObject(Serializable s) {13     try {14       ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(FILE_NAME));15       oos.writeObject(s);16       oos.close();17     } catch (FileNotFoundException e) {18       e.printStackTrace();19     } catch (IOException e) {20       e.printStackTrace();21     }22   }23   //反序列化24   public static Object readObject() {25     Object obj = null;26     try {27       ObjectInputStream input = new ObjectInputStream(new FileInputStream(FILE_NAME));28       obj=input.readObject();29       input.close();30     } catch (FileNotFoundException e) {31       e.printStackTrace();32     } catch (IOException e) {33       e.printStackTrace();34     } catch (ClassNotFoundException e) {35       e.printStackTrace();36     }37     return obj;38   }39 }

通过对象序列化过程,把一个内存块转化为可传输的数据流,然后通过网络发送到消息消费者(Customer)哪里,进行反序列化,生成实验对象,代码如下:

1 public class Customer {2   public static void main(String[] args) {3     //反序列化4     Person p=(Person) SerializationUtils.readObject();5     System.out.println(p.getName());6   }7 }

这是一个反序列化的过程,也就是对象数据流转换为一个实例的过程,其运行后的输出结果为“混世魔王”。这太easy了,是的,这就是序列化和反序列化的典型Demo。但此处藏着一个问题:如果消息的生产者和消息的消费者(Person类)有差异,会出现何种神奇事件呢?比如:消息生产者中的Person类添加一个年龄属性,而消费者没有增加该属性。为啥没有增加?因为这个是分布式部署的应用,你甚至不知道这个应用部署在何处,特别是通过广播方式发消息的情况,漏掉一两个订阅者也是很正常的。

  这中序列化和反序列化的类在不一致的情况下,反序列化时会报一个InalidClassException异常,原因是序列化和反序列化所对应的类版本发生了变化,JVM不能把数据流转换为实例对象。刨根问底:JVM是根据什么来判断一个类的版本呢?

     好问题,通过SerializableUID,也叫做流标识符(Stream Unique Identifier),即类的版本定义的,它可以显示声明也可以隐式声明。显示声明格式如下:

   private static final long serialVersionUID = 1867341609628930239L; 

  而隐式声明则是我不声明,你编译器在编译的时候帮我生成。生成的依据是通过包名、类名、继承关系、非私有的方法和属性,以及参数、返回值等诸多因子算出来的,极度复杂,基本上计算出来的这个值是唯一的。

  serialVersionUID如何生成已经说明了,我们再来看看serialVersionUID的作用。JVM在反序列化时,会比较数据流中的serialVersionUID与类的serialVersionUID是否相同,如果相同,则认为类没有改变,可以把数据load为实例相同;如果不相同,对不起,我JVM不干了,抛个异常InviladClassException给你瞧瞧。这是一个非常好的校验机制,可以保证一个对象即使在网络或磁盘中“滚过”一次,仍能做到“出淤泥而不染”,完美的实现了类的一致性。

 但是,有时候我们需要一点特例场景,例如我的类改变不大,JVM是否可以把我以前的对象反序列化回来?就是依据显示声明的serialVersionUID,向JVM撒谎说"我的类版本没有变化",如此我买你编写的类就实现了向上兼容,我们修改Person类,里面添加private static final long serialVersionUID = 1867341609628930239L;

  刚开始生产者和消费者持有的Person类一致,都是V1.0,某天生产者的Person类变更了,增加了一个“年龄”属性,升级为V2.0,由于种种原因(比如程序员疏忽,升级时间窗口不同等)消费端的Person类还是V1.0版本,添加的代码为 priavte int age;以及对应的setter和getter方法。

  此时虽然生产这和消费者对应的类版本不同,但是显示声明的serialVersionUID相同,序列化也是可以运行的,所带来的业务问题就是消费端不能读取到新增的业务属性(age属性而已)。通过此例,我们反序列化也实现了版本向上兼容的功能,使用V1.0版本的应用访问了一个V2.0的对象,这无疑提高了代码的健壮性。我们在编写序列化类代码时随手添加一个serialVersionUID字段,也不会带来太多的工作量,但它却可以在关键时候发挥异乎寻常的作用。

  显示声明serialVersionUID可以避免对象的不一致,但尽量不要以这种方式向JVM撒谎。

建议12:避免用序列化类在构造函数中为不变量赋值

我们知道带有final标识的属性是不变量,也就是只能赋值一次,不能重复赋值,但是在序列化类中就有点复杂了,比如这个类:

1 public class Person implements Serializable {2   private static final long serialVersionUID = 1867341609628930239L;3   public final String perName="程咬金";4 }

  这个Peson类(此时V1.0版本)被序列化,然后存储在磁盘上,在反序列化时perName属性会重新计算其值(这与static变量不同,static变量压根就没有保存到数据流中)比如perName属性修改成了"秦叔宝"(版本升级为V2.0),那么反序列化的perName值就是"秦叔宝"。保持新旧对象的final变量相同,有利于代码业务逻辑统一,这是序列化的基本原则之一,也就是说,如果final属性是一个直接量,在反序列化时就会重新计算。对于基本原则不多说,现在说一下final变量的另一种赋值方式:通过构造函数赋值。代码如下:

public class Person implements Serializable {  private static final long serialVersionUID = 1867341609628930239L;  public final String perName;  public Person() {    perName = "程咬金";  }}

  这也是我们常用的一种赋值方式,可以把Person类定义为版本V1.0,然后进行序列化,看看序列化后有什么问题,序列化代码如下: 

public class Serialize {  public static void main(String[] args) {    //序列化以持久保持    SerializationUtils.writeObject(new Person());  }}

Person的实习对象保存到了磁盘上,它时一个贫血对象(承载业务属性定义,但不包含其行为定义),我们做一个简单的模拟,修改一下PerName值代表变更,要注意的是serialVersionUID不变,修改后的代码如下:

public class Person implements Serializable {  private static final long serialVersionUID = 1867341609628930239L;  public final String perName;  public Person() {    perName = "秦叔宝";  }}

此时Person类的版本时V2.0但serialVersionUID没有改变,仍然可以反序列化,代码如下:

public class Deserialize {  public static void main(String[] args) {    Person p = (Person) SerializationUtils.readObject();    System.out.println(p.perName);  }}

现在问题出来了,打印出来的结果是"程咬金" 还是"秦叔宝"?答案是:"程咬金"。final类型的变量不是会重新计算嘛,打印出来的应该是秦叔宝才对呀。为什么会是程咬金?这是因为这里触及到了反序列化的两一个原则:反序列化时构造函数不会执行.

  反序列化的执行过程是这样的:JVM从数据流中获取一个Object对象,然后根据数据流中的类文件描述信息(在序列化时,保存到磁盘的对象文件中包含了类描述信息,注意是描述信息,不是类)查看,发现是final变量,需要重新计算,于是引用Person类中的perName值,而此时JVM又发现perName竟没有赋值,不能引用,于是它很聪明的不再初始化,保持原值状态,所以结果就是"程咬金"了。

  注意:在序列化类中不使用构造函数为final变量赋值.

建议13:避免为final变量复杂赋值

  为final变量赋值还有另外一种方式:通过方法赋值,及直接在声明时通过方法的返回值赋值,还是以Person类为例来说明,代码如下:

public class Person implements Serializable {  private static final long serialVersionUID = 1867341609628930239L;  //通过方法返回值为final变量赋值  public final String pName = initName();  public String initName() {    return "程咬金";  }}

  pName属性是通过initName方法的返回值赋值的,这在复杂的类中经常用到,这比使用构造函数赋值更简洁,易修改,那么如此用法在序列化时会不会有问题呢?我们一起看看。Person类写好了(定义为V1.0版本),先把它序列化,存储到本地文件,其代码与之前相同,不在赘述。现在Person类的代码需要修改,initName的返回值改为"秦叔宝".那么我们之前存储在磁盘上的的实例加载上来,pName的会是什么呢?

  现在,Person类的代码需要修改,initName的返回值也改变了,代码如下: 

public class Person implements Serializable {  private static final long serialVersionUID = 1867341609628930239L;  //通过方法返回值为final变量赋值  public final String pName = initName();  public String initName() {    return "秦叔宝";  }}

 上段代码仅仅修改了initName的返回值(Person类为V2.0版本)也就是通过new生成的对象的final变量的值都是"秦叔宝",那么我们把之前存储在磁盘上的实例加载上来,pName的值会是什么呢?

 结果是"程咬金",很诧异,上一建议说过final变量会被重新赋值,但是这个例子又没有重新赋值,为什么?

  上个建议说的重新赋值,其中的"值"指的是简单对象。简单对象包括:8个基本类型,以及数组、字符串(字符串情况复杂,不通过new关键字生成的String对象的情况下,final变量的赋值与基本类型相同),但是不能方法赋值。

  其中的原理是这样的,保存到磁盘上(或网络传输)的对象文件包括两部分:

    (1).类描述信息:包括类路径、继承关系、访问权限、变量描述、变量访问权限、方法签名、返回值、以及变量的关联类信息。要注意一点是,它并不是class文件的翻版,它不记录方法、构造函数、static变量等的具体实现。之所以类描述会被保存,很简单,是因为能去也能回嘛,这保证反序列化的健壮运行。

    (2).非瞬态(transient关键字)和非静态(static关键字)的实体变量值

      注意,这里的值如果是一个基本类型,好说,就是一个简单值保存下来;如果是复杂对象,也简单,连该对象和关联类信息一起保存,并且持续递归下去(关联类也必须实现Serializable接口,否则会出现序列化异常),也就是递归到最后,还是基本数据类型的保存。

  正是因为这两个原因,一个持久化的对象文件会比一个class类文件大很多,有兴趣的读者可以自己测试一下,体积确实膨胀了不少。  

  总结一下:反序列化时final变量在以下情况下不会被重新赋值:

  1. 通过构造函数为final变量赋值
  2. 通过方法返回值为final变量赋值
  3. final修饰的属性不是基本类型

建议14:使用序列化类的私有方法巧妙解决部分属性持久化问题

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

 1 public class Salary implements Serializable { 2   private static final long serialVersionUID = 2706085398747859680L; 3   // 基本工资 4   private int basePay; 5   // 绩效工资 6   private int bonus; 7  8   public Salary(int _basepay, int _bonus) { 9     this.basePay = _basepay;10     this.bonus = _bonus;11   }12 //Setter和Getter方法略13 14 }

Person类和Salary类是关联关系,代码如下: 

 1 public class Person implements Serializable { 2  3   private static final long serialVersionUID = 9146176880143026279L; 4  5   private String name; 6  7   private Salary salary; 8  9   public Person(String _name, Salary _salary) {10     this.name = _name;11     this.salary = _salary;12   }13 14   //Setter和Getter方法略15 16 }

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

 1 public class Serialize { 2   public static void main(String[] args) { 3     // 基本工资1000元,绩效工资2500元 4     Salary salary = new Salary(1000, 2500); 5     // 记录人员信息 6     Person person = new Person("张三", salary); 7     // HR系统持久化,并传递到计税系统 8     SerializationUtils.writeObject(person); 9   }10 }

在通过网络传输到计税系统后,进行反序列化,代码如下:

 1 public class Deserialize { 2   public static void main(String[] args) { 3     Person p = (Person) SerializationUtils.readObject(); 4     StringBuffer buf = new StringBuffer(); 5     buf.append("姓名: "+p.getName()); 6     buf.append("\t基本工资: "+p.getSalary().getBasePay()); 7     buf.append("\t绩效工资: "+p.getSalary().getBonus()); 8     System.out.println(buf); 9   }10 }

打印出的结果为:姓名: 张三    基本工资: 1000    绩效工资: 2500

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

  1. 在bonus前加上关键字transient:这是一个方法,但不是一个好方法,加上transient关键字就标志着Salary失去了分布式部署的功能,它可能是HR系统核心的类了,一旦遭遇性能瓶颈,再想实现分布式部署就可能了,此方案否定;
  2. 新增业务对象:增加一个Person4Tax类,完全为计税系统服务,就是说它只有两个属性:姓名和基本工资。符合开闭原则,而且对原系统也没有侵入性,只是增加了工作量而已。但是这个方法不是最优方法;
  3. 请求端过滤:在计税系统获得Person对象后,过滤掉Salary的bonus属性,方案可行但不符合规矩,因为HR系统中的Salary类安全性竟然然外系统(计税系统来承担),设计严重失职;
  4. 变更传输契约:例如改用

下面展示一个优秀的方案,其中实现了Serializable接口的类可以实现两个私有方法:writeObject和readObject,以影响和控制序列化和反序列化的过程。我们把Person类稍作修改,看看如何控制序列化和反序列化,代码如下:

 1 public class Person implements Serializable { 2  3   private static final long serialVersionUID = 9146176880143026279L; 4  5   private String name; 6  7   private transient Salary salary; 8  9   public Person(String _name, Salary _salary) {10     this.name = _name;11     this.salary = _salary;12   }13   //序列化委托方法14   private void writeObject(ObjectOutputStream oos) throws IOException {15     oos.defaultWriteObject();16     oos.writeInt(salary.getBasePay());17   }18   //反序列化委托方法19   private void readObject(ObjectInputStream input)throws ClassNotFoundException, IOException {20     input.defaultReadObject();21     salary = new Salary(input.readInt(), 0);22   }23 }

其它代码不做任何改动,运行之后结果为:姓名: 张三    基本工资: 1000    绩效工资: 0

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

  1. oos.defaultWriteObject():告知JVM按照默认的规则写入对象,惯例的写法是写在第一行。
  2. input.defaultReadObject():告知JVM按照默认规则读入对象,惯例的写法是写在第一行。
  3. oos.writeXX和input.readXX

分别是写入和读出相应的值,类似一个队列,先进先出,如果此处有复杂的数据逻辑,建议按封装Collection对象处理。大家可能注意到上面的方式也是Person失去了分布式部署的能了,确实是,但是HR系统的难点和重点是薪水的计算,特别是绩效工资,它所依赖的参数很复杂(仅从数量上说就有上百甚至上千种),计算公式也不简单(一般是引入脚本语言,个性化公式定制)而相对来说Person类基本上都是静态属性,计算的可能性不大,所以即使为性能考虑,Person类为分布式部署的意义也不大。

建议15:break万万不可忘

  我们经常会写一些转换类,比如货币转换,日期转换,编码转换等,在金融领域里用到的最多的要数中文数字转换了,比如把"1"转换为"壹" ,不过开源工具是不会提供此工具类的,因为它太贴近中国文化了,需要自己编写:

 1 public class Client15 { 2   public static void main(String[] args) { 3     System.out.println(toChineseNuberCase(0)); 4   } 5  6   public static String toChineseNuberCase(int n) { 7     String chineseNumber = ""; 8     switch (n) { 9     case 0:10       chineseNumber = "零";11     case 1:12       chineseNumber = "壹";13     case 2:14       chineseNumber = "贰";15     case 3:16       chineseNumber = "叁";17     case 4:18       chineseNumber = "肆";19     case 5:20       chineseNumber = "伍";21     case 6:22       chineseNumber = "陆";23     case 7:24       chineseNumber = "柒";25     case 8:26       chineseNumber = "捌";27     case 9:28       chineseNumber = "玖";29     }30     return chineseNumber;31   }32 }

这是一个简单的代码,但运行结果却是"玖",这个很简单,可能大家在刚接触语法时都学过,但虽简单,如果程序员漏写了,简单的问题会造成很大的后果,甚至经济上的损失。所以在用switch语句上记得加上break,养成良好的习惯。对于此类问题,除了平常小心之外,可以使用单元测试来避免,但大家都晓得,项目紧的时候,可能但单元测试都覆盖不了。所以对于此类问题,一个最简单的办法就是:修改IDE的警告级别,例如在Eclipse中,可以依次点击PerFormaces-->Java-->Compiler-->Errors/Warings-->Potential Programming problems,然后修改'switch' case fall-through为Errors级别,如果你胆敢不在case语句中加入break,那Eclipse直接就报个红叉给你看,这样可以避免该问题的发生了。但还是啰嗦一句,养成良好习惯更重要!