Java 中最多见的 5 个错误

在编程时，开发者常常会遭遇各式各样莫名错误。近日，Sushil Das 在 Geek On Java上列举了 Java 开发中常见的 5 个错误，与君共「免」。

原文连接：Top 5 Common Mistake in Java

如下为译文：

1. Null 的过分使用

避免过分使用 null 值是一个最佳实践。例如，更好的作法是让方法返回空的 array 或者 collection 而不是 null 值，由于这样能够防止程序抛出 NullPointerException。下面代码片断会从另外一个方法得到一个集合：

</>
List<String> accountIds = person.getAccountIds();
for (String accountId : accountIds) {
    processAccount(accountId);
}

当一个 person 没有 account 的时候，getAccountIds() 将返回 null 值，程序就会抛出 NullPointerException 异常。所以须要加入空检查来解决这个问题。若是将返回的 null 值替换成一个空的 list，那么 NullPointerException 也不会出现。并且，由于咱们再也不须要对变量 accountId 作空检查，代码将变得更加简洁。

当你想避免 null 值的时候，不一样场景可能采起不一样作法。其中一个方法就是使用 Optional 类型，它既能够是一个空对象，也能够是一些值的封装。

</>
Optional<String> optionalString = Optional.ofNullable(nullableString);
if(optionalString.isPresent()) {
    System.out.println(optionalString.get());
}

事实上，Java8 提供了一个更简洁的方法：

</>
Optional<String> optionalString = Optional.ofNullable(nullableString);
optionalString.ifPresent(System.out::println);

Java 是从 Java8 版本开始支持 Optional 类型，可是它在函数式编程世界早已广为人知。在此以前，它已经在 Google Guava 中针对 Java 的早期版本被使用。

2. 忽视异常

咱们常常对异常置之不理。然而，针对初学者和有经验的 Java 程序员，最佳实践还是处理它们。异常抛出一般是带有目的性的，所以在大多数状况下须要记录引发异常的事件。别小看这件事，若是必要的话，你能够从新抛出它，在一个对话框中将错误信息展现给用户或者将错误信息记录在日志中。至少，为了让其它开发者知晓来龙去脉，你应该解释为何没有处理这个异常。

</>
selfie = person.shootASelfie();
try {
    selfie.show();
} catch (NullPointerException e) {
    // Maybe, invisible man. Who cares, anyway?
}

强调某个异常不重要的一个简便途径就是将此信息做为异常的变量名，像这样：

</>
try { selfie.delete(); } catch (NullPointerException unimportant) {  }

3. 并发修改异常

这种异常发生在集合对象被修改，同时又没有使用 iterator 对象提供的方法去更新集合中的内容。例如，这里有一个 hats 列表，并想删除其中全部含 ear flaps 的值：

</>
List<IHat> hats = new ArrayList<>();
hats.add(new Ushanka()); // that one has ear flaps
hats.add(new Fedora());
hats.add(new Sombrero());
for (IHat hat : hats) {
    if (hat.hasEarFlaps()) {
        hats.remove(hat);
    }
}

若是运行此代码，ConcurrentModificationException 将会被抛出，由于代码在遍历这个集合的同时对其进行修改。当多个进程做用于同一列表，在其中一个进程遍历列表时，另外一个进程试图修改列表内容，一样的异常也可能会出现。

在多线程中并发修改集合内容是很是常见的，所以须要使用并发编程中经常使用的方法进行处理，例如同步锁、对于并发修改采用特殊的集合等等。Java 在单线程和多线程状况下解决这个问题有微小的差异。

收集对象并在另外一个循环中删除它们

直接的解决方案是将带有 ear flaps 的 hats 放进一个 list，以后用另外一个循环删除它。不过这须要一个额外的集合来存放将要被删除的 hats。

</>
List<IHat> hatsToRemove = new LinkedList<>();
for (IHat hat : hats) {
    if (hat.hasEarFlaps()) {
        hatsToRemove.add(hat);
    }
}
for (IHat hat : hatsToRemove) {
    hats.remove(hat);
}

使用 Iterator.remove 方法

这个方法更简单，同时并不须要建立额外的集合：

</>
Iterator<IHat> hatIterator = hats.iterator();
while (hatIterator.hasNext()) {
    IHat hat = hatIterator.next();
    if (hat.hasEarFlaps()) {
        hatIterator.remove();
    }
}

