编写高质量代码：改善Java程序的151个建议（第一章：JAVA开发中通用的方法和准则）
目录
-
The reasonable man adapts himself to the world; The unreasonable one persists in trying to adapt the world himself.
明白事理的人使自己适应世界；不明事理的人想让世界适应自己。--------萧伯纳
JAVA的世界丰富又多彩，但同时也布满了经济陷阱，大家一不小心就可能跌入黑暗的深渊，只有在了解了其通行规则后才能是自己在技术的海洋里遨游飞翔，恣意驰骋。
千里之行，始于足下，本章主要讲述与JAVA语言基础相关的问题及建议的解决方案和变量的注意事项、如何安全的序列化、断言到底该如何使用等;
建议1:不要在常量和变量中出现易混淆的字母
包名全小写，类名首字母全大写，常量全部大写并用下划线分隔，变量采用驼峰命名法(Camel Case)命名等，这些都是最基本的Java编码规范，是每个javaer都应熟知的规则，但是在变量的声明中要注意不要引入容易混淆的字母。尝试阅读如下代码，思考打印结果的i是多少：
public class Demo{
public static void main(String[] args) {
test01();
}
public static void test01(){
long i=1l;
System.out.println("i的两倍是："+(i+i));
}
}
肯定会有人说：这么简单的例子还能出错？运行结果肯定是22！实践是检验真理的唯一标准，将其Run一下看看，或许你会很奇怪，结果是2，而不是22.难道是编译器出问题了，少了个"2"?
因为赋给变量i的值就是数字"1",只是后面加了长整型变量的标示字母"l"而已。别说是我挖坑让你跳，如果有类似程序出现在项目中，当你试图通过阅读代码来理解作者的思想时，此情景就可能会出现。所以为了让你的程序更容易理解，字母"l"(包括大写字母"O")尽量不要和数字混用，以免使读者的理解和程序意图产生偏差。如果字母和数字混合使用，字母"l"务必大写，字母"O"则增加注释。
注意：字母"l"作为长整型标志时务必大写。
建议2：莫让常量蜕变成变量
常量蜕变成变量？你胡扯吧，加了final和static的常量怎么可能会变呢？不可能为此赋值的呀。真的不可能吗？看看如下代码：
import java.util.Random;
public class Demo01 {
public static void main(String[] args) {
test02();
}
public static void test02() {
System.out.println("常量会变哦:" + Constant.RAND_CONST);
}
}
interface Constant {
public static final int RAND_CONST = new Random().nextInt();
}
同一个class文件，多次运行，RAND_CONST值是不一样的；但main方法中多次调用值是一样的
RAND_CONST是常量吗?它的值会变吗？绝对会变！这种常量的定义方式是绝对不可取的，常量就是常量，在编译期就必须确定其值，不应该在运行期更改，否则程序的可读性会非常差，甚至连作者自己都不能确定在运行期发生了何种神奇的事情。
甭想着使用常量会变的这个功能来实现序列号算法、随机种子生成，除非这真的是项目中的唯一方案，否则就放弃吧，常量还是当常量使用。
注意：务必让常量的值在运行期保持不变。
建议3：三元操作符的类型务必一致
三元操作符是if-else的简化写法，在项目中使用它的地方很多，也非常好用，但是好用又简单的东西并不表示就可以随意使用，看看如下代码:
public static void test03() {
int i = 80;
String str = String.valueOf(i < 100 ? 90 : 100);
String str1 = String.valueOf(i < 100 ? 90 : 100.0);
System.out.println("两者是否相等：" + str.equals(str1));
}
分析一下这段程序，i是80，小于100，两者的返回值肯定都是90，再转成String类型，其值也绝对相等，毋庸置疑的。嗯，分析的有点道理，但是变量str中的三元操作符的第二个操作数是100，而str1中的第二个操作数是100.0，难道木有影响吗?不可能有影响吧，三元操作符的条件都为真了，只返回第一个值嘛，于第二个值有毛线关系，貌似有道理。
运行之后，结果却是："两者是否相等：false"，不相等，why?
问题就出在了100和100.0这两个数字上，在变量str中，三元操作符的第一个操作数90和第二个操作数100都是int类型，类型相同，返回的结果也是int类型的90，而变量str1中的第一个操作数(90)是int类型，第二个操作数100.0是浮点数，也就是两个操作数的类型不一致，可三元操作符必须要返回一个数据，而且类型要确定，不可能条件为真时返回int类型，条件为假时返回float类型，编译器是不允许如此的，所以它会进行类型转换int类型转换为浮点数90.0，也就是三元操作符的返回值是浮点数90.0，那么当然和整型的90不相等了。这里为什么是整型转成浮点型，而不是浮点型转成整型呢？这就涉及三元操作符类型的转换规则:
若两个操作数不可转换，则不作转换，返回值是Object类型；
若两个操作数是明确类型的表达式(比如变量)，则按照正常的二进制数字转换，int转为long，long转为float等;
若两个操作数中有一个是数字S,另外一个是表达式，且其类型标志位T，那么，若数字S在T的范围内，则转换为T类型；若S超出了T的范围，则T转换为S;
-
若两个操作数都是直接量数字，则返回值类型范围较大者。
知道什么原因了，相应的解决办法也就有了：保证三元操作符中的两个操作数类型一致，避免此错误的发生。
建议4：避免带有变长参数的方法重载
在项目和系统开发中，为了提高方法的灵活度和可复用性，我们经常要传递不确定数量的参数到方法中，在JAVA5之前常用的设计技巧就是把形参定义成Collection类型或其子类类型，或者数组类型，这种方法的缺点就是需要对空参数进行判断和筛选，比如实参为null值和长度为0的Collection或数组。而Java5引入了变长参数(varags)就是为了更好地挺好方法的复用性，让方法的调用者可以"随心所欲"地传递实参数量，当然变长参数也是要遵循一定规则的，比如变长参数必须是方法中的最后一个参数；一个方法不能定义多个变长参数等，这些基本规则需要牢记，但是即使记住了这些规则，仍然有可能出现错误，看如下代码:
public class Client {
public static void main(String[] args) {
Client client = new Client();
// 499元的货物 打75折
client.calPrice(499, 75);
}
// 简单折扣计算
public void calPrice(int price, int discount) {
float knockdownPrice = price * discount / 100.0F;
System.out.println("简单折扣后的价格是：" + formatCurrency(knockdownPrice));
}
// 复杂多折扣计算
public void calPrice(int price, int... discounts) {
float knockdownPrice = price;
for (int discount : discounts) {
knockdownPrice = knockdownPrice * discount / 100;
}
System.out.println("复杂折扣后的价格是：" + formatCurrency(knockdownPrice));
}
public String formatCurrency(float price) {
return NumberFormat.getCurrencyInstance().format(price);
}
}
这是一个计算商品折扣的模拟类，带有两个参数的calPrice方法（该方法的业务逻辑是：提供商品的原价和折扣率，即可获得商品的折扣价）是一个简单的折扣计算方法，该方法在实际项目中经常会用到，这是单一的打折方法。而带有变长参数的calPrice方法是叫较复杂的折扣计算方式，多种折扣的叠加运算（模拟类是比较简单的实现）在实际中也经常见到，比如在大甩卖期间对VIP会员再度进行打折；或者当天是你的生日，再给你打个9折，也就是俗话中的折上折。
业务逻辑清楚了，我们来仔细看看这两个方法，它们是重载吗?当然是了，重载的定义是："方法名相同，参数类型或数量不同"，很明显这两个方法是重载。但是这个重载有点特殊，calPrice(int price ,int... discounts)的参数范畴覆盖了calPrice（int price,int discount）的参数范畴。那问题就出来了：对于calPrice(499,75)这样的计算，到底该调用哪个方法来处理呢？
我们知道java编译器是很聪明的，它在编译时会根据方法签名来确定调用那个方法，比如：calPrice（499,75,95）这个调用，很明显75和95会被转成一个包含两个元素的数组，并传递到calPrice（int price,int...discounts）中，因为只有这一个方法符合这个实参类型，这很容易理解。但是我们现在面对的是calPrice(499,75)调用，这个75既可以被编译成int类型的75，也可以被编译成int数组{75}，即只包含一个元素的数组。那到底该调用哪一个方法呢？运行结果是:"简单折扣后的价格是：374.25"。看来调用了第一个方法，为什么会调用第一个方法，而不是第二个变长方法呢？因为java在编译时，首先会根据实参的数量和类型（这里2个实参，都为int类型，注意没有转成int数组）来进行处理，也就是找到calPrice(int price,int discount)方法，而且确认他是否符合方法签名条件。现在的问题是编译器为什么会首先根据两个int类型的实参而不是一个int类型，一个int数组类型的实参来查找方法呢？
因为int是一个原生数据类型，而数组本身是一个对象，编译器想要"偷懒",于是它会从最简单的开始"猜想"，只要符合编译条件的即可通过，于是就出现了此问题。
问题阐述清楚了，为了让我们的程序能被"人类"看懂，还是慎重考虑变长参数的方法重载吧，否则让人伤脑筋不说，说不定哪天就陷入这类小陷阱里了。
建议5：别让null值和空值威胁到变长方法
上一建议讲解了变长参数的重载问题，本建议会继续讨论变长参数的重载问题，上一建议的例子是变长参数的范围覆盖了非变长参数的范围，这次讨论两个都是变长参数的方法说起，代码如下:
public class Client5 {
public void methodA(String str, Integer... is) {
}
public void methodA(String str, String... strs) {
}
public static void main(String[] args) {
Client5 client5 = new Client5();
client5.methodA("china", 0);
client5.methodA("china", "people");
client5.methodA("china");
client5.methodA("china", null);
}
}
两个methodA都进行了重载，现在的问题是：上面的client5.methodA("china");client5.methodA("china", null);编译不通过，提示相同：方法模糊不清，编译器不知道调用哪一个方法，但这两处代码反应的味道是不同的。
对于methodA("china")方法，根据实参"china"(String类型)，两个方法都符合形参格式，编译器不知道调用那个方法，于是报错。我们思考一下此问题：Client5这个类是一个复杂的商业逻辑，提供了两个重载方法，从其它模块调用（系统内本地调用系统或系统外远程系统调用）时，调用者根据变长参数的规范调用，传入变长参数的参数数量可以是N个（N>=0）,那当然可以写成client5.methodA("china")方法啊！完全符合规范，但是这个却让编译器和调用者郁闷，程序符合规则却不能运行，如此问题，谁之责任呢？是Client5类的设计者，他违反了KISS原则(Keep it Smile,Stupid,即懒人原则)，按照此设计的方法应该很容一调用，可是现在遵循规范却编译不通过，这对设计者和开发者而言都是应该禁止出现的。
对于Client5.methodA("China",null),直接量null是没哟类型的，虽然两个methodA方法都符合调用要求，但不知道调用哪一个，于是报错了。仔细分析一下，除了不符合上面的懒人原则之外，还有一个非常不好的编码习惯，即调用者隐藏了实参类型，这是非常危险的，不仅仅调用者需要"猜测调用那个方法"，而且被调用者也可能产生内部逻辑混乱的情况。对于本例来说应该如此修改:
public static void main(String[] args) {
Client5 client5 = new Client5();
String strs[] = null;
client5.methodA("china", strs);
}
也就是说让编译器知道这个null值是String类型的，编译即可顺利通过，也就减少了错误的发生。
建议6：覆写变长方法也循规蹈矩
在JAVA中，子类覆写父类的中的方法很常见，这样做既可以修正bug，也可以提供扩展的业务功能支持，同时还符合开闭原则(Open-Closed Principle)，下面我们看一下覆写必须满足的条件：
- 覆写方法不能缩小访问权限；
- 参数列表必须与被覆写方法相同；
- 返回类型必须与被重写方法的相同；
- 重写方法不能抛出新的异常，或者超出父类范围的异常，但是可以抛出更少，更有限的异常，或者不抛出异常。
看下面这段代码：
public class Client6 {
public static void main(String[] args) {
// 向上转型
Base base = new Sub();
base.fun(100, 50);
// 不转型
Sub sub = new Sub();
sub.fun(100, 50);
}
}
// 基类
class Base {
void fun(int price, int... discounts) {
System.out.println("Base......fun");
}
}
// 子类，覆写父类方法
class Sub extends Base {
@Override
void fun(int price, int[] discounts) {
System.out.println("Sub......fun");
}
}
该程序中sub.fun(100, 50)报错，提示找不到fun(int,int)方法。这太奇怪了：子类继承了父类的所有属性和方法，甭管是私有的还是公开的访问权限，同样的参数，同样的方法名，通过父类调用没有任何问题，通过子类调用，却编译不过，为啥？难到是没继承下来？或者子类缩小了父类方法的前置条件？如果是这样，就不应该覆写，@Override就应该报错呀。
事实上，base对象是把子类对象做了向上转型，形参列表由父类决定，由于是变长参数，在编译时,base.fun(100, 50);中的50这个实参会被编译器"猜测"而编译成"{50}"数组，再由子类Sub执行。我们再来看看直接调用子类的情况，这时编译器并不会把"50"座类型转换因为数组本身也是一个对象，编译器还没有聪明到要在两个没有继承关系的类之间转换，要知道JAVA是要求严格的类型匹配的，类型不匹配编译器自然就会拒绝执行，并给予错误提示。
这是个特例，覆写的方法参数列表竟然与父类不相同，这违背了覆写的定义，并且会引发莫名其妙的错误。所以读者在对变长参数进行覆写时，如果要使用次类似的方法，请仔细想想是不是要一定如此。
注意：覆写的方法参数与父类相同，不仅仅是类型、数量，还包括显示形式.
建议7：警惕自增的陷阱
记得大学刚开始学C语言时，老师就说：自增有两种形式，分别是i++和++i,i++表示的先赋值后加1，++i是先加1后赋值，这样理解了很多年也木有问题，直到遇到如下代码，我才怀疑我的理解是不是错了:
看下面这段代码：
public class Client7 {
public static void main(String[] args) {
int count=0;
for(int i=0; i<10;i++){
count=count++;
}
System.out.println("count = "+count);
}
}
这个程序输出的count等于几？是count自加10次吗？答案等于10？可以肯定的说，这个运行结果是count=0。为什么呢？
count++是一个表达式，是由返回值的，它的返回值就是count自加前的值，Java对自加是这样处理的：首先把count的值(注意是值，不是引用)拷贝到一个临时变量区，然后对count变量+1，最后返回临时变量区的值。程序第一次循环处理步骤如下:
- JVM把count的值（其值是0）拷贝到临时变量区；
- count的值+1，这时候count的值是1
- 返回临时变量区的值，注意这个值是0，没修改过；
- 返回值赋给count，此时count的值被重置为0.
"count=count++"这条语句可以按照如下代码理解：
public static int mockAdd(int count) {
// 先保存初始值
int temp = count;
// 做自增操作
count = count + 1;
// 返回原始值
return temp;
}
于是第一次循环后count的值为0，其它9次循环也是一样的，最终你会发现count的值始终没有改变，仍然保持着最初的状态.
此例中代码作者的本意是希望count自增，所以想当然的赋值给自身就可以了，不曾想到调到Java自增的陷阱中了，解决办法很简单，把"count=count++"改为"count++"即可。该问题在不同的语言环境中有着不同的实现：C++中"count=count++"与"count++"是等效的，而在PHP中保持着与JAVA相同的处理方式。每种语言对自增的实现方式各不相同。
建议8：不要让旧语法困扰你
看下面这段代码：
public class Client8 {
public static void main(String[] args) {
// 数据定义初始化
int fee = 200;
// 其它业务处理
saveDefault: save(fee);
}
static void saveDefault() {
System.out.println("saveDefault....");
}
static void save(int fee) {
System.out.println("save....");
}
}
这段代码分析一下，输出结果，以及语法含义：
- 首先这段代码中有标号(:)操作符，C语言的同学一看便知，类似JAVA中的保留关键字 go to 语句，但Java中抛弃了goto语法，只是不进行语义处理，与此类似的还有const关键字。
- Java中虽然没有了goto语法，但扩展了break和continue关键字，他们的后面都可以加上标号做跳转，完全实现了goto功能，同时也把goto的诟病带进来了。
- 运行之后代码输入为"save....",运行时没错，但这样的代码，给大家阅读上造成了很大的问题，所以就语法就让他随风远去吧!
建议9：少用静态导入
从Java5开始引入了静态导入语法(import static),其目的是为了减少字符的输入量，提高代码的可阅读性，以便更好地理解程序。我们先俩看一个不用静态导入的例子，也就是一般导入：
看下面这段代码：
public class Client9 {
// 计算圆面积
public static double claCircleArea(double r) {
return Math.PI * r * r;
}
// 计算球面积
public static double claBallArea(double r) {
return 4 * Math.PI * r * r;
}
}
这是很简单的两个方法，我们再这两个计算面积的方法中都引入了java.lang.Math类(该类是默认导入的)中的PI(圆周率)常量，而Math这个类写在这里有点多余，特别是如果Client9类中的方法比较多时。如果每次输入都需要敲入Math这个类，繁琐且多余，静态导入可以解决此问题，使用静态导入后的程序如下：
import static java.lang.Math.PI;
public class Client9 {
// 计算圆面积
public static double claCircleArea(double r) {
return PI * r * r;
}
// 计算球面积
public static double claBallArea(double r) {
return 4 * PI * r * r;
}
}
静态导入的作用是把Math类中的Pi常量引入到本类中，这会是程序更简单，更容易阅读，只要看到PI就知道这是圆周率，不用每次都把类名写全了。但是，滥用静态导入会使程序更难阅读，更难维护，静态导入后，代码中就不需要再写类名了，但我们知道类是"一类事物的描述"，缺少了类名的修饰，静态属性和静态方法的表象意义可以被无限放大，这会让阅读者很难弄清楚其属性或者方法代表何意，绳子哪一类的属性(方法)都要思考一番（当然IDE的友好提示功能另说），把一个类的静态导入元素都引入进来了，那简直就是噩梦。我们来看下面的例子：
import static java.lang.Math.*;
import static java.lang.Double.*;
import static java.lang.Integer.*;
import static java.text.NumberFormat.*;
import java.text.NumberFormat;
public class Client9 {
public static void formatMessage(String s) {
System.out.println("圆面积是: " + s);
}
public static void main(String[] args) {
double s = PI * parseDouble(args[0]);
NumberFormat nf = getInstance();
nf.setMaximumFractionDigits(parseInt(args[1]));
formatMessage(nf.format(s));
}
}
就这么一段程序，看着就让人恼火，常量PI，这知道是圆周率；parseDouble方法可能是Double类的一个转换方法，这看名称可以猜的到。那紧接着getInstance()方法是哪个类的？是Client9本地类？不对呀，本地没有这个方法，哦，原来是NumberFormat类的方法，这个和formatMessage本地方法没有任何区别了---这代码太难阅读了，肯定有人骂娘。
C所以，对于静态导入，一定要追寻两个原则：
- 不使用*(星号)通配符，除非是导入静态常量类(只包含常量的类或接口)；
- 方法名是具有明确、清晰表象意义的工具类。
何为具有明确、清晰表象意义的工具类，我们看看Junit中使用静态导入的例子：
import static org.junit.Assert.*;
class DaoTest{
@Test
public void testInsert(){
//断言
assertEquals("foo","foo");
assertFalse(Boolean.FALSE);
}
}
我们从程序中很容易判断出assertEquals方法是用来断言两个值是否相等的，assertFalse方法则是断言表达式为假，如此确实减少了代码量，而且代码的可读性也提高了，这也是静态导入用到正确的地方带来的好处。
建议10：不要在本类中覆盖静态导入的变量和方法
如果在一个类中的方法及属性与静态导入的方法及属性相同会出现什么问题呢?
看下面这段代码：
import static java.lang.Math.PI;
import static java.lang.Math.abs;
public class Client10 {
// 常量名于静态导入的PI相同
public final static String PI = "祖冲之";
//方法名于静态导入的方法相同
public static int abs(int abs) {
return 0;
}
public static void main(String[] args) {
System.out.println("PI = "+PI);
System.out.println("abs(-100) = "+abs(-100));
}
}
以上代码中定义了一个String类型的常量PI，又定义了一个abs方法，与静态导入的相同。首先说好消息，代码没有报错，接下来是坏消息:我们不知道那个属性和方法别调用了，因为常量名和方法名相同，到底调用了那一个方法呢？运行之后结果为：
PI = "祖冲之"，abs(-100) = 0;
很明显是本地的方法被调用了，为何不调用Math类中的属性和方法呢？那是因为编译器有一个"最短路径"原则:如果能够在本类中查找到相关的变量、常量、方法、就不会去其它包或父类、接口中查找，以确保本类中的属性、方法优先。
因此，如果要变更一个被静态导入的方法，最好的办法是在原始类中重构，而不是在本类中覆盖.
建议11：养成良好习惯，显示声明UID
我们编写一个实现了Serializable接口（序列化标志接口）的类，Eclipse马上就会给一个黄色警告：需要添加一个Serial Version ID。为什么要增加？他是怎么计算出来的？有什么用?下面就来解释该问题。
类实现Serializable接口的目的是为了可持久化，比如网络传输或本地存储，为系统的分布和异构部署提供先决条件支持。若没有序列化，现在我们熟悉的远程调用、对象数据库都不可能存在，我们来看一个简单的序列化类：
看下面这段代码：
import java.io.Serializable;
public class Person implements Serializable {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
这是一个简单的JavaBean，实现了Serializable接口，可以在网络上传输，也可以在本地存储然后读取。这里我们以java消息服务(Java Message Service)方式传递对象（即通过网络传递一个对象），定义在消息队列中的数据类型为ObjectMessage，首先定义一个消息的生产者（Producer）,代码如下:
public class Producer {
public static void main(String[] args) {
Person p = new Person();
p.setName("混世魔王");
// 序列化，保存到磁盘上
SerializationUtils.writeObject(p);
}
}
这里引入了一个工具类SerializationUtils，其作用是对一个类进行序列化和反序列化，并存储到硬盘上（模拟网络传输），其代码如下：
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;
public class SerializationUtils {
private static String FILE_NAME = "c:/obj.bin";
//序列化
public static void writeObject(Serializable s) {
try {
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(FILE_NAME));
oos.writeObject(s);
oos.close();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
//反序列化
public static Object readObject() {
Object obj = null;
try {
ObjectInputStream input = new ObjectInputStream(new FileInputStream(FILE_NAME));
obj=input.readObject();
input.close();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
return obj;
}
}
通过对象序列化过程，把一个内存块转化为可传输的数据流，然后通过网络发送到消息消费者（Customer）哪里，进行反序列化，生成实验对象，代码如下：
public class Customer {
public static void main(String[] args) {
//反序列化
Person p=(Person) SerializationUtils.readObject();
System.out.println(p.getName());
}
}
这是一个反序列化的过程，也就是对象数据流转换为一个实例的过程，其运行后的输出结果为“混世魔王”。这太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标识的属性是不变量，也就是只能赋值一次，不能重复赋值，但是在序列化类中就有点复杂了，比如这个类：
看下面这段代码：
public class Person implements Serializable {
private static final long serialVersionUID = 1867341609628930239L;
public final String perName="程咬金";
}
这个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变量的赋值与基本类型相同)，但是不能方法赋值。
其中的原理是这样的，保存到磁盘上(或网络传输)的对象文件包括两部分:
- 类描述信息：包括类路径、继承关系、访问权限、变量描述、变量访问权限、方法签名、返回值、以及变量的关联类信息。要注意一点是，它并不是class文件的翻版，它不记录方法、构造函数、static变量等的具体实现。之所以类描述会被保存，很简单，是因为能去也能回嘛，这保证反序列化的健壮运行。
- 非瞬态(transient关键字)和非静态(static关键字)的实体变量值
注意，这里的值如果是一个基本类型，好说，就是一个简单值保存下来；如果是复杂对象，也简单，连该对象和关联类信息一起保存，并且持续递归下去（关联类也必须实现Serializable接口，否则会出现序列化异常），也就是递归到最后，还是基本数据类型的保存。
正是因为这两个原因，一个持久化的对象文件会比一个class类文件大很多，有兴趣的读者可以自己测试一下，体积确实膨胀了不少。
总结一下：反序列化时final变量在以下情况下不会被重新赋值:
- 通过构造函数为final变量赋值
- 通过方法返回值为final变量赋值
- final修饰的属性不是基本类型
建议14：使用序列化类的私有方法巧妙解决部分属性持久化问题
部分属性持久化问题看似很简单，只要把不需要持久化的属性加上瞬态关键字(transient关键字)即可。这是一种解决方案，但有时候行不通。例如一个计税系统和一个HR系统，通过RMI(Remote Method Invocation,远程方法调用)对接，计税系统需要从HR系统获得人员的姓名和基本工资，以作为纳税的依据，而HR系统的工资分为两部分：基本工资和绩效工资，基本工资没什么秘密，绩效工资是保密的，不能泄露到外系统，这明显是连个相互关联的类，先看看薪水类Salary的代码：
看下面这段代码：
public class Salary implements Serializable {
private static final long serialVersionUID = 2706085398747859680L;
// 基本工资
private int basePay;
// 绩效工资
private int bonus;
public Salary(int _basepay, int _bonus) {
this.basePay = _basepay;
this.bonus = _bonus;
}
//Setter和Getter方法略
}
Person类和Salary类是关联关系，代码如下:
public class Person implements Serializable {
private static final long serialVersionUID = 9146176880143026279L;
private String name;
private Salary salary;
public Person(String _name, Salary _salary) {
this.name = _name;
this.salary = _salary;
}
//Setter和Getter方法略
}
这是两个简单的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 buf = new StringBuffer();
buf.append("姓名: "+p.getName());
buf.append("\t基本工资: "+p.getSalary().getBasePay());
buf.append("\t绩效工资: "+p.getSalary().getBonus());
System.out.println(buf);
}
}
打印出的结果为:姓名: 张三 基本工资: 1000 绩效工资: 2500
但是这不符合需求，因为计税系统只能从HR系统中获取人员姓名和基本工资，而绩效工资是不能获得的，这是个保密数据，不允许发生泄漏。怎么解决这个问题呢？你可能会想到以下四种方案:
- 在bonus前加上关键字transient：这是一个方法，但不是一个好方法，加上transient关键字就标志着Salary失去了分布式部署的功能，它可能是HR系统核心的类了，一旦遭遇性能瓶颈，再想实现分布式部署就可能了，此方案否定;
- 新增业务对象：增加一个Person4Tax类，完全为计税系统服务，就是说它只有两个属性：姓名和基本工资。符合开闭原则，而且对原系统也没有侵入性，只是增加了工作量而已。但是这个方法不是最优方法;
- 请求端过滤：在计税系统获得Person对象后，过滤掉Salary的bonus属性，方案可行但不符合规矩，因为HR系统中的Salary类安全性竟然然外系统(计税系统来承担)，设计严重失职;
- 变更传输契约：例如改用XML传输，或者重建一个WebSerive服务，可以做但成本很高。
下面展示一个优秀的方案，其中实现了Serializable接口的类可以实现两个私有方法：writeObject和readObject，以影响和控制序列化和反序列化的过程。我们把Person类稍作修改，看看如何控制序列化和反序列化，代码如下:
public class Person implements Serializable {
private static final long serialVersionUID = 9146176880143026279L;
private String name;
private transient Salary salary;
public Person(String _name, Salary _salary) {
this.name = _name;
this.salary = _salary;
}
//序列化委托方法
private void writeObject(ObjectOutputStream oos) throws IOException {
oos.defaultWriteObject();
oos.writeInt(salary.getBasePay());
}
//反序列化委托方法
private void readObject(ObjectInputStream input)throws ClassNotFoundException, IOException {
input.defaultReadObject();
salary = new Salary(input.readInt(), 0);
}
}
其它代码不做任何改动，运行之后结果为：姓名: 张三 基本工资: 1000 绩效工资: 0
在Person类中增加了writeObject和readObject两个方法，并且访问权限都是私有级别，为什么会改变程序的运行结果呢？其实这里用了序列化的独有机制：序列化回调。Java调用ObjectOutputStream类把一个对象转换成数据流时，会通过反射（Refection）检查被序列化的类是否有writeObject方法，并且检查其是否符合私有，无返回值的特性，若有，则会委托该方法进行对象序列化，若没有，则由ObjectOutputStream按照默认规则继续序列化。同样，在从流数据恢复成实例对象时，也会检查是否有一个私有的readObject方法，如果有，则会通过该方法读取属性值，此处有几个关键点需要说明：
- oos.defaultWriteObject():告知JVM按照默认的规则写入对象，惯例的写法是写在第一行。
- input.defaultReadObject():告知JVM按照默认规则读入对象，惯例的写法是写在第一行。
- oos.writeXX和input.readXX
分别是写入和读出相应的值，类似一个队列，先进先出，如果此处有复杂的数据逻辑，建议按封装Collection对象处理。大家可能注意到上面的方式也是Person失去了分布式部署的能了，确实是，但是HR系统的难点和重点是薪水的计算，特别是绩效工资，它所依赖的参数很复杂（仅从数量上说就有上百甚至上千种），计算公式也不简单(一般是引入脚本语言，个性化公式定制)而相对来说Person类基本上都是静态属性，计算的可能性不大，所以即使为性能考虑，Person类为分布式部署的意义也不大。
建议15：break万万不可忘
我们经常会写一些转换类，比如货币转换，日期转换，编码转换等，在金融领域里用到的最多的要数中文数字转换了，比如把"1"转换为"壹" ，不过开源工具是不会提供此工具类的，因为它太贴近中国文化了，需要自己编写：
public class Client15 {
public static void main(String[] args) {
System.out.println(toChineseNuberCase(0));
}
public static String toChineseNuberCase(int n) {
String chineseNumber = "";
switch (n) {
case 0:
chineseNumber = "零";
case 1:
chineseNumber = "壹";
case 2:
chineseNumber = "贰";
case 3:
chineseNumber = "叁";
case 4:
chineseNumber = "肆";
case 5:
chineseNumber = "伍";
case 6:
chineseNumber = "陆";
case 7:
chineseNumber = "柒";
case 8:
chineseNumber = "捌";
case 9:
chineseNumber = "玖";
}
return chineseNumber;
}
}
这是一个简单的代码，但运行结果却是"玖"，这个很简单，可能大家在刚接触语法时都学过，但虽简单，如果程序员漏写了，简单的问题会造成很大的后果，甚至经济上的损失。所以在用switch语句上记得加上break，养成良好的习惯。对于此类问题，除了平常小心之外，可以使用单元测试来避免，但大家都晓得，项目紧的时候，可能但单元测试都覆盖不了。所以对于此类问题，一个最简单的办法就是：修改IDE的警告级别，例如在Eclipse中，可以依次点击PerFormaces-->Java-->Compiler-->Errors/Warings-->Potential Programming problems,然后修改'switch' case fall-through为Errors级别，如果你胆敢不在case语句中加入break，那Eclipse直接就报个红叉给你看，这样可以避免该问题的发生了。但还是啰嗦一句，养成良好习惯更重要!
建议16：易变业务使用脚本语言编写
Java世界一直在遭受着异种语言的入侵，比如PHP，Ruby，Groovy、Javascript等，这些入侵者都有一个共同特征：全是同一类语言-----脚本语言，它们都是在运行期解释执行的。为什么Java这种强编译型语言会需要这些脚本语言呢？那是因为脚本语言的三大特征，如下所示：
- 灵活：脚本语言一般都是动态类型，可以不用声明变量类型而直接使用，可以再运行期改变类型。
- 便捷：脚本语言是一种解释性语言，不需要编译成二进制代码，也不需要像Java一样生成字节码。它的执行时依靠解释器解释的，因此在运行期间变更代码很容易，而且不用停止应用；
- 简单：只能说部分脚本语言简单，比如Groovy，对于程序员来说，没有多大的门槛。
脚本语言的这些特性是Java缺少的，引入脚本语言可以使Java更强大，于是Java6开始正式支持脚本语言。但是因为脚本语言比较多，Java的开发者也很难确定该支持哪种语言，于是JSCP（Java Community ProCess）很聪明的提出了JSR233规范，只要符合该规范的语言都可以在Java平台上运行（它对JavaScript是默认支持的）。
简单看看下面这个小例子：
function formual(var1, var2){
return var1 + var2 * factor;
}
这就是一个简单的脚本语言函数，可能你会很疑惑:factor(因子)这个变量是从那儿来的？它是从上下文来的，类似于一个运行的环境变量。该js保存在C:/model.js中，下一步需要调用JavaScript公式，代码如下：
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.util.Scanner;
import javax.script.Bindings;
import javax.script.Invocable;
import javax.script.ScriptContext;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
public class Client16 {
public static void main(String[] args) throws FileNotFoundException,
ScriptException, NoSuchMethodException {
// 获得一个JavaScript执行引擎
ScriptEngine engine = new ScriptEngineManager().getEngineByName("javascript");
// 建立上下文变量
Bindings bind = engine.createBindings();
bind.put("factor", 1);
// 绑定上下文，作用于是当前引擎范围
engine.setBindings(bind, ScriptContext.ENGINE_SCOPE);
Scanner input =new Scanner(System.in);
while(input.hasNextInt()){
int first = input.nextInt();
int second = input.nextInt();
System.out.println("输入参数是："+first+","+second);
// 执行Js代码
engine.eval(new FileReader("C:/model.js"));
// 是否可调用方法
if (engine instanceof Invocable) {
Invocable in = (Invocable) engine;
// 执行Js中的函数
Double result = (Double) in.invokeFunction("formula", first, second);
System.out.println("运算结果是：" + result.intValue());
}
}
}
}
上段代码使用Scanner类接受键盘输入的两个数字，然后调用JavaScript脚本的formula函数计算其结果，注意，除非输入了一个非int数字，否则当前JVM会一直运行，这也是模拟生成系统的在线变更情况。运行结果如下：
输入参数是;1,2 运算结果是：3
此时，保持JVM的运行状态，我们修改一下formula函数，代码如下：
function formual(var1, var2){
return var1 + var2 - factor;
}
其中,乘号变成了减号，计算公式发生了重大改变。回到JVM中继续输入，运行结果如下：
输入参数：1,2 运行结果是：2
修改Js代码，JVM没有重启，输入参数也没有任何改变，仅仅改变脚本函数即可产生不同的效果。这就是脚本语言对系统设计最有利的地方：可以随时发布而不用部署；这也是我们javaer最喜爱它的地方----即使进行变更，也能提供不间断的业务服务。
Java6不仅仅提供了代码级的脚本内置，还提供了jrunscript命令工具，它可以再批处理中发挥最大效能，而且不需要通过JVM解释脚本语言，可以直接通过该工具运行脚本。想想看。这是多么大的诱惑力呀！而且这个工具是可以跨操作系统的，脚本移植就更容易了。
建议17：慎用动态编译
动态编译一直是java的梦想，从Java6开始支持动态编译了，可以再运行期直接编译.java文件，执行.class，并且获得相关的输入输出，甚至还能监听相关的事件。不过，我们最期望的还是定一段代码，直接编译，然后运行，也就是空中编译执行（on-the-fly），看如下代码：
import java.io.IOException;
import java.lang.reflect.Method;
import java.net.URI;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import javax.tools.JavaCompiler;
import javax.tools.JavaFileObject;
import javax.tools.SimpleJavaFileObject;
import javax.tools.StandardJavaFileManager;
import javax.tools.ToolProvider;
public class Client17 {
public static void main(String[] args) throws Exception {
// Java源代码
String sourceStr = "public class Hello { public String sayHello (String name) {return \"Hello,\"+name+\"!\";}}";
// 类名及文件名
String clsName = "Hello";
// 方法名
String methodName = "sayHello";
// 当前编译器
JavaCompiler cmp = ToolProvider.getSystemJavaCompiler();
// Java标准文件管理器
StandardJavaFileManager fm = cmp.getStandardFileManager(null, null,
null);
// Java文件对象
JavaFileObject jfo = new StringJavaObject(clsName, sourceStr);
// 编译参数，类似于javac <options>中的options
List<String> optionsList = new ArrayList<String>();
// 编译文件的存放地方，注意：此处是为Eclipse工具特设的
optionsList.addAll(Arrays.asList("-d", "./bin"));
// 要编译的单元
List<JavaFileObject> jfos = Arrays.asList(jfo);
// 设置编译环境
JavaCompiler.CompilationTask task = cmp.getTask(null, fm, null,
optionsList, null, jfos);
// 编译成功
if (task.call()) {
// 生成对象
Object obj = Class.forName(clsName).newInstance();
Class<? extends Object> cls = obj.getClass();
// 调用sayHello方法
Method m = cls.getMethod(methodName, String.class);
String str = (String) m.invoke(obj, "Dynamic Compilation");
System.out.println(str);
}
}
}
class StringJavaObject extends SimpleJavaFileObject {
// 源代码
private String content = "";
// 遵循Java规范的类名及文件
public StringJavaObject(String _javaFileName, String _content) {
super(_createStringJavaObjectUri(_javaFileName), Kind.SOURCE);
content = _content;
}
// 产生一个URL资源路径
private static URI _createStringJavaObjectUri(String name) {
// 注意，此处没有设置包名
return URI.create("String:///" + name + Kind.SOURCE.extension);
}
// 文本文件代码
@Override
public CharSequence getCharContent(boolean ignoreEncodingErrors)
throws IOException {
return content;
}
}
上面代码较多，可以作为一个动态编译的模板程序。只要是在本地静态编译能够实现的任务，比如编译参数，输入输出，错误监控等，动态编译都能实现。
Java的动态编译对源提供了多个渠道。比如，可以是字符串，文本文件，字节码文件，还有存放在数据库中的明文代码或者字节码。汇总一句话，只要符合Java规范的就可以在运行期动态加载，其实现方式就是实现JavaFileObject接口，重写getCharContent、openInputStream、openOutputStream，或者实现JDK已经提供的两个SimpleJavaFileObject、ForwardingJavaFileObject,具体代码可以参考上个例子。
动态编译虽然是很好的工具，让我们可以更加自如的控制编译过程，但是在我们目前所接触的项目中还是使用较少。原因很简单，静态编译已经能够帮我们处理大部分的工作，甚至是全部的工作，即使真的需要动态编译，也有很好的替代方案，比如Jruby、Groovy等无缝的脚本语言。另外，我们在使用动态编译时，需要注意以下几点：
- 在框架中谨慎使用：比如要在struts中使用动态编译，动态实现一个类，它若继承自ActionSupport就希望它成为一个Action。能做到，但是debug很困难；再比如在Spring中，写一个动态类，要让它注入到Spring容器中，这是需要花费老大功夫的。
- 不要在要求性能高的项目中使用：如果你在web界面上提供了一个功能，允许上传一个java文件然后运行，那就等于说:"我的机器没有密码，大家都可以看看"，这是非常典型的注入漏洞，只要上传一个恶意Java程序就可以让你所有的安全工作毁于一旦。
- 记录动态编译过程：建议记录源文件，目标文件，编译过程，执行过程等日志，不仅仅是为了诊断，还是为了安全和审计，对Java项目来说，空中编译和运行时很不让人放心的，留下这些依据可以很好地优化程序。
建议18：避免instanceof非预期结果
instanceof是一个简单的二元操作符，它是用来判断一个对象是否是一个类的实现，其操作类似于>=、==，非常简单，我们看段程序，代码如下:
import java.util.Date;
public class Client18 {
public static void main(String[] args) {
// String对象是否是Object的实例 true
boolean b1 = "String" instanceof Object;
// String对象是否是String的实例 true
boolean b2 = new String() instanceof String;
// Object对象是否是String的实例 false
boolean b3 = new Object() instanceof String;
// 拆箱类型是否是装箱类型的实例 编译不通过
boolean b4 = 'A' instanceof Character;
// 空对象是否是String的实例 false
boolean b5 = null instanceof String;
// 转换后的空对象是否是String的实例 false
boolean b6 = (String) null instanceof String;
// Date是否是String的实例 编译不通过
boolean b7 = new Date() instanceof String;
// 在泛型类型中判断String对象是否是Date的实例 false
boolean b8 = new GenericClass<String>().isDateInstance("");
}
}
class GenericClass<T> {
// 判断是否是Date类型
public boolean isDateInstance(T t) {
return t instanceof Date;
}
}
就这么一段程序，instanceof的应用场景基本都出现了，同时问题也产生了：这段程序中哪些语句编译不通过，我们一个一个的解释说:
- "String" instanceof Object：返回值是true，这很正常,"String"是一个字符串，字符串又继承了Object，那当然返回true了。
- new String() instanceof String：返回值是true，没有任何问题，一个类的对象当然是它的实例了。
- new Object() instanceof String：返回值为false，Object是父类，其对象当然不是String类的实例了。要注意的是，这句话其实完全可以编译通过，只要instanceof关键字的左右两个操作数有继承或实现关系，就可以编译通过。
- 'A' instanceof Character：这句话编译不通过，为什么呢？因为'A'是一个char类型，也就是一个基本类型，不是一个对象，instanceof只能用于对象的判断，不能用于基本类型的判断。
- null instanceof String：返回值为false，这是instanceof特有的规则，若做操作数为null，结果就直接返回false，不再运算右操作数是什么类。这对我们的程序非常有利，在使用instanceof操作符时，不用关心被判断的类(也就是左操作数)是否为null，这与我们经常用到的equals、toString方法不同。
- (String) null instanceof String：返回值为false，不要看这里有个强制类型转换就认为结果是true，不是的，null是一个万用类型，也就是说它可以没类型，即使做类型转换还是个null。
- new Date() instanceof String：编译不通过，因为Date类和String没有继承或实现关系，所以在编译时就直接报错了，instanceof操作符的左右操作数必须有继承或实现关系，否则编译会失败。
- new GenericClass().isDateInstance("")：编译不通过，非也，编译通过了，返回值为false，T是个String类型，于Date之间没有继承或实现关系，为什么"t instanceof Date"会编译通过呢？那是因为Java的泛型是为编码服务的，在编译成字节码时，T已经是Object类型了传递的实参是String类型，也就是说T的表面类型是Object，实际类型是String，那么"t instanceof Date"等价于"Object instanceof Date"了，所以返回false就很正常了。
建议19：断言绝对不是鸡肋
在防御式编程中经常会用断言(Assertion)对参数和环境做出判断，避免程序因不当的判断或输入错误而产生逻辑异常，断言在很多语言中都存在，C、C++、Python都有不同的断言表现形式.在Java中断言使用的是assert关键字，其基本用法如下：
assert<布尔表达式>
assert<布尔表达式> : <错误信息>
在布尔表达式为假时，跑出AssertionError错误，并附带了错误信息。assert的语法比较简单，有以下两个特性：
（1）、assert默认是不启用的
我们知道断言是为调试程序服务的，目的是为了能够迅速、方便地检查到程序异常，但Java在默认条件下是不启用的，要启用就要在编译、运行时加上相关的关键字，这就不多说，有需要的话可以参考一下Java规范。
（2）、assert跑出的异常AssertionError是继承自Error的
断言失败后，JVM会抛出一个AssertionError的错误，它继承自Error，注意，这是一个错误，不可恢复，也就是表明这是一个严重问题，开发者必须予以关注并解决之。
assert虽然是做断言的，但不能将其等价于if...else...这样的条件判断，它在以下两种情况下不可使用：
(1)、在对外的公开方法中
我们知道防御式编程最核心的一点就是：所有的外部因素(输入参数、环境变量、上下文)都是"邪恶"的，都存在着企图摧毁程序的罪恶本源，为了抵制它，我们要在程序处处检验。满地设卡，不满足条件，就不执行后续程序，以保护后续程序的正确性，处处设卡没问题，但就是不能用断言做输入校验，特别是公开方法。我们开看一个例子：
public class Client19 {
public static void main(String[] args) {
System.out.println(StringUtils.encode(null));;
}
}
class StringUtils{
public static String encode(String str){
assert str != null : "加密的字符串为null";
/*加密处理*/
return str;
}
}
encode方法对输入参数做了不为空的假设，如果为空，则抛出AssertionError错误，但这段程序存在一个严重的问题，encode是一个public方法，这标志着它时对外公开的，任何一个类只要能传递一个String类型的参数（遵守契约）就可以调用，但是Client19类按照规定和契约调用encode方法，却获得了一个AssertionError错误信息，是谁破坏了契约协议？---是encode方法自己。
(2)、在执行逻辑代码的情况下
assert的支持是可选的，在开发时可以让他运行，但在生产环境中系统则不需要其运行了（以便提高性能），因此在assert的布尔表达式中不能执行逻辑代码，否则会因为环境的不同而产生不同的逻辑，例如：
public void doSomething(List list, Object element) {
assert list.remove(element) : "删除元素" + element + "失败";
/*业务处理*/
}
这段代码在assert启用的环境下没有任何问题，但是一但投入到生成环境，就不会启用断言了，而这个方法就彻底完蛋了，list的删除动作永远不会执行，所以就永远不会报错或异常了，因为根本就没有执行嘛！
以上两种情况下不能使用断言assert，那在什么情况下能够使用assert呢？一句话：按照正常的执行逻辑不可能到达的代码区域可以防止assert。具体分为三种情况：
- 在私有方法中放置assert作为输入参数的校验：在私有方法中可以放置assert校验输入参数，因为私有方法的使用者是作者自己，私有的方法的调用者和被调用者是一种契约关系，或者说没有契约关系，期间的约束是靠作者自己控制的，因此加上assert可以更好地预防自己犯错，或者无意的程序犯错。
- 流程控制中不可能到达的区域：这类似于Junit的fail方法，其标志性的意义就是，程序执行到这里就是错误的，例如：
public void doSomething() {
int i = 7;
while (i > 7) {
/* 业务处理 */
}
assert false : "到达这里就表示错误";
}
- 建立程序探针：我们可能会在一段程序中定义两个变量，分别代两个不同的业务含义，但是两者有固定的关系，例如:var1=var2 * 2，那我们就可以在程序中到处设"桩"了，断言这两者的关系，如果不满足即表明程序已经出现了异常，业务也就没有必要运行下去了。
建议20：不要只替换一个类
我们经常在系统中定义一个常量接口（或常量类），以囊括系统中所涉及的常量，从而简化代码，方便开发，在很多的开源项目中已经采用了类似的方法，比如在struts2中，org.apache.struts2.StrutsConstants就是一个常量类，它定义Struts框架中与配置有关的常量，而org.apache.struts2.StrutsConstants则是一个常量接口，其中定义了OGNL访问的关键字。
关于常量接口(类)我们开看一个例子，首先定义一个常量类：
public class Constant {
//定义人类寿命极限
public static final int MAX_AGE=150;
}
这是一个非常简单的常量类，定义了人类的最大年龄，我们引用这个常量，代码如下：
public class Client{
public static void main(String[] args) {
System.out.println("人类的寿命极限是："+Constant.MAX_AGE);
}
}
运行结果easy，故省略。目前的代码是写在"智能型"IDE工具中完成的，下面暂时回溯到原始时代，也就是回归到用记事本编写代码的年代，然后看看会发生什么事情（为什么要如此，下面会给出答案）
修改常量Constant类，人类的寿命极限增加了，最大活到180,代码如下：
public class Constant {
//定义人类寿命极限
public static final int MAX_AGE=180;
}
然后重新编译，javac Constant，编译完成后执行：java Client，大家猜猜输出的年龄是多少？
输出的结果是:"人类的寿命极限是150"，竟然没有改成180，太奇怪了，这是为何？
原因是：对于final修饰的基本类型和String类型，编译器会认为它是稳定态的(Immutable Status)所以在编译时就直接把值编译到字节码中了，避免了在运行期引用（Run-time Reference），以提高代码的执行效率。对于我们的例子来说，Client类在编译时字节码中就写上了"150",这个常量，而不是一个地址引用，因此无论你后续怎么修改常量类，只要不重新编译Client类，输出还是照旧。
对于final修饰的类(即非基本类型)，编译器会认为它不是稳定态的（Mutable Status），编译时建立的则是引用关系（该类型也叫作Soft Final）。如果Client类引入的常量是一个类或实例，及时不重新编译也会输出最新值。
千万不可小看了这点知识，细坑也能绊倒大象，比如在一个web项目中，开发人员修改了一个final类型的值（基本类型）考虑到重新发布的风险较大，或者是审批流程过于繁琐，反正是为了偷懒，于是直接采用替换class类文件的方式发布，替换完毕后应用服务器自动重启，然后简单测试一下，一切Ok，可运行几天后发现业务数据对不上，有的类(引用关系的类)使用了旧值，有的类（继承关系的类）使用的是新值，而且毫无头绪，让人一筹莫展，其实问题的根源就在于此。
还有个小问题没有说明，我们的例子为什么不在IDE工具(比如Eclipse)中运行呢？那是因为在IDE中设置了自动编译不能重现此问题，若修改了Constant类，IDE工具会自动编译所有的引用类,"智能"化屏蔽了该问题，但潜在的风险其实仍然存在，我记得Eclipse应该有个设置自动编译的入口，有兴趣大家可以自己尝试一下。
注意：发布应用系统时禁止使用类文件替换方式，整体WAR包发布才是万全之策。但我觉得应特殊情况特殊对待，并不可以偏概全，大家以为呢？