编写高质量代码：改善Java程序的151个建议（第二章：基本类型）
编写高质量代码：改善Java程序的151个建议（第二章：基本类型）
目录
- 建议21：用偶判断，不用奇判断
- 建议22：用整数类型处理货币
- 建议23：不要让类型默默转换
- 建议24：边界还是边界
- 建议25：不要让四舍五入亏了一方
- 建议26：提防包装类型的null值
- 建议27：谨慎包装类型的大小比较
- 建议28：优先使用整型池
- 建议29：优先选择基本类型
- 建议30：不要随便设置随机种子
建议21：用偶判断，不用奇判断
判断一个数是奇数还是偶数是小学里的基本知识，能够被2整除的整数是偶数，不能被2整除的数是奇数，这规则简单明了，还有什么可考虑的？好，我们来看一个例子，代码如下：
import java.util.Scanner;
public class Client21 {
public static void main(String[] args) {
// 接收键盘输入参数
Scanner input = new Scanner(System.in);
System.out.println("输入多个数字判断奇偶：");
while (input.hasNextInt()) {
int i = input.nextInt();
String str = i + "-->" + (i % 2 == 1 ? "奇数" : "偶数");
System.out.println(str);
}
}
}
输入多个数字，然后判断每个数字的奇偶性，不能被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万公里，根据光线的旅行时间，计算月球和地球，太阳和地球之间的距离。代码如下：
public class Client23 {
// 光速是30万公里/秒，常量
public static final int LIGHT_SPEED = 30 * 10000 * 1000;
public static void main(String[] args) {
System.out.println("题目1：月球照射到地球需要一秒，计算月亮和地球的距离。");
long dis1 = LIGHT_SPEED * 1;
System.out.println("月球与地球的距离是：" + dis1 + " 米 ");
System.out.println("-------------------------------");
System.out.println("题目2：太阳光照射到地球需要8分钟，计算太阳到地球的距离.");
// 可能要超出整数范围，使用long型
long dis2 = LIGHT_SPEED * 60 * 8;
System.out.println("太阳与地球之间的距离是：" + dis2 + " 米");
}
}
估计有人鄙视了，这种小学生的乘法有神么可做的，不错，就是一个乘法运算，我们运行之后的结果如下：
题目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天预订才能抢到手，同时还规定了一个会员可拥有的最多产品数量，目的是为了防止囤积压货肆意加价。会员的预订过程是这样的：先登录官方网站，选择产品型号，然后设置需要预订的数量，提交，符合规则即提示下单成功，不符合规则提示下单失败，后台的处理模拟如下：
import java.util.Scanner;
public class Client24 {
// 一个会员拥有产品的最多数量
public final static int LIMIT = 2000;
public static void main(String[] args) {
// 会员当前用有的产品数量
int cur = 1000;
Scanner input = new Scanner(System.in);
System.out.println("请输入需要预定的数量：");
while (input.hasNextInt()) {
int order = input.nextInt();
if (order > 0 && order + cur <= LIMIT) {
System.out.println("你已经成功预定：" + order + " 个产品");
} else {
System.out.println("超过限额，预定失败！");
}
}
}
}
这是一个简单的订单处理程序，其中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（每笔利息损失的金额）
5000100000.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.56
要在Java5以上的版本中使用银行家的舍入法则非常简单，直接使用RoundingMode类提供的Round模式即可，示例代码如下：
import java.math.BigDecimal;
import java.math.RoundingMode;
public class Client25 {
public static void main(String[] args) {
// 存款
BigDecimal d = new BigDecimal(888888);
// 月利率，乘3计算季利率
BigDecimal r = new BigDecimal(0.001875*3);
//计算利息
BigDecimal i =d.multiply(r).setScale(2,RoundingMode.HALF_EVEN);
System.out.println("季利息是："+i);
}
}
在上面的例子中，我们使用了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方法，但在大量与货币数字交互的项目中，一定要选择好近似的计算模式，尽量减少因算法不同而造成的损失。
注意：根据不同的场景，慎重选择不同的舍入模式，以提高项目的精准度，减少算法损失。
建议26：提防包装类型的null值
我们知道Java引入包装类型(Wrapper Types)是为了解决基本类型的实例化问题，以便让一个基本类型也能参与到面向对象的编程世界中。而在Java5中泛型更是对基本类型说了"不"，如果把一个整型放入List中，就必须使用Integer包装类型。我们看一段代码：
import java.util.ArrayList;
import java.util.List;
public class Client26 {
public static int testMethod(List<Integer> list) {
int count = 0;
for (int i : list) {
count += i;
}
return count;
}
public static void main(String[] args) {
List<Integer> list = new ArrayList<Integer>();
list.add(1);
list.add(2);
list.add(null);
System.out.println(testMethod(list));
}
}
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(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接口，也说明了此问题，那我们来比较一下两个包装类型的大小，代码如下：
public class Client27 {
public static void main(String[] args) {
Integer i = new Integer(100);
Integer j = new Integer(100);
compare(i, j);
}
public static void compare(Integer i, Integer j) {
System.out.println(i == j);
System.out.println(i > j);
System.out.println(i < j);
}
}
代码很简单，产生了两个Integer对象，然后比较两个的大小关系，既然包装类型和基本类型是可以自由转换的，那上面的代码是不是就可以打印出两个相等的值呢？让事实说话，运行结果如下：
false false false
竟然是3个false，也就是说两个值之间不相等，也没大小关系，这个也太奇怪了吧。不奇怪，我们来一 一解释：
- ij：在java中""是用来判断两个操作数是否有相等关系的，如果是基本类型则判断值是否相等，如果是对象则判断是否是一个对象的两个引用，也就是地址是否相等，这里很明显是两个对象，两个地址不可能相等。
- i>j 和 i<j：在Java中，">" 和 "<" 用来判断两个数字类型的大小关系，注意只能是数字类型的判断，对于Integer包装类型，是根据其intValue()方法的返回值(也就是其相应的基本类型)进行比较的(其它包装类型是根据相应的value值比较的，如doubleValue,floatValue等)，那很显然，两者不肯能有大小关系的。
问题清楚了，修改总是比较容易的，直接使用Integer的实例compareTo方法即可，但是这类问题的产生更应该说是习惯问题，只要是两个对象之间的比较就应该采用相应的方法，而不是通过Java的默认机制来处理，除非你确定对此非常了解。
建议28：优先使用整型池
上一个建议我们解释了包装对象的比较问题，本建议将继续深入讨论相关问题，首先看看如下代码：
import java.util.Scanner;
public class Client28 {
public static void main(String[] args) {
Scanner input = new Scanner(System.in);
while (input.hasNextInt()) {
int tempInt = input.nextInt();
System.out.println("\n=====" + tempInt + " 的相等判断=====");
// 两个通过new产生的对象
Integer i = new Integer(tempInt);
Integer j = new Integer(tempInt);
System.out.println(" new 产生的对象：" + (i == j));
// 基本类型转换为包装类型后比较
i = tempInt;
j = tempInt;
System.out.println(" 基本类型转换的对象：" + (i == j));
// 通过静态方法生成一个实例
i = Integer.valueOf(tempInt);
j = Integer.valueOf(tempInt);
System.out.println(" valueOf产生的对象：" + (i == j));
}
}
}
输入多个数字，然后按照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的源码
/**
* Returns an {@code Integer} instance representing the specified
* {@code int} value. If a new {@code Integer} instance is not
* required, this method should generally be used in preference to
* the constructor {@link #Integer(int)}, as this method is likely
* to yield significantly better space and time performance by
* caching frequently requested values.
*
* This method will always cache values in the range -128 to 127,
* inclusive, and may cache other values outside of this range.
*
* @param i an {@code int} value.
* @return an {@code Integer} instance representing {@code i}.
* @since 1.5
*/
public static Integer valueOf(int i) {
assert IntegerCache.high >= 127;
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
这段代码的意思已经很明了了，如果是-128到127之间的int类型转换为Integer对象，则直接从cache数组中获得，那cache数组里是什么东西，JDK7的源代码如下：
/**
* Cache to support the object identity semantics of autoboxing for values between
* -128 and 127 (inclusive) as required by JLS.
*
* The cache is initialized on first usage. The size of the cache
* may be controlled by the -XX:AutoBoxCacheMax=<size> option.
* During VM initialization, java.lang.Integer.IntegerCache.high property
* may be set and saved in the private system properties in the
* sun.misc.VM class.
*/
private static class IntegerCache {
static final int low = -128;
static final int high;
static final Integer cache[];
static {
// high value may be configured by property
int h = 127;
String integerCacheHighPropValue =
sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
if (integerCacheHighPropValue != null) {
int i = parseInt(integerCacheHighPropValue);
i = Math.max(i, 127);
// Maximum array size is Integer.MAX_VALUE
h = Math.min(i, Integer.MAX_VALUE - (-low));
}
high = h;
cache = new Integer[(high - low) + 1];
int j = low;
for(int k = 0; k < cache.length; k++)
cache[k] = new Integer(j++);
}
private IntegerCache() {}
}
cache是IntegerCache内部类的一个静态数组，容纳的是-128到127之间的Integer对象。通过valueOf产生包装对象时，如果int参数在-128到127之间，则直接从整型池中获得对象，不在该范围内的int类型则通过new生成包装对象。
明白了这一点，要理解上面的输出结果就迎刃而解了，127的包装对象是直接从整型池中获得的，不管你输入多少次127这个数字，获得的对象都是同一个，那地址自然是相等的。而128、555超出了整型池范围，是通过new产生一个新的对象，地址不同，当然也就不相等了。
以上的理解也是整型池的原理，整型池的存在不仅仅提高了系统性能，同时也节约了内存空间，这也是我们使用整型池的原因，也就是在声明包装对象的时候使用valueOf生成，而不是通过构造函数来生成的原因。顺便提醒大家，在判断对象是否相等的时候，最好使用equals方法，避免使用"=="产生非预期效果。
注意：通过包装类型的valueOf生成的包装实例可以显著提高空间和时间性能。
建议29：优先选择基本类型
包装类型是一个类，它提供了诸如构造方法，类型转换，比较等非常实用的功能，而且在Java5之后又实现了与基本类型的转换，这使包装类型如虎添翼，更是应用广泛了，在开发中包装类型已经随处可见，但无论是从安全性、性能方面来说，还是从稳定性方面来说，基本类型都是首选方案。我们看一段代码：
public class Client29 {
public static void main(String[] args) {
Client29 c = new Client29();
int i = 140;
// 分别传递int类型和Integer类型
c.testMethod(i);
c.testMethod(new Integer(i));
}
public void testMethod(long a) {
System.out.println(" 基本类型的方法被调用");
}
public void testMethod(Long a) {
System.out.println(" 包装类型的方法被调用");
}
}
在上面的程序中首先声明了一个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对象，但不能直接转变成包装类型，注意这里指的都是自动转换，不是通过构造函数生成，为了解释这个原则，我们再来看一个例子：
public class Client29 {
public static void main(String[] args) {
Client29 c = new Client29();
int i = 140;
c.testMethod(i);
}
public void testMethod(Long a) {
System.out.println(" 包装类型的方法被调用");
}
}
这段程序的编译是不通过的，因为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类来获得随机数的，我们来看一段代码：
import java.util.Random;
public class Client30 {
public static void main(String[] args) {
Random r = new Random();
for(int i=1; i<=4; i++){
System.out.println("第"+i+"次:"+r.nextInt());
}
}
}
代码很简单，我们一般都是这样获得随机数的，运行此程序可知，三次打印，的随机数都不相同，即使多次运行结果也不同，这也正是我们想要随机数的原因，我们再来看看下面的程序：
public class Client30 {
public static void main(String[] args) {
Random r = new Random(1000);
for(int i=1; i<=4; i++){
System.out.println("第"+i+"次:"+r.nextInt());
}
}
}
上面使用了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()方法的，两者殊途同归，没有差别。
java岛上程序猿，十指弯弯不弄弦。
终日立于电脑前，不问今夕是何年。
但行好事，莫问前程。
泰山崩于前，我依然沐浴更衣焚香沏茶。
诚心正意，手起键落。
人生如戏， 全靠演技。
Hello World !
作者：人生如戏， 全靠演技
出处：http://www.cnblogs.com/yy1024/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
