对我来说，做这些空检查并改善此代码的性能的更好方法是什么？

Question

这项工作正在谈论30多个小时的时间。 该迭代器可容纳80万条记录，并且循环必须为每条记录执行，并且在同一方法中大约有20多个这些检查。 在这里如何避免圈复杂度？

CustomerPreference newRecord = null;

while (iterator.hasNext())
              {

final CustomerPreference current = iterator.next();

                     if (newRecord != null)
                     {
                           if (!newRecord.getEmail().equals(current.getEmail()))
                           {
                                  resList.add(newRecord);
                                  newRecord = current;
                           }
                     }
                     else
                     {
                           newRecord = current;
                     }

                     if (null != current.getEmailPref())
                     {
                           newRecord.setEmailPref(current.getHdCaEmailPref());
                     }

              else
                     {
                           if (newRecord.getEmailPref() == null)
                           {
                             newRecord.setEmailPref(NO_CHANGE);
                           }
                     }

Answer 1

如果这只是一个内部应用程序，请进行检查并将代码包含在try / catch块中，尤其是在空引用的可能性很小的情况下。

catch块将继续循环。

Answer 2

空检查最多可能需要一个CPU周期，为了保守起见，我们将其称为1ns。 800k x 20 x 1 ns = 16毫秒...

=>空检查不是您的问题！

Answer 3

其他方法：检查时间！

使用监视器，例如JVM监视器： http : //www.jvmmonitor.org/

将其安装在Eclipse中，您可以验证真正花费时间的内容...

Answer 4

我怀疑真正的性能问题不在显示的代码范围内。 即使字符串比较花费一微秒的时间，并且循环的迭代包含数百个微秒，一次迭代的时间也不应超过一毫秒。 这将导致大约10到15分钟的运行时间。

Answer 5

这些检查可能不是性能下降的原因。 但是您可以通过遵循良好的编码约定来避免可能的逻辑错误。

我遵循以下约定。

1. 尽可能避免成员变量的lazy initialization 。 在声明本身中初始化变量。 这将处理NullPointerExceptions。

2. 在周期的早期确定成员变量的mutability 。 有效地使用诸如final关键字之类的语言结构。

3. 如果您知道方法的扩充不会更改，请将其声明为final 。

4. 尽可能限制数据的mutation 。 某些变量可以在构造函数中创建，并且永远不能更改。 如果可能，请删除公共设置方法。

5. 最后，在正确的位置有效地使用try{} catch{} finally{}块。