基本數據類型的性能與其包裝器類的關系

Question

我試圖測量原始數據類型及其包裝器類的執行時間，以計算相同的數量。 我知道包裝器類比原始數據類型花費更多的時間。

在我的以下代碼中，原始t1的執行時間為5，包裝類t2的執行時間為31。

import java.io.*;
import java.util.*;
public class Performance
{
  public static long primitive(int count)
     {
   long startTime = System.currentTimeMillis();
   for(int i=0;i<10000;i++)
     count++;
    System.out.println(count);
   long stopTime = System.currentTimeMillis();
   long elapsedTime = stopTime - startTime;
   return elapsedTime;
}
  public static long wrapper(Integer count)
{
    long startTime = System.currentTimeMillis();
    for(int i=0;i<10000;i++)
      count++;
      System.out.println(count);
    long stopTime = System.currentTimeMillis();
    long elapsedTime = stopTime - startTime;
    return elapsedTime;
 }

  public static void main(String args[])
  {

   Integer c = new Integer(0);
   long t2=Performance.wrapper(c);
    int count=0;
   long t1=Performance.primitive(count);
  System.out.println("t1="+t1+"t2="+t2);

  }
}

是否由於Wrapper類（整數）的對象創建或其他原因而導致性能差異？

Answer 1

您在這里得到的是必不可少的東西，實際上是錯誤的。

首先，編寫好的微基准測試遠遠超出了代碼中的工作范圍。 請參閱此處以獲取一些指導。

然后：您必須了解要進行基准測試的內容。 抱歉，您顯然沒有。 像這兒：

public static long wrapper(Integer count)
{
  long startTime = System.currentTimeMillis();
  for(int i=0;i<10000;i++)
    count++

整數對象是不可變的 。 此代碼不僅“添加” Integer對象，而且還在每次迭代中創建一個新的Integer對象。

當然：您的代碼甚至不使用計算結果。 如果JVM / JIT注意到這一點，它可能會完全放棄該循環並添加構造。 因此，您的方法至少應返回count的最終值； 呼叫者應打印該結果。

並回答您的特定問題：當然，使用引用類型包裝器類需要付出一定的代價。 當您的程序要處理（確實）要處理的大量元素時，例如，使用整數列表確實比使用整數數組要高得多。 而且，當您不注意並且在代碼中執行隱式自動裝箱/拆箱操作時，這確實很有害 。

但真正的答案是：您專注於錯誤的事情。 您會看到，您的首要任務應該是進行出色的設計 ，然后進行經過良好測試的，健壯的，可讀的，可維護的實現。 當然，你不應該做徹底的蠢事，浪費的表現，但好了， 你不用擔心性能，對一般的Java技能，你更好的擔心了。

長話短說：專注於理解Java和“如何創建好的設計”； 暫時不要考慮“性能”。 當“性能”在您的應用程序中是一個真正的問題時，您只需要處理它即可。 然后進行真正的性能分析，以找出根本原因並加以解決。