java开发150个建议

时间 2019-11-12

标签 java 开发建议栏目 Java 繁體版

原文原文链接

阅读目录javascript

建议1：不要在常量和变量中出现易混淆的字母

包名全小写，类名首字母全大写，常量所有大写并用下划线分隔，变量采用驼峰命名法(Camel Case)命名等，这些都是最基本的Java编码规范，是每一个javaer都应熟知的规则，可是在变量的声明中要注意不要引入容易混淆的字母。尝试阅读以下代码，思考打印结果的i是多少：html

 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"则增长注释。java

注意：字母"l"做为长整型标志时务必大写。git

建议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是常量吗?它的值会变吗？绝对会变！这种常量的定义方式是绝对不可取的，常量就是常量，在编译期就必须肯定其值，不该该在运行期更改，不然程序的可读性会很是差，甚至连做者本身都不能肯定在运行期发生了何种神奇的事情。web

甭想着使用常量会变的这个功能来实现序列号算法、随机种子生成，除非这真的是项目中的惟一方案，不然就放弃吧，常量仍是当常量使用。面试

注意：务必让常量的值在运行期保持不变。算法

建议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>中的options
30         List<String> optionsList = new ArrayList<String>();
31         // 编译文件的存放地方，注意：此处是为Eclipse工具特设的
32         optionsList.addAll(Arrays.asList("-d", "./bin"));
33         // 要编译的单元
34         List<JavaFileObject> 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<? extends Object> 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<String>().isDateInstance("");
21 
22     }
23 }
24 
25 class GenericClass<T> {
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<String>().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.00一、0.00二、0.00三、0.004由于是舍弃的，对于银行家来讲就不须要付款给储户了，那每舍一个数字就会赚取相应的金额：0.000、0.00一、0.00二、0.00三、0.004.

　　五入：进位的数值是：0.00五、0.00六、0.00七、0.00八、0.009，由于是进位，对银行家来讲，每进一位就会多付款给储户，也就是亏损了，那亏损部分就是其对应的10进制补数：0.00五、.000四、0.00三、0.00二、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 <i>rounding behavior</i> 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 <i>discarded fraction</i> 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  * <p>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  *<p>
 26  *<table border>
 27  * <caption><b>Summary of Rounding Operations Under Different Rounding Modes</b></caption>
 28  * <tr><th></th><th colspan=8>Result of rounding input to one digit with the given
 29  *                           rounding mode</th>
 30  * <tr valign=top>
 31  * <th>Input Number</th>         <th>{@code UP}</th>
 32  *                                           <th>{@code DOWN}</th>
 33  *                                                        <th>{@code CEILING}</th>
 34  *                                                                       <th>{@code FLOOR}</th>
 35  *                                                                                    <th>{@code HALF_UP}</th>
 36  *                                                                                                   <th>{@code HALF_DOWN}</th>
 37  *                                                                                                                    <th>{@code HALF_EVEN}</th>
 38  *                                                                                                                                     <th>{@code UNNECESSARY}</th>
 39  *
 40  * <tr align=right><td>5.5</td>  <td>6</td>  <td>5</td>    <td>6</td>    <td>5</td>  <td>6</td>      <td>5</td>       <td>6</td>       <td>throw {@code ArithmeticException}</td>
 41  * <tr align=right><td>2.5</td>  <td>3</td>  <td>2</td>    <td>3</td>    <td>2</td>  <td>3</td>      <td>2</td>       <td>2</td>       <td>throw {@code ArithmeticException}</td>
 42  * <tr align=right><td>1.6</td>  <td>2</td>  <td>1</td>    <td>2</td>    <td>1</td>  <td>2</td>      <td>2</td>       <td>2</td>       <td>throw {@code ArithmeticException}</td>
 43  * <tr align=right><td>1.1</td>  <td>2</td>  <td>1</td>    <td>2</td>    <td>1</td>  <td>1</td>      <td>1</td>       <td>1</td>       <td>throw {@code ArithmeticException}</td>
 44  * <tr align=right><td>1.0</td>  <td>1</td>  <td>1</td>    <td>1</td>    <td>1</td>  <td>1</td>      <td>1</td>       <td>1</td>       <td>1</td>
 45  * <tr align=right><td>-1.0</td> <td>-1</td> <td>-1</td>   <td>-1</td>   <td>-1</td> <td>-1</td>     <td>-1</td>      <td>-1</td>      <td>-1</td>
 46  * <tr align=right><td>-1.1</td> <td>-2</td> <td>-1</td>   <td>-1</td>   <td>-2</td> <td>-1</td>     <td>-1</td>      <td>-1</td>      <td>throw {@code ArithmeticException}</td>
 47  * <tr align=right><td>-1.6</td> <td>-2</td> <td>-1</td>   <td>-1</td>   <td>-2</td> <td>-2</td>     <td>-2</td>      <td>-2</td>      <td>throw {@code ArithmeticException}</td>
 48  * <tr align=right><td>-2.5</td> <td>-3</td> <td>-2</td>   <td>-2</td>   <td>-3</td> <td>-3</td>     <td>-2</td>      <td>-2</td>      <td>throw {@code ArithmeticException}</td>
 49  * <tr align=right><td>-5.5</td> <td>-6</td> <td>-5</td>   <td>-5</td>   <td>-6</td> <td>-6</td>     <td>-5</td>      <td>-6</td>      <td>throw {@code ArithmeticException}</td>
 50  *</table>
 51  *
 52  *
 53  * <p>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          *<p>Example:
 74          *<table border>
 75          *<tr valign=top><th>Input Number</th>
 76          *    <th>Input rounded to one digit<br> with {@code UP} rounding
 77          *<tr align=right><td>5.5</td>  <td>6</td>
 78          *<tr align=right><td>2.5</td>  <td>3</td>
 79          *<tr align=right><td>1.6</td>  <td>2</td>
 80          *<tr align=right><td>1.1</td>  <td>2</td>
 81          *<tr align=right><td>1.0</td>  <td>1</td>
 82          *<tr align=right><td>-1.0</td> <td>-1</td>
 83          *<tr align=right><td>-1.1</td> <td>-2</td>
 84          *<tr align=right><td>-1.6</td> <td>-2</td>
 85          *<tr align=right><td>-2.5</td> <td>-3</td>
 86          *<tr align=right><td>-5.5</td> <td>-6</td>
 87          *</table>
 88          */
 89     UP(BigDecimal.ROUND_UP),
 90 
 91         /**
 92          * Rounding mode to round towards zero.  Never increments the digit
 93          * prior to a discarded fraction (i.e., truncates).  Note that this
 94          * rounding mode never increases the magnitude of the calculated value.
 95          *
 96          *<p>Example:
 97          *<table border>
 98          *<tr valign=top><th>Input Number</th>
 99          *    <th>Input rounded to one digit<br> with {@code DOWN} rounding
100          *<tr align=right><td>5.5</td>  <td>5</td>
101          *<tr align=right><td>2.5</td>  <td>2</td>
102          *<tr align=right><td>1.6</td>  <td>1</td>
103          *<tr align=right><td>1.1</td>  <td>1</td>
104          *<tr align=right><td>1.0</td>  <td>1</td>
105          *<tr align=right><td>-1.0</td> <td>-1</td>
106          *<tr align=right><td>-1.1</td> <td>-1</td>
107          *<tr align=right><td>-1.6</td> <td>-1</td>
108          *<tr align=right><td>-2.5</td> <td>-2</td>
109          *<tr align=right><td>-5.5</td> <td>-5</td>
110          *</table>
111          */
112     DOWN(BigDecimal.ROUND_DOWN),
113 
114         /**
115          * Rounding mode to round towards positive infinity.  If the
116          * result is positive, behaves as for {@code RoundingMode.UP};
117          * if negative, behaves as for {@code RoundingMode.DOWN}.  Note
118          * that this rounding mode never decreases the calculated value.
119          *
120          *<p>Example:
121          *<table border>
122          *<tr valign=top><th>Input Number</th>
123          *    <th>Input rounded to one digit<br> with {@code CEILING} rounding
124          *<tr align=right><td>5.5</td>  <td>6</td>
125          *<tr align=right><td>2.5</td>  <td>3</td>
126          *<tr align=right><td>1.6</td>  <td>2</td>
127          *<tr align=right><td>1.1</td>  <td>2</td>
128          *<tr align=right><td>1.0</td>  <td>1</td>
129          *<tr align=right><td>-1.0</td> <td>-1</td>
130          *<tr align=right><td>-1.1</td> <td>-1</td>
131          *<tr align=right><td>-1.6</td> <td>-1</td>
132          *<tr align=right><td>-2.5</td> <td>-2</td>
133          *<tr align=right><td>-5.5</td> <td>-5</td>
134          *</table>
135          */
136     CEILING(BigDecimal.ROUND_CEILING),
137 
138         /**
139          * Rounding mode to round towards negative infinity.  If the
140          * result is positive, behave as for {@code RoundingMode.DOWN};
141          * if negative, behave as for {@code RoundingMode.UP}.  Note that
142          * this rounding mode never increases the calculated value.
143          *
144          *<p>Example:
145          *<table border>
146          *<tr valign=top><th>Input Number</th>
147          *    <th>Input rounded to one digit<br> with {@code FLOOR} rounding
148          *<tr align=right><td>5.5</td>  <td>5</td>
149          *<tr align=right><td>2.5</td>  <td>2</td>
150          *<tr align=right><td>1.6</td>  <td>1</td>
151          *<tr align=right><td>1.1</td>  <td>1</td>
152          *<tr align=right><td>1.0</td>  <td>1</td>
153          *<tr align=right><td>-1.0</td> <td>-1</td>
154          *<tr align=right><td>-1.1</td> <td>-2</td>
155          *<tr align=right><td>-1.6</td> <td>-2</td>
156          *<tr align=right><td>-2.5</td> <td>-3</td>
157          *<tr align=right><td>-5.5</td> <td>-6</td>
158          *</table>
159          */
160     FLOOR(BigDecimal.ROUND_FLOOR),
161 
162         /**
163          * Rounding mode to round towards {@literal "nearest neighbor"}
164          * unless both neighbors are equidistant, in which case round up.
165          * Behaves as for {@code RoundingMode.UP} if the discarded
166          * fraction is &ge; 0.5; otherwise, behaves as for
167          * {@code RoundingMode.DOWN}.  Note that this is the rounding
168          * mode commonly taught at school.
169          *
170          *<p>Example:
171          *<table border>
172          *<tr valign=top><th>Input Number</th>
173          *    <th>Input rounded to one digit<br> with {@code HALF_UP} rounding
174          *<tr align=right><td>5.5</td>  <td>6</td>
175          *<tr align=right><td>2.5</td>  <td>3</td>
176          *<tr align=right><td>1.6</td>  <td>2</td>
177          *<tr align=right><td>1.1</td>  <td>1</td>
178          *<tr align=right><td>1.0</td>  <td>1</td>
179          *<tr align=right><td>-1.0</td> <td>-1</td>
180          *<tr align=right><td>-1.1</td> <td>-1</td>
181          *<tr align=right><td>-1.6</td> <td>-2</td>
182          *<tr align=right><td>-2.5</td> <td>-3</td>
183          *<tr align=right><td>-5.5</td> <td>-6</td>
184          *</table>
185          */
186     HALF_UP(BigDecimal.ROUND_HALF_UP),
187 
188         /**
189          * Rounding mode to round towards {@literal "nearest neighbor"}
190          * unless both neighbors are equidistant, in which case round
191          * down.  Behaves as for {@code RoundingMode.UP} if the discarded
192          * fraction is &gt; 0.5; otherwise, behaves as for
193          * {@code RoundingMode.DOWN}.
194          *
195          *<p>Example:
196          *<table border>
197          *<tr valign=top><th>Input Number</th>
198          *    <th>Input rounded to one digit<br> with {@code HALF_DOWN} rounding
199          *<tr align=right><td>5.5</td>  <td>5</td>
200          *<tr align=right><td>2.5</td>  <td>2</td>
201          *<tr align=right><td>1.6</td>  <td>2</td>
202          *<tr align=right><td>1.1</td>  <td>1</td>
203          *<tr align=right><td>1.0</td>  <td>1</td>
204          *<tr align=right><td>-1.0</td> <td>-1</td>
205          *<tr align=right><td>-1.1</td> <td>-1</td>
206          *<tr align=right><td>-1.6</td> <td>-2</td>
207          *<tr align=right><td>-2.5</td> <td>-2</td>
208          *<tr align=right><td>-5.5</td> <td>-5</td>
209          *</table>
210          */
211     HALF_DOWN(BigDecimal.ROUND_HALF_DOWN),
212 
213         /**
214          * Rounding mode to round towards the {@literal "nearest neighbor"}
215          * unless both neighbors are equidistant, in which case, round
216          * towards the even neighbor.  Behaves as for
217          * {@code RoundingMode.HALF_UP} if the digit to the left of the
218          * discarded fraction is odd; behaves as for
219          * {@code RoundingMode.HALF_DOWN} if it's even.  Note that this
220          * is the rounding mode that statistically minimizes cumulative
221          * error when applied repeatedly over a sequence of calculations.
222          * It is sometimes known as {@literal "Banker's rounding,"} and is
223          * chiefly used in the USA.  This rounding mode is analogous to
224          * the rounding policy used for {@code float} and {@code double}
225          * arithmetic in Java.
226          *
227          *<p>Example:
228          *<table border>
229          *<tr valign=top><th>Input Number</th>
230          *    <th>Input rounded to one digit<br> with {@code HALF_EVEN} rounding
231          *<tr align=right><td>5.5</td>  <td>6</td>
232          *<tr align=right><td>2.5</td>  <td>2</td>
233          *<tr align=right><td>1.6</td>  <td>2</td>
234          *<tr align=right><td>1.1</td>  <td>1</td>
235          *<tr align=right><td>1.0</td>  <td>1</td>
236          *<tr align=right><td>-1.0</td> <td>-1</td>
237          *<tr align=right><td>-1.1</td> <td>-1</td>
238          *<tr align=right><td>-1.6</td> <td>-2</td>
239          *<tr align=right><td>-2.5</td> <td>-2</td>
240          *<tr align=right><td>-5.5</td> <td>-6</td>
241          *</table>
242          */
243     HALF_EVEN(BigDecimal.ROUND_HALF_EVEN),
244 
245         /**
246          * Rounding mode to assert that the requested operation has an exact
247          * result, hence no rounding is necessary.  If this rounding mode is
248          * specified on an operation that yields an inexact result, an
249          * {@code ArithmeticException} is thrown.
250          *<p>Example:
251          *<table border>
252          *<tr valign=top><th>Input Number</th>
253          *    <th>Input rounded to one digit<br> with {@code UNNECESSARY} rounding
254          *<tr align=right><td>5.5</td>  <td>throw {@code ArithmeticException}</td>
255          *<tr align=right><td>2.5</td>  <td>throw {@code ArithmeticException}</td>
256          *<tr align=right><td>1.6</td>  <td>throw {@code ArithmeticException}</td>
257          *<tr align=right><td>1.1</td>  <td>throw {@code ArithmeticException}</td>
258          *<tr align=right><td>1.0</td>  <td>1</td>
259          *<tr align=right><td>-1.0</td> <td>-1</td>
260          *<tr align=right><td>-1.1</td> <td>throw {@code ArithmeticException}</td>
261          *<tr align=right><td>-1.6</td> <td>throw {@code ArithmeticException}</td>
262          *<tr align=right><td>-2.5</td> <td>throw {@code ArithmeticException}</td>
263          *<tr align=right><td>-5.5</td> <td>throw {@code ArithmeticException}</td>
264          *</table>
265          */
266     UNNECESSARY(BigDecimal.ROUND_UNNECESSARY);
267 
268     // Corresponding BigDecimal rounding constant
269     final int oldMode;
270 
271     /**
272      * Constructor
273      *
274      * @param oldMode The {@code BigDecimal} constant corresponding to
275      *        this mode
276      */
277     private RoundingMode(int oldMode) {
278         this.oldMode = oldMode;
279     }
280 
281     /**
282      * Returns the {@code RoundingMode} object corresponding to a
283      * legacy integer rounding mode constant in {@link BigDecimal}.
284      *
285      * @param  rm legacy integer rounding mode to convert
286      * @return {@code RoundingMode} corresponding to the given integer.
287      * @throws IllegalArgumentException integer is out of range
288      */
289     public static RoundingMode valueOf(int rm) {
290         switch(rm) {
291 
292         case BigDecimal.ROUND_UP:
293             return UP;
294 
295         case BigDecimal.ROUND_DOWN:
296             return DOWN;
297 
298         case BigDecimal.ROUND_CEILING:
299             return CEILING;
300 
301         case BigDecimal.ROUND_FLOOR:
302             return FLOOR;
303 
304         case BigDecimal.ROUND_HALF_UP:
305             return HALF_UP;
306 
307         case BigDecimal.ROUND_HALF_DOWN:
308             return HALF_DOWN;
309 
310         case BigDecimal.ROUND_HALF_EVEN:
311             return HALF_EVEN;
312 
313         case BigDecimal.ROUND_UNNECESSARY:
314             return UNNECESSARY;
315 
316         default:
317             throw new IllegalArgumentException("argument out of range");
318         }
319     }
320 }