使用 ListIterator 的方法

当须要修改的集合实现了 List 接口时，list iterator 是很是合适的选择。实现 ListIterator 接口的 iterator 不只支持删除操做，还支持 add 和 set 操做。ListIterator 接口实现了 Iterator 接口，所以这个例子看起来和 Iterator 的 remove 方法很像。惟一的区别是 hat iterator 的类型和咱们得到 iterator 的方式——使用 listIterator() 方法。下面的片断展现了如何使用 ListIterator.remove 和 ListIterator.add 方法将带有 ear flaps 的 hat 替换成带有sombreros 的。

</>
IHat sombrero = new Sombrero();
ListIterator<IHat> hatIterator = hats.listIterator();
while (hatIterator.hasNext()) {
    IHat hat = hatIterator.next();
    if (hat.hasEarFlaps()) {
        hatIterator.remove();
        hatIterator.add(sombrero);
    }
}

使用 ListIterator，调用 remove 和 add 方法可替换为只调用一个 set 方法：

</>
IHat sombrero = new Sombrero();
ListIterator<IHat> hatIterator = hats.listIterator();
while (hatIterator.hasNext()) {
    IHat hat = hatIterator.next();
    if (hat.hasEarFlaps()) {
        hatIterator.set(sombrero); // set instead of remove and add
    }
}

使用Java 8中的 stream 方法

在 Java8 中，开发人员能够将一个 collection 转换为 stream，而且根据一些条件过滤 stream。这个例子讲述了 stream api 是如何过滤 hats 和避免 ConcurrentModificationException。
hats = hats.stream().filter((hat -> !hat.hasEarFlaps()))

</>
 .collect(Collectors.toCollection(ArrayList::new));

Collectors.toCollection 方法将会建立一个新的 ArrayList，它负责存放被过滤掉的 hats 值。若是过滤条件过滤掉了大量条目，这里将会产生一个很大的 ArrayList。所以，须要谨慎使用。

使用 Java 8 中的 List.removeIf 方法

可使用 Java 8 中另外一个更简洁明了的方法—— removeIf 方法:

</>
hats.removeIf(IHat::hasEarFlaps);

在底层，它使用 Iterator.remove 来完成这个操做。

使用特殊的集合

若是在一开始就决定使用 CopyOnWriteArrayList 而不是 ArrayList，那就不会出现问题。由于 CopyOnWriteArrayList 提供了修改的方法（例如 set，add，remove），它不会去改变原始集合数组，而是建立了一个新的修改版本。这就容许遍历原来版本集合的同时进行修改，从而不会抛出 ConcurrentModificationException 异常。这种集合的缺点也很是明显——针对每次修改都产生一个新的集合。

还有其余适用于不一样场景的集合，好比 CopyOnWriteSet 和 ConcurrentHashMap。

关于另外一个可能可能在并发修改集合时产生的错误是，从一个 collection 建立了一个 stream，在遍历 stream 的时候，同时修改后端的 collection。针对 stream 的通常准则是，在查询 stream 的时候，避免修改后端的 collection。接下来的例子将展现如何正确地处理 stream：

</>
List<IHat> filteredHats = hats.stream().peek(hat -> {
    if (hat.hasEarFlaps()) {
        hats.remove(hat);
    }
}).collect(Collectors.toCollection(ArrayList::new));

peek 方法收集全部的元素，并对每个元素执行既定动做。在这里，动做即为尝试从一个基础列表中删除数据，这显然是错误的。为避免这样的操做，能够尝试一些上面讲解的方法。

4. 违约

有时候，为了更好地协做，由标准库或者第三方提供的代码必须遵照共同的依赖准则。例如，必须遵照 hashCode 和 equals 的共同约定，从而保证 Java 集合框架中的一系列集合类和其它使用 hashCode 和 equals 方法的类可以正常工做。不遵照约定并不会产生 exception 或者破坏代码编译之类的错误；它很阴险，由于它随时可能在毫无危险提示的状况下更改应用程序行为。

错误代码可能潜入生产环境，从而形成一大堆不良影响。这包括较差的 UI 体验、错误的数据报告、较差的应用性能、数据丢失或者更多。庆幸的是，这些灾难性的错误不会常常发生。在以前已经说起了 hashCode 和equals 约定，它出现的场景多是：集合依赖于将对象进行哈希或者比较，就像 HashMap 和 HashSet。简单来讲，这个约定有两个准则：

