對我來說，做這些空檢查並改善此代碼的性能的更好方法是什么？

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{}塊。