建议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<Integer> 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<Integer> list = new ArrayList<Integer>();
16         list.add(1);
17         list.add(2);
18         list.add(null);
19         System.out.println(testMethod(list));
20     }
21 }

　　testMethod接收一个元素是整型的List参数，计算全部元素之和，这在统计和项目中很常见，而后编写一个测试testMethod，在main方法中把一、2和空值都放到List中，而后调用方法计算，如今思考一下会不会报错。应该不会吧，基本类型和包装类型都是能够经过自动装箱（Autoboxing）和自动拆箱(AutoUnboxing)自由转换的，null应该能够转换为0吧，真的是这样吗？运行以后的结果是：　　Exception in thread "main" java.lang.NullPointerException　　运行失败，报空指针异常，咱们稍稍思考一下很快就知道缘由了：在程序for循环中，隐含了一个拆箱过程，在此过程当中包装类型转换为了基本类型。咱们知道拆箱过程是经过调用包装对象的intValue方法来实现的，因为包装类型为null，访问其intValue方法报空指针异常就在所不免了。问题清楚了，修改也很简单，加入null值检查便可，代码以下：

public static int testMethod(List<Integer> list) {
        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<j：在Java中，">" 和 "<" 用来判断两个数字类型的大小关系，注意只能是数字类型的判断，对于Integer包装类型，是根据其intValue()方法的返回值(也就是其相应的基本类型)进行比较的(其它包装类型是根据相应的value值比较的，如doubleValue,floatValue等)，那很显然，二者不愿能有大小关系的。

问题清楚了，修改老是比较容易的，直接使用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对象，判断其是否相等，注意这里使用了"=="，这说明判断的不是同一个对象。咱们输入三个数字12七、12八、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=<size> 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这个数字，得到的对象都是同一个，那地址天然是相等的。而12八、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方法)，再来看看问题，这种场景不可能出现吗?　　

　　可能你们会以为这样的场景不会出现，这种问题只要系统一运行就会发现，不可能对项目产生影响。

　　那是由于咱们这里展现的代码比较简单，很容易一眼洞穿，一个项目中的构造函数可不止一两个，类之间的关系也不会这么简单，要想瞥一眼就能明白是否有缺陷这对全部人员来讲都是不可能完成的任务，解决此类问题最好的办法就是：不要在构造函数中声明初始化其余类，养成良好习惯。