第2章 基本类型
不积跬步，无以至千里；
不积小流，无以成江海。
——荀子《劝学篇》
Java中的基本数据类型（Primitive Data Types）有8个：byte、char、short、int、long、float、double、boolean，它们是Java最基本的单元，我们的每一段程序中都有它们的身影，但我们对如此熟悉的“伙伴”又了解多少呢？
积少成多，积土成山，本章我们就来一探这最基本的8个数据类型。
建议21：用偶判断，不用奇判断
判断一个数是奇数还是偶数是小学里学的基本知识，能够被2整除的整数是偶数，不能被2整除的是奇数，这规则简单又明了，还有什么好考虑的？好，我们来看一个例子，代码如下：
public class Client {
public static void main(String[] args) {
//接收键盘输入参数
Scanner input = new Scanner(System.in);
System.out.print("请输入多个数字判断奇偶：");
while(input.hasNextInt()){
int i = input.nextInt();
String str =i+ "->" + (i%2 ==1?"奇数":"偶数");
System.out.println(str);
}
}
}
输入多个数字，然后判断每个数字的奇偶性，不能被2整除就是奇数，其他的都是偶数，完全是根据奇偶数的定义编写的程序，我们来看看打印的结果：
请输入多个数字判断奇偶：120 -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.60元的零食，售货员应该找你0.4元也就是4毛钱才对，我们来看下面的程序：
public class Client {
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 Client {
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 Client {
//光速是30万公里/秒，常量
public static final int LIGHT_SPEED = 30 ＊ 10000 ＊ 1000;
public static void main(String[] args) {
System.out.println("题目1：月亮光照射到地球需要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：月亮光照射到地球需要1秒，计算月亮和地球的距离。 月亮与地球的距离是：300000000米 -------------------------------------------- 题目2：太阳光照射到地球上需要8分钟，计算太阳到地球的距离。 太阳与地球的距离是：-2028888064米
太阳和地球的距离竟然是负的，诡异。dis2不是已经考虑到int类型可能越界的问题，并使用了long型吗，为什么还会出现负值呢？
那是因为Java是先运算然后再进行类型转换的，具体地说就是因为disc2的三个运算参数都是int类型，三者相乘的结果虽然也是int类型，但是已经超过了int的最大值，所以其值就是负值了（为什么是负值？因为过界了就会从头开始），再转换成long型，结果还是负值。
问题知道了，解决起来也很简单，只要加个小小的“L"即可，代码如下：
long dis2 = LIGHT_SPEED ＊ 60L ＊ 8;
60L是一个长整型，乘出来的结果也是一个长整型（此乃Java的基本转换规则，向数据范围大的方向转换，也就是加宽类型），在还没有超过int类型的范围时就已经转换为long型了，彻底解决了越界问题。在实际开发中，更通用的做法是主动声明式类型转化（注意不是强制类型转换），代码如下：
long dis2 = 1L ＊ LIGHT_SPEED ＊ 60 ＊ 8;
既然期望的结果是long型，那就让第一个参与运算的参数也是long型（1L）吧，也就是明说“嗨，我已经是长整型了，你们都跟着我一起转为长整型吧”。
注意 基本类型转换时，使用主动声明方式减少不必要的Bug。
建议24：边界，边界，还是边界
某商家生产的电子产品非常畅销，需要提前30天预订才能抢到手，同时它还规定了一个会员可拥有的最多产品数量，目的是防止囤积压货肆意加价。会员的预定过程是这样的：先登录官方网站，选择产品型号，然后设置需要预订的数量，提交，符合规则即提示下单成功，不符合规则提示下单失败。后台的处理逻辑模拟如下：
public class Client {
//一个会员拥有产品的最多数量
public final static int LIMIT = 2000;
public static void main(String[] args) {
//会员当前拥有的产品数量
int cur = 1000;
Scanner input = new Scanner(System.in);
System.out.print("请输入需要预定的数量：");
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：不要让四舍五入亏了一方
本建议还是来重温一个小学数学问题：四舍五入。四舍五入是一种近似精确的计算方法，在Java 5之前，我们一般是通过使用Math.round来获得指定精度的整数或小数的，这种方法使用非常广泛，代码如下：
public class Client {
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、0.004、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千万是个很小的数字），每年仅仅因为四舍五入的误差而损失的金额是：
public class Client {
public static void main(String[] args) {
//银行账户数量，5千万
int accountNum =5000＊10000;
//按照人行的规定，每个季度末月的20日为银行结息日
double cost = 0.0005 ＊ accountNum ＊ 4 ;
System.out.println("银行每年损失的金额：" + cost);
}
}
输出的结果是：“银行每年损失的金额：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
要在Java 5以上的版本中使用银行家的舍入法则非常简单，直接使用RoundingMode类提供的Round模式即可，示例代码如下：
public class Client {
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方向靠拢，也就是说，向绝对值最小的方向输入，注意：所有的位都舍弃，不存在进位情况。
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）是为了解决基本类型的实例化问题，以便让一个基本类型也能参与到面向对象的编程世界中。而在Java 5中泛型更是对基本类型说了“不”，如想把一个整型放到List中，就必须使用Integer包装类型。我们来看一段代码：
//计算list中所有元素之和
public static int f(List<Integer> list){
int count = 0;
for(int i:list){
count += i;
}
return count;
}
接收一个元素是整型的List参数，计算所有元素之和，这在统计、报表项目中很常见，我们来看看这段代码有没有问题。遍历一个列表，然后相加，应该没有问题。那我们再来写一个方法调用，代码如下：
public static void main(String[] args) {
List<Integer> list = new ArrayList<Integer>();
list.add(1);
list.add(2);
list.add(null);
System.out.println(f(list));
}
把1、2和空值都放到List中，然后调用方法计算，现在来思考一下会不会出错。应该不会出错吧，基本类型和包装类型都是可以通过自动装箱（Autoboxing）和自动拆箱（AutoUnboxing）自由转换的，null应该可以转为0吧，真的是这样吗？我们运行一下看看结果：
Exception in thread "main" java.lang.NullPointerException
运行失败，报空指针异常，我们稍稍思考一下很快就知道原因了：在程序的for循环中，隐含了一个拆箱过程，在此过程中包装类型转换为了基本类型。我们知道拆箱过程是通过调用包装对象的intValue方法来实现的，由于包装对象是null值，访问其intValue方法报空指针异常也就在所难免了。问题清楚了，修改也很简单，加入null值检查即可，代码如下：
public static int f(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 Client {
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，也就是说两个值之间不等，也没大小关系，这也太奇怪了吧。不奇怪，我们来一一解释。
i==j
在Java中“==”是用来判断两个操作数是否有相等关系的，如果是基本类型则判断值是否相等，如果是对象则判断是否是一个对象的两个引用，也就是地址是否相等，这里很明显是两个对象，两个地址，不可能相等。
i>j和i<j
在Java中，“>”和“<”用来判断两个数字类型的大小关系，注意只能是数字型的判断，对于Integer包装类型，是根据其intValue()方法的返回值（也就是其相应的基本类型）进行比较的（其他包装类型是根据相应的value值来比较的，如doubleValue、floatValue等），那很显然，两者不可能有大小关系的。
问题清楚了，修改总是比较容易的，直接使用Integer实例的compareTo方法即可。但是这类问题的产生更应该说是习惯问题，只要是两个对象之间的比较就应该采用相应的方法，而不是通过Java的默认机制来处理，除非你确定对此非常了解。
建议28：优先使用整型池
上一建议我们解释了包装对象的比较问题，本建议将继续深入讨论相关问题，首先看如下代码：
public static void main(String[] args) {
Scanner input = new Scanner(System.in);
while(input.hasNextInt()){
int ii = input.nextInt();
System.out.println("\n===="+ii+" 的相等判断======");
//两个通过new产生的Integer对象
Integer i =new Integer(ii);
Integer j = new Integer(ii);
System.out.println("new产生的对象：" + (i==j));
//基本类型转为包装类型后比较
i=ii;
j=ii;
System.out.println("基本类型转换的对象：" + (i==j));
//通过静态方法生成一个实例
i=Integer.valueOf(ii);
j = Integer.valueOf(ii);
System.out.println("valueOf产生的对象：" + (i==j));
}
}
输入多个数字，然后按照3种不同的方式产生Integer对象，判断其是否相等，注意这里使用了“==”，这说明判断的不是同一个对象。我们输入三个数字127、128、555，结果如下：
====127 的相等判断====== new产生的对象：false 基本类型转换的对象：true valueOf产生的对象：true ====128 的相等判断====== new产生的对象：false 基本类型转换的对象：false valueOf产生的对象：false ====555 的相等判断====== new产生的对象：false 基本类型转换的对象：false valueOf产生的对象：false
很不可思议呀，数字127的比较结果竟然与其他两个数字不同，它的装箱动作所产生的对象竟然是同一个对象，valueOf产生的也是同一个对象，但是大于127的数字128和555在比较过程中所产生的却不是同一个对象，这是为什么？我们一个一个来解释。
（1）new产生的Integer对象
new声明的就是要生成一个新的对象，没二话，这是两个对象，地址肯定不等，比较结果为false。
（2）装箱生成的对象
对于这一点，首先要说明的是装箱动作是通过valueOf方法实现的，也就是说后两个算法是相同的，那结果肯定也是一样的，现在的问题是：valueOf是如何生成对象的呢？我们来阅读一下Integer.valueOf的实现代码：
public static Integer valueOf(int i) {
final int offset = 128;
if (i >= -128 && i <= 127) { // must cache
return IntegerCache.cache[i + offset];
}
return new Integer(i);
}
这段代码的意思已经很明了了，如果是-128到127之间的int类型转换为Integer对象，则直接从cache数组中获得，那cache数组里是什么东西，代码如下：
static final Integer cache[] = new Integer[-(-128) + 127 + 1];
static {
for(int i = 0; i < cache.length; i++)
cache[i] = new Integer(i - 128);
}
cache是IntegerCache内部类的一个静态数组，容纳的是-128到127之间的Integer对象。通过valueOf产生包装对象时，如果int参数在-128和127之间，则直接从整型池中获得对象，不在该范围的int类型则通过new生成包装对象。
明白了这一点，要理解上面的输出结果就迎刃而解了，127的包装对象是直接从整型池中获得的，不管你输入多少次127这个数字，获得的对象都是同一个，那地址当然都是相等的。而128、555超出了整型池范围，是通过new产生一个新的对象，地址不同，当然也就不相等了。
以上的解释也是整型池的原理，整型池的存在不仅仅提高了系统性能，同时也节约了内存空间，这也是我们使用整型池的原因，也就是在声明包装对象的时候使用valueOf生成，而不是通过构造函数来生成的原因。顺便提醒大家，在判断对象是否相等的时候，最好是用equals方法，避免用“==”产生非预期结果。
注意 通过包装类的valueOf生成包装实例可以显著提高空间和时间性能。
建议29：优先选择基本类型
包装类型是一个类，它提供了诸如构造方法、类型转换、比较等非常实用的功能，而且在Java 5之后又实现了与基本类型之间的自动转换，这使包装类型如虎添翼，更是应用广泛了，在开发中包装类型已经随处可见，但无论是从安全性、性能方面来说，还是从稳定性方面来说，基本类型都是首选方案。我们来看一段代码：
public class Client {
public static void main(String[] args) {
Client cilent = new Client();
int i=140;
//分别传递int类型和Integer类型
cilent.f(i);
cilent.f(Integer.valueOf(i));
}
public void f(long a) {
System.out.println("基本类型的方法被调用");
}
public void f(Long a) {
System.out.println("包装类型的方法被调用");
}
}
在上面的程序中首先声明了一个int变量i，然后加宽转变成long型，再调用f()方法，分别传递int和long的基本类型和包装类型，诸位想想该程序是否能够编译？如果能编译输出结果又是什么呢？
首先，这段程序绝对是能够编译的。不过，说不能编译的同学还是很动了一番脑筋的，只是还欠缺点火候，你可能会猜测以下这些地方不能编译：
f()方法重载有问题。定义的两个f()方法实现了重载，一个形参是基本类型，一个形参是包装类型，这类重载很正常。虽然基本类型和包装类型有自动装箱、自动拆箱的功能，但并不影响它们的重载，自动拆箱（装箱）只有在赋值时才会发生，和重载没有关系。
cilent.f(i)报错。i是int类型，传递到fun(long l)是没有任何问题的，编译器会自动把i的类型加宽，并将其转变为long型，这是基本类型的转换规则，也没有任何问题。
cilent.f(Integer.valueOf(i)) 报错。代码中没有f(Integer i)方法，不可能接收一个Integer类型的参数，而且Integer和Long两个包装类型是兄弟关系，不是继承关系，那就是说肯定编译失败了？不，编译是成功的，稍后再解释为什么这里编译成功。
既然编译通过了，我们来看一下输出：
基本类型的方法被调用 基本类型的方法被调用
cilent.f(i)的输出是正常的，我们已经解释过了。那第二个输出就让人很困惑了，为什么会调用f(long a)方法呢？这是因为自动装箱有一个重要的原则：基本类型可以先加宽，再转变成宽类型的包装类型，但不能直接转变成宽类型的包装类型。这句话比较拗口，简单地说就是，int可以加宽转变成long，然后再转变成Long对象，但不能直接转变成包装类型，注意这里指的都是自动转换，不是通过构造函数生成。为了解释这个原则，我们再来看一个例子：
public class Client {
public static void main(String[] args) {
int i=100;
f(i);
}
public static void f(Long l){
}
}
这段程序编译是通不过的，因为i是一个int类型，不能自动转变为Long型。但是修改成以下代码就可以编译通过了：
public static void main(String[] args) {
int i=100;
long l = (long)i;
f(l);
}
这就是int先加宽转变为long型，然后自动转换成Long型。规则说明白了，我们继续来看f(Integer.valueOf(i))是如何调用的，Integer.valueOf(i)返回的是一个Integer对象，这没错，但是Integer和int是可以互相转换的。没有f(Integer i)方法？没关系，编译器会尝试转换成int类型的实参调用，OK，这次成功了，与f(i)相同了，于是乎被加宽转变成long型—结果也很明显了。整个f(Integer.valueOf(i))的执行过程是这样的：
i通过valueOf方法包装成一个Integer对象。
由于没有f(Integer i)方法，编译器“聪明”地把Integer对象转换成int。
int自动拓宽为long，编译结束。
使用包装类型确实有方便的地方，但是也会引起一些不必要的困惑，比如我们这个例子，如果f()的两个重载方法使用的是基本类型，而且实参也是基本类型，就不会产生以上问题，而且程序的可读性更强。自动装箱（拆箱）虽然很方便，但引起的问题也非常严重—我们甚至都不知道执行的是哪个方法。
注意 重申，基本类型优先考虑。
建议30：不要随便设置随机种子
随机数在太多的地方使用了，比如加密、混淆数据等，我们使用随机数是期望获得一个唯一的、不可仿造的数字，以避免产生相同的业务数据造成混乱。在Java项目中通常是通过Math.random方法和Random类来获得随机数的，我们来看一段代码：
public class Client {
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 Client {
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次：-498702880 第2次：-858606152 第3次：1942818232
计算机不同输出的随机数也不同，但是有一点是相同的：在同一台机器上，甭管运行多少次，所打印的随机数都是相同的，也就是说第一次运行，会打印出这三个随机数，第二次运行还是打印出这三个随机数，只要是在同一台硬件机器上，就永远都会打印出相同的随机数，似乎随机数不随机了，问题何在？
那是因为产生随机数的种子被固定了，在Java中，随机数的产生取决于种子，随机数和种子之间的关系遵从以下两个规则：
种子不同，产生不同的随机数。
种子相同，即使实例不同也产生相同的随机数。
看完上面两个规则，我们再来看这个例子，会发现问题就出在有参构造上，Random类的默认种子（无参构造）是System.nanoTime()的返回值（JDK 1.5版本以前默认种子是System. currentTimeMillis()的返回值），注意这个值是距离某一个固定时间点的纳秒数，不同的操作系统和硬件有不同的固定时间点，也就是说不同的操作系统其纳秒值是不同的，而同一个操作系统纳秒值也会不同，随机数自然也就不同了。（顺便说下，System.nanoTime不能用于计算日期，那是因为“固定”的时间点是不确定的，纳秒值甚至可能是负值，这点与System. currentTimeMillis不同。）
new Random(1000)显式地设置了随机种子为1000，运行多次，虽然实例不同，但都会获得相同的三个随机数。所以，除非必要，否则不要设置随机种子。
顺便提一下，在Java中有两种方法可以获得不同的随机数：通过java.util.Random类获得随机数的原理和Math.random方法相同，Math.random()方法也是通过生成一个Random类的实例，然后委托nextDouble()方法的，两者是殊途同归，没有差别。
注意 若非必要，不要设置随机数种子。