• 若是两个对象相等，那么 hash code 必须相等。
• 若是两个对象有相同的 hash code，那么它们可能相等也可能不相等。

破坏约定的第一条准则，当你试图从一个 hashmap 中检索数据的时候将会致使错误。第二个准则意味着拥有相同 hash code 的对象不必定相等。

下面看一下破坏第一条准则的后果：

</>
public static class Boat {
    private String name;

    Boat(String name) {
        this.name = name;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        Boat boat = (Boat) o;

        return !(name != null ? !name.equals(boat.name) : boat.name != null);
    }

    @Override
    public int hashCode() {
        return (int) (Math.random() * 5000);
    }
}

正如你所见，Boat 类重写了 equals 和 hashCode 方法。然而，它破坏了约定，由于 hashCode 针对每次调用的相同对象返回了随机值。下面的代码极可能在 hashset 中找不到一个名为 Enterprise 的boat，尽管事实上咱们提早加入了这种类型的 boat：

</>
public static void main(String[] args) {
    Set<Boat> boats = new HashSet<>();
    boats.add(new Boat("Enterprise"));

    System.out.printf("We have a boat named 'Enterprise' : %b\n", boats.contains(new Boat("Enterprise")));
}

另外一个约定的例子是 finalize 方法。这里是官方 Java 文档关于它功能描述的引用：

finalize 的常规约定是：当 JavaTM 虚拟机肯定任何线程都没法再经过任何方式访问指定对象时，这个方法会被调用，此后这个对象只能在某个其余（准备终止的）对象或类终结时被做为某个行为的结果。finalize 方法有多个功能，其中包括再次使此对象对其余线程可用；不过 finalize 的主要目的是在不可撤消地丢弃对象以前执行清除操做。例如，表示输入/输出链接对象的 finalize 方法可执行显式 I/O 事务，以便在永久丢弃对象以前中断链接。

你能够决定在诸如文件处理器中使用 finalize 方法来释放资源，可是这种用法是很糟糕的。因为它是在垃圾回收期间被调用的，而 GC 的时间并不肯定，所以 finalize 被调用的时间将没法保证。

5. 使用原始类型而不是参数化的

根据 Java 文档描述：原始类型要么是非参数化的，要么是类 R 的（同时也是非继承 R 父类或者父接口的）非静态成员。在 Java 泛型被引入以前，并无原始类型的替代类型。Java 从1.5版本开始支持泛型编程，毫无疑问这是一个重要的功能提高。然而，因为向后兼容的缘由，这里存在一个陷阱可能会破坏整个类型系统。着眼下例：

</>
List listOfNumbers = new ArrayList();
listOfNumbers.add(10);
listOfNumbers.add("Twenty");
listOfNumbers.forEach(n -> System.out.println((int) n * 2));

这是一个由数字组成的列表被定义为原始的 ArrayList。因为它并无指定类型参数，所以能够给它添加任何对象。可是最后一行将其包含的元素映射为 int 类型并乘以 2，打印出翻倍以后的数据到标准输出。

此代码编译时不会出错，可是一旦运行就会抛出运行时错误，由于这里试图将字符类型映射为整形。很显然，若是隐藏了必要信息，类型系统将不能帮助写出安全代码。

为了解决这个问题，须要为存入集合中的对象指定具体类型：

</>
List<Integer> listOfNumbers = new ArrayList<>();

listOfNumbers.add(10);
listOfNumbers.add("Twenty");

listOfNumbers.forEach(n -> System.out.println((int) n * 2));

与以前代码的惟一差异便是定义集合的那一行：

</>
List<Integer> listOfNumbers = new ArrayList<>();

修改以后的代码编译不可能被经过，由于这里试图向只指望存储整形的集合中添加字符串。编译器将会显示错误信息，并指向试图向列表中添加 Twenty 字符的那一行。参数化泛型类型是个不错的主意。这样的话，编译器就可以检查全部可能的类型，从而因为类型不一致而致使的运行时异常概率将大大下降。

本文系 OneAPM 工程师编译整理。想阅读更多技术文章，请访问 OneAPM 官方博客。