阅读目录
- 建议1：不要在常量和变量中出现易混淆的字母
- 建议2：莫让常量蜕变成变量
- 建议3：三元操作符的类型务必一致
- 建议4：避免带有变长参数的方法重载
- 建议5：别让null值和空值威胁到变长方法
建议1：不要在常量和变量中出现易混淆的字母
包名全小写，类名首字母全大写，常量全部大写并用下划线分隔，变量采用驼峰命名法(Camel Case)命名等，这些都是最基本的Java编码规范，是每个javaer都应熟知的规则，但是在变量的声明中要注意不要引入容易混淆的字母。尝试阅读如下代码，思考打印结果的i是多少：
1 public class Demo{
2 public static void main(String[] args) {
3 test01();
4 }
5
6 public static void test01(){
7 long i=1l;
8 System.out.println("i的两倍是："+(i+i));
9 }
10 }
肯定会有人说：这么简单的例子还能出错？运行结果肯定是22！实践是检验真理的唯一标准，将其Run一下看看，或许你会很奇怪，结果是2，而不是22.难道是编译器出问题了，少了个"2"?
因为赋给变量i的值就是数字"1",只是后面加了长整型变量的标示字母"l"而已。别说是我挖坑让你跳，如果有类似程序出现在项目中，当你试图通过阅读代码来理解作者的思想时，此情景就可能会出现。所以为了让你的程序更容易理解，字母"l"(包括大写字母"O")尽量不要和数字混用，以免使读者的理解和程序意图产生偏差。如果字母和数字混合使用，字母"l"务必大写，字母"O"则增加注释。
注意：字母"l"作为长整型标志时务必大写。
建议2：莫让常量蜕变成变量
常量蜕变成变量？你胡扯吧，加了final和static的常量怎么可能会变呢？不可能为此赋值的呀。真的不可能吗？看看如下代码：
1 import java.util.Random;
2
3 public class Demo01 {
4 public static void main(String[] args) {
5 test02();
6 }
7
8 public static void test02() {
9 System.out.println("常量会变哦:" + Constant.RAND_CONST);
10 }
11 }
12
13 interface Constant {
14 public static final int RAND_CONST = new Random().nextInt();
15 }
RAND_CONST是常量吗?它的值会变吗？绝对会变！这种常量的定义方式是绝对不可取的，常量就是常量，在编译期就必须确定其值，不应该在运行期更改，否则程序的可读性会非常差，甚至连作者自己都不能确定在运行期发生了何种神奇的事情。
甭想着使用常量会变的这个功能来实现序列号算法、随机种子生成，除非这真的是项目中的唯一方案，否则就放弃吧，常量还是当常量使用。
注意：务必让常量的值在运行期保持不变。
建议3：三元操作符的类型务必一致
三元操作符是if-else的简化写法，在项目中使用它的地方很多，也非常好用，但是好用又简单的东西并不表示就可以随意使用，看看如下代码:
1 public static void test03() {
2 int i = 80;
3 String str = String.valueOf(i < 100 ? 90 : 100);
4 String str1 = String.valueOf(i < 100 ? 90 : 100.0);
5 System.out.println("两者是否相等：" + str.equals(str1));
6 }
分析一下这段程序，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)就是为了更好地挺好方法的复用性，让方法的调用者可以"随心所欲"地传递实参数量，当然变长参数也是要遵循一定规则的，比如变长参数必须是方法中的最后一个参数；一个方法不能定义多个变长参数等，这些基本规则需要牢记，但是即使记住了这些规则，仍然有可能出现错误，看如下代码:
1 public class Client {
2 public static void main(String[] args) {
3 Client client = new Client();
4 // 499元的货物 打75折
5 client.calPrice(499, 75);
6 }
7
8 // 简单折扣计算
9 public void calPrice(int price, int discount) {
10 float knockdownPrice = price * discount / 100.0F;
11 System.out.println("简单折扣后的价格是：" + formatCurrency(knockdownPrice));
12 }
13
14 // 复杂多折扣计算
15 public void calPrice(int price, int... discounts) {
16 float knockdownPrice = price;
17 for (int discount : discounts) {
18 knockdownPrice = knockdownPrice * discount / 100;
19 }
20 System.out.println("复杂折扣后的价格是：" + formatCurrency(knockdownPrice));
21 }
22
23 public String formatCurrency(float price) {
24 return NumberFormat.getCurrencyInstance().format(price);
25 }
26 }
这是一个计算商品折扣的模拟类，带有两个参数的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值和空值威胁到变长方法
上一建议讲解了变长参数的重载问题，本建议会继续讨论变长参数的重载问题，上一建议的例子是变长参数的范围覆盖了非变长参数的范围，这次讨论两个都是变长参数的方法说起，代码如下:
1 public class Client5 {
2
3 public void methodA(String str, Integer... is) {
4
5 }
6
7 public void methodA(String str, String... strs) {
8
9 }
10
11 public static void main(String[] args) {
12 Client5 client5 = new Client5();
13 client5.methodA("china", 0);
14 client5.methodA("china", "people");
15 client5.methodA("china");
16 client5.methodA("china", null);
17 }
18 }
两个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方法都符合调用要求，但不知道调用哪一个，于是报错了。仔细分析一下，除了不符合上面的懒人原则之外，还有一个非常不好的编码习惯，即调用者隐藏了实参类型，这是非常危险的，不仅仅调用者需要"猜测调用那个方法"，而且被调用者也可能产生内部逻辑混乱的情况。对于本例来说应该如此修改:
1 public static void main(String[] args) {
2 Client5 client5 = new Client5();
3 String strs[] = null;
4 client5.methodA("china", strs);
5 }
也就是说让编译器知道这个null值是String类型的，编译即可顺利通过，也就减少了错误的发生。
建议6：覆写变长方法也循规蹈矩
在JAVA中，子类覆写父类的中的方法很常见，这样做既可以修正bug，也可以提供扩展的业务功能支持，同时还符合开闭原则(Open-Closed Principle)。
符合开闭原则(Open-Closed Principle)的主要特征：
1.对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。
2.对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。
下面我们看一下覆写必须满足的条件：
- 覆写方法不能缩小访问权限；
- 参数列表必须与被覆写方法相同；
- 返回类型必须与被重写方法的相同；
- 重写方法不能抛出新的异常，或者超出父类范围的异常，但是可以抛出更少，更有限的异常，或者不抛出异常。
看下面这段代码:
1 public class Client6 {
2 public static void main(String[] args) {
3 // 向上转型
4 Base base = new Sub();
5 base.fun(100, 50);
6 // 不转型
7 Sub sub = new Sub();
8 sub.fun(100, 50);
9 }
10 }
11
12 // 基类
13 class Base {
14 void fun(int price, int... discounts) {
15 System.out.println("Base......fun");
16 }
17 }
18
19 // 子类，覆写父类方法
20 class Sub extends Base {
21 @Override
22 void fun(int price, int[] discounts) {
23 System.out.println("Sub......fun");
24 }
25 }
该程序中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后赋值，这样理解了很多年也木有问题，直到遇到如下代码，我才怀疑我的理解是不是错了:
1 public class Client7 {
2 public static void main(String[] args) {
3 int count=0;
4 for(int i=0; i<10;i++){
5 count=count++;
6 }
7 System.out.println("count = "+count);
8 }
9 }
这个程序输出的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++"这条语句可以按照如下代码理解：
1 public static int mockAdd(int count) {
2 // 先保存初始值
3 int temp = count;
4 // 做自增操作
5 count = count + 1;
6 // 返回原始值
7 return temp;
8 }
于是第一次循环后count的值为0，其它9次循环也是一样的，最终你会发现count的值始终没有改变，仍然保持着最初的状态.
此例中代码作者的本意是希望count自增，所以想当然的赋值给自身就可以了，不曾想到调到Java自增的陷阱中了，解决办法很简单，把"count=count++"改为"count++"即可。该问题在不同的语言环境中有着不同的实现：C++中"count=count++"与"count++"是等效的，而在PHP中保持着与JAVA相同的处理方式。每种语言对自增的实现方式各不相同。
建议8：不要让旧语法困扰你
1 public class Client8 {
2 public static void main(String[] args) {
3 // 数据定义初始化
4 int fee = 200;
5 // 其它业务处理
6 saveDefault: save(fee);
7 }
8
9 static void saveDefault() {
10 System.out.println("saveDefault....");
11 }
12
13 static void save(int fee) {
14 System.out.println("save....");
15 }
16 }
这段代码分析一下，输出结果，以及语法含义：
- 首先这段代码中有标号(:)操作符，C语言的同学一看便知，类似JAVA中的保留关键字 go to 语句，但Java中抛弃了goto语法，只是不进行语义处理，与此类似的还有const关键字。
- Java中虽然没有了goto语法，但扩展了break和continue关键字，他们的后面都可以加上标号做跳转，完全实现了goto功能，同时也把goto的诟病带进来了。
- 运行之后代码输入为"save....",运行时没错，但这样的代码，给大家阅读上造成了很大的问题，所以就语法就让他随风远去吧!
建议9：少用静态导入
从Java5开始引入了静态导入语法(import static),其目的是为了减少字符的输入量，提高代码的可阅读性，以便更好地理解程序。我们先俩看一个不用静态导入的例子，也就是一般导入：
1 public class Client9 {
2 // 计算圆面积
3 public static double claCircleArea(double r) {
4 return Math.PI * r * r;
5 }
6
7 // 计算球面积
8 public static double claBallArea(double r) {
9 return 4 * Math.PI * r * r;
10 }
11 }
这是很简单的两个方法，我们再这两个计算面积的方法中都引入了java.lang.Math类(该类是默认导入的)中的PI(圆周率)常量，而Math这个类写在这里有点多余，特别是如果Client9类中的方法比较多时。如果每次输入都需要敲入Math这个类，繁琐且多余，静态导入可以解决此问题，使用静态导入后的程序如下：
1 import static java.lang.Math.PI;
2
3 public class Client9 {
4 // 计算圆面积
5 public static double claCircleArea(double r) {
6 return PI * r * r;
7 }
8
9 // 计算球面积
10 public static double claBallArea(double r) {
11 return 4 * PI * r * r;
12 }
13 }
静态导入的作用是把Math类中的Pi常量引入到本类中，这会是程序更简单，更容易阅读，只要看到PI就知道这是圆周率，不用每次都把类名写全了。但是，滥用静态导入会使程序更难阅读，更难维护，静态导入后，代码中就不需要再写类名了，但我们知道类是"一类事物的描述"，缺少了类名的修饰，静态属性和静态方法的表象意义可以被无限放大，这会让阅读者很难弄清楚其属性或者方法代表何意，绳子哪一类的属性(方法)都要思考一番（当然IDE的友好提示功能另说），把一个类的静态导入元素都引入进来了，那简直就是噩梦。我们来看下面的例子：
1 import static java.lang.Math.*;
2 import static java.lang.Double.*;
3 import static java.lang.Integer.*;
4 import static java.text.NumberFormat.*;
5
6 import java.text.NumberFormat;
7
8 public class Client9 {
9
10 public static void formatMessage(String s) {
11 System.out.println("圆面积是: " + s);
12 }
13
14 public static void main(String[] args) {
15 double s = PI * parseDouble(args[0]);
16 NumberFormat nf = getInstance();
17 nf.setMaximumFractionDigits(parseInt(args[1]));
18 formatMessage(nf.format(s));
19
20 }
21 }
就这么一段程序，看着就让人恼火，常量PI，这知道是圆周率；parseDouble方法可能是Double类的一个转换方法，这看名称可以猜的到。那紧接着getInstance()方法是哪个类的？是Client9本地类？不对呀，本地没有这个方法，哦，原来是NumberFormat类的方法，这个和formatMessage本地方法没有任何区别了---这代码太难阅读了，肯定有人骂娘。
所以，对于静态导入，一定要追寻两个原则：
- 不使用*(星号)通配符，除非是导入静态常量类(只包含常量的类或接口)；
- 方法名是具有明确、清晰表象意义的工具类。
何为具有明确、清晰表象意义的工具类，我们看看Junit中使用静态导入的例子：
1 import static org.junit.Assert.*;
2 class DaoTest{
3 @Test
4 public void testInsert(){
5 //断言
6 assertEquals("foo","foo");
7 assertFalse(Boolean.FALSE);
8 }
9 }
我们从程序中很容易判断出assertEquals方法是用来断言两个值是否相等的，assertFalse方法则是断言表达式为假，如此确实减少了代码量，而且代码的可读性也提高了，这也是静态导入用到正确的地方带来的好处。
建议10：不要在本类中覆盖静态导入的变量和方法
如果在一个类中的方法及属性与静态导入的方法及属性相同会出现什么问题呢?看下面的代码
1 import static java.lang.Math.PI;
2 import static java.lang.Math.abs;
3
4 public class Client10 {
5 // 常量名于静态导入的PI相同
6 public final static String PI = "祖冲之";
7 //方法名于静态导入的方法相同
8 public static int abs(int abs) {
9 return 0;
10 }
11
12 public static void main(String[] args) {
13 System.out.println("PI = "+PI);
14 System.out.println("abs(-100) = "+abs(-100));
15 }
16 }
以上代码中定义了一个String类型的常量PI，又定义了一个abs方法，与静态导入的相同。首先说好消息，代码没有报错，接下来是坏消息:我们不知道那个属性和方法别调用了，因为常量名和方法名相同，到底调用了那一个方法呢？运行之后结果为：
PI = "祖冲之"，abs(-100) = 0;
很明显是本地的方法被调用了，为何不调用Math类中的属性和方法呢？那是因为编译器有一个"最短路径"原则:如果能够在本类中查找到相关的变量、常量、方法、就不会去其它包或父类、接口中查找，以确保本类中的属性、方法优先。
因此，如果要变更一个被静态导入的方法，最好的办法是在原始类中重构，而不是在本类中覆盖.
建议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变量在以下情况下不会被重新赋值:
- 通过构造函数为final变量赋值
- 通过方法返回值为final变量赋值
- 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系统中获取人员姓名和基本工资，而绩效工资是不能获得的，这是个保密数据，不允许发生泄漏。怎么解决这个问题呢？你可能会想到以下四种方案:
- 在bonus前加上关键字transient：这是一个方法，但不是一个好方法，加上transient关键字就标志着Salary失去了分布式部署的功能，它可能是HR系统核心的类了，一旦遭遇性能瓶颈，再想实现分布式部署就可能了，此方案否定;
- 新增业务对象：增加一个Person4Tax类，完全为计税系统服务，就是说它只有两个属性：姓名和基本工资。符合开闭原则，而且对原系统也没有侵入性，只是增加了工作量而已。但是这个方法不是最优方法;
- 请求端过滤：在计税系统获得Person对象后，过滤掉Salary的bonus属性，方案可行但不符合规矩，因为HR系统中的Salary类安全性竟然然外系统(计税系统来承担)，设计严重失职;
- 变更传输契约：例如改用XML传输，或者重建一个WebSerive服务，可以做但成本很高。
下面展示一个优秀的方案，其中实现了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方法，如果有，则会通过该方法读取属性值，此处有几个关键点需要说明：
- oos.defaultWriteObject():告知JVM按照默认的规则写入对象，惯例的写法是写在第一行。
- input.defaultReadObject():告知JVM按照默认规则读入对象，惯例的写法是写在第一行。
- 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直接就报个红叉给你看，这样可以避免该问题的发生了。但还是啰嗦一句，养成良好习惯更重要!
建议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公式，代码如下：
1 import java.io.FileNotFoundException;
2 import java.io.FileReader;
3 import java.util.Scanner;
4
5 import javax.script.Bindings;
6 import javax.script.Invocable;
7 import javax.script.ScriptContext;
8 import javax.script.ScriptEngine;
9 import javax.script.ScriptEngineManager;
10 import javax.script.ScriptException;
11
12 public class Client16 {
13 public static void main(String[] args) throws FileNotFoundException,
14 ScriptException, NoSuchMethodException {
15 // 获得一个JavaScript执行引擎
16 ScriptEngine engine = new ScriptEngineManager().getEngineByName("javascript");
17 // 建立上下文变量
18 Bindings bind = engine.createBindings();
19 bind.put("factor", 1);
20 // 绑定上下文，作用于是当前引擎范围
21 engine.setBindings(bind, ScriptContext.ENGINE_SCOPE);
22 Scanner input =new Scanner(System.in);
23
24 while(input.hasNextInt()){
25 int first = input.nextInt();
26 int second = input.nextInt();
27 System.out.println("输入参数是："+first+","+second);
28 // 执行Js代码
29 engine.eval(new FileReader("C:/model.js"));
30 // 是否可调用方法
31 if (engine instanceof Invocable) {
32 Invocable in = (Invocable) engine;
33 // 执行Js中的函数
34 Double result = (Double) in.invokeFunction("formula", first, second);
35 System.out.println("运算结果是：" + result.intValue());
36 }
37 }
38
39 }
40 }
上段代码使用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），看如下代码：
1 import java.io.IOException;
2 import java.lang.reflect.Method;
3 import java.net.URI;
4 import java.util.ArrayList;
5 import java.util.Arrays;
6 import java.util.List;
7
8 import javax.tools.JavaCompiler;
9 import javax.tools.JavaFileObject;
10 import javax.tools.SimpleJavaFileObject;
11 import javax.tools.StandardJavaFileManager;
12 import javax.tools.ToolProvider;
13
14 public class Client17 {
15 public static void main(String[] args) throws Exception {
16 // Java源代码
17 String sourceStr = "public class Hello { public String sayHello (String name) {return \"Hello,\"+name+\"!\";}}";
18 // 类名及文件名
19 String clsName = "Hello";
20 // 方法名
21 String methodName = "sayHello";
22 // 当前编译器
23 JavaCompiler cmp = ToolProvider.getSystemJavaCompiler();
24 // Java标准文件管理器
25 StandardJavaFileManager fm = cmp.getStandardFileManager(null, null,
26 null);
27 // Java文件对象
28 JavaFileObject jfo = new StringJavaObject(clsName, sourceStr);
29 // 编译参数，类似于javac 中的options
30 List optionsList = new ArrayList();
31 // 编译文件的存放地方，注意：此处是为Eclipse工具特设的
32 optionsList.addAll(Arrays.asList("-d", "./bin"));
33 // 要编译的单元
34 List jfos = Arrays.asList(jfo);
35 // 设置编译环境
36 JavaCompiler.CompilationTask task = cmp.getTask(null, fm, null,
37 optionsList, null, jfos);
38 // 编译成功
39 if (task.call()) {
40 // 生成对象
41 Object obj = Class.forName(clsName).newInstance();
42 Class cls = obj.getClass();
43 // 调用sayHello方法
44 Method m = cls.getMethod(methodName, String.class);
45 String str = (String) m.invoke(obj, "Dynamic Compilation");
46 System.out.println(str);
47 }
48
49 }
50 }
51
52 class StringJavaObject extends SimpleJavaFileObject {
53 // 源代码
54 private String content = "";
55
56 // 遵循Java规范的类名及文件
57 public StringJavaObject(String _javaFileName, String _content) {
58 super(_createStringJavaObjectUri(_javaFileName), Kind.SOURCE);
59 content = _content;
60 }
61
62 // 产生一个URL资源路径
63 private static URI _createStringJavaObjectUri(String name) {
64 // 注意，此处没有设置包名
65 return URI.create("String:///" + name + Kind.SOURCE.extension);
66 }
67
68 // 文本文件代码
69 @Override
70 public CharSequence getCharContent(boolean ignoreEncodingErrors)
71 throws IOException {
72 return content;
73 }
74 }
上面代码较多，可以作为一个动态编译的模板程序。只要是在本地静态编译能够实现的任务，比如编译参数，输入输出，错误监控等，动态编译都能实现。
Java的动态编译对源提供了多个渠道。比如，可以是字符串，文本文件，字节码文件，还有存放在数据库中的明文代码或者字节码。汇总一句话，只要符合Java规范的就可以在运行期动态加载，其实现方式就是实现JavaFileObject接口，重写getCharContent、openInputStream、openOutputStream，或者实现JDK已经提供的两个SimpleJavaFileObject、ForwardingJavaFileObject,具体代码可以参考上个例子。
动态编译虽然是很好的工具，让我们可以更加自如的控制编译过程，但是在我们目前所接触的项目中还是使用较少。原因很简单，静态编译已经能够帮我们处理大部分的工作，甚至是全部的工作，即使真的需要动态编译，也有很好的替代方案，比如Jruby、Groovy等无缝的脚本语言。另外，我们在使用动态编译时，需要注意以下几点：
- 在框架中谨慎使用：比如要在struts中使用动态编译，动态实现一个类，它若继承自ActionSupport就希望它成为一个Action。能做到，但是debug很困难；再比如在Spring中，写一个动态类，要让它注入到Spring容器中，这是需要花费老大功夫的。
- 不要在要求性能高的项目中使用：如果你在web界面上提供了一个功能，允许上传一个java文件然后运行，那就等于说:"我的机器没有密码，大家都可以看看"，这是非常典型的注入漏洞，只要上传一个恶意Java程序就可以让你所有的安全工作毁于一旦。
- 记录动态编译过程：建议记录源文件，目标文件，编译过程，执行过程等日志，不仅仅是为了诊断，还是为了安全和审计，对Java项目来说，空中编译和运行时很不让人放心的，留下这些依据可以很好地优化程序。
建议18：避免instanceof非预期结果
instanceof是一个简单的二元操作符，它是用来判断一个对象是否是一个类的实现，其操作类似于>=、==，非常简单，我们看段程序，代码如下:
1 import java.util.Date;
2
3 public class Client18 {
4 public static void main(String[] args) {
5 // String对象是否是Object的实例 true
6 boolean b1 = "String" instanceof Object;
7 // String对象是否是String的实例 true
8 boolean b2 = new String() instanceof String;
9 // Object对象是否是String的实例 false
10 boolean b3 = new Object() instanceof String;
11 // 拆箱类型是否是装箱类型的实例 编译不通过
12 boolean b4 = 'A' instanceof Character;
13 // 空对象是否是String的实例 false
14 boolean b5 = null instanceof String;
15 // 转换后的空对象是否是String的实例 false
16 boolean b6 = (String) null instanceof String;
17 // Date是否是String的实例 编译不通过
18 boolean b7 = new Date() instanceof String;
19 // 在泛型类型中判断String对象是否是Date的实例 false
20 boolean b8 = new GenericClass().isDateInstance("");
21
22 }
23 }
24
25 class GenericClass {
26 // 判断是否是Date类型
27 public boolean isDateInstance(T t) {
28 return t instanceof Date;
29 }
30
31 }
就这么一段程序，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)、在对外的公开方法中
我们知道防御式编程最核心的一点就是：所有的外部因素(输入参数、环境变量、上下文)都是"邪恶"的，都存在着企图摧毁程序的罪恶本源，为了抵制它，我们要在程序处处检验。满地设卡，不满足条件，就不执行后续程序，以保护后续程序的正确性，处处设卡没问题，但就是不能用断言做输入校验，特别是公开方法。我们开看一个例子：
1 public class Client19 {
2 public static void main(String[] args) {
3 System.out.println(StringUtils.encode(null));;
4 }
5 }
6
7 class StringUtils{
8 public static String encode(String str){
9 assert str != null : "加密的字符串为null";
10 /*加密处理*/
11 return str;
12
13 }
14 }
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 : "到达这里就表示错误";
}
3.建立程序探针：我们可能会在一段程序中定义两个变量，分别代两个不同的业务含义，但是两者有固定的关系，例如: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应该有个设置自动编译的入口，有兴趣大家可以自己尝试一下。
建议21：用偶判断，不用奇判断
判断一个数是奇数还是偶数是小学里的基本知识，能够被2整除的整数是偶数，不能被2整除的数是奇数，这规则简单明了，还有什么可考虑的？好，我们来看一个例子，代码如下：
1 import java.util.Scanner;
2
3 public class Client21 {
4 public static void main(String[] args) {
5 // 接收键盘输入参数
6 Scanner input = new Scanner(System.in);
7 System.out.println("输入多个数字判断奇偶：");
8 while (input.hasNextInt()) {
9 int i = input.nextInt();
10 String str = i + "-->" + (i % 2 == 1 ? "奇数" : "偶数");
11 System.out.println(str);
12
13 }
14 }
15 }
输入多个数字，然后判断每个数字的奇偶性，不能被2整除的就是奇数，其它的都是偶数，完全是根据奇偶数的定义编写的程序，我们开看看打印的结果：
输入多个数字判断奇偶：1 2 0 -1 -2 1-->奇数 2-->偶数 0-->偶数 -1-->偶数 -2-->偶数
前三个还很靠谱，第四个参数-1怎么可能是偶数呢，这Java也太差劲了吧。如此简单的计算也会出错！别忙着下结论，我们先来了解一下Java中的取余(%标识符)算法，模拟代码如下：
// 模拟取余计算，dividend被除数，divisor除数
public static int remainder(int dividend, int divisor) {
return dividend - dividend / divisor * divisor;
}
看到这段程序，大家都会心的笑了，原来Java这么处理取余计算的呀，根据上面的模拟取余可知，当输入-1的时候，运算结果为-1，当然不等于1了，所以它就被判定为偶数了，也就是我们的判断失误了。问题明白了，修正也很简单，改为判断是否是偶数即可。代码如下： i % 2 == 0 ? "偶数" : "奇数";
注意：对于基础知识，我们应该"知其然，并知其所以然"。
建议22：用整数类型处理货币
在日常生活中，最容易接触到的小数就是货币，比如，你付给售货员10元钱购买一个9.6元的零食，售货员应该找你0.4元，也就是4毛钱才对，我们来看下面的程序：
public class Client22 {
public static void main(String[] args) {
System.out.println(10.00-9.60);
}
}
我们的期望结果是0.4，也应该是这个数字，但是打印出来的却是:0.40000000000000036,这是为什么呢？
这是因为在计算机中浮点数有可能（注意是有可能）是不准确的，它只能无限接近准确值，而不能完全精确。为什么会如此呢？这是由浮点数的存储规则所决定的，我们先来看看0.4这个十进制小数如何转换成二进制小数，使用"乘2取整，顺序排列"法（不懂，这就没招了，这太基础了），我们发现0.4不能使用二进制准确的表示，在二进制数世界里它是一个无限循环的小数，也就是说，"展示" 都不能 "展示"，更别说在内存中存储了(浮点数的存储包括三部分：符号位、指数位、尾数，具体不再介绍)，可以这样理解，在十进制的世界里没有办法唯一准确表示1/3，那么在二进制的世界里当然也无法准确表示1/5(如果二进制也有分数的话倒是可以表示)，在二进制的世界里1/5是一个无限循环的小数。
大家可能要说了，那我对结果取整不就对了吗？代码如下
public class Client22 {
public static void main(String[] args) {
NumberFormat f = new DecimalFormat("#.##");
System.out.println(f.format(10.00-9.60));
}
}
打印出的结果是0.4，看似解决了。但是隐藏了一个很深的问题。我们来思考一下金融行业的计算方法，会计系统一般记录小数点后的4为小数，但是在汇总、展现、报表中、则只记录小数点后的2位小数，如果使用浮点数来计算货币，想想看，在大批量加减乘除后结果会有很大的差距(其中还涉及到四舍五入的问题)！会计系统要求的就是准确，但是因为计算机的缘故不准确了，那真是罪过，要解决此问题有两种方法：
(1)、使用BigDecimal
BigDecimal是专门为弥补浮点数无法精确计算的缺憾而设计的类，并且它本身也提供了加减乘除的常用数学算法。特别是与数据库Decimal类型的字段映射时，BigDecimal是最优的解决方案。
(2)、使用整型
把参与运算的值扩大100倍，并转为整型，然后在展现时再缩小100倍，这样处理的好处是计算简单，准确，一般在非金融行业(如零售行业)应用较多。此方法还会用于某些零售POS机，他们输入和输出的全部是整数，那运算就更简单了.
建议23：不要让类型默默转换
我们做一个小学生的题目，光速每秒30万公里，根据光线的旅行时间，计算月球和地球，太阳和地球之间的距离。代码如下：
1 public class Client23 {
2 // 光速是30万公里/秒，常量
3 public static final int LIGHT_SPEED = 30 * 10000 * 1000;
4
5 public static void main(String[] args) {
6 System.out.println("题目1：月球照射到地球需要一秒，计算月亮和地球的距离。");
7 long dis1 = LIGHT_SPEED * 1;
8 System.out.println("月球与地球的距离是：" + dis1 + " 米 ");
9 System.out.println("-------------------------------");
10 System.out.println("题目2：太阳光照射到地球需要8分钟，计算太阳到地球的距离.");
11 // 可能要超出整数范围，使用long型
12 long dis2 = LIGHT_SPEED * 60 * 8;
13 System.out.println("太阳与地球之间的距离是：" + dis2 + " 米");
14 }
15 }
估计有人鄙视了，这种小学生的乘法有神么可做的，不错，就是一个乘法运算，我们运行之后的结果如下：
题目1：月球照射到地球需要一秒，计算月亮和地球的距离。
月球与地球的距离是：300000000 米
-------------------------------
题目2：太阳光照射到地球需要8分钟，计算太阳到地球的距离.
太阳与地球之间的距离是：-2028888064 米
太阳和地球的距离竟然是负的，诡异。dis2不是已经考虑到int类型可能越界的问题，并使用了long型吗，怎么还会出现负值呢？
那是因为Java是先运算然后进行类型转换的，具体的说就是因为dis2的三个运算参数都是int型，三者相乘的结果虽然也是int型，但是已经超过了int的最大值，所以其值就是负值了(为什么是负值，因为过界了就会重头开始)，再转换为long型，结果还是负值。
问题知道了，解决起来也很简单，只要加个小小的L即可，代码如下：
long dis2 = LIGHT_SPEED * 60L * 8;
60L是一个长整型，乘出来的结果也是一个长整型的（此乃Java的基本转换规则，向数据范围大的方向转换，也就是加宽类型），在还没有超过int类型的范围时就已经转换为long型了，彻底解决了越界问题。在实际开发中，更通用的做法是主动声明类型转化(注意，不是强制类型转换)代码如下：
long dis2 = 1L * LIGHT_SPEED * 60L * 8
既然期望的结果是long型，那就让第一个参与的参数也是Long(1L)吧，也就说明"嗨"我已经是长整型了，你们都跟着我一块转为长整型吧。
注意：基本类型转换时，使用主动声明方式减少不必要的Bug.
建议24：边界还是边界
某商家生产的电子产品非常畅销，需要提前30天预订才能抢到手，同时还规定了一个会员可拥有的最多产品数量，目的是为了防止囤积压货肆意加价。会员的预订过程是这样的：先登录官方网站，选择产品型号，然后设置需要预订的数量，提交，符合规则即提示下单成功，不符合规则提示下单失败，后台的处理模拟如下：
1 import java.util.Scanner;
2
3 public class Client24 {
4 // 一个会员拥有产品的最多数量
5 public final static int LIMIT = 2000;
6
7 public static void main(String[] args) {
8 // 会员当前用有的产品数量
9 int cur = 1000;
10 Scanner input = new Scanner(System.in);
11 System.out.println("请输入需要预定的数量：");
12 while (input.hasNextInt()) {
13 int order = input.nextInt();
14 if (order > 0 && order + cur <= LIMIT) {
15 System.out.println("你已经成功预定：" + order + " 个产品");
16 } else {
17 System.out.println("超过限额，预定失败！");
18 }
19 }
20
21 }
22 }
这是一个简单的订单处理程序，其中cur代表的是会员当前拥有的产品数量，LIMIT是一个会员最多拥有的产品数量（现实中，这两个参数当然是从数据库中获得的，不过这里是一个模拟程序），如果当前预订数量与拥有数量之和超过了最大数量，则预订失败，否则下单成功。业务逻辑很简单，同时在web界面上对订单数量做了严格的校验，比如不能是负值、不能超过最大数量等，但是人算不如天算，运行不到两小时数据库中就出现了异常数据：某会员拥有的产品数量与预定数量之和远远大于限额。怎么会这样呢？程序逻辑上不可能有问题呀，这如何产生的呢？我们来模拟一下，第一次输入：
请输入需要预定的数量：800 你已经成功预定800个产品
这完全满足条件，没有任何问题，继续输入：
请输入需要预定的数量：2147483647 你已经成功预定2147483647个产品
看到没有，这个数字已经远远超过了2000的限额，但是竟然预定成功了，真实神奇！
看着2147483647这个数字很眼熟？那就对了，这个数字就是int类型的最大值，没错，有人输入了一个最大值，使校验条件失败了，Why？我们来看程序，order的值是2147483647那再加上1000就超出int的范围了，其结果是-2147482649，那当然是小于正数2000了！一句归其原因：数字越界使校验条件失效。
在单元测试中，有一项测试叫做边界测试(也叫临界测试)，如果一个方法接收的是int类型的参数，那么以下三个值是必须测试的:0、正最大、负最小，其中正最大、负最小是边界值，如果这三个值都没有问题，方法才是比较安全可靠的。我们的例子就是因为缺少边界测试，致使生产系统产生了严重的偏差。
也许你要疑惑了，Web界面已经做了严格的校验，为什么还能输入2147483647 这么大的数字呢？是否说明Web校验不严格?错了，不是这样的，Web校验都是在页面上通过JavaScript实现的，只能限制普通用户(这里的普通用户是指不懂html，不懂HTTP，不懂Java的简单使用者)，而对于高手，这些校验基本上就是摆设，HTTP是明文传输的，将其拦截几次，分析一下数据结构，然后写一个模拟器，一切前端校验就成了浮云！想往后台提交个什么数据还不是信手拈来！
建议25：不要让四舍五入亏了一方
本建议还是来重温一个小学数学问题：四舍五入。四舍五入是一种近似精确的计算方法，在Java5之前，我们一般是通过Math.round来获得指定精度的整数或小数的，这种方法使用非常广泛，代码如下：
public class Client25 {
public static void main(String[] args) {
System.out.println("10.5近似值: "+Math.round(10.5));
System.out.println("-10.5近似值: "+Math.round(-10.5));
}
}
输出结果为：10.5近似值: 11 -10.5近似值: -10
这是四舍五入的经典案例，也是初级面试官很乐意选择的考题，绝对值相同的两个数字，近似值为什么就不同了呢？这是由Math.round采用的舍入规则决定的(采用的是正无穷方向舍入规则)，我们知道四舍五入是有误差的：其误差值是舍入的一半。我们以舍入运用最频繁的银行利息计算为例来阐述此问题。
我们知道银行的盈利渠道主要是利息差，从储户手里收拢资金，然后房贷出去，期间的利息差额便是所获得利润，对一个银行来说，对付给储户的利息计算非常频繁，人民银行规定每个季度末月的20日为银行结息日，一年有4次的结息日。
场景介绍完毕，我们回头来看看四舍五入，小于5的数字被舍去，大于5的数字进位后舍去，由于单位上的数字都是自然计算出来的，按照利率计算可知，被舍去的数字都分布在0~9之间，下面以10笔存款利息计算作为模型，以银行家的身份来思考这个算法：
四舍：舍弃的数值是：0.000、0.001、0.002、0.003、0.004因为是舍弃的，对于银行家来说就不需要付款给储户了，那每舍一个数字就会赚取相应的金额：0.000、0.001、0.002、0.003、0.004.
五入：进位的数值是：0.005、0.006、0.007、0.008、0.009，因为是进位，对银行家来说，每进一位就会多付款给储户，也就是亏损了，那亏损部分就是其对应的10进制补数：0.005、.0004、0.003、0.002、0.001.
因为舍弃和进位的数字是均匀分布在0~9之间，对于银行家来说，没10笔存款的利息因采用四舍五入而获得的盈利是：
0.000 + 0.001 + 0.002 + 0.003 + 0.004 - 0.005 - 0.004 - 0.003 - 0.002 - 0.001 = - 0.005；
也就是说，每10笔利息计算中就损失0.005元，即每笔利息计算就损失0.0005元，这对一家有5千万储户的银行家来说(对国内银行来说，5千万是个小数字)，每年仅仅因为四舍五入的误差而损失的金额是：
银行账户数量（5千万）*4（一年计算四次利息）*0.0005（每笔利息损失的金额）
5000*10000*0.0005*4=100000.0；即，每年因为一个算法误差就损失了10万元，事实上以上的假设条件都是非常保守的，实际情况可能损失的更多。那各位可能要说了，银行还要放贷呀，放出去这笔计算误差不就抵消了吗？不会抵消，银行的贷款数量是非常有限的其数量级根本无法和存款相比。
这个算法误差是由美国银行家发现的(那可是私人银行，钱是自己的，白白损失了可不行)，并且对此提出了一个修正算法，叫做银行家舍入(Banker's Round)的近似算法，其规则如下：
- 舍去位的数值小于5时，直接舍去；
- 舍去位的数值大于等于6时，进位后舍去；
- 当舍去位的数值等于5时，分两种情况：5后面还有其它数字(非0)，则进位后舍去；若5后面是0(即5是最后一个数字)，则根据5前一位数的奇偶性来判断是否需要进位，奇数进位，偶数舍去。
以上规则汇总成一句话：四舍六入五考虑，五后非零就进一，五后为零看奇偶，五前为偶应舍去，五前为奇要进一。我们举例说明，取2位精度；
round(10.5551) = 10.56 round(10.555) = 10.56 round(10.545) = 10.54
要在Java5以上的版本中使用银行家的舍入法则非常简单，直接使用RoundingMode类提供的Round模式即可，示例代码如下：
1 import java.math.BigDecimal;
2 import java.math.RoundingMode;
3
4 public class Client25 {
5 public static void main(String[] args) {
6 // 存款
7 BigDecimal d = new BigDecimal(888888);
8 // 月利率，乘3计算季利率
9 BigDecimal r = new BigDecimal(0.001875*3);
10 //计算利息
11 BigDecimal i =d.multiply(r).setScale(2,RoundingMode.HALF_EVEN);
12 System.out.println("季利息是："+i);
13
14 }
15 }
在上面的例子中，我们使用了BigDecimal类，并且采用了setScale方法设置了精度，同时传递了一个RoundingMode.HALF_EVEN参数表示使用银行家法则进行近似计算，BigDecimal和RoundingMode是一个绝配，想要采用什么方式使用RoundingMode设置即可。目前Java支持以下七种舍入方式：
- ROUND_UP：原理零方向舍入。向远离0的方向舍入，也就是说，向绝对值最大的方向舍入，只要舍弃位非0即进位。
- ROUND_DOWN：趋向0方向舍入。向0方向靠拢，也就是说，向绝对值最小的方向输入，注意：所有的位都舍弃，不存在进位情况。
- ROUND_CEILING：向正无穷方向舍入。向正最大方向靠拢，如果是正数，舍入行为类似于ROUND_UP；如果为负数，则舍入行为类似于ROUND_DOWN.注意：Math.round方法使用的即为此模式。
- ROUND_FLOOR：向负无穷方向舍入。向负无穷方向靠拢，如果是正数，则舍入行为类似ROUND_DOWN，如果是负数，舍入行为类似以ROUND_UP。
- HALF_UP：最近数字舍入(5舍)，这就是我们经典的四舍五入。
- HALF_DOWN：最近数字舍入(5舍)。在四舍五入中，5是进位的，在HALF_DOWN中却是舍弃不进位。
- HALF_EVEN：银行家算法
在普通的项目中舍入模式不会有太多影响，可以直接使用Math.round方法，但在大量与货币数字交互的项目中，一定要选择好近似的计算模式，尽量减少因算法不同而造成的损失。
注意：根据不同的场景，慎重选择不同的舍入模式，以提高项目的精准度，减少算法损失。
附录:此处说的这些常量全部来自java的RoundingMode类，故而贴出此类的源码供大家参考。
1 package java.math; 2 /** 3 * Specifies a rounding behavior for numerical operations 4 * capable of discarding precision. Each rounding mode indicates how 5 * the least significant returned digit of a rounded result is to be 6 * calculated. If fewer digits are returned than the digits needed to 7 * represent the exact numerical result, the discarded digits will be 8 * referred to as the discarded fraction regardless the digits' 9 * contribution to the value of the number. In other words, 10 * considered as a numerical value, the discarded fraction could have 11 * an absolute value greater than one. 12 * 13 *Each rounding mode description includes a table listing how 14 * different two-digit decimal values would round to a one digit 15 * decimal value under the rounding mode in question. The result 16 * column in the tables could be gotten by creating a 17 * {@code BigDecimal} number with the specified value, forming a 18 * {@link MathContext} object with the proper settings 19 * ({@code precision} set to {@code 1}, and the 20 * {@code roundingMode} set to the rounding mode in question), and 21 * calling {@link BigDecimal#round round} on this number with the 22 * proper {@code MathContext}. A summary table showing the results 23 * of these rounding operations for all rounding modes appears below. 24 * 25 *
26 *
| Result of rounding input to one digit with the given 29 * rounding mode | 30 *||||||||
|---|---|---|---|---|---|---|---|---|
| Input Number | {@code UP} | 32 *{@code DOWN} | 33 *{@code CEILING} | 34 *{@code FLOOR} | 35 *{@code HALF_UP} | 36 *{@code HALF_DOWN} | 37 *{@code HALF_EVEN} | 38 *{@code UNNECESSARY} | 39 * 40 *
| 5.5 | 6 | 5 | 6 | 5 | 6 | 5 | 6 | throw {@code ArithmeticException} | 41 *
| 2.5 | 3 | 2 | 3 | 2 | 3 | 2 | 2 | throw {@code ArithmeticException} | 42 *
| 1.6 | 2 | 1 | 2 | 1 | 2 | 2 | 2 | throw {@code ArithmeticException} | 43 *
| 1.1 | 2 | 1 | 2 | 1 | 1 | 1 | 1 | throw {@code ArithmeticException} | 44 *
| 1.0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 45 *
| -1.0 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | 46 *
| -1.1 | -2 | -1 | -1 | -2 | -1 | -1 | -1 | throw {@code ArithmeticException} | 47 *
| -1.6 | -2 | -1 | -1 | -2 | -2 | -2 | -2 | throw {@code ArithmeticException} | 48 *
| -2.5 | -3 | -2 | -2 | -3 | -3 | -2 | -2 | throw {@code ArithmeticException} | 49 *
| -5.5 | -6 | -5 | -5 | -6 | -6 | -5 | -6 | throw {@code ArithmeticException} | 50 *
This {@code enum} is intended to replace the integer-based 54 * enumeration of rounding mode constants in {@link BigDecimal} 55 * ({@link BigDecimal#ROUND_UP}, {@link BigDecimal#ROUND_DOWN}, 56 * etc. ). 57 * 58 * @see BigDecimal 59 * @see MathContext 60 * @author Josh Bloch 61 * @author Mike Cowlishaw 62 * @author Joseph D. Darcy 63 * @since 1.5 64 */ 65 public enum RoundingMode { 66 67 /** 68 * Rounding mode to round away from zero. Always increments the 69 * digit prior to a non-zero discarded fraction. Note that this 70 * rounding mode never decreases the magnitude of the calculated 71 * value. 72 * 73 *
Example: 74 *
| Input Number | 76 *Input rounded to one digit with {@code UP} rounding 77 * |
|---|---|
| 5.5 | 6 | 78 *
| 2.5 | 3 | 79 *
| 1.6 | 2 | 80 *
| 1.1 | 2 | 81 *
| 1.0 | 1 | 82 *
| -1.0 | -1 | 83 *
| -1.1 | -2 | 84 *
| -1.6 | -2 | 85 *
| -2.5 | -3 | 86 *
| -5.5 | -6 | 87 *
Example: 97 *
| Input Number | 99 *Input rounded to one digit with {@code DOWN} rounding 100 * |
|---|---|
| 5.5 | 5 | 101 *
| 2.5 | 2 | 102 *
| 1.6 | 1 | 103 *
| 1.1 | 1 | 104 *
| 1.0 | 1 | 105 *
| -1.0 | -1 | 106 *
| -1.1 | -1 | 107 *
| -1.6 | -1 | 108 *
| -2.5 | -2 | 109 *
| -5.5 | -5 | 110 *
Example: 121 *
| Input Number | 123 *Input rounded to one digit with {@code CEILING} rounding 124 * |
|---|---|
| 5.5 | 6 | 125 *
| 2.5 | 3 | 126 *
| 1.6 | 2 | 127 *
| 1.1 | 2 | 128 *
| 1.0 | 1 | 129 *
| -1.0 | -1 | 130 *
| -1.1 | -1 | 131 *
| -1.6 | -1 | 132 *
| -2.5 | -2 | 133 *
| -5.5 | -5 | 134 *
Example: 145 *
| Input Number | 147 *Input rounded to one digit with {@code FLOOR} rounding 148 * |
|---|---|
| 5.5 | 5 | 149 *
| 2.5 | 2 | 150 *
| 1.6 | 1 | 151 *
| 1.1 | 1 | 152 *
| 1.0 | 1 | 153 *
| -1.0 | -1 | 154 *
| -1.1 | -2 | 155 *
| -1.6 | -2 | 156 *
| -2.5 | -3 | 157 *
| -5.5 | -6 | 158 *
Example: 171 *
| Input Number | 173 *Input rounded to one digit with {@code HALF_UP} rounding 174 * |
|---|---|
| 5.5 | 6 | 175 *
| 2.5 | 3 | 176 *
| 1.6 | 2 | 177 *
| 1.1 | 1 | 178 *
| 1.0 | 1 | 179 *
| -1.0 | -1 | 180 *
| -1.1 | -1 | 181 *
| -1.6 | -2 | 182 *
| -2.5 | -3 | 183 *
| -5.5 | -6 | 184 *
Example: 196 *
| Input Number | 198 *Input rounded to one digit with {@code HALF_DOWN} rounding 199 * |
|---|---|
| 5.5 | 5 | 200 *
| 2.5 | 2 | 201 *
| 1.6 | 2 | 202 *
| 1.1 | 1 | 203 *
| 1.0 | 1 | 204 *
| -1.0 | -1 | 205 *
| -1.1 | -1 | 206 *
| -1.6 | -2 | 207 *
| -2.5 | -2 | 208 *
| -5.5 | -5 | 209 *
Example: 228 *
| Input Number | 230 *Input rounded to one digit with {@code HALF_EVEN} rounding 231 * |
|---|---|
| 5.5 | 6 | 232 *
| 2.5 | 2 | 233 *
| 1.6 | 2 | 234 *
| 1.1 | 1 | 235 *
| 1.0 | 1 | 236 *
| -1.0 | -1 | 237 *
| -1.1 | -1 | 238 *
| -1.6 | -2 | 239 *
| -2.5 | -2 | 240 *
| -5.5 | -6 | 241 *
Example: 251 *
| Input Number | 253 *Input rounded to one digit with {@code UNNECESSARY} rounding 254 * |
|---|---|
| 5.5 | throw {@code ArithmeticException} | 255 *
| 2.5 | throw {@code ArithmeticException} | 256 *
| 1.6 | throw {@code ArithmeticException} | 257 *
| 1.1 | throw {@code ArithmeticException} | 258 *
| 1.0 | 1 | 259 *
| -1.0 | -1 | 260 *
| -1.1 | throw {@code ArithmeticException} | 261 *
| -1.6 | throw {@code ArithmeticException} | 262 *
| -2.5 | throw {@code ArithmeticException} | 263 *
| -5.5 | throw {@code ArithmeticException} | 264 *
建议26：提防包装类型的null值
我们知道Java引入包装类型(Wrapper Types)是为了解决基本类型的实例化问题，以便让一个基本类型也能参与到面向对象的编程世界中。而在Java5中泛型更是对基本类型说了"不"，如果把一个整型放入List中，就必须使用Integer包装类型。我们看一段代码：
1 import java.util.ArrayList;
2 import java.util.List;
3
4 public class Client26 {
5
6 public static int testMethod(List list) {
7 int count = 0;
8 for (int i : list) {
9 count += i;
10 }
11 return count;
12 }
13
14 public static void main(String[] args) {
15 List list = new ArrayList();
16 list.add(1);
17 list.add(2);
18 list.add(null);
19 System.out.println(testMethod(list));
20 }
21 }
testMethod接收一个元素是整型的List参数，计算所有元素之和，这在统计和项目中很常见，然后编写一个测试testMethod，在main方法中把1、2和空值都放到List中，然后调用方法计算，现在思考一下会不会报错。应该不会吧，基本类型和包装类型都是可以通过自动装箱（Autoboxing）和自动拆箱(AutoUnboxing)自由转换的，null应该可以转换为0吧，真的是这样吗？运行之后的结果是： Exception in thread "main" java.lang.NullPointerException 运行失败，报空指针异常，我们稍稍思考一下很快就知道原因了：在程序for循环中，隐含了一个拆箱过程，在此过程中包装类型转换为了基本类型。我们知道拆箱过程是通过调用包装对象的intValue方法来实现的，由于包装类型为null，访问其intValue方法报空指针异常就在所难免了。问题清楚了，修改也很简单，加入null值检查即可，代码如下：
public static int testMethod(Listlist) { int count = 0; for (Integer i : list) { count += (i != null) ? i : 0; } return count; }
上面以Integer和int为例说明了拆箱问题，其它7个包装对象的拆箱过程也存在着同样的问题。包装对象和拆箱对象可以自由转换，这不假，但是要剔除null值，null值并不能转换为基本类型。对于此问题，我们谨记一点：包装类型参与运算时，要做null值校验。
建议27：谨慎包装类型的大小比较
基本类型是可以比较大小的，其所对应的包装类型都实现了Comparable接口，也说明了此问题，那我们来比较一下两个包装类型的大小，代码如下：
1 public class Client27 {
2 public static void main(String[] args) {
3 Integer i = new Integer(100);
4 Integer j = new Integer(100);
5 compare(i, j);
6 }
7
8 public static void compare(Integer i, Integer j) {
9 System.out.println(i == j);
10 System.out.println(i > j);
11 System.out.println(i < j);
12
13 }
14 }
代码很简单，产生了两个Integer对象，然后比较两个的大小关系，既然包装类型和基本类型是可以自由转换的，那上面的代码是不是就可以打印出两个相等的值呢？让事实说话，运行结果如下：
false false false
竟然是3个false，也就是说两个值之间不相等，也没大小关系，这个也太奇怪了吧。不奇怪，我们来一 一解释：
- i==j：在java中"=="是用来判断两个操作数是否有相等关系的，如果是基本类型则判断值是否相等，如果是对象则判断是否是一个对象的两个引用，也就是地址是否相等，这里很明显是两个对象，两个地址不可能相等。
- i>j 和 i
问题清楚了，修改总是比较容易的，直接使用Integer的实例compareTo方法即可，但是这类问题的产生更应该说是习惯问题，只要是两个对象之间的比较就应该采用相应的方法，而不是通过Java的默认机制来处理，除非你确定对此非常了解。
建议28：优先使用整型池
上一个建议我们解释了包装对象的比较问题，本建议将继续深入讨论相关问题，首先看看如下代码：
1 import java.util.Scanner;
2
3 public class Client28 {
4 public static void main(String[] args) {
5 Scanner input = new Scanner(System.in);
6 while (input.hasNextInt()) {
7 int tempInt = input.nextInt();
8 System.out.println("\n=====" + tempInt + " 的相等判断=====");
9 // 两个通过new产生的对象
10 Integer i = new Integer(tempInt);
11 Integer j = new Integer(tempInt);
12 System.out.println(" new 产生的对象：" + (i == j));
13 // 基本类型转换为包装类型后比较
14 i = tempInt;
15 j = tempInt;
16 System.out.println(" 基本类型转换的对象：" + (i == j));
17 // 通过静态方法生成一个实例
18 i = Integer.valueOf(tempInt);
19 j = Integer.valueOf(tempInt);
20 System.out.println(" valueOf产生的对象：" + (i == j));
21 }
22 }
23 }
输入多个数字，然后按照3中不同的方式产生Integer对象，判断其是否相等，注意这里使用了"=="，这说明判断的不是同一个对象。我们输入三个数字127、128、555，结果如下：
127
=====127 的相等判断=====
new 产生的对象：false
基本类型转换的对象：true
valueOf产生的对象：true
128
=====128 的相等判断=====
new 产生的对象：false
基本类型转换的对象：false
valueOf产生的对象：false
555
=====555 的相等判断=====
new 产生的对象：false
基本类型转换的对象：false
valueOf产生的对象：false
很不可思议呀，数字127的比较结果竟然和其它两个数字不同，它的装箱动作所产生的对象竟然是同一个对象，valueOf产生的也是同一个对象，但是大于127的数字和128和555的比较过程中产生的却不是同一个对象，这是为什么？我们来一个一个解释。
(1)、new产生的Integer对象
new声明的就是要生成一个新的对象，没二话，这是两个对象，地址肯定不等，比较结果为false。
(2)、装箱生成的对象
对于这一点，首先要说明的是装箱动作是通过valueOf方法实现的，也就是说后两个算法相同的，那结果肯定也是一样的，现在问题是：valueOf是如何生成对象的呢？我们来阅读以下Integer.valueOf的源码：
1 /**
2 * Returns an {@code Integer} instance representing the specified
3 * {@code int} value. If a new {@code Integer} instance is not
4 * required, this method should generally be used in preference to
5 * the constructor {@link #Integer(int)}, as this method is likely
6 * to yield significantly better space and time performance by
7 * caching frequently requested values.
8 *
9 * This method will always cache values in the range -128 to 127,
10 * inclusive, and may cache other values outside of this range.
11 *
12 * @param i an {@code int} value.
13 * @return an {@code Integer} instance representing {@code i}.
14 * @since 1.5
15 */
16 public static Integer valueOf(int i) {
17 assert IntegerCache.high >= 127;
18 if (i >= IntegerCache.low && i <= IntegerCache.high)
19 return IntegerCache.cache[i + (-IntegerCache.low)];
20 return new Integer(i);
21 }
这段代码的意思已经很明了了，如果是-128到127之间的int类型转换为Integer对象，则直接从cache数组中获得，那cache数组里是什么东西，JDK7的源代码如下：
1 /** 2 * Cache to support the object identity semantics of autoboxing for values between 3 * -128 and 127 (inclusive) as required by JLS. 4 * 5 * The cache is initialized on first usage. The size of the cache 6 * may be controlled by the -XX:AutoBoxCacheMax=option. 7 * During VM initialization, java.lang.Integer.IntegerCache.high property 8 * may be set and saved in the private system properties in the 9 * sun.misc.VM class. 10 */ 11 12 private static class IntegerCache { 13 static final int low = -128; 14 static final int high; 15 static final Integer cache[]; 16 17 static { 18 // high value may be configured by property 19 int h = 127; 20 String integerCacheHighPropValue = 21 sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high"); 22 if (integerCacheHighPropValue != null) { 23 int i = parseInt(integerCacheHighPropValue); 24 i = Math.max(i, 127); 25 // Maximum array size is Integer.MAX_VALUE 26 h = Math.min(i, Integer.MAX_VALUE - (-low)); 27 } 28 high = h; 29 30 cache = new Integer[(high - low) + 1]; 31 int j = low; 32 for(int k = 0; k < cache.length; k++) 33 cache[k] = new Integer(j++); 34 } 35 36 private IntegerCache() {} 37 }
cache是IntegerCache内部类的一个静态数组，容纳的是-128到127之间的Integer对象。通过valueOf产生包装对象时，如果int参数在-128到127之间，则直接从整型池中获得对象，不在该范围内的int类型则通过new生成包装对象。
明白了这一点，要理解上面的输出结果就迎刃而解了，127的包装对象是直接从整型池中获得的，不管你输入多少次127这个数字，获得的对象都是同一个，那地址自然是相等的。而128、555超出了整型池范围，是通过new产生一个新的对象，地址不同，当然也就不相等了。
以上的理解也是整型池的原理，整型池的存在不仅仅提高了系统性能，同时也节约了内存空间，这也是我们使用整型池的原因，也就是在声明包装对象的时候使用valueOf生成，而不是通过构造函数来生成的原因。顺便提醒大家，在判断对象是否相等的时候，最好使用equals方法，避免使用"=="产生非预期效果。
注意：通过包装类型的valueOf生成的包装实例可以显著提高空间和时间性能。
建议29：优先选择基本类型
包装类型是一个类，它提供了诸如构造方法，类型转换，比较等非常实用的功能，而且在Java5之后又实现了与基本类型的转换，这使包装类型如虎添翼，更是应用广泛了，在开发中包装类型已经随处可见，但无论是从安全性、性能方面来说，还是从稳定性方面来说，基本类型都是首选方案。我们看一段代码：
1 public class Client29 {
2 public static void main(String[] args) {
3 Client29 c = new Client29();
4 int i = 140;
5 // 分别传递int类型和Integer类型
6 c.testMethod(i);
7 c.testMethod(new Integer(i));
8 }
9
10 public void testMethod(long a) {
11 System.out.println(" 基本类型的方法被调用");
12 }
13
14 public void testMethod(Long a) {
15 System.out.println(" 包装类型的方法被调用");
16 }
17 }
在上面的程序中首先声明了一个int变量i，然后加宽转变成long型，再调用testMethod()方法,分别传递int和long的基本类型和包装类型，诸位想想该程序是否能够编译？如果能编译，输出结果又是什么呢？
首先，这段程序绝对是能够编译的。不过，说不能编译的同学还是动了一番脑筋的，你可能猜测以下这些地方不能编译：
(1)、testMethod方法重载问题。定义的两个testMethod()方法实现了重载，一个形参是基本类型，一个形参是包装类型，这类重载很正常。虽然基本类型和包装类型有自动装箱、自动拆箱功能，但并不影响它们的重载，自动拆箱(装箱)只有在赋值时才会发生，和编译重载没有关系。
(2)、c.testMethod(i) 报错。i 是int类型，传递到testMethod(long a)是没有任何问题的，编译器会自动把 i 的类型加宽，并将其转变为long型，这是基本类型的转换法则，也没有任何问题。
(3)、c.testMethod(new Integer(i))报错。代码中没有testMethod(Integer i)方法，不可能接收一个Integer类型的参数，而且Integer和Long两个包装类型是兄弟关系，不是继承关系，那就是说肯定编译失败了？不，编译时成功的，稍后再解释为什么这里编译成功。
既然编译通过了，我们看一下输出：
基本类型的方法被调用
基本类型的方法被调用
c.testMethod(i)的输出是正常的，我们已经解释过了，那第二个输出就让人困惑了，为什么会调用testMethod（long a）方法呢？这是因为自动装箱有一个重要原则：基本类型可以先加宽，再转变成宽类型的包装类型，但不能直接转变成宽类型的包装类型。这句话比较拗口，简单的说就是，int可以加宽转变成long，然后再转变成Long对象，但不能直接转变成包装类型，注意这里指的都是自动转换，不是通过构造函数生成，为了解释这个原则，我们再来看一个例子：
1 public class Client29 {
2 public static void main(String[] args) {
3 Client29 c = new Client29();
4 int i = 140;
5 c.testMethod(i);
6 }
7
8 public void testMethod(Long a) {
9 System.out.println(" 包装类型的方法被调用");
10 }
11 }
这段程序的编译是不通过的，因为i是一个int类型，不能自动转变为Long型，但是修改成以下代码就可以通过了：
int i = 140; long a =（long）i； c.testMethod(a);
这就是int先加宽转变成为long型，然后自动转换成Long型，规则说明了，我们继续来看testMethod(Integer.valueOf(i))是如何调用的，Integer.valueOf(i)返回的是一个Integer对象，这没错，但是Integer和int是可以互相转换的。没有testMethod(Integer i)方法？没关系，编译器会尝试转换成int类型的实参调用，Ok，这次成功了，与testMethod（i）相同了，于是乎被加宽转变成long型---结果也很明显了。整个testMethod(Integer.valueOf(i))的执行过程是这样的：
(1)、i 通过valueOf方法包装成一个Integer对象
(2)、由于没有testMethod(Integer i)方法，编译器会"聪明"的把Integer对象转换成int。
(3)、int自动拓宽为long，编译结束
使用包装类型确实有方便的方法，但是也引起一些不必要的困惑，比如我们这个例子，如果testMethod()的两个重载方法使用的是基本类型，而且实参也是基本类型，就不会产生以上问题，而且程序的可读性更强。自动装箱(拆箱)虽然很方便，但引起的问题也非常严重，我们甚至都不知道执行的是哪个方法。
注意：重申，基本类型优先考虑。
建议30：不要随便设置随机种子
随机数用的地方比较多，比如加密，混淆计算，我们使用随机数期望获得一个唯一的、不可仿造的数字，以避免产生相同的业务数据造成混乱。在Java项目中通常是通过Math.random方法和Random类来获得随机数的，我们来看一段代码：
1 import java.util.Random;
2
3 public class Client30 {
4 public static void main(String[] args) {
5 Random r = new Random();
6 for(int i=1; i<=4; i++){
7 System.out.println("第"+i+"次:"+r.nextInt());
8
9 }
10 }
11 }
代码很简单，我们一般都是这样获得随机数的，运行此程序可知，三次打印，的随机数都不相同，即使多次运行结果也不同，这也正是我们想要随机数的原因，我们再来看看下面的程序：
1 public class Client30 {
2 public static void main(String[] args) {
3 Random r = new Random(1000);
4 for(int i=1; i<=4; i++){
5 System.out.println("第"+i+"次:"+r.nextInt());
6
7 }
8 }
9 }
上面使用了Random的有参构造，运行结果如下：
第1次:-1244746321
第2次:1060493871
第3次:-1826063944
第4次:1976922248
计算机不同输出的随机数也不同，但是有一点是相同的：在同一台机器上，甭管运行多少次，所打印的随机数都是相同的，也就是说第一次运行，会打印出这几个随机数，第二次运行还是打印出这三个随机数，只要是在同一台机器上，就永远都会打印出相同的随机数，似乎随机数不随机了，问题何在？
那是因为产生的随机数的种子被固定了，在Java中，随机数的产生取决于种子，随机数和种子之间的关系遵从以下两个原则：
- 种子不同，产生不同的随机数
- 种子相同，即使实例不同也产生相同的随机数
看完上面两个规则，我们再来看这个例子，会发现问题就出在有参构造上，Random类的默认种子(无参构造)是System.nonoTime()的返回值(JDK1.5版本以前默认种子是System.currentTimeMillis()的返回值)，注意这个值是距离某一个固定时间点的纳秒数，不同的操作系统和硬件有不同的固定时间点，也就是说不同的操作系统其纳秒值是不同的，而同一个操作系统纳秒值也会不同，随机数自然也就不同了.(顺便说下，System.nonoTime不能用于计算日期，那是因为"固定"的时间是不确定的，纳秒值甚至可能是负值，这点与System.currentTiemMillis不同)。
new Random(1000)显示的设置了随机种子为1000，运行多次，虽然实例不同，但都会获得相同的四个随机数，所以，除非必要，否则不要设置随机种子。
顺便提一下，在Java中有两种方法可以获得不同的随机数：通过，java.util.Random类获得随机数的原理和Math.random方法相同，Math.random方法也是通过生成一个Random类的实例，然后委托nextDouble()方法的，两者殊途同归，没有差别。
建议31：在接口中不要存在实现代码
看到这样的标题，大家是否感到郁闷呢？接口中有实现代码吗？这怎么可能呢？确实，接口中可以声明常量，声明抽象方法，可以继承父接口，但就是不能有具体实现，因为接口是一种契约(Contract),是一种框架性协议，这表明它的实现类都是同一种类型，或者具备相似特征的一个集合体。对于一般程序，接口确实没有任何实现，但是在那些特殊的程序中就例外了，阅读如下代码：
1 public class Client31 {
2 public static void main(String[] args) {
3 //调用接口的实现
4 B.s.doSomeThing();
5 }
6 }
7
8 // 在接口中存在实现代码
9 interface B {
10 public static final S s = new S() {
11 public void doSomeThing() {
12 System.out.println("我在接口中实现了");
13 }
14 };
15 }
16
17 // 被实现的接口
18 interface S {
19 public void doSomeThing();
20 }
仔细看main方法，注意那个B接口。它调用了接口常量，在没有实现任何显示实现类的情况下，它竟然打印出了结果，那B接口中的s常量(接口是S)是在什么地方被实现的呢？答案在B接口中。
在B接口中声明了一个静态常量s，其值是一个匿名内部类(Anonymous Inner Class)的实例对象，就是该匿名内部类（当然，也可以不用匿名，直接在接口中是实现内部类也是允许的）实现了S接口。你看，在接口中也存在着实现代码吧！
这确实很好，很强大，但是在一般的项目中，此类代码是严禁出现的，原因很简单：这是一种非常不好的编码习惯，接口是用来干什么的？接口是一个契约，不仅仅约束着实现，同时也是一个保证，保证提供的服务(常量和方法)是稳定的、可靠的，如果把实现代码写到接口中，那接口就绑定了可能变化的因素，这会导致实现不再稳定和可靠，是随时都可能被抛弃、被更改、被重构的。所以，接口中虽然可以有实现，但应避免使用。
注意：接口中不能出现实现代码。
建议32：静态变量一定要先声明后赋值
这个标题是否像上一个建议的标题一样让人郁闷呢？什么叫做变量一定要先声明后赋值？Java中的变量不都是先声明后使用的吗？难道还能先使用后声明?能不能暂且不说，我们看一个例子，代码如下：
1 public class Client32 {
2 public static int i = 1;
3
4 static {
5 i = 100;
6 }
7 public static void main(String[] args) {
8 System.out.println(i);
9 }
10 }
这段程序很简单，输出100嘛，对，确实是100，我们稍稍修改一下，代码如下：
1 public class Client32 {
2 static {
3 i = 100;
4 }
5
6 public static int i = 1;
7
8 public static void main(String[] args) {
9 System.out.println(i);
10 }
11 }
注意变量 i 的声明和赋值调换了位置，现在的问题是：这段程序能否编译？如过可以编译，输出是多少？还要注意，这个变量i可是先使用(也就是赋值)后声明的。
答案是：可以编译，没有任何问题，输出结果为1。对，输出是 1 不是100.仅仅调换了位置，输出就变了，而且变量 i 还是先使用后声明的，难道颠倒了？
这要从静态变量的诞生说起，静态变量是类加载时被分配到数据区(Data Area)的，它在内存中只有一个拷贝，不会被分配多次，其后的所有赋值操作都是值改变，地址则保持不变。我们知道JVM初始化变量是先声明空间，然后再赋值，也就是说：在JVM中是分开执行的，等价于：
int i ; //分配空间
i = 100; //赋值
静态变量是在类初始化的时候首先被加载的，JVM会去查找类中所有的静态声明，然后分配空间，注意这时候只是完成了地址空间的分配，还没有赋值，之后JVM会根据类中静态赋值(包括静态类赋值和静态块赋值)的先后顺序来执行。对于程序来说，就是先声明了int类型的地址空间，并把地址传递给了i，然后按照类的先后顺序执行赋值操作，首先执行静态块中i = 100,接着执行 i = 1,那最后的结果就是 i =1了。
哦，如此而已，如果有多个静态块对 i 继续赋值呢？i 当然还是等于1了，谁的位置最靠后谁有最终的决定权。
有些程序员喜欢把变量定义放到类最底部，如果这是实例变量还好说，没有任何问题，但如果是静态变量，而且还在静态块中赋值了，那这结果就和期望的不一样了，所以遵循Java通用的开发规范"变量先声明后赋值使用"，是一个良好的编码风格。
注意：再次重申变量要先声明后使用，这不是一句废话。
建议33：不要覆写静态方法
我们知到在Java中可以通过覆写(Override)来增强或减弱父类的方法和行为，但覆写是针对非静态方法(也叫做实例方法，只有生成实例才能调用的方法)的，不能针对静态方法(static修饰的方法，也叫做类方法)，为什么呢？我们看一个例子，代码如下：
1 public class Client33 {
2 public static void main(String[] args) {
3 Base base = new Sub();
4 //调用非静态方法
5 base.doAnything();
6 //调用静态方法
7 base.doSomething();
8 }
9 }
10
11 class Base {
12 // 我是父类静态方法
13 public static void doSomething() {
14 System.out.println("我是父类静态方法");
15 }
16
17 // 父类非静态方法
18 public void doAnything() {
19 System.out.println("我是父类非静态方法");
20 }
21 }
22
23 class Sub extends Base {
24 // 子类同名、同参数的静态方法
25 public static void doSomething() {
26 System.out.println("我是子类静态方法");
27 }
28
29 // 覆写父类非静态方法
30 @Override
31 public void doAnything() {
32 System.out.println("我是子类非静态方法");
33 }
34 }
注意看程序，子类的doAnything方法覆写了父类方法，真没有问题，那么doSomething方法呢？它与父类的方法名相同，输入、输出也相同，按道理来说应该是覆写，不过到底是不是覆写呢？我们看看输出结果： 我是子类非静态方法 我是父类静态方法
这个结果很让人困惑，同样是调用子类方法，一个执行了父类方法，两者的差别仅仅是有无static修饰，却得到不同的结果，原因何在呢？
我们知道一个实例对象有两个类型：表面类型(Apparent Type)和实际类型(Actual Type)，表面类型是声明的类型，实际类型是对象产生时的类型，比如我们例子，变量base的表面类型是Base，实际类型是Sub。对于非静态方法，它是根据对象的实际类型来执行的，也就是执行了Sub类中的doAnything方法。而对于静态方法来说就比较特殊了，首先静态方法不依赖实例对象，它是通过类名来访问的；其次，可以通过对象访问静态方法，如果是通过对象访问静态方法，JVM则会通过对象的表面类型查找静态方法的入口，继而执行之。因此上面的程序打印出"我是父类非静态方法"，也就不足为奇了。
在子类中构建与父类方法相同的方法名、输入参数、输出参数、访问权限(权限可以扩大)，并且父类，子类都是静态方法，此种行为叫做隐藏(Hide),它与覆写有两点不同：
(1)、表现形式不同：隐藏用于静态方法，覆写用于非静态方法，在代码上的表现是@Override注解可用于覆写，不可用于隐藏。
(2)、职责不同：隐藏的目的是为了抛弃父类的静态方法，重现子类方法，例如我们的例子，Sub.doSomething的出现是为了遮盖父类的Base.doSomething方法，也就是i期望父类的静态方法不要做破坏子类的业务行为，而覆写是将父类的的行为增强或减弱，延续父类的职责。
解释了这么多，我们回头看看本建议的标题，静态方法不能覆写，可以再续上一句话，虽然不能覆写，但可以隐藏。顺便说一下，通过实例对象访问静态方法或静态属性不是好习惯，它给代码带来了"坏味道"，建议大家阅之戒之。
建议34：构造函数尽量简化
我们知道通过new关键字生成的对象必然会调用构造函数，构造函数的简繁情况会直接影响实例对象的创建是否繁琐，在项目开发中，我们一般都会制定构造函数尽量简单，尽可能不抛异常，尽量不做复杂运算等规范，那如果一个构造函数确实复杂了会怎么样？我们开看一段代码：
1 public class Client34 {
2 public static void main(String[] args) {
3 Server s= new SimpleServer(1000);
4 }
5 }
6
7 abstract class Server {
8 public final static int DEFAULT_PORT = 40000;
9
10 public Server() {
11 // 获得子类提供的端口号
12 int port = getPort();
13 System.out.println("端口号：" + port);
14 /* 进行监听动作 */
15 }
16
17 // 由子类提供端口号，并作可用性检查
18 protected abstract int getPort();
19 }
20
21 class SimpleServer extends Server {
22 private int port = 100;
23
24 // 初始化传递一个端口号
25 public SimpleServer(int _port) {
26 port = _port;
27 }
28
29 // 检查端口是否有效，无效则使用默认端口，这里使用随机数模拟
30 @Override
31 protected int getPort() {
32 return Math.random() > 0.5 ? port : DEFAULT_PORT;
33 }
34
35 }
该代码是一个服务类的简单模拟程序，Server类实现了服务器的创建逻辑，子类要在生成实例对象时传递一个端口号即可创建一个监听端口的服务，该代码的意图如下：
- 通过SimpleServer的构造函数接收端口参数；
- 子类的构造函数默认调用父类的构造函数；
- 父类构造函数调用子类的getPort方法获得端口号；
- 父类的构造函数建立端口监听机制；
- 对象创建完毕，服务监听启动，正常运行。
貌似很合理，再仔细看看代码，确实与我们的意图相吻合，那我们尝试多次运行看看，输出结果要么是"端口号：40000"，要么是"端口号：0",永远不会出现"端口号：100"或是"端口号：1000",这就奇怪了，40000还好说，那个0是怎么冒出来的呢？怠慢什么地方出现了问题呢？
要解释这个问题，我们首先要说说子类是如何实例化的。子类实例化时，会首先初始化父类(注意这里是初始化，不是生成父类对象)，也就是初始化父类的变量，调用父类的构造函数，然后才会初始化子类的变量，调用子类的构造函数，最后生成一个实例对象。了解了相关知识，我们再来看看上面的程序，其执行过程如下：
- 子类SimpleServer的构造函数接收int类型的参数1000；
- 父类初始化常量，也就是DEFAULT_PORT初始化，并设置值为40000;
- 执行父类无参构造函数，也就是子类有参构造函数默认包含了super()方法；
- 父类无参构造函数执行到“int port = getPort() ”方法，调用子类的getPort方法实现；
- 子类的getPort方法返回port值(注意，此时port变量还没有赋值，是0)或DEFAULT_PORT(此时已经是40000)了；
- 父类初始化完毕，开始初始化子类的实例变量，port值赋值100；
- 执行子类构造函数，port值被重新赋值为1000；
- 子类SimpleServer实例化结束，对象创建完毕。
终于清楚了，在类初始化时getPort方法返回值还没有赋值，port只是获得了默认初始值(int类型的实例变量默认初始值是0)，因此Server永远监听的是40000端口(0端口是没有意义的)。这个问题的产生从浅处说是类元素初始顺序导致的，从深处说是因为构造函数太复杂引起的。构造函数用作初始化变量，声明实例的上下文，这都是简单实现的，没有任何问题，但我们的例子却实现了一个复杂的逻辑，而这放在构造函数里就不合适了。
问题知道了，修改也很简单，把父类的无参构造函数中的所有实现都移动到一个叫做start的方法中，将SimpleServer类初始化完毕，再调用其start方法即可实现服务器的启动工作，简洁而又直观，这也是大部分JEE服务器的实现方式。
注意：构造函数简化，再简化，应该达到"一眼洞穿"的境界。
建议35：避免在构造函数中初始化其它类
构造函数是一个类初始化必须执行的代码，它决定着类初始化的效率，如果构造函数比较复杂，而且还关联了其它类，则可能产生想不到的问题，我们来看如下代码：
1 public class Client35 {
2 public static void main(String[] args) {
3 Son son = new Son();
4 son.doSomething();
5 }
6 }
7
8 // 父类
9 class Father {
10 public Father() {
11 new Other();
12 }
13 }
14
15 // 相关类
16 class Other {
17 public Other() {
18 new Son();
19 }
20 }
21
22 // 子类
23 class Son extends Father {
24 public void doSomething() {
25 System.out.println("Hi, show me Something!");
26 }
27 }
这段代码并不复杂，只是在构造函数中初始化了其它类，想想看这段代码的运行结果是什么？会打印出"Hi ，show me Something!"吗？
答案是这段代码不能运行，报StatckOverflowError异常，栈(Stack)内存溢出，这是因为声明变量son时，调用了Son的无参构造函数，JVM又默认调用了父类的构造函数，接着Father又初始化了Other类，而Other类又调用了Son类，于是一个死循环就诞生了，知道内存被消耗完停止。
大家可能觉得这样的场景不会出现在开发中，我们来思考这样的场景，Father是由框架提供的，Son类是我们自己编写的扩展代码，而Other类则是框架要求的拦截类(Interceptor类或者Handle类或者Hook方法)，再来看看问题，这种场景不可能出现吗?
可能大家会觉得这样的场景不会出现，这种问题只要系统一运行就会发现，不可能对项目产生影响。
那是因为我们这里展示的代码比较简单，很容易一眼洞穿，一个项目中的构造函数可不止一两个，类之间的关系也不会这么简单，要想瞥一眼就能明白是否有缺陷这对所有人员来说都是不可能完成的任务，解决此类问题最好的办法就是：不要在构造函数中声明初始化其他类，养成良好习惯。