盘点JDK方法中的那些“陷阱”，网友：这里面的坑我都踩过，囧~

点击关注下方公众号，Java面试资料 都在这里

正文如下：

JDK作为我们每天必备的调用类库，里面大量提供了基础类供我们使用.可以说离开jdk，我们的java代码寸步难行，jdk带给我们的便利可谓是不胜枚举，但同时这些方法在使用起来也存在一些坑，如果不注意就很容易掉入到陷阱里面，导致程序抛出错误。

jdk中的很多方法都不会做非null判断，可能设计jdk的作者默认开发者已经处理好null值了.不过这个设计可能会造成很严重的后果，实在是暗藏杀机。比如今天早上我们查了一笔订单没有退款，查了一早上最终才发现是同事写的代码的BigDecimal的subtract方法的值没有做非null判断处理导致程序抛出了空指针异常，看似简单的异常却直接无法让很多订单退款，是在是小问题造成大事故。而要修补退款这个问题，要耗费很多时间去修补，出错的成本太高。

本期我们就来看看jdk中那些坑你没商量的方法，这些方法很常见，相信你一定遇到过。

案发现场：某个鸟语花香的早上，我们在开心的敲着代码，突然客户群有人投诉反映，我们发给用户的短信有部分尊敬的"null"你好，xx等。开发第一时间看了代码，觉的没有问题啊，为什么短信内容会出现用户名为null呢，不是经过了非空判断的吗？String.valueOf()是String提供的一个类型转换的方法，我们来看一下(代码简化过后的):

// 调用用户服务根据用户id获取用户信息Map<String， Object> userInfo = userService.getUserInfoById(userId);Object userNameObject = userInfo.get("name");String userName = String.valueOf(userNameObject);// 判空if(userName!=null&&userName.length()>0) {String message = getMessage(userName); smsService.send(message);}

这段代码是简化过的，主要作用就是通过用户服务根据id获取用户信息发送短信，后来经过定位发现了问题所在:首先用户的名字里有特殊的emoji符号，数据库写入的时候有部分写入失败，因为当时的数据库字符格式并无法兼容emoji，而获取的时候因为这个问题值为null了，接下来是重点：

这里是重点，也是最大的坑人之处，注意这里返回了一个"null"的字符串，而不是null。这两个是有很大区别的，当进行非空判断的时候，返回的是ture。也就是这个"null"的字符串它是符合判空条件的！

正确的姿势是在String.valueOf方法前必须判空：

事故现场 

Integer.parseInt()方法用于将字符串转化为Integer类型的方法，此方法的适用方向就显得比较窄，因为是String类型的参数，没有任何限定，当在传入一些比如50.0、20L、30d、40f这类数据的情况下。

我们来看一个栗子:

会抛出异常NumberFormatException：

事实上对于这样的数据，比如小数、浮点数据、long型数据它都可以自动转换，而不是给我们抛出烦人的报错信息，如果预先知道是整数或者小数，可以用Bigdecimal转换(注意此方法不适用于double和float、Long类型的数据，比如10d，20L)

对于浮点类型、long类型的数据可以用以下方法来处理：推荐使用hutool的NumberUtil.parseInt()方法，充分考虑到了浮点、long、小数等类型数据可能带来的解析异常的问题，hutool是一个国人开源的工具类库，这里实名推荐，容错性和处理异常能力很强，可以自行百度搜索使用

3、Bigdecimal的除法坑你没商量

众所周知，BigDecimal是处理金额最有效的数据类型，一般进行财务报表计算的时候为了防止金额出现错误，一般情况下都会采用Bigdecimal，而double、float都会存在些许的误差。你开开心心的用Bigdecimal进行了计算，而最终的结果返回却有问题，我们来看一个栗子:

常见的除法用起来没有任何丝毫的问题，妥妥的没毛病.但是一旦程序中的数据出现以下情况，如果用Bigdecimal来接受前端的参数，而前端的参数是用户输入不确定的，一旦出现如下的数据，我们来看看结果:

执行结果一看，居然报错了哎：

这就是BidDecimal的坑，一旦返回的结果是无限循环小数，就会抛出ArithmeticException。因此在进行Bigdecimal除法的时候，需要进行保留小数的处理，正确的处理姿势：

4、Collections.emptyList()此list非彼list

我们先来看一个sample:

public List<String> getUserNameList(String userId) {

List<String> resultList = Collections.emptyList();try { resultList = userDao.getUserName(userId); } catch (Exception ex) { logger.info(ex); }return resultList;}

这样会抛出错误，主要问题在于Collections.emptyList()并非我们平时看到的List，此list不支持add、remove方法，否则会抛出operationNotSupportException:

结果抛出异常:

原因是:Collections.emptyList返回的并不是我们平时认识的那个list，它是一个内部常量类：

public static final List EMPTY_LIST = new EmptyList<>();

这个list并不具有add、remove元素的能力，我猜想是因为jdk设计之初的想法是将这个list作为一种只读的list，并不提供数据的写入能力，因此它仅可作为一种 空值返回，无法进行删除、添加操作。

答案是肯定可以的，要不然的话list怎么删除数据呢，不过要注意遍历的姿势，我们再来看一个简单的例子:

很不幸，又双叒叕报错了：

仔细翻阅源码会发现，每次remove之前会检查元素的条数，如果发现预期的modCount和当前的modCount不一致就会抛出这个异常.modCount是list中用来记录修改次数的一个属性，当对元素进行统计的时候就会对该元素加1，而当对list边遍历边删除的话，就会造成excepted与modCount不一致，从而抛出异常。

正确的删除姿势就是使用Iterator.remove进行遍历删除，可以规避这个问题。

List<Integer> list = new ArrayList<>();list.add(1);list.add(2);list.add(3);list.add(4);Iterator<Integer> iterator = list.iterator();while (iterator.hasNext()) { Integer integer = iterator.next();if (integer == 2) { iterator.remove(); }}

6、Bigdecimal在比较的时候，最好使用compareTo方法，不要使用equals方法

如下案例，虽然Bigdecimal重写了equals方法，但是使用会存在问题：

1和1.0在比较的时候返回了false，这是因为在equals的源码中进行了数据的scale(也就是精度)的比较，如果不一致就会返回false，如果使用compareTo方法就不存在这个问题。

7、mysql的减法计算如果有null值结果就为null

select 5-null 结果会返回null，所以在进行mysql计算的时候，对于有可能出现null值的列一定要进行ifnull(field，0)的转换，将null值转化为0，否则就会出现一些意想不到的数据错误和空指针问题

正确的姿势：

# 总结

jdk的设计者有两个很大的特点:

在实际开发中，面对jdk一定要谨慎使用，jdk提供了便利的同时，也有一些我们使用上的盲区，应该养成多看源码，多注意错误性处理，防止在小问题上栽大跟头。

回到最开始说的那个subtract方法的问题，因为这个问题等需要我处理完之后用户才能收到退款，这直接造成了用户体验直线下降，而部分用户还直接打电话投诉。同事一个小小的不谨慎和马虎就给公司造成了很多负面影响，技术问题虽然不大但是带来的业务影响范围很严重。所以我们必须防微杜渐，小小的问题都得细细的打磨，才能避免很多问题的产生。

热门推荐：