优化 Java 中的多态代码

用户1257393

发布于 2018-07-30 15:18:11

9810

发布于 2018-07-30 15:18:11

来源：ImportNew - 进林

优化Java中的多态代码

Oracle的Java是一个门快速的语言，有时候它可以和C++一样快。编写Java代码时，我们通常使用接口、继承或者包装类（wrapper class）来实现多态，使软件更加灵活。不幸的是，多态会引入更多的调用，让Java的性能变得糟糕。部分问题是，Java不建议使用完全的内联代码，即使它是非常安全的。（这个问题可能会在最新的Java版本里得到缓解，请看文章后面的更新部分）

考虑下这种情况，我们要用接口抽象出一个整型数组：

public interface Array { public int get(int i); public void set(int i, int x); public int size(); }

你为什么要这样做？可能是因为你的数据是保存在数据库里、网络上、磁盘上或者在其他的数据结构里。你想一次编码后就不用关心数组的具体实现。

编写一个与标准Java数组一样高效率的类并不难，不同之处在于它实现了这个接口：

public final class NaiveArray implements Array {
    protected int[] array;
 
    public NaiveArray(int cap) {
        array = new int[cap];
    }
 
    public int get(int i) {
        return array[i];
    }
 
    public void set(int i, int x) {
        array[i] = x; 
    }
 
    public int size() {
        return array.length;
    }
}

至少在理论上，NaiveArray类不会出现任何的性能问题。这个类是final的，所有的方法都很简短。

不幸的是，在一个简单的benchmark类里，当使用NavieArray作为数组实例时，你会发现NavieArray比标准数组慢5倍以上。就像这个例子：

public int compute() {
   for(int k = 0; k < array.size(); ++k)
      array.set(k,k);
   int sum = 0;
   for(int k = 0; k < array.size(); ++k)
      sum += array.get(k);
   return sum;
}

你可以通过使用NavieArray作为NavieArray的一个实例来稍微减缓性能问题（避免使用多态）。不幸的是，它依然会慢3倍多。而你仅是放弃了多态的好处。

那么，强制使用内联函数调用会怎样?

一个可行的解决方法是手动实现内联函数。你可以使用 instanceof 关键字来提供优化实现，否则你只会得到一个普通（更慢）的实现。例如，如果你使用下面的代码，NavieArray就会变得和标准数组一样快：

public int compute() {
     if(array instanceof NaiveArray) {
        int[] back = ((NaiveArray) array).array;
        for(int k = 0; k < back.length; ++k)
           back[k] = k;
        int sum = 0;
        for(int k = 0; k < back.length; ++k)
           sum += back[k];
        return sum;
     }
     //...
}

当然，我也会介绍一个维护问题作为需要实现不止一次的同类算法…… 当出现性能问题时，这是一个可接受的替代。

和往常一样，我的benchmarking代码可以在网上获取到。

总结

一些Java版本可能不完全支持频繁的内联函数调用，即使它可以并且应该支持。这会造成严重的性能问题。
把类声明为 final 看起来不会缓解性能问题。
对于消耗大的函数，可行的解决方法是自己手动优化多态和实现内联函数调用。使用 instanceof 关键字，你可以为一些特定的类编写代码并且（因此）保留多态的灵活性。

更新

Erich Schubert使用 double 数组运行简单的benchmark类发现他的运行结果与我的结果相矛盾，而且我们的变量实现都是一样的。我通过更新到最新版本的OpenJDK证明了他的结果。下面的表格给出了处理10百万整数需要的纳秒时间：