• 编写高质量代码:改善Java程序的151个建议(第二章:基本类型)


    编写高质量代码:改善Java程序的151个建议(第二章:基本类型)

    目录

    建议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("
    =====" + 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()方法的,两者殊途同归,没有差别。

  • 相关阅读:
    精通特征工程
    reduce_mem_usage 降低内存使用 绘制学习率曲线和验证曲线
    正态性检验 Python正态性检验
    pd.melt Pandas 的melt的使用
    pandas dataframe 格式设置 set_option
    常用模块
    第9章 列表生成式、生成器和迭代器
    全栈作业(一)
    第8章 装饰器、模块和包
    第7章 Python 函数
  • 原文地址:https://www.cnblogs.com/yy1024/p/5910626.html
Copyright © 2020-2023  润新知