Java 基本数据类型与其包装类的性能

我试图测量原始数据类型及其包装类的执行时间，以计算相同的数量。我发现包装类比原始数据类型花费更多的时间

在下面的代码中，原语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);

  }
}

---

由于包装器类Integer的对象创建或其他原因，是否存在性能差异？

您在这里遇到了一些基本问题

首先，编写一个好的微基准远远超出了您在代码中所做的工作；有关一些指导原则，请参阅

然后：你必须理解你想要基准测试的东西。很抱歉，你显然没有。就像这里：

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

整数对象是不可变的。这段代码不仅添加整数对象，而且在每次迭代中创建一个新的整数对象

当然，您的代码甚至不使用计算结果。如果JVM/JIT注意到了这一点，它可能会完全抛弃循环和添加构造。因此，您的方法至少应该返回count的最终值；调用方应该打印该结果

为了回答您的具体问题：当然，使用引用类型包装器类要付出一定的代价。当您的程序要处理的元素数量非常多时，使用整数列表的成本确实比使用int数组的成本要高得多。如果您不注意，并且在代码中执行隐式的自动装箱/取消装箱，那么这种情况确实会发生

但真正的答案是：你把注意力放在了错误的事情上。你看，你的首要任务应该是做一个伟大的设计，然后是一个经过良好测试的、健壮的、可读的、可维护的实现。当然，您不应该做完全愚蠢的事情，浪费性能，但是，在您担心性能之前，您最好先考虑一下您的Java技能

---

长话短说：专注于理解java和如何创建一个好的设计；现在就忘了表演吧。只有当性能在应用程序中是一个真正的问题时，您才需要处理它。然后，您需要进行真正的分析，以确定根本原因并加以解决。

您在这里遇到了一些根本性问题

首先，编写一个好的微基准远远超出了您在代码中所做的工作；有关一些指导原则，请参阅

然后：你必须理解你想要基准测试的东西。很抱歉，你显然没有。就像这里：

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

整数对象是不可变的。这段代码不仅添加整数对象，而且在每次迭代中创建一个新的整数对象

当然，您的代码甚至不使用计算结果。如果JVM/JIT注意到了这一点，它可能会完全抛弃循环和添加构造。因此，您的方法至少应该返回count的最终值；调用方应该打印该结果

为了回答您的具体问题：当然，使用引用类型包装器类要付出一定的代价。当您的程序要处理的元素数量非常多时，使用整数列表的成本确实比使用int数组的成本要高得多。如果您不注意，并且在代码中执行隐式的自动装箱/取消装箱，那么这种情况确实会发生

但真正的答案是：你把注意力放在了错误的事情上。你看，你的首要任务应该是做一个伟大的设计，然后是一个经过良好测试的、健壮的、可读的、可维护的实现。当然，您不应该做完全愚蠢的事情，浪费性能，但是，在您担心性能之前，您最好先考虑一下您的Java技能

---

长话短说：专注于理解java和如何创建一个好的设计；现在就忘了表演吧。只有当性能在应用程序中是一个真正的问题时，您才需要处理它。然后进行真正的分析，以确定根本原因并解决问题。

尝试使用强制转换/自动装箱，而不是自己创建包装。整数缓存在字节范围内。不管怎样，你的微基准测试方法与精确的结果JVM预热、更多的运行、Nano vs MILIS、ETCU也可以尝试翻转处理顺序，以便在原语之前尝试你的包装，看看你是否看到同样的东西。不过，我同意Rogue的观点——您正在进行的微基准测试存在一些问题。如果你想更详细地了解原因，请看一看。你可能想更新一个问题，询问你为什么关心。你可能会得到更好的答案。@Snekse先生，非常感谢。当我在原语之前翻转包装器的处理顺序时。我也得到了同样的结果，你可以测量“count”的输出时间。您应该将System.out移到“停止时间”后面。IO操作可能会影响结果。请尝试使用强制转换/自动装箱，而不是自己创建包装。在里面

---

teger缓存在字节范围内。不管怎样，你的微基准测试方法与精确的结果JVM预热、更多的运行、Nano vs MILIS、ETCU也可以尝试翻转处理顺序，以便在原语之前尝试你的包装，看看你是否看到同样的东西。不过，我同意Rogue的观点——您正在进行的微基准测试存在一些问题。如果你想更详细地了解原因，请看一看。你可能想更新一个问题，询问你为什么关心。你可能会得到更好的答案。@Snekse先生，非常感谢。当我在原语之前翻转包装器的处理顺序时。我也得到了同样的结果，你可以测量“count”的输出时间。您应该将System.out移到“停止时间”后面。IO操作可能会显著影响结果。